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?