scripts to mange other scripts

I am considering a project that will require a management script, and I am debating how to implement a script that control one or many other scripts scripts. I could hard code the scripts. That would creates allot of manual labor, and isn't that modular. But I know it is possible, and that I could script it.
What I am tempted to do, is make a modular script. A script that would not require any manual settings to be hard coded or inputed by hand.

Goals:
 * manage a set of scripts through the use of a control script
    * identify the script to control (refereed there after as unit scripts)
    * create a list units scripts 
    * identify which unit scripts are active and inactive
    * send command to specific unit scripts when active or inactive
    * keep the list of unit scripts up to date
    * create as many copies of unit script as need

I was wondering if any one has done a similar script. How did your script turn out? Was it successful? Did you come across any problems? How did you chose to have your script talk to specific unit scripts? What did you chose to use to identify active vs inactive script. Is there any thing I could learn from your experience, that would help me make a better script?

Many of my projects end up having a bunch of particular function scripts along with the main core script that calls the various function scripts. I built a rather large array of various function scripts, and just toss their calls through the link message pipe... However the master script really did not do much besides call them for most..

Recently I started writing a Forth interpreter in LSL and it probably falls closer to what you are looking for as far as a knowledgeable master/slave relationship. For this task, each script was assigned an integer address. When shipping a packet of data between the scripts, I utilized something like llMessageLinked(-1,[to],[datapacket],[return address]), where I would wrap the sender's address in the key field. (I did this mainly to control the execution order, and to allow a reply to a function call in a slave script). The main parser script has a list of functions (currently at least... I think I will be moving it to a daughter script for memory reasons) in a list along with the address to the slave script so it was something like:

list foo = [ "function1",200,"function2",200,"function3",203 ];

The slave scripts upon init'ing ship to the main script a list of it's callable functions which are added to the list. I am not quite sure the purpose of storing the scripts active/inactive state (and I am assuming you are meaning running/not running) but this could also be achived several ways. Perhaps a list of all their addresses, and if it is a positive address indicates it's running or negative, not running. Another method is just polling their state via llGetScriptState() whenever you need to know (which is probably more memory efficient).

As far as making copies of scripts, I am not sure this will really work.. I believe if you copy a script of the same name via LSL calls, it replaces opposed to duplicates (I could be wrong though... I have not tried). I just tend to replicate scripts beforehand.

[ I hope the above makes a little sense.. had a long day ]

well I'm writing my sudo code for a dance machine. But if I properly oop the control script,. I should be able to use it in future projects. One day it could be the troller for a DnD based RPG system.

When I wrote active and inactive I was referring to a script running. I could have checked the status of running to see what was active. And then each script c08pd shut down when the script was done running. I would have to check running, because off script would not respond to link message.

But I may just use link message. And have each script get it's name at state_entry, and use tje name as their form of unique id. Just like your numbers. I wonder if un-checking run, instead of just using sending end to a script would offer any notable sim performance.

I've done something like that with my firebirds: I've got a variety of different AIs that I can drop in to get different behaviors, and a master script that switches among AIs.

Basic procedure:
On rez or state_entry, the master script sends out a "register" linkmessage. It then sets a ten-second timer to wait for replies.
Each AI script then replies to the "register" message with a message detailing what situations it can respond to and what message code to use to contact it.
After the ten seconds are up, the master script then selects an AI from among those that indicated they can handle the situation of the bird being on the ground, and things run from there. If an AI script has finished its run, it indicates the current situation to the controller, and that controller selects a script that can handle the new situation.

Yep that pritty much what I'll need to script. But because it will also have a more complex waiting system to handle adding scripts, and dancers at any time and each one needing it's own decay timer.

A long time ago I implemented a core "master script" architecture, which controlled many sub scripts. I used this model for my mHUDS (10 objects that register a variety of data, all controlled by a central processing script), and before that (in Beta) for a city-management script (when it was just being built I played with this architecture for managing all the scripted objects in a city, like elevators, etc). .

Although not failures, it became evident in short order that for, say, registering bullet hits in real time to subtract HP, message links were WAY (yes caps) too slow. I mean WAY. I would shoot an avatar five times with a rapid burst gun and it would take several seconds for all the hits to process. It was possible to be dead long before the damage had finished processing if, say, you were hit be a lot of shrapnel from one of the scatter grenade guns.

The way to go in SL for optimum performance is to NOT use link messages. Although the architecture is instinctive and one that many of us are familiar with, you get much, much better performance, and more consistent performance, if you treat objects as black box components rather than message-enabled classes.

In short, minimize your link messages to only messages that need to be sent infrequently and do not have to be processed in near real time; make your individual objects do as much as they possibly can without having to receive link-messaged data. The more complete the encapsulation of your objects are, the better your LSLapp will run.

Edit: I propose a new term for LSL script applications called SLapps. What you doing dood? SLapping around. Or, SLapping my....tori.

This of course depends on the project. For a game that has the luxury of being able to make the player wait for a "next move", yeah you can get away with it. But if you need that data moving along rapidly and consistently, it's not the way to go.

Basically, turn around your thinking; instead of a central engine sending data to objects when they need to do something, have the objects process the data and do something, and send updates when necessary to the engine (like total score, or if the player is dead, etc.).

well in the case of dnd that might be a good idea. But dance machines have little overhead. And having each script bid for the right to animate creates more over head. And if there was ever a point when 200 avatar uses a single dance machine. there could be some major unseen problems.