Hi there, I'm currently designing my little scripting language (and browsing though the forum, who isn't :)). I've read a little about UnrealScript and this seems a well-designed scripting language. My own one will be only little compared to UnrealScript but I wondered how to implement latent functions. Afaik if a latent function is called from the script, the current script state function pauses until the lat. function has finished. But meanwhile functions from other classes/objects are still executed. Now I wonder how to implement this or how latent functions itself are realized in C++ code (i.e. a simple "MoveTo" function). Does Unreal have a seperate thread for each latent function until it's finished? Thanks in advance!

Ok... from what I understand, Unrealscript's latent functions are basically subroutines that take a certain amount of game time to complete. In other words, they return control to the game for a period of time before the game.

So, how I implemented this in my game was to have these functions do 2 things:
Firstly, they post an event onto the event queue. The nature of the event varies according to the function. For example, if your function was 'Sleep(1)' then the event would just be set to go off in 1 second. The event contains a reference to the current script being executed.
Secondly, they return immediately and tell the script interpreter to stop script execution, but to remember the symbol table and current line being executed.

Then, your game proceeds as normal, until that event is fired in a second's time. That event says 'wake up the given script', and that script is then resumed; just execute it as usual, except that you use the symbol table and line that are stored, instead of resetting both.

Is that any help? The main thing is to have a way of storing the current state of a script's execution so that you can pause and resume the script at will.

Interesting...
I'd like to here more about your event system.
Cheers

My event system is just an all-purpose way to schedule things to happen in the future. It's implemented with a priority queue, sorted by event time, and stores a collection of Event objects. Each event has a particular event type and that determines which function is going to be called. Most events just occur and are then deleted, although some events are recurring and will post a copy of themselves back to the list, set to go off later. Each time I look at the queue, I only pop the elements that are due, according to their expiry time.

For instance, my scripting language has a !WALKTO <location> command. What that command does when executed is to post a Pathfind event to the queue, and suspend the script. The game proceeds as normal, checking the event queue for relevant events each time through the game loop.

When the Pathfind event eventually comes up on the queue, we calculate a path from the character's current position to the destination, move the character one step along that path, then schedule another Pathfind event to go off a few seconds later. To the observer, this just looks like the character is moving one room every couple of seconds. Eventually, there'll come a Pathfind event where the character reaches the destination, so instead of posting another event, we resume the script that called !WALKTO so that it can continue with the next command.

Hope that makes things clearer.

Seperate threads for each would be expensive (alot of overhead).
They probably have their own micro-thread scheme where each
thread maintains its own state (a node on a chain) and the chain is sorted by 'next expected wakeup' time.

The top of the chain (sometimes several nodes that are 'due') is polled every turn cycle and if a nodes action is completed
the AI resumes the last state where the thread had gone to sleep.
The next action is decided and started and the thread goes back to sleep (further down the chain).

The time period to sleep is usually related to how long animations of an 'action' are expected to play.

An action may be broken up into sub actions ie- (1)swing the sword, (2) decide hit or miss, (3) finish the swing(miss) or rebound (hit).

How the Resume is done is dependant on what kind of internal representation the script takes (if on a file, or in a memory
blob or compiled native code or bytecode. The thread has a pointer of one kind or another as well as other state data.



One thing is needed for a versatile script system is the capability for a script to be interrupted and readdapt to the current situation (changed situation or new events directly interfering). The reevaluation can add a significant amount of processing (and a scheme to figure how often its required).