Author Topic: Player Persistent Variables in Techroom Missions?  (Read 980 times)

0 Members and 1 Guest are viewing this topic.

Offline wookieejedi

  • 27
  • Intensify Forward Firepower
Player Persistent Variables in Techroom Missions?
I am working on coding a semi-complex mission that requires player persistent variables. The question I have is not how to use them, but rather the following:

Do player persistent variables save and load correctly when playing/testing missions from the Techroom? I have a player persistent variable that is used in a mission briefing, but despite the fact that it changes in the mission, it never changes in the briefing screen. I have a message that displays the variable in-mission to show that in fact the variable had been changed successfully, but when I warp out and end the mission then go back to the Techroom to play it again, the briefing still displays the default value for the variable and not the proper updated value.

Is this simply an issue with testing missions with Techroom play-throughs, or is this actually a bug?

Any help or comments about this issue would be greatly appreciated. Thanks!
Team Member for FotG

 

Offline Axem

  • Administrator
  • 211
Re: Player Persistent Variables in Techroom Missions?
Player persistent is just persistent to the player playing inside the campaign. Outside of a campaign, it will use the default value you've given it. So to test certain player persistent variable values, you would have to change it in FRED before playing it.

 

Offline wookieejedi

  • 27
  • Intensify Forward Firepower
Re: Player Persistent Variables in Techroom Missions?
Player persistent is just persistent to the player playing inside the campaign. Outside of a campaign, it will use the default value you've given it. So to test certain player persistent variable values, you would have to change it in FRED before playing it.

Got it. Thanks for the quick reply (from the master himself!), it saved me quite a but of time!
Team Member for FotG

 

Offline AdmiralRalwood

  • 211
  • Mister Subspace Strikes
    • Skype
    • Steam
    • Twitter
Re: Player Persistent Variables in Techroom Missions?
The fact that player- and campaign-persistent variables have their default values when the mission is run through the techroom is used by some missions to detect that they're being run through the techroom and e.g. display a special menu.
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.

 
Re: Player Persistent Variables in Techroom Missions?
Actually, I wonder whether the capability of reading a variable value from a file (like .txt) would be useful.

Like for carrying some of them between campaigns.
Excuse me for any spelling errors I make - I'm still learning English :P

 

Offline karajorma

  • King Louie - Jungle VIP
  • Administrator
  • 214
    • Karajorma's Freespace FAQ
Re: Player Persistent Variables in Techroom Missions?
Taylor was interested in adding that kind of variable a while back.
Karajorma's Freespace FAQ. It's almost like asking me yourself.

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

 

Offline wookieejedi

  • 27
  • Intensify Forward Firepower
Re: Player Persistent Variables in Techroom Missions?
Would it be possible to make a script simply change the default value of the variable to whatever the mission sets it as? For example, if the default value is 0, but during the mission it sets it as 1, could a script then change the default value to 1 so when the mission reloads the value is now 1?
Team Member for FotG

 

Offline AdmiralRalwood

  • 211
  • Mister Subspace Strikes
    • Skype
    • Steam
    • Twitter
Re: Player Persistent Variables in Techroom Missions?
Actually, I wonder whether the capability of reading a variable value from a file (like .txt) would be useful.

Like for carrying some of them between campaigns.
...You mean like a player-persistent variable?
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 wookieejedi

  • 27
  • Intensify Forward Firepower
Re: Player Persistent Variables in Techroom Missions?
Actually, I wonder whether the capability of reading a variable value from a file (like .txt) would be useful.

Like for carrying some of them between campaigns.
...You mean like a player-persistent variable?

Yes, but one that can be changed with play throughs in Techroom missions and between campaigns, not just within one campaign. So would this be possible with a simple-sih script?
Team Member for FotG

 

Offline AdmiralRalwood

  • 211
  • Mister Subspace Strikes
    • Skype
    • Steam
    • Twitter
Re: Player Persistent Variables in Techroom Missions?
between campaigns, not just within one campaign
That's player-persistent variables. If the variable is just supposed to be within one campaign, that's a campaign-specific variable.
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 wookieejedi

  • 27
  • Intensify Forward Firepower
Re: Player Persistent Variables in Techroom Missions?
Player persistent is just persistent to the player playing inside the campaign. Outside of a campaign, it will use the default value you've given it. So to test certain player persistent variable values, you would have to change it in FRED before playing it.

Yeah, I just wish it would change with Techroom missions. :P
Team Member for FotG

 

Offline AdmiralRalwood

  • 211
  • Mister Subspace Strikes
    • Skype
    • Steam
    • Twitter
Re: Player Persistent Variables in Techroom Missions?
What exactly is the design need that requires that the mission be run through the techroom?
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 wookieejedi

  • 27
  • Intensify Forward Firepower
Re: Player Persistent Variables in Techroom Missions?
What exactly is the design need that requires that the mission be run through the techroom?

I am using a lot of variables that are randomly chosen, including many that are used in the briefing. So it would just be nice to have a way to test those variables that doesn't require making a whole list of campaign missions then running the campaign.
Team Member for FotG

 

