Author Topic: Persistent variables  (Read 92 times)

0 Members and 1 Guest are viewing this topic.

Offline AdmiralRalwood

  • 211
  • Posts: 3,122
  • Mister Subspace Strikes
    • Skype
    • Steam
    • Twitter
Persistent variables
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?
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline karajorma

  • King Louie - Jungle VIP
  • Administrator
  • 214
  • Posts: 29,432
    • Karajorma's Freespace FAQ
Re: Persistent variables
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.
Karajorma's Freespace FAQ. It's almost like asking me yourself.

[ Diaspora ] - [ Seeds Of Rebellion ] - [ Mind Games ]