MSW,
I'm a lil foggy on the concepts muti-threading approch with Pcode(script) instanceing, parent/child linking, and messageing between. Please provide more detail as im very interesting in adding these features.
Okay...this may be a bit confuseing:
First you will need a resource manager...this handles the loading of scripts, allocating of memory banks, etc...
The pcode itself is stored in bank...and when the resource manager is called upon to load a script into memory it first checks to see if it hasn't already been loaded...if not then it creates a resorce tracking record (basicly a type) which contains the handle for the Pcode bank, the name of the pcode, info about how much variable space the pcode requires and all that...then a script instance is created (another type) it is given a name along with handles to both the pcode bank, and a bank for pcode variables, messages, and bytecode pointers....if the resource manager finds that the script already exists, it simply creates another script instance of that type.
basicly there are two scirpt instance lists. and the VM works with the "active" list.
messages are basicly special stacks that parents can push data onto, with the script instance owning the particular message list being the only instance able to pop data off.
the parent/child stuff works quite simply.
basicly you have something like this:
Type script_inst ;basic stuff Field Name$ Field ID% ;used for classifying scripts Field Pcode ;handle to a bank Field variables ;handle to another bank Field Messages ;handle to another bank Field pcodepointer% ;VM active/inactive list stuff Field flags% ;is script active, etc.. Field previous.script_inst Field next.script_inst ;instance parent child stuff Field parent.script_inst Field child.script_inst end type
typicaly only the highest level parent (its parent = NULL...or possably the game control script) scripts are active...this means thier children will likely be on the inactive list.
Say the parent script decides to fire its gun...the vm then searched through the scripts children for the first matching gun ID..finds that the child is inactive...changes the childs flag to active and puts it on the end of the active list adding "fire" to its messages
the lists are structured like this:
Dim active.script_inst[1] Dim inactive.script_inst[1]
active[0] points to the first script in the list
active[1] points to the last.
tis' basic linked list stuff...I think you prolly have a handle on that.
anyway..when the VM gets to the particular gun script...first thing it may do is check it's messages...sees "fire"...and does so by calling upon the resource manager to create a new script instance...in this case it's "bullet 1" or some such...the resource manager creates the appropriate instance...and the gun script becomes it's parent, putting it on the active list, and giveing it messages informing it of what direction to travel in, etc...then the gun script tells the VM to put it on the inactive list and reset it's pcode pointer.
course the bullet script is then run, gets it's messges, sets the appropriate variables, moves the bullet mesh into possition, etc...it remains on the active list...until the game control script that is parent over everything finds that it has collided with a wall, and gives it the appropriate message...it reads it, and decides to generate a smoke script...does so...then tells the VM to delete it (parent/child, previous/next lists are updated in the process)
hopefully that makes some sense.