Offline AdmiralRalwood

  • 211
  • Mister Subspace Strikes
    • Skype
    • Steam
    • Twitter
Re: Player Persistent Variables in Techroom Missions?
What exactly is the design need that requires that the mission be run through the techroom?

I am using a lot of variables that are randomly chosen, including many that are used in the briefing. So it would just be nice to have a way to test those variables that doesn't require making a whole list of campaign missions then running the campaign.
Can you just detect that the variable is set to its default and display some kind of menu with scripting to select what value to use?
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
    • Karajorma's Freespace FAQ
Re: Player Persistent Variables in Techroom Missions?
between campaigns, not just within one campaign
That's player-persistent variables. If the variable is just supposed to be within one campaign, that's a campaign-specific variable.

Nope. The names are somewhat confusing (and caused something of a discussion between Taylor and myself when he made a similar mistake).

The difference between player-persistent and campaign-persistent variable is when they update themselves. Player-persistent variables change as soon as the value is changed. If you then replay the mission the new value of the variable will be used. Campaign-persistent variables on the other hand only update when the campaign advances to the next mission. If you replay the mission again the variable will be reset to whatever the value was at the start of the first time the mission was played.


What wookieejedi requires is a variable flag that says "If this variable is updated from the default value make that the new default value in the techroom." In addition he's also asking for the flag to allow other campaigns access to that variable (regardless of whether it is a campaign or player-persistent variable).
Karajorma's Freespace FAQ. It's almost like asking me yourself.

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

 

Offline AdmiralRalwood

  • 211
  • Mister Subspace Strikes
    • Skype
    • Steam
    • Twitter
Re: Player Persistent Variables in Techroom Missions?
between campaigns, not just within one campaign
That's player-persistent variables. If the variable is just supposed to be within one campaign, that's a campaign-specific variable.

Nope. The names are somewhat confusing (and caused something of a discussion between Taylor and myself when he made a similar mistake).
I suggest you read and compare the differences between pilotfile::plr_read_variables()/pilotfile::plr_write_variables() and pilotfile::csg_read_variables()/pilotfile::csg_write_variables(). Player-persistent variables are stored in the Player object and the .plr file. Campaign-persistent variables are stored in the Campaign object and the .csg file. If a player-persistent variable isn't accessible from two different campaigns, that's a bug.

EDIT: After further discussion on the Discord (and reviewing decade-old forum threads and 7-and-14-year-old commits), the current behavior of player-persistent variables (since 3.7.0) is, in fact, the bug. I may be opening a separate thread for discussing potential solutions.
« Last Edit: March 08, 2017, 03:35:10 am by AdmiralRalwood »
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 herkie423

  • 28
  • Plunge into the chaos!
Re: Player Persistent Variables in Techroom Missions?
This may be an older post but I post my reply anyway.

I have known this fact for a long time. Persistent variables, all of them, even the "previous-event-true" which is also a variable, doesen't work in techroom replays. One obvious example is red alert mission. That's why I never use them.  If only it does, it might be useful for loadout budget that will reflect in the techroom simulator. This might be solved through a simple variable save script.

 

Offline wookieejedi

  • 27
  • Intensify Forward Firepower
Re: Player Persistent Variables in Techroom Missions?
This may be an older post but I post my reply anyway.

I have known this fact for a long time. Persistent variables, all of them, even the "previous-event-true" which is also a variable, doesen't work in techroom replays. One obvious example is red alert mission. That's why I never use them.  If only it does, it might be useful for loadout budget that will reflect in the techroom simulator. This might be solved through a simple variable save script.

The script solution is what I have setup. With it it loads before the rest of the mission and can be loaded between campaigns and campaign replay-throughs.
Team Member for FotG

  

Offline herkie423

  • 28
  • Plunge into the chaos!
Re: Player Persistent Variables in Techroom Missions?
This may be an older post but I post my reply anyway.

I have known this fact for a long time. Persistent variables, all of them, even the "previous-event-true" which is also a variable, doesen't work in techroom replays. One obvious example is red alert mission. That's why I never use them.  If only it does, it might be useful for loadout budget that will reflect in the techroom simulator. This might be solved through a simple variable save script.

The script solution is what I have setup. With it it loads before the rest of the mission and can be loaded between campaigns and campaign replay-throughs.

Oh yes, this might be a solution. Can we have that script? :)

 

Offline wookieejedi

  • 27
  • Intensify Forward Firepower
Re: Player Persistent Variables in Techroom Missions?
This may be an older post but I post my reply anyway.

I have known this fact for a long time. Persistent variables, all of them, even the "previous-event-true" which is also a variable, doesen't work in techroom replays. One obvious example is red alert mission. That's why I never use them.  If only it does, it might be useful for loadout budget that will reflect in the techroom simulator. This might be solved through a simple variable save script.

The script solution is what I have setup. With it it loads before the rest of the mission and can be loaded between campaigns and campaign replay-throughs.

Oh yes, this might be a solution. Can we have that script? :)

It has been combined with a bunch of other custom scripts for FotG at the moment, but if someone was really interested I could give them a theoretical run down of how it works.  :)
Team Member for FotG