Plan for script multitasking

To support script multitasking, each script "thread" will have separate execution information: the list of running scripts (currently scrat), a private stack for arguments and state information, and probably space for local variables (if each script instance doesn't get it's own buffer for locals).

Now each triggered script will run in its own thread. So a map autorun script containing a loop will be able to check if the player has left the map so it should stop, even if another looping map autorun script was triggered. This will of course break a great many games, so it will be turned on by a general bitset which will be off for old games and on for new games.

Execution order

New triggered threads should be set to run before all current ones. That way, onkeypress scripts are run first, and the current script order is preserved: the mapautorun script of the first map runs before the newgame script.

However, script threads started from other scripts are tricky. Should they run last? After the current thread? First? If this is specifiable, what should the default be? And should/could they pause the current thread and run for a tick?

Hazards

Some commands, like teleporttomap, imply a wait, and others set variables to trigger an effect when they finish, like showtextbox. Needs thought.

The script debugger would need a lot of attention to handle threads.

New script commands

A tentative list of suggested new commands to handle threads:

Missing are commands to check what threads are currently running, and to manipulate the order they run in. Possibly the ability to switch temporarily between threads?

new script thread (@scriptname, arg1, arg2, ...)

Create a new script thread, and return a number which can be used to identify it. Possibly create a nicer way of running the script, so that default args can still be checked and used, maybe something like

thread := new thread (carnival npc walk (npc, west))

On the other hand, still being able to run scripts by ID would be a plus.

pause thread (thread)

Stop a thread from being executed. For example, if you want the current and another thread to wait for something, you could do:

pause thread (thread)
wait for npc (npc)
unpause thread (thread)

pause all threads

Pause all other threads.

kill thread (thread)

Kill off a whole thread, ending all scripts in it. Could be used to kill the current thread (prehaps a command to get an id for the current thread? But would it have other uses?)

exit thread

Kill off current thread. This could be used if multitasking threads were not enabled, killing all scripts.

pause script triggers

Stop triggering scripts (by game events). This would also be useful if multitasking were disabled.

Blocking scripts

A general bitset will disable threading for old games, so backwards compatibility will not be affected.

However, to ease the transition from blocking scripts to threading scripts for authors of existing games, we can add a new script trigger type, such as blockingscript. A blockingscript will be triggerable anywhere that a regular script is usable, and it will pause any other blockingscripts until it is finished.

A game author who wishes to convert their existing scripts to use threads can do the following:

1. Change all their instances of "plotscript, scriptname, begin" to "blockingscript, scriptname, begin"
2. Change the general bitset to enable threads for their RPG
3. Convert instances of blockingscript back into plotscript one-at-a-time, with testing.

It might make sense to make old-style scripts defined with "define script" always be blocking scripts.

See Also

• Development Plans