Hard Light Productions Forums
FreeSpace Releases => Scripting Releases => Topic started by: Admiral MS on February 20, 2011, 12:33:22 pm
-
Goober5000 made a much improved (and backwards compatible) version of the script:
https://www.hard-light.net/forums/index.php?topic=96939
----------------
Ship save/load script for checkpoints and red-alert like missions.
Instructions how to use it can be found in the readme.
Download:
http://www.mediafire.com/file/6dclueqkc4yxuol/Ship_SaveLoad_script.zip
Use 3.7.2 or newer (probably works on 3.6.16 upwards).
----------------
While working on a campaign I remembered reading that red-alert is not always doing what it should, especially with branching missions and several red-alert missions in a row. So I thought that a script might be a solution and because I wanted to learn how scripting works (haven't done much programming up to now, nothing object oriented) I started creating a script that saves all important (shipclass, hitpoints, ammo left,...) and some not so important (energy, shields, ...) shipdata into a file and loads the data into the game from the file.
The script is working as it should and gets called via script-eval with the shipname in FRED. It manages data for several ships in one file and does ship-vanish when a ship that was dead or absent while saving gets loaded. That way it can be used for red-alert like missions while playing them in the simulator or when a ship is not present in the next mission but is used again in the mission afterwards without repairs.
That said I have a few questions:
Does a script like this already exist and I just didn't find it?
Does it make sense at all to make a script for something the game engine should be able to do?
Is anyone interested in such a script and wants to see some feature in it? I'm still thinking about what else can be added or what options for loading may be of use...
The script needs a place to save shipdata and possibly a configuration file. Do you know what filetype may be the best choice and where to save it?
At the moment everything is in one file and all functions are in
#Global Hooks
$Global:
[
...
]
#end
I'm not exactly sure if this is the right place or if the functions should be better somewhere else.
So if there is any interest in the script I'll put in some changes, clean it, try to follow some of the advise in http://www.hard-light.net/forums/index.php?topic=72312.0 (http://www.hard-light.net/forums/index.php?topic=72312.0) and release it. At the moment it's more or less the result of me learning lua the hard way with a target and without starting with easy examples like 'Hello World' :D
-
the thing i like about scripting is its not fred. im not really sure what can and cant be pulled off with existing features in the mission editor, im not sure what bugs affect red alert missions. but having a way to log stats for ships and reload them in the next mission with exactly the same stats sounds impressive. not sure if that is out of fred's capabilities or not.
it sounds like your'e using fred to call functions defined globally with scripting. of course i would use the $game_init: hook because i dont think global hooks work with modular tables, so if you stacked your script onto another mod wih scripting, only one of those mods would get its global hook scripts used which could lead to things you defined being nil when you go to use them. instead use:
#Conditional Hooks
$Application: FS2_Open
$On Game Init:
[
--script goes here
]
#end
you should also kind of keep the use of globals to the minimum. using locals in functions is sufficient so long as you use descriptive enough names on your functions. you can further reduce the number of globals by sticking functions in tables such as:
pongFuncs = {}
function pongFuncs.initPong()
of course this kinda thing is somewhat overkill in most cases and even i dont do this. you could also make things easier and just use a prefix specific to your script on all your global names. this is also somewhat overkill because there just arent enough people using scripting for people to have clashing variables.
i probibly dont have much use for such a script, of course im not really a mission designer so i wouldnt know. getting non-scripters (especially moders who are primarily graphics people, and to a lesser degree freders) to use scripts no matter how well packaged and well written scripts are is all but impossible. there are exceptions, such as mega-mods and tcs who would jump at the possibility to have a full time scripter on their team. my scripting interest pretty much revolves around graphics, game play and physics. i do have a concept for a mod which revolves around being able to "collect" supplies from one mission add them to an inventory of sorts and use them to "collect" more supplies in the next mission, and where failing to "collect" them results in a very hard game, and will end the game for you when the inventory reaches zero. but its a bridge i cross if i ever get there.
-
the thing i like about scripting is its not fred. im not really sure what can and cant be pulled off with existing features in the mission editor, im not sure what bugs affect red alert missions. but having a way to log stats for ships and reload them in the next mission with exactly the same stats sounds impressive. not sure if that is out of fred's capabilities or not.
You can do some saving in fred using player-persistent variables but for a lot of ships you need tons of variables and so on. I think changing the class of a ship to something else and loading all other stats is impossible in fred.
it sounds like your'e using fred to call functions defined globally with scripting. of course i would use the $game_init: hook because i dont think global hooks work with modular tables, so if you stacked your script onto another mod wih scripting, only one of those mods would get its global hook scripts used which could lead to things you defined being nil when you go to use them. instead use:
#Conditional Hooks
$Application: FS2_Open
$On Game Init:
[
--script goes here
]
#end
The script is used in fred like a sexp with the shipname as argument. For a number of uses you should be able to call it everytime (so save and load in the same mission). $On Game Init: doesn't seem to enable this.
you should also kind of keep the use of globals to the minimum. using locals in functions is sufficient so long as you use descriptive enough names on your functions. you can further reduce the number of globals by sticking functions in tables such as:
pongFuncs = {}
function pongFuncs.initPong()
of course this kinda thing is somewhat overkill in most cases and even i dont do this. you could also make things easier and just use a prefix specific to your script on all your global names. this is also somewhat overkill because there just arent enough people using scripting for people to have clashing variables.
I already did most of this because i got a number of problems when using globals. There are only local variables and the complete shipdata is stored in one table with a lot of integrated tables. The data is transferred via function calls anyway.
I expected that only a few people will ever look into the scripting section but I'll finish the script for use in my campaign and propably release it in a few days. Some campaigns already have in-mission savepoints and i may try to extend the script to be used at reloading to a given point in a mission or you can do quite some funny things with it in a parody campaign.
Scripting really needs some advertising outside this part of forum...
-
This would be a much better way to do this stuff than the system used in War in Heaven. If I can figure out how to use it I'd definitely consider it as a replacement. Nice job.
-
While trying to implement the last feature into the script i sort of hit a wall.
I tried to use
if (mn.evaluateSEXP("is-destroyed-delay !0! !"..shipname.."!")) thenand the game dumps me to desktop with a stupid error message:
Can't find operator s-destroyed-delay in operator list
.
ntdll.dll! KiFastSystemCallRet
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_12r_INF_SSE2.exe! <no symbol>
fs2_open_3_6_12r_INF_SSE2.exe! <no symbol>
fs2_open_3_6_12r_INF_SSE2.exe! <no symbol>
Debug gives an assertion at that point :confused::
Assert: *Mp == '('
File: sexp.cpp
Line: 18613
It does this with the same error message no matter what is actually written inside evaluateSEXP(" ... ") and the debug log doesn't contain any more information with the standart settings.
Am i using it the wrong way or what's the problem with it?
-
this is not familiar territory for me. the only mission integration i have done is using the script-eval sexp (this is used by the atmospheric flight script to tell it what planetary/atmospheric profile to use for the mission).
does the sexp expect some kind of termination on the string, like a \0 or \r\n or some such?
*edited because im a moron*
-
(mn:runSEXP("is-destroyed-delay !0! !"..shipname.."!"))
This returns a true (for running that sexp succesfully) so unless evaluateSEXP ist totally different it should be right. And as i already said, it doesn't matter if i use evaluateSEXP("") or evaluateSEXP("stuff"), the error message is the same.
It feels more like something is buggy. I never got an assertion in debug up to now, not even a crash at all no matter what i did in my script. And one time the game freezed without error message when getting to the evaluateSEXP part...
-
The error message makes it look like the initial 'i' in 'is' is somehow being chopped off and the SEXP thus cannot be recognized. That's weird.
-
i dont see any reason in the source why that should happen, did you try padding it with whitespace?
though there is this amusing little snippet:
// HACK: ! -> "
for (i = 0; i < (int)strlen(buf); i++)
if (buf[i] == '!')
buf[i]='\"';
-
Adding spaces in front of it changes nothing, adding an "i" in front of it freezes the normal game but debug keeps producing the same assertion. So i guess the normal game just crashes because it ignores that assertion or whatever and tryes to go on somehow.
// HACK: ! -> "
for (i = 0; i < (int)strlen(buf); i++)
if (buf[i] == '!')
buf[i]='\"';
Uh what's that?
-
just an amusing piece of code from run_sexp() in sexp.cpp.
but i followed the calls and run_sexp(), does some string magic (namely the hack above) to process the string and dump it into a buffer. then set a pointer to the buffer. this pointer seems to be a global. at some point in get_sexp(), a call is made to get_sexp_main(), which makes use of that same global pointer (*Mp). and in that function there is this code:
savep = Mp;
if (!strncmp(Mp, "( )", 3))
savep++;
Assert(*Mp == '(');
and theres yer problem. seems it expected to see a ( character, but saw an 'i' instead. thus the assert. i think your sexp needs to be in a set of (). that is assuming my understanding of how asserts work is correct.
-
Adding some () so it looks like:
if (mn.evaluateSEXP("(is-destroyed-delay !0! !"..shipname.."!)")) thenseems to work. I get no error and there are the right results in the savefile. :)
That much about the documentation of scripting :rolleyes: and error messages telling the user what's wrong :wtf: Why is the syntax of evaluateSEXP() different than that of runSEXP()?
Thanks for looking for it in the code, would've been stuck without your help!
-
seems the only difference between evaluateSexp() and runSexp() is this line:
snprintf(buf, 8191, "( when ( true ) ( %s ) )", s);
which is present in runSexp() but not evaluateSexp(). to make the syntax more uniform, i could just add it to evaluateSexp but use:
snprintf(buf, 8191, "( %s )", s);
which would essentially put anything in your sting in parenthesis for you, but this feels kinda like yet another hack in an already hackish system. im gonna ask the coders if this is a good idea to do this or not or not. it also kind of makes me question why we need both functions.
-
it also kind of makes me question why we need both functions.
I need both evaluateSEXP() and runSEXP() because what they return is completely different. Evaluate does return whether the statement is true, false or whatever and run just tells me if the game could process the sexp or not.
-
in that case i may just add more info to the description strings so scripters aren't at a total loss about syntax.
-
Finally finished the script.
There are 4 functions usable with script-eval in fred:
saveship('shipname')
saves the data of a ship to the savefile
deleteship('shipname')
deletes the data of a ship out of the savefile
deleteshipsavefile()
obvious
loadship('shipname')
loads the saved data of a ship into the game, has a number of optional arguments besides the standard use which tell the script what data and how to load the data.
For shipnames too long for the characterlimit in script-eval there is an option to load the shipname from a variable defined in fred.
An explanation of the features is in the readme.txt or you can just ask me here if it's hard to understand. I was trying to make the use really simple but somehow after reading my readme it feels complicated.
Download:
http://www.mediafire.com/?3bc31gfn2c2k9vw
The .zip contains two missions as example, the script and a readme. It is now in a .tbm enabling the modular use everyone likes ;) and no more parts of the script are in #Global Hooks.
I tested everything I could think of in 3.6.12 but if you encounter any problems just report it in this thread.
-
It feels like my era is over as soon as it came. What place is there for a FREDder with these brilliant new minds and their 'scripts'?
-
It feels like my era is over as soon as it came. What place is there for a FREDder with these brilliant new minds and their 'scripts'?
A lot of places after all... Considering that I'm working on my campaign for many years and the only things of it i actually finished are 5 missions which are of no use unless i finish the others and this script that may never see the light of the day inside the campaign i made it for :sigh:
-
there still needs to be mission designers. this script really just means they have new toys to play with. this is one of the reasons ive always tried to push for mission-embedded scripts so that missions could include scripting without needing any other external tables or scripts, and that scripted missions may be validated for multi and not require mods to run.
also a note for functions that are to be called from sexp, i helps to keep arguments and function names as short as possible, because, iirc, you are limited to 32 byte strings. i usually just use a proxie function to allow a shorthand version that can be used if you need a lot of arguments or long arguments (some ships have really long names), it might call for a series of functions or globals to be set before calling the function to do the job. but in this case i think it should be enough space.
-
Yeah I am pretty much joking cats
-
also a note for functions that are to be called from sexp, i helps to keep arguments and function names as short as possible, because, iirc, you are limited to 32 byte strings. i usually just use a proxie function to allow a shorthand version that can be used if you need a lot of arguments or long arguments (some ships have really long names), it might call for a series of functions or globals to be set before calling the function to do the job. but in this case i think it should be enough space.
shipload('Alpha 1',1,1,'Alpha 2') is already too long for it... And thats just loading Alpha 1 shipdata on Alpha 2. For that reason i added a way to use normal string-variables to get the shipname into the script. In this case that is shipload ('var',1,1,'var') and then the script would try to load the first name out of a variable named loadship and the second out of loadship2. That way you have the full string length for a shipname and if someone ever needs it, i could add something to use several variables for a single name...
-
And that may be a moot point soon, as I'm looking at seeing if it's possible to eliminate that limitation.
(or at the least, making it MUCH larger than it currently is)
-
i figure 2-4 times larger would be adequate for most function calls, even very large ones. though it would be really cool to be able to run a large block of lua from a sexp. 1024 bytes would allow for a block the size of a small function, and upwards of 4096 for a large one. you could run multiple blocks to initialize a large number of functions that would be used in the mission and call them as required
-
Well, it would be cool if you could embed "real" lua code into the mission and call that without the "hack" (please don't understand me wrong, I know that it's the only way). Or a system where you could create SEXPs that are actually lua functions. But thats very unlikely to happen. :sigh:
-
Well, it would be cool if you could embed "real" lua code into the mission and call that without the "hack" (please don't understand me wrong, I know that it's the only way). Or a system where you could create SEXPs that are actually lua functions. But thats very unlikely to happen. :sigh:
yea this would be somewhat preferable. you cant really choose the hook you are executing in. i guess mission lua is run during sexp evaluation. so if you wanted to draw on the hud, you would need to queue up commands in a buffer and run them with another script in the $on hud draw: hook. you definately want an init block (for function defs, custom objects, custom graphics) and an uninit block (for unloading anything that may have been loaded). you would also want at bare minimum simulation and hud hooks in addition to sexp based function calls.
-
I can see two possible fixes that seem reasonable:
script-eval-fcn
-- funcname
-- arg1
-- arg2
-- arg3
-- ...
script-eval-cat
-- part1
-- part2
-- part3
where the final string evaluated as a Lua script is part1+part2+part3 (where '+' is a concatenation operator)
I'm sure there's a more user-friendly name than 'script-eval-cat' but that's the first one that comes to mind.
-
I can see two possible fixes that seem reasonable:
script-eval-fcn
-- funcname
-- arg1
-- arg2
-- arg3
-- ...
A sexp like this looks really helpful at least for my scripts. It removes the need to put every argument and the function name into one string or create some impractical workaround as i did. Using scripting functions with it would feel more like using a normal sexp (and maybe create some more acceptance for scripting stuff in fred).
script-eval-cat
-- part1
-- part2
-- part3
where the final string evaluated as a Lua script is part1+part2+part3 (where '+' is a concatenation operator)
I'm sure there's a more user-friendly name than 'script-eval-cat' but that's the first one that comes to mind.
I don't know if there are many scripts short enough to make use of this fix because i would not want to use like 10+ parts...
-
the first one looks good. this would need to format the arguments in the proper data types though. numbers, strings, and bools (and possibly userdata variables) should be sufficient for most situations. i know sexps can only return integers but im not sure what the limits are on the type of the argument, or how to get across to lua what type it is supposed to be.
the second one looks like it would be really user unfriendly, but would come in handy if you need to do something that is rather large, like declare a table and fill in its contents. would just assume its a block of text. actually if this had some kind of front end in fred, where it would take a block of script, and break it up into the various parts to parse it as a series of sexp arguments (and reassemble it for editing), it would be about the same as having lua blocks as part of the mission file.
another idea is include lua blocks right in the mission, something like
$lua block name: block1
+script: [
--script goes here
]
and then have it so you can call certain embedded blocks from the sexp.
script-eval-block
--block name
this doesnt directly pass any arguments back and fourth at all. of course that doesnt stop you from reading sexp variables. im not sure it would support a return code either.
-
the first one looks good. this would need to format the arguments in the proper data types though. numbers, strings, and bools (and possibly userdata variables) should be sufficient for most situations. i know sexps can only return integers but im not sure what the limits are on the type of the argument, or how to get across to lua what type it is supposed to be.
I assumed that the arguments would be taken verbatim and placed into the script.
<funcname>(<arg1>, <arg2>, <arg3>)
I think that solves the problem.
-
so it wouldnt really care what the args are at all, it would just be passed as text.
-
The script itself should care about what it gets as arguments and change data types if needed or check if its something unexpected. Passing text seems sufficient to me.
-
A system where you could create pseudo-SEXPs that calls lua code would be awesome. This could also be build to take specific variable types (like the currently existing SEXPs), e.g. a ship or a weaponclass, that would get converted to the corresponding lua type. The lua code would be saved inside the mission making it easier to create mission specific lua-script.
Would that be doable?
-
thats why i suggested mission embedded lua blocks, and calling a sexp executes a block. this gets around the string size limits. it also would make it fairly easy to edit the lua outside of fred.
script-eval-cat
--arg1 "[local foo=3]"
--arg2 "[local bar=2]"
--arg3 "[foo=foo+bar]"
--arg4 "[hv.sexpReturn(foo)]"
is a lot harder to read and edit than:
script-eval-block
--block name foobar
...
#luablocks
$lua block name: foobar
+script: [
local foo=3
local bar=2
foo=foo+bar
hv.sexpReturn(foo)
]
hv.sexpReturn() would be part of the interface to set the return argument for the script-eval-block sexp. the sexp might also have other arguments as well, which might get passed through hv.sexpVars[] to the block. this method would be a fairly powerful way to do scripted events in missions without requiring custom mods. i sitll like wmc's script-eval-fcn and script-eval-cat functions, but i think these sexps would be suited more to talking to existing scripts as part of a mod. instead of mission scripts, which for the most part would be standalone. since the script is part of a mission it can be validated for multiplayer, allowing some pretty interesting game types. i can imagine doing things like letting some players control turrets, in-game powerups, capture the flag type games, etc.
-
That's a pretty good idea there. Although I would move the block declarations into scripting.tbl so that you could call them from several missions without having to copy-paste a lot of code, and also so that you don't need to code up a new interface in FRED.
-
That's a pretty good idea there. Although I would move the block declarations into scripting.tbl so that you could call them from several missions without having to copy-paste a lot of code, and also so that you don't need to code up a new interface in FRED.
i could imagine having a place for global block defs in scripting.tbl. certainly if you write a ctf script, you might want to use it in other missions, and since the blocks may be included in the scripting.tbl they may be used as part of the mediavps, but lie dormant untill a mission calls on them. however if you dont have the scripts embedded in the missions then you loose the standalone advantages. user creates a new game type and they either have to release it with a mod or wait for it to get included in the next version of mediavps. i would still allow for mission embedded script blocks, even if fred has no way of editing them.
-
Download link in first post has been updated with a new version of the script.
It now uses several recently added sexps like destroy-instantly or set-departure-info and has several of other changes and fixes making it much more stable to use.
If anyone already uses the script: just replace old files and add new ones. The function calls are exactly the same as in older versions
-
Don't MediaFire links expire after a while?
-
Script updated with a copyship function to directly copy the data of one ship to another without saving it to a file. Includes some extra features like target setting if the player had the original ship as target and copying of all physical properties like velocity.
Download link is in the first post.
-
Is there any interest in loading or saving ship orders with this script? I'm working on an updated version of it so I could try to add that as well.
-
Only if its a new load type (stat or whatever).
-
Uploaded a new version allowing saving and loading of SEXP controlled variables. The savefile is the same that is used for ship data.
-
Thought I'd drop a note of appreciation - I'm in the process of porting the FS1 (FSPort) campaign to co-op and was looking for a way to get Red Alert-like functionality working properly in multiplayer (as doing this natively in the code is extremely daunting).
With a couple of minor code tweaks (there are some MP-specific client-side issues with processing ship-vanish / ship-destroy on AI-controlled ships that I've been hacking around), your script actually works PERFECTLY and has saved me a lot of trouble. I have mission handling in place to bypass the script if any player-controlled ships are dead (I give them a fresh default ship to work with in the next mission if they've run out of respawns before the previous mission had ended), but otherwise all player-ship stats for all players transition to the next mission flawlessly, and the "red-alert experience" (for lack of a better term) is completely preserved.
As soon as I wrap some things up, I'll be releasing a beta of the mod soon. Is it OK if I include your script with it? Full credit will be given of course.
-
Damn, nice work Parias (and damn nice work to the original script creator too of course). I read about this and was curious if it worked with multiplayer coop. I imagine you got this to work in multiplayer campaign arcs correct? For example, there is no way to save multiplayer campaign progress, so a work around is to group 2 or 3 missions together so that there is some type of continuity from mission to mission.
-
Essentially correct - I have the campaign split up into multiple smaller multiplayer campaigns, consisting of a few missions each. This way if there's a problem (someone has to bomb out mid-campaign, or crashes), the group doesn't have to start all over again.
Each mission can also be played as "single" co-op missions of course... and the benefit of using this script is that it'll work regardless on if you're doing campaign mode or not. So long as the previous mission was played (and it had a chance to fire the save function), it'll load the corresponding ship data in the next mission. And if it wasn't played, everyone will still just get default ships.
-
That is amazing. Will the script only affect one mission ahead?
For example, say you have the entire freespace 1 campaign. You are in mission 1 and there is trigger set up that if you don't save that ship, it won't show up in the final mission. Will the save function keep the data handy until you play through all the mission between and then you arrive at mission 30 and depending on your actions the ship is gone. I will try to test it out over the weekend but it opens up many possibilities that have been lacking in multiplayer.
-
Yup - the script is file-based (it writes the ship data to a specific file and reads it afterwards). So long as the file exists on your hard drive, the ship data is maintained, and just needs to be called by an appropriate SEXP. You can set a string variable called "filename" to tell it which file to use for saving and loading - check out the PDF included with the script as Admiral MS explains how that works. He's done a pretty good job with this.
-
This script was originally intended as an alternative to FSO's sketchy Red Alert system. In fact, when I built a Red Alert mission set, I used this scrip to transfer all of the ship data from one mission to the next instead of Red Alert. All Red Alert did was show the specialized briefing.
Red Alert may have been fixed and become more reliable by now, I dunno. I just don't trust it to be reliable.
-
It's wise to use the script since the script is a better way of keeping track of the data and could be adjusted for special cases if desired.
-
And the script can actually be made to work properly for multiplayer campaigns too. :D
-
Red Alert may have been fixed and become more reliable by now, I dunno. I just don't trust it to be reliable.
Well, quite a few Red Alert bugs have been fixed recently... but ultimately, it still has design problems (can only go back one mission, doesn't work in multiplayer) that make it undesirable.
-
Small question:
When implementing the loadship feature for a checkpoint, do you need to have the ship present in the mission at the time to have it loaded correctly when it jumps to the next part.
Currently in my mission when I move to the checkpoint only the ships that were in system at that time load. The others just don't appear.
-
There's an option to have the script create-ship.. but here's what I recommend instead.
When you have a ship that arrives later in a mission AND is part of a checkpoint, use SEXPs to change it's arrival info. What I mean is this. During the SEXP sequence where the player chooses to go to the checkpoint (or where the mission starts loading the checkpoint), use set-arrival-info sexp to change that ship's arrival to some trigger that forces it to arrive 'RIGHT NOW' (instead of it's later trigger) with no warp and no delay. Then use the script a frame or second later to load the saved checkpoint data onto that ship.
That way the ship shows up at the right times for both types of playthroughs (checkpoint vs no checkpoint).
-
Thanks mjn, I've set it up but its not working, you suggest using the set-arrival-info sexp right?
Its not making my ship arrive though, what do I particularly have to do to force it to arrive?
-
Can I see your SEXP?
-
( set-arrival-info
"Yarra"
"Hyperspace"
"Yarra"
0
0
0
( true )
That is the specific sexp in question
-
It looks like there is currently no way to change an object's arrival or departure cue at runtime; instead, you should change the arrival cue to logically "or" together the normal condition and a check to see if the checkpoint was activated.
-
So.....tie it to arrive with the checkpoint trigger just prior to loading the actual checkpoint?
-
It looks like there is currently no way to change an object's arrival or departure cue at runtime; instead, you should change the arrival cue to logically "or" together the normal condition and a check to see if the checkpoint was activated.
Oh, whoops. You're right. I forgot that set-arrival-info doesn't handle that.
Yeah, so here's how I'd do this. For the ship that needs to arrive, open it's properties and set it to arrive when 'Ship Arrival Event' becomes true. In the Events editor I would have the Ship Arrival Event to trigger when the mission reaches it's time to arrive OR when the checkpoint is triggered.
-
Okay thanks guys, had a feeling that may have been the way to solve it.
Is there a way to make the Yarra's warp dissapear (does set arrival info do that) or would it be easier to just have it warp in after a fade out and fade back in to start the next part?
-
Okay thanks guys, had a feeling that may have been the way to solve it.
Is there a way to make the Yarra's warp dissapear (does set arrival info do that) or would it be easier to just have it warp in after a fade out and fade back in to start the next part?
You see that "( true )" at the bottom of the set-arrival-info SEXP? Set it to "( false )" and there won't be a warp effect.
-
Okay thanks guys, had a feeling that may have been the way to solve it.
Is there a way to make the Yarra's warp dissapear (does set arrival info do that) or would it be easier to just have it warp in after a fade out and fade back in to start the next part?
You see that "( true )" at the bottom of the set-arrival-info SEXP? Set it to "( false )" and there won't be a warp effect.
Thanks, I suspected it would be as such. :yes:
-
Generally, I find it good form to fade to black when a checkpoint is chosen. Then perform all the setup stuff (ship arrivals, ship removals, skybox changes, whatever) and then fade back in.
-
Yeah it doesn't look very nice if you don't fade to black. Its smoother when it is done behind the black screen.
-
You guys are fast answering any questions before I even get around reading the thread. Anyway, I'm happy that people are using my script and that it brings some life into this forum ;)
-
No worries Admiral MS, your script is very good and in my opinion very powerful for not only checkpoints. :yes:
Keep up the good work mate.
EDIT: All good guys, the adding the extra event for the other ships to enter to make the checkpoint work plus the set-arrival info plus the fade out has got the checkpoint system work all properly now. Thanks for the help.
-
Hello,
I am now trying to create a checkpoint system using your script. The script itself is great and its standard functions are working well, but I encountered a problem when trying to read long ship names from a variable.
I have variables saveexist, filename and loadship defined.
My ship-saving event looks like this:
$Formula: ( when
( true )
( script-eval
"saveship('shipname1',3,3)"
"saveship('shipname2',3,3)"
...
)
( modify-variable
"@loadship[a]"
"longshipname1"
)
( script-eval "saveship('var',3,3)" )
( modify-variable
"@loadship[a]"
"longshipname2"
)
( script-eval "saveship('var',3,3)" )
...
)
During the mission, when the event is run, all data is written in file correctly, but I'm getting this exception (the same one goes when I load ship data from file):
LUA ERROR: [string "?"]:1: ')' expected near 'at'
------------------------------------------------------------------
ADE Debug:
------------------------------------------------------------------
Name: (null)
Name of: (null)
Function type: (null)
Defined on: 0
Upvalues: 0
Source: (null)
Short source:
Current line: 0
- Function line: 0
------------------------------------------------------------------
------------------------------------------------------------------
stack traceback:
------------------------------------------------------------------
------------------------------------------------------------------
It looks like there is a bug in your script somewhere after saving/loading data. I looked through your code, but I couldn't find any missing closing brackets. Do you have any idea what can be wrong here?
EDIT: problem solved. The reason was a ' sign in ship name that was treated by LUA as string's end.
-
I just downloaded the script from the first post in this thread, and the test missions included don't work. I play saveload1.fs2 and it seems to do what it's supposed to (though I didn't notice any loading going on). I then play saveload2.fs2 and it says the savefile doesn't exist. After running both missions, the scripts folder contains a file called saveload1.txt with the contents "§third,n,1213" and two newlines. This occurs on 3.7.2 RC5.
[EDIT] Can confirm script works properly on 3.7.0.
[EDIT] Does not work in Swifty's new shadows/bloom/awesome-pixels build.
[EDIT] Tested with various nightlies. Seems to be broken on anything past 11223, and not broken on 11221 and previous.
[EDIT] Indeed, r11222 changed the cf_exists(const char *filename, int dir_type) function, and based on how the script fails (loading does nothing, saveexist() always returns false) it seems that FS's cf.fileExists() lua function always returns false.
[EDIT] r11222 is a fix for mantis 3036 (http://scp.indiegames.us/mantis/view.php?id=3036). As chief1983 said in the notes for that bug, there are issues with lua's cf.fileExists(). Setting the third argument to true wherever it appears in the shipsaveload-sct.tbm causes the script to work properly.
-
Awesome... Can you show me an example of what to change? I'm no scripter, but I can find and replace! :)
-
Since r11222, the behavior of cf_exists() and cf_exists_full() should be identical in this scenario, meaning that it failing to find the file with the third argument not set to true makes absolutely no sense whatsoever. Unfortunately, I have to go to bed at this exact moment, but I'll be looking into this after I wake up.
-
Something has definitely changed... but it's been so long since I updated the builds I was using with BtA, that I couldn't tell you where the problem is. I'll have to confirm with Admiral MS to see if we can nail down what's going on.
-
Awesome... Can you show me an example of what to change? I'm no scripter, but I can find and replace! :)
Missed this post before, sorry - the temporary fix (content of shipsaveload-sct.tbm) is here (http://0bin.net/paste/q98UuuGvQ+8KrNTG#YceiFAkZcSWkgVTAKuKSW+qelhgXdXCeBuMOAChSS8V). Basically all "cf.fileExists(*,*)" was changed to "cf.fileExists(*,*,true)".
-
Sorry about this guys. I dropped the ball on the file exists fix in cfile, and my broken fix ended up making it into the 3.7.2 release. The fix for this is already in 3.7.3 but unfortunately that means anyone wanting to avoid custom builds or nightlies would have to put a workaround in their script or wait for the next release (I'm actually hoping to speed the pace of that now that we're on git though).
-
Updated download with the fix for 3.7.2!
Might revert it when 3.7.4 is available.
-
I'm running into a problem using this script. I have used it successfully for implementing checkpoints twice before, but now I'm using it on a really complex checkpoint and it seems to be choking. It saves all the ships, but it forgets all but one of the variables.
Here is the sexp that calls the scripts:
$Formula: ( when
( and
( is-event-true-delay
"mark clusters"
0
)
( is-event-true-delay
"Zeta Target Miners"
0
)
( is-event-true-delay
"Zeta Target SAC 3"
0
)
( is-event-true-delay
"phase 2 time limit"
0
)
( not
( is-event-true-delay
"unsuccessful phase 2"
0
)
)
)
( modify-variable
"@filename[unset]"
"sa_m1_03_checkpoint1"
)
( script-eval "saveship('Alpha 1')" )
( script-eval "saveship('Beta 1')" )
( script-eval "saveship('Gamma 1')" )
( script-eval "saveship('Delta 1')" )
( script-eval "saveship('Zeta 1')" )
( script-eval "svar('random-seed')" )
( script-eval "svar('proximity_state')" )
( script-eval
"svar('AkihamCargoScanned')"
)
( script-eval
"svar('FighterProxBitfield')"
)
( script-eval-block
"svar('"
"ShipRecordBitfield_0_31')"
)
( script-eval-block
"svar('"
"ShipRecordBitfield_32_63')"
)
( script-eval-block
"svar('"
"ShipRecordBitfield_64_95')"
)
( script-eval-block
"svar('"
"ShipRecordBitfield_96_127')"
)
( script-eval
"svar('StealthStateInAsteroids')"
)
( script-eval "svar('StealthFlank')" )
( script-eval "svar('StealthFront')" )
( script-eval "svar('StealthScene')" )
( script-eval "svar('TargetACGLV')" )
( script-eval "svar('TargetAS')" )
( script-eval
"svar('TargetBhavisal')"
)
( script-eval "svar('TargetCP')" )
( script-eval "svar('TargetErebos')" )
( script-eval
"svar('TargetFreighters')"
)
( script-eval "svar('TargetMiners')" )
( script-eval "svar('TargetPCargo')" )
( script-eval "svar('TargetSCargo')" )
( script-eval "svar('TargetTotal')" )
( modify-variable
@sa_m1_03_checkpoint1[0]
1
)
( show-subtitle-text
"Checkpoint Reached!"
0
20
( true )
( false )
2000
2000
)
( script-eval "saveship('Akiham',3)" )
( script-eval "svar('AkihamState')" )
( script-eval
"saveship('Tauros 1',3)"
)
( script-eval "svar('Tauros1State')" )
( script-eval
"saveship('Tauros 2',3)"
)
( script-eval "svar('Tauros2State')" )
( script-eval
"saveship('Tauros 3',3)"
)
( script-eval "svar('Tauros3State')" )
( script-eval
"saveship('Tauros 4',3)"
)
( script-eval "svar('Tauros4State')" )
( script-eval
"saveship('Marduk 1',3)"
)
( script-eval "svar('Marduk1State')" )
( script-eval
"saveship('Marduk 2',3)"
)
( script-eval "svar('Marduk2State')" )
( script-eval
"saveship('Marduk 3',3)"
)
( script-eval "svar('Marduk3State')" )
( script-eval
"saveship('Marduk 4',3)"
)
( script-eval "svar('Marduk4State')" )
( script-eval
"saveship('Auroch 1',3)"
)
( script-eval "svar('Auroch1State')" )
( script-eval
"saveship('Auroch 2',3)"
)
( script-eval "svar('Auroch2State')" )
( script-eval
"saveship('Auroch 3',3)"
)
( script-eval "svar('Auroch3State')" )
( script-eval
"saveship('Auroch 4',3)"
)
( script-eval "svar('Auroch4State')" )
( script-eval "saveship('Nandi 1',3)" )
( script-eval "saveship('Nandi 2',3)" )
( script-eval "saveship('Nandi 3',3)" )
( script-eval "saveship('Nandi 4',3)" )
( script-eval
"saveship('Gugalana 1',3)"
)
( script-eval
"saveship('Gugalana 2',3)"
)
( script-eval
"saveship('Gugalana 3',3)"
)
( script-eval
"saveship('Gugalana 4',3)"
)
)
+Name: end of phase 2
+Repeat Count: 1
+Interval: 1
But here is the resulting save file. Note that it has forgotten all but the Auroch4State variable.
§§§§§§§§§Auroch4State,n,1
Alpha 1,Beta 1,Gamma 1,Delta 1,Zeta 1,Akiham,Tauros 1,Tauros 2,Tauros 3,Tauros 4,Marduk 1,Marduk 2,Marduk 3,Marduk 4,Auroch 1,Auroch 2,Auroch 3,Auroch 4,Nandi 1,Nandi 2,Nandi 3,Nandi 4,Gugalana 1,Gugalana 2,Gugalana 3,Gugalana 4
1,GVF Ptah,Friendly,220,220,40,300,150,330,82.5,82.5,82.5,82.5,:5&22§-1,-1,-2&22§-1,-1,-2&22§-1,-1,-2&22§-1,-1,-2&77§-1,-1,-2&:1,0,0,Mekhu HL-7,1,0,-1,2,0,1,Harpoon,1,8,8,Hornet,0,10,10,-1:1749.4664306641,1945.6525878906,-6681.3193359375,0.2119675129652,0.84559243917465,0.4899420440197,-0.9258154630661,0.33428671956062,-0.17640353739262,-0.3129466176033,-0.41620409488678,0.85372048616409,-26.920928955078,-31.220394134521,80.040863037109,0.028319850564003,-0.20697958767414,0.10348979383707
-1,:::
-1,:::
-1,:::
-1,:::
1,SFr Asmodeus,Hostile,8000,8000,0,-1,-1,0,0,0,0,0,:9&160§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&160§1,0,0,Standard Flak,0,0,-1,-1,-2&160§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&160§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&800§-1,-1,-2&800§-1,-1,-2&2800§-1,-1,-2&1200§-1,-1,-2&400§-1,-1,-2&:-1,-1,-1:2015.7319335938,2416.9699707031,-6971.810546875,0.76672065258026,0.0030975113622844,0.64197355508804,-3.1947376555763e-05,0.99998861551285,-0.0047867726534605,-0.64198106527328,0.0036496073007584,0.76671189069748,-9.9432001113892,0.056258119642735,12.779983520508,-7.8788480095682e-06,-0.052359879016876,-1.0372954420745e-05
1,SG Rahu,Hostile,15000,15000,0,-1,100,0,0,0,0,0,:9&8250§-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&750§-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&:-1,-1,-1:-387.93002319336,2683.7058105469,141.72229003906,0.022241676226258,0.99865698814392,0.046793092042208,0.92409145832062,-0.0026743800844997,-0.38216230273247,-0.38152387738228,0.051741026341915,-0.92290979623795,-9.7253007888794,1.5225415229797,-22.98059463501,-0.0098177222535014,-0.013089870102704,-5.3543990361504e-06
1,SG Rahu,Hostile,15000,15000,0,-1,100,0,0,0,0,0,:9&8250§-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&750§-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&:-1,-1,-1:-371.04776000977,1029.3172607422,1891.2720947266,-0.74798130989075,0.01705326884985,-0.66350078582764,-0.14498016238213,0.97133135795593,0.1884049475193,0.6476919054985,0.23711779713631,-0.7240651845932,2.0399961471558,17.785364151001,-1.8436107635498,0,0,0
1,SG Rahu,Hostile,15000,15000,0,-1,100,0,0,0,0,0,:9&8250§-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&750§-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&:-1,-1,-1:-697.95867919922,1355.4770507813,3.6695795059204,0.99060279130936,-0.055693596601486,0.12491779029369,0.056748703122139,0.99837654829025,-0.0049011660739779,-0.12444201111794,0.011944029480219,0.9921550154686,0,0,0,-2.8025969286496e-45,2.8025969286496e-45,2.8025969286496e-45
1,SG Rahu,Hostile,15000,15000,0,-1,100,0,0,0,0,0,:9&8250§-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&750§-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&:-1,-1,-1:414.72634887695,556.40447998047,-84.58536529541,0.98482799530029,0.020200338214636,-0.17235386371613,0.011632325127721,0.98328328132629,0.18171043694019,0.17314326763153,-0.18095837533474,0.96812987327576,0,0,0,-2.8025969286496e-45,2.8025969286496e-45,2.8025969286496e-45
1,SG Rahu,Hostile,15000,15000,0,-1,100,0,0,0,0,0,:9&8250§-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&750§-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&:-1,-1,-1:-252.92047119141,1966.3835449219,1017.5070800781,-0.50716537237167,0.81865471601486,0.26942130923271,0.81662517786026,0.35653561353683,0.45387834310532,0.27551129460335,0.45020759105682,-0.84935653209686,2.225492477417,3.4630470275879,-6.3334193229675,0.039269909262657,8.3833304742598e-09,4.8773788563494e-08
1,SG Rahu,Hostile,15000,15000,0,-1,100,0,0,0,0,0,:9&8250§-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&750§-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&:-1,-1,-1:1389.0887451172,985.52075195313,1873.6368408203,-0.68945723772049,-0.024940863251686,0.7238963842392,0.1892569065094,0.9584869146347,0.21327394247055,-0.69916516542435,0.28404608368874,-0.65611606836319,0,0,0,0,0,0
1,SG Rahu,Hostile,15000,15000,0,-1,100,0,0,0,0,0,:9&8250§-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&750§-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&:-1,-1,-1:497.95657348633,980.94219970703,-236.01528930664,0.99938416481018,0.03196494281292,0.014573499560356,-0.026034750044346,0.95242595672607,-0.30365744233131,-0.023587238043547,0.30309188365936,0.95267045497894,0,0,0,0,0,0
1,SG Rahu,Hostile,15000,15000,0,-1,100,0,0,0,0,0,:9&8250§-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&750§-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&:-1,-1,-1:502.50012207031,444.89120483398,1783.6767578125,-0.99976217746735,-0.0013449247926474,0.021768424659967,0.016912292689085,0.58241301774979,0.81271719932556,-0.013771256431937,0.81289196014404,-0.58225172758102,-0.079322904348373,-9.1715831756592,-8.3134927749634,-0.02126107364893,-0,-0
1,SG Rahu,Hostile,15000,15000,0,-1,100,0,0,0,0,0,:9&8250§-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&750§-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&:-1,-1,-1:1560.4761962891,1216.4621582031,-134.83256530762,-0.44461166858673,0.033565573394299,0.89509433507919,0.079608127474785,0.99682402610779,0.0021626011002809,-0.89217889308929,0.072218306362629,-0.44587162137032,-12.260375022888,0.99243462085724,-6.1271953582764,0,0,0
1,SG Rahu,Hostile,15000,15000,0,-1,100,0,0,0,0,0,:9&8250§-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&750§-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&:-1,-1,-1:1967.5775146484,1490.1624755859,967.74774169922,-0.015821624547243,0.0021374630741775,0.99987250566483,0.011283962056041,0.9999343752861,-0.0019590419251472,-0.99981111288071,0.011251525953412,-0.015844708308578,-16.519058227539,0.56184715032578,-0.63938641548157,0.039267908781767,0.039271909743547,-2.2700987756252e-09
1,SG Rahu,Hostile,15000,15000,0,-1,100,0,0,0,0,0,:9&8250§-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&750§-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&:-1,-1,-1:2555.3361816406,1438.9107666016,905.05975341797,0.55889397859573,-0.18078395724297,0.80929273366928,0.63395726680756,0.72226411104202,-0.2764650285244,-0.53454262018204,0.66757160425186,0.51827836036682,-13.367321014404,16.685007095337,12.958599090576,0.00056615460198373,-4.3055409980897e-16,-6.3940339134483e-11
1,SG Rahu,Hostile,15000,15000,0,-1,100,0,0,0,0,0,:9&8250§-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§1,0,0,Shivan Heavy Laser,0,0,-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&750§-1,-1,-2&750§-1,-1,-2&300§-1,-1,-2&:-1,-1,-1:2628.9907226563,914.78259277344,1227.3508300781,-0.38969203829765,-0.085560120642185,0.91696220636368,-0.35064280033112,0.9344664812088,-0.061823315918446,-0.85158079862595,-0.34561821818352,-0.39415517449379,-21.289522171021,-8.6404581069946,-9.8538846969604,0,0,0
1,SFr Dis,Hostile,7000,7000,0,-1,-1,0,0,0,0,0,:9&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&700§-1,-1,-2&700§-1,-1,-2&2450§-1,-1,-2&1050§-1,-1,-2&350§-1,-1,-2&:-1,-1,-1:-12692.14453125,1075.083984375,-9313.240234375,-0.00013404585479293,0.99796831607819,0.063713036477566,0.00105993647594,0.063713148236275,-0.99796783924103,-0.99999952316284,-6.62416787236e-05,-0.0010663233697414,-42.00297164917,-0.0027823492418975,-0.044788770377636,-0,-0,-0
1,SFr Dis,Hostile,7000,7000,0,-1,-1,0,0,0,0,0,:9&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&700§-1,-1,-2&700§-1,-1,-2&2450§-1,-1,-2&1050§-1,-1,-2&350§-1,-1,-2&:-1,-1,-1:-12335.026367188,1074.5417480469,-8114.462890625,-0.00015267438720912,0.9978329539299,0.065798848867416,0.0013103621313348,0.065798997879028,-0.99783211946487,-0.99999916553497,-6.6123095166404e-05,-0.0013175681233406,-42.00297164917,-0.0027773682959378,-0.055341817438602,-0,0,-0
1,SFr Dis,Hostile,7000,7000,0,-1,-1,0,0,0,0,0,:9&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&700§-1,-1,-2&700§-1,-1,-2&2450§-1,-1,-2&1050§-1,-1,-2&350§-1,-1,-2&:-1,-1,-1:-12071.549804688,1073.9110107422,-6917.3559570313,-0.00016516138566658,0.99799358844757,0.063314735889435,0.001561131211929,0.06331492215395,-0.99799239635468,-0.9999988079071,-6.5987194830086e-05,-0.0015684560639784,-42.002956390381,-0.0027716606855392,-0.065879851579666,0,0,-0
1,SFr Dis,Hostile,7000,7000,0,-1,-1,0,0,0,0,0,:9&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&700§-1,-1,-2&700§-1,-1,-2&2450§-1,-1,-2&1050§-1,-1,-2&350§-1,-1,-2&:-1,-1,-1:-11681.903320313,1078.8231201172,-6319.19921875,-0.00018842735153157,0.99741989374161,0.071788139641285,0.0016845333157107,0.071788363158703,-0.99741852283478,-0.99999862909317,-6.7011424107477e-05,-0.0016937139444053,-42.002952575684,-0.0028146819677204,-0.071141093969345,-0,0,-0
1,SFr Dis,Hostile,7000,7000,0,-1,-1,0,0,0,0,0,:9&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&700§-1,-1,-2&700§-1,-1,-2&2450§-1,-1,-2&1050§-1,-1,-2&350§-1,-1,-2&:-1,-1,-1:-2279.6684570313,1432.3571777344,-5967.4145507813,0.0037887820508331,0.00094227399677038,-0.99999243021011,-0.00079163914779201,0.99999934434891,0.00093928113346919,0.9999925494194,0.00078807427780703,0.003789525013417,42.00269317627,0.033102300018072,0.15917903184891,0,0,0
1,SFr Dis,Hostile,7000,7000,0,-1,-1,0,0,0,0,0,:9&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&700§-1,-1,-2&700§-1,-1,-2&2450§-1,-1,-2&1050§-1,-1,-2&350§-1,-1,-2&:-1,-1,-1:-2695.1577148438,1432.0119628906,-6573.1518554688,-0.0044539640657604,0.00052171957213432,-0.99998992681503,-0.00079270644346252,0.99999958276749,0.00052525533828884,0.99998980760574,0.00079503800952807,-0.0044535486958921,42.002578735352,0.033392697572708,-0.18706528842449,0,0,0
1,SFr Dis,Hostile,7000,7000,0,-1,-1,0,0,0,0,0,:9&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&700§-1,-1,-2&700§-1,-1,-2&2450§-1,-1,-2&1050§-1,-1,-2&350§-1,-1,-2&:-1,-1,-1:-3007.9592285156,1431.8013916016,-7171.7045898438,-0.012268927879632,0.0037197540514171,-0.99991780519485,-0.00073440955020487,0.99999284744263,0.0037290442269295,0.99992454051971,0.00078010058496147,-0.012266108766198,41.999839782715,0.032766491174698,-0.51521396636963,-0,-0,-0
1,SFr Dis,Hostile,7000,7000,0,-1,-1,0,0,0,0,0,:9&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Shivan Light Laser,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&140§1,0,0,Standard Flak,0,0,-1,-1,-2&700§-1,-1,-2&700§-1,-1,-2&2450§-1,-1,-2&1050§-1,-1,-2&350§-1,-1,-2&:-1,-1,-1:-3320.037109375,1431.6094970703,-7765.5537109375,-0.020158337429166,0.0045972722582519,-0.99978625774384,-0.0006685794214718,0.9999892115593,0.0046116858720779,0.99979662895203,0.00076140038436279,-0.020155046135187,41.994464874268,0.031982272863388,-0.84656834602356,0,0,0
I looked in fs2_open.log and the script seems to know about the variables, at least. (I wish the logging used newlines here, but at least I can follow what it's doing):
random-seed,n,698random-seed,n,698&proximity_state,n,1random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863&ShipRecordBitfield_64_95,n,1010270175random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863&ShipRecordBitfield_64_95,n,1010270175&ShipRecordBitfield_96_127,n,968random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863&ShipRecordBitfield_64_95,n,1010270175&ShipRecordBitfield_96_127,n,968&StealthStateInAsteroids,n,0random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863&ShipRecordBitfield_64_95,n,1010270175&ShipRecordBitfield_96_127,n,968&StealthStateInAsteroids,n,0&StealthFlank,n,200random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863&ShipRecordBitfield_64_95,n,1010270175&ShipRecordBitfield_96_127,n,968&StealthStateInAsteroids,n,0&StealthFlank,n,200&StealthFront,n,300random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863&ShipRecordBitfield_64_95,n,1010270175&ShipRecordBitfield_96_127,n,968&StealthStateInAsteroids,n,0&StealthFlank,n,200&StealthFront,n,300&StealthScene,n,1random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863&ShipRecordBitfield_64_95,n,1010270175&ShipRecordBitfield_96_127,n,968&StealthStateInAsteroids,n,0&StealthFlank,n,200&StealthFront,n,300&StealthScene,n,1&TargetACGLV,n,9random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863&ShipRecordBitfield_64_95,n,1010270175&ShipRecordBitfield_96_127,n,968&StealthStateInAsteroids,n,0&StealthFlank,n,200&StealthFront,n,300&StealthScene,n,1&TargetACGLV,n,9&TargetAS,n,4random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863&ShipRecordBitfield_64_95,n,1010270175&ShipRecordBitfield_96_127,n,968&StealthStateInAsteroids,n,0&StealthFlank,n,200&StealthFront,n,300&StealthScene,n,1&TargetACGLV,n,9&TargetAS,n,4&TargetBhavisal,n,1random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863&ShipRecordBitfield_64_95,n,1010270175&ShipRecordBitfield_96_127,n,968&StealthStateInAsteroids,n,0&StealthFlank,n,200&StealthFront,n,300&StealthScene,n,1&TargetACGLV,n,9&TargetAS,n,4&TargetBhavisal,n,1&TargetCP,n,4random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863&ShipRecordBitfield_64_95,n,1010270175&ShipRecordBitfield_96_127,n,968&StealthStateInAsteroids,n,0&StealthFlank,n,200&StealthFront,n,300&StealthScene,n,1&TargetACGLV,n,9&TargetAS,n,4&TargetBhavisal,n,1&TargetCP,n,4&TargetErebos,n,0random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863&ShipRecordBitfield_64_95,n,1010270175&ShipRecordBitfield_96_127,n,968&StealthStateInAsteroids,n,0&StealthFlank,n,200&StealthFront,n,300&StealthScene,n,1&TargetACGLV,n,9&TargetAS,n,4&TargetBhavisal,n,1&TargetCP,n,4&TargetErebos,n,0&TargetFreighters,n,4random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863&ShipRecordBitfield_64_95,n,1010270175&ShipRecordBitfield_96_127,n,968&StealthStateInAsteroids,n,0&StealthFlank,n,200&StealthFront,n,300&StealthScene,n,1&TargetACGLV,n,9&TargetAS,n,4&TargetBhavisal,n,1&TargetCP,n,4&TargetErebos,n,0&TargetFreighters,n,4&TargetMiners,n,6random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863&ShipRecordBitfield_64_95,n,1010270175&ShipRecordBitfield_96_127,n,968&StealthStateInAsteroids,n,0&StealthFlank,n,200&StealthFront,n,300&StealthScene,n,1&TargetACGLV,n,9&TargetAS,n,4&TargetBhavisal,n,1&TargetCP,n,4&TargetErebos,n,0&TargetFreighters,n,4&TargetMiners,n,6&TargetPCargo,n,16random-seed,n,698&proximity_state,n,1&AkihamCargoScanned,n,1&FighterProxBitfield,n,12288&ShipRecordBitfield_0_31,n,-2129657859&ShipRecordBitfield_32_63,n,2147438863&ShipRecordBitfield_64_95,n,1010270175&ShipRecordBitfield_96_127,n,968&StealthStateInAsteroids,n,0&StealthFlank,n,200&StealthFront,n,300&StealthScene,n,1&TargetACGLV,n,9&TargetAS,n,4&TargetBhavisal,n,1&TargetCP,n,4&TargetErebos,n,0&TargetFreighters,n,4&TargetMiners,n,6&TargetPCargo,n,16&TargetSCargo,n,14Frame 5462 too long!!: frametime = 1.335 (1.335)
It looks like it's saving variables just fine up until it gets to TargetTotal. Then, at least, it stops writing to the log. It still saved Auroch4State despite this variable not appearing in the log.
-
This is strange. Besides the fact that only the last variable is properly saved, the script tried to save maybe half of the variables you actually wanted to save.
I'll fix the problem later today.
Edit: Looking at my script I think I have an idea why this happens. The script didn't have variable saving at first. To be able to use old files with a newer script version I added some compatibility functions that also convert old files. This somehow deletes the saved variables when saving a ship and corrupts the savefile :banghead:
-
Updated first post with a download link to the new version that should fix this issue.
-
Indeed, it fixes it. Thanks!
-
Actually, one additional question. How well does this script handle loading the status of docked ships?
-
Back when I made the script it was not possible to properly detect the docking status of ships so the script ignores it. If you load two ships that were docked it will position them as if docked but they might bounce off each other afterwards...
-
Ok, no worries, I realized that I can check the mission variables and then call set-dock on the proper ships.
One suggestion for a possible future version: separate the table creation and population from the file saving. That way, rather than writing the file to disk every time saveship or sval is called, you would just defer that and have the FREDder call a savefile function at the end.
Another suggestion is to specify the filename and other parameters in the script parameters rather than in sexp variables. The new(ish) script-eval-block lets you make longer function calls.
-
Well, the script is more than 6 years old and I would do many things different today. Especially the limited length of a scripting call required several workarounds that are not necessary anymore.
Both of your suggestions don't seem to be hard to implement there is still the issue of backwards compatibility. All missions have to be changed, old savefiles might be broken,... People also use ScreenCam which comes with this script, so if the mod used an older version saving/loading might not work anymore.
The question is how many people use this script at all and if there is any real interest in an improved version. If yes then I would do the modifications...
-
Your ship save script is amazing and the cornerstone of our checkpoint system, so there is at least one modding team that has an interest in anything you can do to improve it!
-
Likewise. BtA makes heavy use of it.
-
BtA, BP and whatever Goober does are the projects using the script that I know of.
Goobers suggestions won't add any features or actual functionality to the script. It would just streamline how the script works internally and how it is used in FRED. This means that I have to change a lot and you would have to modify all missions with checkpoints.
My question is if there is any real need for these things. A reason could be that the script slows down the game due to too many savecalls or feature ideas/additions that would be easier to use/implement in a modified script. Otherwise it would just create work for me and the modding teams while the script was already fine before.
What I have in mind is a structure like:
openfile 'filename' (loads data from a file into temporary table, without 'name' just creates an empty table or clears the table)
saveship/savevar 'name' (saves shipdata/variable from mission in temporary table)
loadship/loadvar 'name' (loads shipdata/variable from temporary table into mission)
savefile 'filename' (saves temporary table in file)
removeship/removevar 'name' (removes shipdata/variable from temporary table)
-
I'm using the script for two missions in Scroll of Atankharzim so far, and I will almost certainly use it for more. One of these missions has two checkpoints and would have been quite intractable to playtest without the script.
Your proposed changes sound good. They are not, strictly speaking, needed, since the script is very satisfactory already (especially now that you've fixed the variable saving). But they would definitely be appreciated and would improve the ease-of-use of the script for future missions.
The deferred file writing would be welcome. The complicated Scroll mission I mentioned has a noticeable freeze for about a half-second when a large checkpoint, involving lots of variables and ships, is saved.
I don't think you would need to worry about backwards compatibility. Just create a new script with a new filename, and make sure that all the function calls are different from the old ones. To make this obvious, you could use e.g. saveship2 rather than the original saveship. You should not need to worry about the savefile format because presumably only newly released missions would use the new savefile.
-
I thought I'd post my version (http://staff.hard-light.net/goober5000/downloads/shipsaveload-sct.tbm) of the ship save/load script. The only major change is to implement the deferred file writing I mentioned above, since I encountered significant pauses in both Scroll and Deneb III when using the script in certain missions. With this new version, the pauses are not noticeable.
The new functionality required a few changes to the API. When saving a file, you must call save_init before all of the save calls, followed by save_done after all of them. (The save_done call is what actually writes the data to the file.) When loading a file, you must call load_init before all of the load calls. There is no corresponding load_done.
NB: In this script, I used "Invisible Target" instead of "Shipsave" for the temp class ship entry.
-
Oh, so you already made these changes, that's nice :)
I'll add your version to the package, update the readme and maybe rename the shipclass back to Shipsave for consistency. You could have sent me a PM though - I didn't notice any new posts in here despite checking the forum nearly every day.
-
Oh, well, I thought you would have thread notifications enabled.
(Actually, we have had issues with the forum not sending emails to some members, so you may not have seen it.)
-
Bump to let people know about my rewritten version (https://www.hard-light.net/forums/index.php?topic=96939.0) of this script.