[mjn.mixael]

Admiral MS, why are optional Stat 3 and 4 not recommended currently? (Just curious)

[General Battuta]

This tutorial thread has taught me a lot, my technique is disappointing and would be better handled by LUA

[mjn.mixael]

Wut, no. Your technique is still quite valid. Just instead of using like 50 PPVs we can just do script-evals. The rest of the 'how-to' is still very relevant.

[Admiral MS]

Admiral MS, why are optional Stat 3 and 4 not recommended currently? (Just curious)

I'm not exactly sure why, I made the script over a year ago. But as far as I remember Freespace had the habit of crashing randomly when using these and I couldn't figure out why. If I think about it the reason could be as well that the engine was unhappy about all the manipulation work going on at the same time 
I guess it's as safe to use them as is the whole script. The sample missions are using both stat 3 & 4 without problems anyway.

This tutorial thread has taught me a lot, my technique is disappointing and would be better handled by LUA

Actually I thought about extending the script to cover some more stuff like recreating SEXP states but I have absolutely no idea how that should work 
So you still need proper fredding as described in your tutorial to make anything like a checkpoint work. The script helps going around the PPV cap and simplyfies the process of saving and loading to one SEXP for each.

The reason for creating the script wasn't checkpoints at first but getting rid of buggy red-alert and still transport shipdata to the next mission and if possible even in the mission simulator.

[Goober5000]

Wut, no. Your technique is still quite valid. Just instead of using like 50 PPVs we can just do script-evals. The rest of the 'how-to' is still very relevant.

The new sexps Battuta mentioned should significantly reduce the number of variables you need.

[Admiral MS]

Admiral MS, why are optional Stat 3 and 4 not recommended currently? (Just curious)

I'm not exactly sure why, I made the script over a year ago. But as far as I remember Freespace had the habit of crashing randomly when using these and I couldn't figure out why.

Took a look at it again. There are two reasons: Depending on the mod and mission you may need to change entries directly in the script. Stat 3 & 4 need a shiptype and coordinates to place it before destroying it or sending it into subspace.
Second reason is that the Fredder needs to be really careful to prevent any unwanted influence on other SEXPs. I'm not sure if the script can get something wrong as a consequence. It uses SEXPs itself to determine whether a ship has departed or is destroyed.

Wut, no. Your technique is still quite valid. Just instead of using like 50 PPVs we can just do script-evals. The rest of the 'how-to' is still very relevant.

The new sexps Battuta mentioned should significantly reduce the number of variables you need.

I already asked this but no one answered. Which SEXPs were added and what can they do older ones can't?

[General Battuta]

You can alter individual characters in a string.

[Goober5000]

I already asked this but no one answered. Which SEXPs were added and what can they do older ones can't?

Sorry, missed it.

What Battuta said.  Take a look at all the uncategorized sexps in the latest FRED build.  The int-to-string, string-to-int, string-get-substring, string-set-substring, string-concatenate, and string-get-length sexps will all help here.

[karajorma]

They really should be categorised.

int-to-string
string-to-int
string-get-substring
string-set-substring
string-concatenate
string-get-length

It's not like figuring out what to call the category should be an issue.

[Admiral MS]

These sexps are really interesting. Still they sort of belong together with the other variable sexps like variable-array-set. My suggestion is putting them into a variables category 

Am I right that with variable arrays and these new sexps you can get as much variables as you need?
So the main difference using a script like the one I made is that there won't be tons of sexps confusing fredders (instead a short ( script-eval "saveship('Alpha 1')" ) or ( script-eval "loadship('Alpha 1')" )) and the ability to save and change some data sexps can't access at the moment?

[Snail]

string to int and int to string sound like awesome awesome sexps

[Goober5000]

These sexps are really interesting. Still they sort of belong together with the other variable sexps like variable-array-set. My suggestion is putting them into a variables category 

Indeed... good suggestion.  This will also allow us to categorize the modify-variable sexp.

Am I right that with variable arrays and these new sexps you can get as much variables as you need?

No, you are still limited to 200 (or whatever) variables total.  But these sexps let you pack a lot more information into each string variable.

