That way all the functions will be ready for any script to use right away. I like to put down any function definitions in $On Game Init. So basically when our application is FS2_Open (which will be… always), during game initialization do this stuff between the square brackets. So I put down #Conditional Hooks, and the condition is $Application: FS2_Open, and our action is $On Game Init. There's also other game-wise benefits to using Conditional Hooks, this part from the scripting.tbl wiki page sums it up well enough. Conditional Hooks will only check actions that we define later if the condition is met. State Hooks aren't really used anymore, the Conditional Hooks are more flexible and better. I'd advise staying away from Global Hooks unless you really know what you're doing. Global Hooks run regardless of state or condition. There are Global Hooks, State Hooks, and Conditional Hooks. The -sct.tbm will clue FreeSpace in that this is a Lua scripting file.įirst we need to tell the game what type of hook we're going to run. I like to just create smaller modular scripting tables.īelow is the basic framework of a script, saved as sexplibrary-sct.tbm. You could stuff all your scripts into a single scripting.tbl, but it might get pretty large and unwieldy if you add a lot of Lua. This will not be the only correct way to do things, but it’s a way that I feel is easily readable and accessible. There's quite a few ways you can run Lua scripts. That way we can just use a single script-eval function and, presto! Those sexps will all get run, no muss, no fuss. Such a pain, right? Let's rectify this by allowing us to combine all the sexps we would use into a single Lua function. So what do you do? Add 5 sexps that lock player weapons, afterburner, ETS etc etc. Press an ETS key and hear that immersion breaking sound. Watch it, and accidently slip and press primary fire and hear your Subachs fire. We've all been there haven't we? Make an in-game cutscene. Properly cloaking a ship (linking the stealth with the visual effect). Lockdown the player's fighter's for in-game cutscenes and 2. The SEXP library we make will contain 2 groups of SEXPs: 1.
The concept of a SEXP library is simple: we have some SEXPs that we want to use in multiple missions, and instead of copy and pasting them in multiple missions, we will store them in a Lua function that can be called upon in any mission and be executed. Let's do something that is still simple but is also something you could actually use in your campaign, a SEXP library. So what is our first project going to be? A super lame "Hello World" script? Those are so overdone. This will be very valuable to us, it lists all of the game accessible information we can use for our nefarious purposes. In your FreeSpace directory will be a scripting.html file. Go into your launcher and in the Dev Tool section, tick the "Output scripting to scripting.html" box. First is a good text editor, I suggest Notepad++! You should also generate a scripting.html file from FreeSpace. If I want to do X with Lua, how would you even begin?įirst we need a few tools.
There's just very little in the way of how FreeSpace and Lua interact with each other. There's a lot of basic Lua tutorials around the internet, so I'm not going to get into the specifics too much.
Lua runs a more unregulated campaign and, if you're not careful, can spew out baffling error messages that leave you clueless even after an hour on Google. FreeSpace has a lot of error checking and can handle any dumb SEXP efforts with a shrug. It allows a certain amount of freedom that SEXPs don't allow, but on the other hand Lua is a lot more, let's say, risky. One of the coolest things that's been added to FreeSpace Open is the Lua scripting language.
0 kommentar(er)
