Modding, Mission Design, and Coding > FS2 Open Coding - The Source Code Project (SCP)
Persistent variables
AdmiralRalwood:
As a result of another thread, I became aware that player-persistent variables have been broken since Antipodes 8 (the pilot code overhaul that was the major new feature in FSO 3.7.0). Namely, they're actually player-persistent now, instead of resetting when the campaign does.
"Wait, what?" you might ask. "Player-persistent variables being player-persistent is a bug?"
Yes. Yes it is.
When player-persistent variables were first introduced (all the way back in 2003), it wasn't really possible to play more than one campaign simultaneously. Whenever you changed campaigns, PPVs would be explicitly reset. This reset was removed at the start of Antipodes 8 back in 2010, but without any attempt made to keep the old behavior in some way. Presumably simply never resetting PPVs was considered preferable to them resetting if you just switched to a different campaign and then switched back, but the proper solution would have been to move them to the .csg file instead of leaving them in their current state.
Alas, they were left in their current state, and have been so for years (3.7.0 Final was released in August of 2013).
No documentation appears to have been updated to account for the code change; the wiki still claims player-persistent variables get reset with the campaign. Why haven't I corrected the wiki? Well, because the way the wiki describes it is definitely how it's supposed to work, and how FREDers have been using them since they were introduced. The difference that's supposed to be between the two variable types is when they're saved: CPVs are saved at the end of the mission (assuming you accept the outcome), while PPVs are updated as they change (so restarting a mission after it sets a PPV will leave the PPV set to the new value).
Now, I'm currently thinking that the correct fix here is to move so-called "player-persistent variables" into the campaign savefile, even though that would require bumping the pilotfile version to accommodate this change, because as they're intended to be used, they're definitely still supposed to be tied to an individual campaign.
On the other hand, I'm sure designers would like variables that could be accessed between campaigns, so at least one new type of variable needs to be added with that functionality (the current, actually-wrong behavior of player-persistent variables). However, renaming PPVs and then making a new type of variable and calling them PPVs is just asking for somebody to get confused and pick the wrong one. So ideally, we need all new names for every kind of persistent variable so that there's no confusion about what they actually do and what they should actually be used for.
Karajorma suggested that 4 types of variables are needed, with the two axes being campaign-/player-specific and saved-on-accept/saved-on-change. Thinking about it as I write this post, perhaps there might even be a way to incorporate wookieejedi's request for a kind of variable that is persistent even through techroom runs; 8 kinds of variables?
Regardless, here's my initial suggestion for the new naming scheme:
* "Campaign-persistent variables" would become "Progression variables" (tied to the campaign, saved when accepting the mission outcome).
* "Player-persistent variables" (the way they're supposed to work) would become "Persistent variables" (not fond of this name, but it was the first thing that came to mind; if you have a better idea, please suggest it) (tied to the campaign, saved whenever the value changes)
* "'True' player-persistent variables" (the incorrect way they currently work) would be "Eternal variables" (Karajorma's idea, but it makes sense to me) (tied to the player, saved whenever the value changes)
* No idea what to call player-specific variables saved on accepting mission outcome; please suggest something.
If "techroom-usable" variables were a separate type (rather than a flag that could be set for one of the other kinds of variables, for example), I have no idea what they'd be called.
Thoughts? Comments? Completely-off-the-wall ideas? Anyone? Bueller?
karajorma:
Given that the only difference between PPVs and CPVs as designed is whether or not they reset on a failed mission it strikes me that a better option is to leave things at only two types of persistent variables but then have a flag decide whether to write it to the player or campaign file. An advantage of this approach is that if someone thinks of another type of persistent variable we wouldn't need to come up with two new names for the player and campaign file versions.
Another major advantage of that would be that it would safely define a system for removing variables from the player file. If you had something like this
Mission 1 - Variable is Progressive and Eternal
Mission 2 - Variable is Progressive and Eternal
Mission 3 - Variable is Progressive
In mission 1 and 2 the value of the variable is written to the player file when the mission is successfully completed. But in Mission 3 the game detects that the Eternal flag has been switched off so the value would be written to the campaign file and the variable in the player file would be deleted on mission completion.
0rph3u5:
Question:
Can this be paired with a convinence function to import variables form one mission to another in FRED?
xenocartographer:
Going off karajorma's suggestion here... I think we could use a system of flags like this:
Persistent: Must be set for the variable to be persisted at all; without this, only the shadow flag has meaning.
Persist regardless of outcome: Writes the variable even if the mission was a failure.
Visible between campaigns: Whether to write the variable to the pilot file (true) or campaign file (false).
Visible in simulator: Whether the tech room simulator can see the value of this variable.
Persist from simulator: Whether the simulator can modify this variable. Must be set along with the previous flag.
Allow shadowing: If not set, the game issues a warning if this variable has the same name, but different flags or type, as another variable in the same campaign.
All flags are false by default.
The E:
--- Quote from: xenocartographer on May 13, 2017, 07:02:42 am ---Allow shadowing: If not set, the game issues a warning if this variable has the same name, but different flags or type, as another variable in the same campaign.
--- End quote ---
This makes little sense to me. Allowing variables to be shadowed leads to complications that are best avoided entirely.
Navigation
[0] Message Index
[#] Next page
Go to full version