Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Goober5000 on September 01, 2003, 01:57:09 am
-
For all you SCP-philes out there, I have implemented persistent variables for campaigns. It all happens behind the scenes, so you'll hardly have to worry about a thing. :)
There are two types of persistent variables - campaign-persistent and player-persistent. I'll address each one separately.- campaign-persistent - Any mission variable can be specified as campaign-persistent in the FRED variable dialog. Variables with this flag are saved in the campaign file, just like goals and events. When a new mission is loaded, the parser compares the saved variable listing with the variables used in the current mission. It finds any matches, it initializes the mission variable with the saved value and updates the saved value upon mission completion. Thus, for a hypothetical trading campaign, you could have a campaign-persistent variable "money" that maintains its value from mission to mission.
- player-persistent - Most of the time, you won't even need to bother with this type, but I implemented it for the off-chance that it would come in handy for something (and also because I had a certain something in mind for later use, heh heh heh :drevil:). Like campaign-persistence, player-persistence is indicated via a checkbox in FRED. However, this variable type is stored in the player file and maintains its value without regard to the missions played or if the mission is even completed. You can die, replay the mission, or even quit the mission in the middle of playing, and this variable will maintain its value. If you wanted to be tricky, you could use this variable to track the player's strategy throughout the mission and, upon death or replay, change things around before the player even encounters them. You can even use this variable to keep track of whether the player has attempted the second mission in a red-alert sequence and then gone back to play the previous mission.
NB: Player-persistent variables overwrite campaign-persistent ones. As far as limits go, you can have as many campaign-persistent variables as you want per mission, up to 100, but you can only have 100 player-persistent variables in a campaign. And in any case, you can't keep track of any variables unless you are playing a campaign - no tracking stuff from standalone missions, although I can't see where you would want to.
Final note: This mod changes both the player and campaign savefile formats, so all player files will now be bumped from version 140 to version 141. The change shouldn't be noticeable; I added compatibility checking so that all pilot files should migrate versions without any problem. However, in-progress campaigns may need to be restarted.
Additional note: I tried using SCP pilots with retail FS2, and as I hoped, they work fine. Version 141 saves additional information at the end of the pilot file, while retail FS2 reads the pilot file only as far as is required for version 140, never encountering the version 141 data. You can continue to interchange SCP and non-SCP pilots without problems. :)
-
All hail Goober :nod:
Good **** dude - this'll add to storylineing no end, and there's a point in my FSUp where these could be _really_ useful.
-
EXTREMELY GOOOOOOOOOD!!!!
I bet this will lead the future mods to new levels:)
-
perhaps mission local variables would be a good idea, so things like x or temp could be made as mission local variables and you wouldn't need to wory about it's value
-
Ye gods, the idea of this thing makes my head hurt. A FREDder could seriously screw with a player using these things :drevil:
Seriously, you SCP d00dz keep up this level of new gubbinz and soon FS2 will piss all over even brand-new games :nod::yes:
-
:D
Originally posted by Bobboau
perhaps mission local variables would be a good idea, so things like x or temp could be made as mission local variables and you wouldn't need to wory about it's value
I dunno, you think people would need this? Initialization is easy enough, and I usually do it anyway for my variables.
Perhaps I should poll on this.
-
just thinking maybe, if it's more than half an hour worth of work, it probly isn't worth it,
though I do wonder what this will do to campains that use variables alredy, assuming they would work the old way (specificly the origonal campain), don't know if this will be an issue
-
:D Excellent. I've been waiting for the SCP to have this feature since they started :D
-
[size=8]W00T![/size]
Excellent work, Goober! You da man!
-
Thanks. :)
Campaign-specific variables now have to be specified in FRED as such, just like player-specific ones. This removes the risk of temporary variables being overwritten. The first post has been edited to reflect this.
-
ooh, this will really open up all kinds of new campaign possibilities, since we are no longer restricted to red alerts for this sort of thing. Great work. :yes:
-
Is CVS back online for you?
-
I don't quite understand. What can we do now that wasn't possible with the is-previous-event and is-previous-goal SEXPs?
-
Originally posted by Inquisitor
Is CVS back online for you?
Nope. :sigh:
cvs [login aborted]: connect to warpcore.org:2401 failed: Connection refused
cvs [diff aborted]: connect to warpcore.org:2401 failed: Connection timed out
Originally posted by GalacticEmperor
I don't quite understand. What can we do now that wasn't possible with the is-previous-event and is-previous-goal SEXPs?
Keep track of ships and weapons for non-red-alert carry-overs; keep track of more nuanced stuff than true/false.
-
Originally posted by GalacticEmperor
I don't quite understand. What can we do now that wasn't possible with the is-previous-event and is-previous-goal SEXPs?
An example of what I'm going to be using it for.
SoR is set on a Carrier trapped in an enemy system. It has no way to repair itself. Suppose I want the carrier itself to appear in mission 1 and 3 and retain the damage it had in mission 1 in the second mission.
Now this is very easy. At the end of mission 1 I set a persistant variable to equal the hull strength of my carrier. In mission 3 I set the carriers hull strength to equal the variable.
To do that with is-previous-event would need 100 SEXPs in both missions :D
-
You could still do this before, though, but you had to be tricky. In Deus Ex Machina, I needed the Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch to appear in missions 1, 2, and 4 with consistent hull strength. Since those are all red-alert missions, I just kept the ship on red-alert status, but moved it really far away in mission 3.
In Fortunes of War, I needed a similar thing to happen with a science cruiser. So I have four sexps that check for damage in 25% increments, and I bump up the hull an arbitrary amount, saying that they've repaired some of the damage between missions. :)
-
True. When I first started writing the explaination I mentioned that both missions were non red-alert missions but I must have edited that bit out :o
As for the second bit that was what I had planned to do in SoR but this is much better (and simpler too).
-
but there is much more you can do now, probably you were able to do the same in precedence, but only with a lot of work and worse results
you can track for example your resources and therefore change the amount of ships for each side during the campaign,you can increase a lot the interaction between player's choices and the story, other examples are those reportesd by goober in first post, persistent variables can have HUGE effects also for multiplayer campaigns
a "little" request: would it be possible to code something like a redalert, a transition between two missions without briefing/debriefing with a special screen (an animation of subspace for example) during the load of the new mission?
Using persistent variables the effect will be like multiple areas in the same mission.
The optimum would be to have the player free to navigate through the areas, so to launch a mission instead of another, like in tachyon, but it probably would add too many probs at this time
-
Only one problem - persistent variables cannot be used in multiplayer. :nervous:
As for your "little" request, that's already possible. Disable debriefing in the first mission and briefing in the second, and set the mission load screen to be the picture of subspace.
-
Originally posted by Goober5000
Only one problem - persistent variables cannot be used in multiplayer. :nervous:
any solution to this?
also, would it be possible to have a variable imported from some file? or something like a MySQL DBase?
-
Originally posted by kasperl
any solution to this?
Find someone who knows multiplayer and ask them. :D
also, would it be possible to have a variable imported from some file? or something like a MySQL DBase?
Yes, but it would be far too much work.
-
I think his two questions comes together: if you have multiplayer camps with persistent variables and external databases, you can really set up a lot of funny things:)
something like strategic turn-based php/asp games with the actions played online...
-
I just figured out what this feature actually adds... that's pretty damn cool, mate. :nod: