[karajorma]

Okay. Try as I might I couldn't see any way to use variables in the breifings editor. I think [V] locked them out because there wasn't any way to declare a variable in the mission until the mission itself had started.

Thanks to the existance of persistant variables we can now so it would be nice to be able to set up a briefing dependant on the state of a PV instead of having to rely on is-previous-event-true.

Oh. As if to make things more complicated I'm thinking of doing this with a player persistant variable in the first mission of a campaign (basically I want to be able to change the briefing if the player has played the mission once already and failed) and I'm a little worried that things won't work the first time through the mission. After all AFAIK player persistant variables are declared at the same time as normal variables which means that the first time through the mission the variable won't have been declared. Will it just ignore the variable and evalute the player usage to false in the same way as missions played in the techroom ignore PV's?

EDIT : Realises that just about the majority of the forum are going to look at this and say "Eh?"

[Viper1000]

Ah... the wonders of variables... what would Programmers do without them?

[karajorma]

Drink less caffinated beverages, go out into the sunshine more often and meet girls most likely. They'd all be out of a job though

That said most FREDders ignore variables almost completely.

[Goober5000]

I'm going to code the whole pre-mission variable handling in one go... ship loadout, briefing stages, etc.  When I'm done, they should all work the same way, so this should not be an issue.

Originally posted by karajorma
I'm thinking of doing this with a player persistant variable in the first mission of a campaign (basically I want to be able to change the briefing if the player has played the mission once already and failed)

Hehehe... this is the tip of the iceberg of screwy stuff you can do with player-persistent variables.

and I'm a little worried that things won't work the first time through the mission

The only time the persistent variable code kicks in is when the mission is loaded.  If the variable is marked as persistent, but there's no match in the existing PV list, it acquires the same default value as it would if it weren't persistent - i.e. the value you specify when adding a variable through the event editor.

The default value is saved in the mission file, so it's assigned to the variable every time the mission is loaded.  PVs work by overwriting this default value with whatever is found in any matching PV entry.

[karajorma]

Originally posted by Goober5000
I'm going to code the whole pre-mission variable handling in one go... ship loadout, briefing stages, etc.  When I'm done, they should all work the same way, so this should not be an issue.

Excellent.  I was aware you were working on them but I wasn't sure if you'd missed this one

Originally posted by Goober5000
Hehehe... this is the tip of the iceberg of screwy stuff you can do with player-persistent variables.

I know. Quite frankly the thing I worry about most is running out of event nodes as I keep coming up with all kinds of screwy stuff I can do with PVs

Originally posted by Goober5000
The only time the persistent variable code kicks in is when the mission is loaded.  If the variable is marked as persistent, but there's no match in the existing PV list, it acquires the same default value as it would if it weren't persistent - i.e. the value you specify when adding a variable through the event editor.

The default value is saved in the mission file, so it's assigned to the variable every time the mission is loaded.  PVs work by overwriting this default value with whatever is found in any matching PV entry.

Excellent. That was precisely how I was hoping they worked. That means I can have a completely different mission briefing the second time around rather than just having to be careful how I word the first one.

[Black Wolf]

Originally posted by karajorma

I know. Quite frankly the thing I worry about most is running out of event nodes as I keep coming up with all kinds of screwy stuff I can do with PVs
 

Eg.? Assuming I can ever get the damned things to work reliably, I'm going to have to start using variables a bit more, and some ideas'd be cool.

[karajorma]

Okay. Here's one idea I had which I couldn't use in SoR.

In the briefing of one of the missions you mention an enemy cruiser that was seen in system and warn the player to keep an eye out for it. The cruiser doesn't appear but using persistant variables you have it appear at random in a later mission.

You could simply use the random SEXp to assign the PV a number. Eg if PV = 1 it appears in mission 3, if PV=2 it appears in mission 8 etc. If you're feeling more devious you could use a Random SEXP to determine when the ship appears and the PV is used as a flag to determine whether or not the ship appeared yet so you can prevent it appearing in later missions.

The benifit of the second method is that you could have the player fail a mission 3 times and have the ship appear out of the blue the fourth time the player tried the mission.

Sure you could do this using is-previous-event-true but it would be a lot more tedious to set up as you'd need to remember the name and event in each mission where the cruiser showed up. With PV's there is one constant variable name to remember and the whole thing can be set up using less SEXP nodes.

[Goober5000]

Originally posted by karajorma
Excellent.  I was aware you were working on them but I wasn't sure if you'd missed this one

I probably would have if you hadn't mentioned it. I'll contact you when I'm ready to release it to make sure I didn't miss anything.

[karajorma]

Sure. You know I'm all excited to test this kind of stuff Load of people want to test the graphics stuff but for me it's the new gameplay stuff that excites me

[Black Wolf]

Originally posted by karajorma
Okay. Here's one idea I had which I couldn't use in SoR.

In the briefing of one of the missions you mention an enemy cruiser that was seen in system and warn the player to keep an eye out for it. The cruiser doesn't appear but using persistant variables you have it appear at random in a later mission.

You could simply use the random SEXp to assign the PV a number. Eg if PV = 1 it appears in mission 3, if PV=2 it appears in mission 8 etc. If you're feeling more devious you could use a Random SEXP to determine when the ship appears and the PV is used as a flag to determine whether or not the ship appeared yet so you can prevent it appearing in later missions.

The benifit of the second method is that you could have the player fail a mission 3 times and have the ship appear out of the blue the fourth time the player tried the mission.

Sure you could do this using is-previous-event-true but it would be a lot more tedious to set up as you'd need to remember the name and event in each mission where the cruiser showed up. With PV's there is one constant variable name to remember and the whole thing can be set up using less SEXP nodes.

Couldn't that severely mess with balance though? Still, you're probably right - that sort of thing could definitely makes things interesting.

[karajorma]

Carefully scripted you could probably get away with it Remember that you could design the rest of the mission to take into account whether the cruiser turned up or not.

If you were doing a FS1 style campaign with a shivan super ship on the prowl the matter of balance wouldn't matter. You could have the ship turn up in random missions and kill everything (after checking to see if the player had done enough to warrent moving on to the next mission of course).
 By doing things that way it really would become a case of "Oh my God. It's the Lucifer!" because the player would never know in which missions the ship might appear and so would always be worried that it might turn up to ruin his day.