Bug? FR? Don't reset player wing arrival data on FRED save

[Durandal-Thoth]

Player wing arrival data always resets to true on save with FRED. 99.99% of the time, this is not a problem.

However, I have a use case where it absolutely is.

Can we get a game settings flag or something to disable this behavior, or turn it off entirely and just have FRED throw a warning about a possibly bad arrival cue for the player's wing?

I promise I'm not insane.

[Goober5000]

The player wing arrival cue needs to be true because the wing always needs to be present at mission start. This really isn't something that can be changed, flag or not.

What is the use case?

[Durandal-Thoth]

It doesn't need to be a literal true boolean, though - it only needs to return true. As long as your arrival cue is true on mission init, it functions. I need the player wing to have an arrival cue (in this case, a variable) to control when a second wave arrives.

This could be also be solved by implementing a sexp to alter arrival cues, but simply not having FRED reset the data would be far simpler to implement.

I do not want to have to worry about having to save this one file in notepad every time I push an update.

[MjnMixael]

This seems like an incredibly reasonable request. The further we get from 1999 the more we need to allow our mission designers to try new things. More importantly it's objectively bad design for FRED to silently undo things a designer has done with intention. Either a warning must be present or the feature must be allowed. Else it feels and acts like a bug. And if anyone's gonna go in and add a warning, might as well allow this highly specific use-case.

[Baezon]

It sounds like a footgun, more than anything. That doesn't necessarily mean it shouldn't be done, it seems like it should be ok to error if it isn't true on initialization, or simply ignore the value for the player's wing for their first spawn at mission start. But it is liable to really confuse users if they don't know exactly what they're doing with it. It would be easy to presume it is a good way to delay the player's start in the mission until a certain point in the simulation, for instance. And I don't know how easy it would be to implement, either.

[Durandal-Thoth]

It sounds like a footgun, more than anything. That doesn't necessarily mean it shouldn't be done, it seems like it should be ok to error if it isn't true on initialization, or simply ignore the value for the player's wing for their first spawn at mission start. But it is liable to really confuse users if they don't know exactly what they're doing with it. It would be easy to presume it is a good way to delay the player's start in the mission until a certain point in the simulation, for instance. And I don't know how easy it would be to implement, either.

I want to stress that there's no reason to expose these values to editing in FRED. They can remain grayed out there and only editable via raw text, which I think solves 95% of footgun cases before they occur.

[Baezon]

It's not ideal to force users to manually write sexps, but yes that would certainly obviate most concerns about it being used accidentally by 'non-advanced users'.

[Durandal-Thoth]

I want to add some notes here that weren't necessarily clear in the OP:

• Non-standard player arrival cues already work in FSO. I am not requesting an engine change.
• I am not requesting that player arrival cue be exposed to FRED edit, only that FRED not overwrite manual notepad edit.

[naomimyselfandi]

Since the use case involves wings with multiple waves, there's an obvious opt-in that avoids footgun cases: allow the player's wing's arrival cue to be edited iff it has multiple waves, and reset it if the wave count is changed to 1. During gameplay, if the player's wing's arrival cue isn't true on the first frame, issue an error (forcibly spawning the wing adds unnecessary complication, imo).