The Dink Network

variables (reserved names?) and a question

April 3rd, 03:08 PM
i see things like &mcrap which i feel is probably a reserved variable name by how it is being used in scripts,

Am I correct, in that assumption ?

if i am what is &mcrap and the others like it referencing?

if i am wrong, or if i am right ...

I assume if you say ... int timer = 0; in a script and use a kill_this_task()

you could say reuse the timer var, in a different script without conflict?
April 3rd, 04:20 PM
Peasant Male Japan xbox steam bloop
Responsible for making things not look like ass 
variables that aren't global are localized to that specific script instance. So if you have a timer int in multiple scripts it wouldn't affect it. You could call the same script several times so you'd have multiple instances of it and the timer int wouldn't interfere with the other scripts.

If you want to use the value of one timer's value in another script you have to send that value over to that script somehow. The easiest method would be to store it it some recyclable global int like &mcrap and then pull the value.

I'm not entirely sure what you're trying to do, but did that help?
April 3rd, 04:39 PM
&mcrap is just a local variable. Seth used that name a lot for some reason.
April 3rd, 05:17 PM
Peasant Male Japan xbox steam bloop
Responsible for making things not look like ass 
Well, the idea is to just use a recyclable global. I've used both &save_x and &save_y for recycling values, so those can be a good alternative.
April 4th, 01:42 AM
ya i follow, I had sorted it out.. seen posts so i checked to see what was said..

no *plan* as of yet only ideas, right now seeing what is and is not possible ... I've smashed the game and the editor a few times now rather intentionally.

if you use attach_script(1000) for how long will it last?

could you use it to store variables as fake global? until say another script was called.
April 4th, 11:33 AM
Peasant Male Japan xbox steam bloop
Responsible for making things not look like ass 
attach_script(1000) will last indefinitely. I think it only closes once you exit/reload the game(could be wrong).
Regardless, it's a good practice to always have a kill_this_task() at the end of a script that uses attach_script(1000);

Hmm, I don't know if you could use it to store variables efficiently. I suppose you could have a control sprite on each screen and use the persistent script to carry the values over from one screen to another. This way the persistent script would always be able to find and assign values to a consistent object. It seems like that would work.
April 4th, 11:45 AM
Peasant Male United States bloop
2nd generation. No easy way to be free. 

Perhaps my response to another one of your postings [Re: is there a make_global_int max? (simulating extra globals)] is what you are looking for in terms of "fake global" variables?

April 4th, 12:21 PM
Peasant 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).