Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Lepanto on January 08, 2016, 04:15:28 pm
-
Hello all. This FREDder thanks you for keeping FSO running, and for coming up with new features and SEXPs we can use in our campaigns.
----------
What's the basic structure of a SEXP?
I'm making an indie space shooter in Unity. Since SEXPs are so flexible and powerful, I'd like to incorporate a similar system into my game. Not copying any FSO code, or doing anything that violates the FSO license; just using the same "if this is true, then this happens in the mission" kind of format.
To that end, can someone tell me what the basic code structure/flow of a SEXP is? How does it get from "game inserts input" to "this effect happens in the game"? I'm a coding newb (only know a little C#, which is what I'm using), so it'd be hard to poke around in the code and find out for myself.
Thanks for your help and patience.
-
From what I know, it's basically a Common LISP interpreter with a number of game-specific functions. That's why it's so ridiculously powerful. It doesn't support all of Common LISP, but there were talks of implementing something like that.
-
If you have even the slightest understanding of code, sexp.cpp is actually one of the more straightforward pieces of code in the codebase; it's almost entirely self-contained, too, so you don't have to keep switching back and forth between different files to follow what's going on most of the time (the only other file you really need to consult most of the time is sexp.h).
Basically, though, the basic structure works something like this:
- Something (game loop checking events, arrival cue checking whether a ship can jump in, campaign file checking which mission to advance to, whatever) wants to evaluate a SEXP.
- The SEXP code looks at which operator it is, and calls the appropriate function (this is a giant switch statement).
- This function goes through the nodes of the SEXP, doing the effects of the SEXP and/or performing whatever calculations it's supposed to perform, and then returning the expected result. This can result in those nodes being themselves evaluated as SEXPs, taking us recursively back to step 1.
- The result of the SEXP is handled (certain results get cached so that conditions that can never become true don't have to be evaluated again, for instance; if you're curious, these cached results are checked before step 2) and the ultimate result is finally returned to whatever wanted to evaluate the SEXP in the first place.
There's a lot more code in sexp.cpp, but outside of these steps, that code is used solely for FRED: validating arguments, providing in-editor help explaining what the various SEXPs do, et cetera.
-
Thanks, all. This should be helpful.