The funny thing is, you can only store 7905 bits of information in a string variable (31 * (2^8 - 1)), compared with 4294967296 bits of information in a numeric variable (2^32).  But most people will find character combinations much more intuitive to work with than numbers.

[karajorma]

Problem is that String-to-int has bugger all to do with Variables. In fact I've never once used it with a variable even though I've used it multiple times.

In addition, if someone ever adds a String return type they'll all be in the wrong place.

[Goober5000]

Problem is that String-to-int has bugger all to do with Variables. In fact I've never once used it with a variable even though I've used it multiple times.

Except that this is the only sexp that works with strings that doesn't put something in a string variable.  For the sake of grouping all the string sexps together, it should be in the same place.

And if someone adds a string return type we'll have to make new sexps for all the others anyway, so that would be an excuse to recategorize them.

[karajorma]

Or we could do it right in the first place.

[Admiral MS]

Whatever you do, please put all of them somewhere together! 
string-to-int is located in status category, int-to-string in change category and it's the same with the script-eval sexps (script-eval in change and script-eval-string/num in status). In case a sort of variable transformation like string-to-int feels too far away from variables, then create a string category, a variables category and a scripts category inside change or whatever. Just give it some organisation.

And if someone adds a string return type we'll have to make new sexps for all the others anyway, so that would be an excuse to recategorize them.

Script-eval-string returns a string, though it's not something like standard sexp. I can't see why you have to make new sexps in case someone adds a string return type?

[Goober5000]

Whatever you do, please put all of them somewhere together! 
string-to-int is located in status category, int-to-string in change category and it's the same with the script-eval sexps (script-eval in change and script-eval-string/num in status).

That part can't be helped because the Change category is for sexps that perform actions as opposed to returning values.  You'll find many other sexps split up that way where one is a "set" and one is a "get".

Script-eval-string returns a string, though it's not something like standard sexp. I can't see why you have to make new sexps in case someone adds a string return type?

The string return capability doesn't work.  Take a look at this excerpt from the code:

Code: [Select]

case OPR_STRING:
Error(LOCATION, "SEXP system does not support string return type; Goober must fix this before script-eval-string will work");
It appears WMC (the author of the above) is trying to blackmail me.   He does have a bit of a point; I can think of a rather clever way to return string values (as well as decimals and whatever else) without rewriting the whole sexp system.  I just haven't gotten around to actually coding it.

[Admiral MS]

That part can't be helped because the Change category is for sexps that perform actions as opposed to returning values.  You'll find many other sexps split up that way where one is a "set" and one is a "get".

Feels like I'm at a loss here with my somewhat basic programming knowledge but oh well, it can't be changed anyway.

The string return capability doesn't work.  Take a look at this excerpt from the code:

Code: [Select]

case OPR_STRING:
Error(LOCATION, "SEXP system does not support string return type; Goober must fix this before script-eval-string will work");
It appears WMC (the author of the above) is trying to blackmail me.   He does have a bit of a point; I can think of a rather clever way to return string values (as well as decimals and whatever else) without rewriting the whole sexp system.  I just haven't gotten around to actually coding it.

Someone should have changed the description in FRED to something like: doesn't work at the moment...

[mjn.mixael]

So I finally got around to this. I injected checkpoints into previously made missions... (which was not an easy task for missions that weren't designed with checkpoints in mind)... But it works! Admiral MS's script is totally win. I made the checkpoint with only 4 variables. I highly recommend others checkout this powerful script tool.

Admiral MS, why are optional Stat 3 and 4 not recommended currently? (Just curious)

Question answered. FSO may not mind this so much with 1 or 2 ships at a time, but doing it for 5 or more definitely screws some things up. I'd recommend saving Stat types 3 and 4 for ships that absolutely need to show as destroyed or departed.

[Admiral MS]

After getting some suggestions from mjn.mixael I modified the script to include filemanagement. Now it's possible to have a different savefile for every mission. Another function was added to check whether a certain file does exist or not. That way the script works fine with multiple checkpoints or checkpoints used for playing missions in the simulator.
I fixed a few other things and made a easier to understand readme

Download here:
http://www.mediafire.com/?ekf69ed865skpf3