The Dink Network

Reply to Re: variables (reserved names?) and a question

If you don't have an account, just leave the password field blank.
Username:
Password:
Subject:
Antispam: Enter Dink Smallwood's last name (surname) below.
Formatting: :) :( ;( :P ;) :D >( : :s :O evil cat blood
Bold font Italic font hyperlink Code tags
Message:
 
 
April 4th 2018, 12:21 PM
peasantm.gif
shevek
Peasant They/Them Netherlands
Never be afraid to ask, but don't demand an answer 
You probably want to know a bit more of what scripts are, because they are _weird_. Local does not mean what you think it does. So I'll try to explain the weirdness:

There are scripts in memory, and every script is attached to an active (non-background) sprite on screen. In addition to normal sprites, they can be attached to special sprited 0 and 1000. Sprites also have a script associated with them. In the normal case each sprite has 0 or 1 scripts attached to it, and it also links back to that same script, or it has none if nothing is attached to it. I'm not sure if it is possible to have more than one script attached to a sprite, or if a script can be attached to a sprite without being "the script of that sprite". So let's assume that is not possible.

Only one script is running at a time, and it never takes long. It stops running when it is either waiting or its program ended. In both cases, it is still active! If it is waiting, there is a timer that will make it continue when it expires; otherwise it will not do anything until there is an event.

Now events are weird: they interrupt whatever the script was doing and instead start running from the event entrypoint. For example, when a sprite is hit with a weapon and it has a hit() function defined, it will start running that function. When that function is done, it does NOT return to the thing it interrupted; that thread of execution is lost forever. This is a common way to break DMods: trigger events during a cut scene and the cut scene will never finish. (A properly written DMod will make sure this cannot happen.)

So all that is weird enough; now how do the variables work? There are globals, which work as expected: every script can access them. Local variables are local to a script. This means that every function in that script can access them, but if the same file on disk is instanced multiple times, they cannot access each other's local variables. This can happen for example when multiple monsters of the same type (and thus with the same script file) are created. Each one gets a unique script from the engine (with its own number), and thus with its own local variables. But again, a local variable created in main() can be accessed from hit() or talk() or any other function within the same script.

Now attach_script will change what sprite a script is attached to (and thus from which it receives event triggers). As I wrote above, there are two special values: 0 and 1000. There is no sprite with those numbers (because Seth hated 0 and started all his array indices at 1, and because the number of sprites is limited to 300 IIRC), but they have a special meaning. The thing is, when a sprite is deactivated, its script dies. A script may want to kill its own sprite, for example, and do some things after that. This is not possible as long as it is attached to the sprite. When attached to "sprite" 0, it will die when the player leaves the screen (or when it is killed, obviously). For "sprite" 1000, it never dies at all, so it must be killed.

Some events trigger scripts that are not attached to a sprite, such as talking when there is no sprite nearby. Those events should always use kill_this_task() at the end to avoid filling up the script slots.

Final note: except for normal events, it is also possible to generate an event from another script. This can be done using run_script_by_number(). It takes a script number and a function name. It runs a function in that script just like an event would have started a function in it: it aborts whatever it is doing and starts running the function instead.

Super-final note: If a timed wait is interrupted by an event that waits for a key (for example say_stop), the timer is not cancelled and when it expires it behaves as if a key was pressed (that is, say_stop completes and the next instruction starts executing).