Yeah, J'Kla's reply was a bit stingy, but I'm sure that was just poor wording and he didn't mean it. Let's just let it slide
Anyway, as promised, here is a complete, unabridged version of what SDLs can do for you.
SDL stands for State Description Language. In other words, it's a language that describes the state of an Age (as in, "in what state did you leave this Age"). That information is stored in an encrypted text file, with the appropriate extension ".sdl". PlasmaShop can open those.
When you explore an Age, information about each interactable object is stored in a variable. For instance, whether a door to a house is opened is stored in a variable "houseDoorIsOpen" which can be either true or false. I'll reuse that door example a lot, but this includes a lot of other mechanisms - think the pillars in Kadish Tolesa, or the elevator level in Teledahn.
Without these variables, the engine wouldn't even know that this door can be opened, or it would forget as soon as you link out.
It's worth noting that when people talk about SDL, they are referring to ONE of those two things:
- the variable that stores the object's state (as in "SDL variable")
- the file that lists all these variables (as in "SDL file")
Note that the SDL file only
describes what objects can be stored; it doesn't
store whether that house door is opened or closed. Storing those variables is done in the "Vault", which is a particular region of the avatar's save (or a special save on the server for public Ages).
SDL
variables are useful for the following:
- persistence ("saving") of puzzles - if you didn't have it your puzzles would reset when you re-link to the Age.
- still on the topic of persistence: sharing this "save" of the Age with others - if a door is open you can be sure it's open for people who will link after you (otherwise you'd see an open door when he sees a closed one, because he himself hasn't opened it yet).
- real-time synchronization. If you were to open the door, your game would tell the server to "flip" the associated variable (toggle it on or off). The server stores that value, then tells all players in the Age "hey, that variable has changed, folks". Then each game on each PC will react by thinking "that variable has changed, so someone must have opened the door. I'll now display the door opening".
SDL
files are useful for the following:
- listing which SDL variables exist (obviously) - you can't use a variable if it hasn't been declared in the SDL
- what is stored in these SDL variables. A simple "on/off" state ? A number ? A name ? etc
- the default value of those variables. When you link to the Age for the first time, this will tell the game what doors to open or close. This is only used once, as once you have messed up with those doors we want them to stay as-is.
So, the obvious question is, how to use SDLs in my Age ?
Well, one thing you should know, is that SDL variables are
ONLY accessible to Python scripts, not PRPs.
However the good news is that Cyan already wrote simple Python scripts to handle common interactions - which means you don't have to ! Those scripts are also optimized to ensure you don't spam the server with synchronization messages, which is a Good Thing. You just have to call those Python scripts from within a Korman NodeTree... But we'll get to this topic later ! hehehe...
Yeah, correctly setting up SDLs and binding those NodeTrees to Python scripts can be a bit long to explain, and I haven't tried it yet anyway. So I'll get to it some other time...
Addentum:
It's worth noting that persistent animations (animations that don't reset when you re-link to the Age, and that are synchronized between players) are also stored as SDL variables. However, those SDLs are automatic and you don't need to worry about it.
By default animations aren't synchronized because synchronized anims can COMPLETELY detroy server performance if used wrong. Usually you DON'T need synchronized animations, because Cyan's scripts do a much better job of "locally" triggering the animation using their own synchronization system, without the overhead that true synchronized animations have.