Author Topic: ship save/load script  (Read 31812 times)

0 Members and 1 Guest are viewing this topic.

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...
Here goes scripting and copy paste coding
Freespace RTS Mod
Checkpoint/Shipsaveload script

 

Offline Zacam

  • Magnificent Bastard
  • Administrator
  • 211
  • I go Sledge-O-Matic on Spammers
    • Minecraft
    • Steam
    • Twitter
    • ModDB Feature

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)
Report MediaVP issues, now on the MediaVP Mantis! Read all about it Here!
Talk with the community on Discord
"If you can keep a level head in all this confusion, you just don't understand the situation"

¤[D+¬>

[08/01 16:53:11] <sigtau> EveningTea: I have decided that I am a 32-bit registerkin.  Pronouns are eax, ebx, ecx, edx.
[08/01 16:53:31] <EveningTea> dhauidahh
[08/01 16:53:32] <EveningTea> sak
[08/01 16:53:40] * EveningTea froths at the mouth
[08/01 16:53:40] <sigtau> i broke him, boys

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
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
« Last Edit: February 26, 2011, 03:36:14 am by Nuke »
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline m!m

  • 211
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:

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
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 no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline WMCoolmon

  • Purveyor of space crack
  • 213
Re: ship save/load script
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.
-C

 
Re: ship save/load script
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).

Quote

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...
Here goes scripting and copy paste coding
Freespace RTS Mod
Checkpoint/Shipsaveload script

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: ship save/load script
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

Code: [Select]
$lua block name:  block1
 +script: [
 --script goes here
 ]

and then have it so you can call certain embedded blocks from the sexp.

Code: [Select]
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.
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline WMCoolmon

  • Purveyor of space crack
  • 213
Re: ship save/load script
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.

Code: [Select]
<funcname>(<arg1>, <arg2>, <arg3>)
I think that solves the problem.
-C

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: ship save/load script
so it wouldnt really care what the args are at all, it would just be passed as text.
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 
Re: ship save/load script
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.
Here goes scripting and copy paste coding
Freespace RTS Mod
Checkpoint/Shipsaveload script

 

Offline m!m

  • 211
Re: ship save/load script
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?

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: ship save/load script
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.

Code: [Select]
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:

Code: [Select]
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.
« Last Edit: April 29, 2011, 09:36:51 am by Nuke »
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline The E

  • He's Ebeneezer Goode
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: ship save/load script
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.
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: ship save/load script
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.
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 
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
Here goes scripting and copy paste coding
Freespace RTS Mod
Checkpoint/Shipsaveload script

 

Offline jr2

  • The Mail Man
  • 212
  • It's prounounced jayartoo 0x6A7232
    • Steam
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.
Here goes scripting and copy paste coding
Freespace RTS Mod
Checkpoint/Shipsaveload script

 
Re: ship save/load script
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.
Here goes scripting and copy paste coding
Freespace RTS Mod
Checkpoint/Shipsaveload script

 

Offline mjn.mixael

  • Cutscene Master
  • 212
  • Chopped liver
    • Steam
    • Twitter
Re: ship save/load script
Only if its a new load type (stat or whatever).
Cutscene Upgrade Project - Mainhall Remakes - Between the Ashes
Youtube Channel - P3D Model Box
Between the Ashes is looking for committed testers, PM me for details.
Freespace Upgrade Project See what's happening.