quick llMessageLinked question

Playing around with a script that uses several llMessageLinked, and strings, one thing i noticed it get easy confused and dont start certain things sometimes.

A script ask the same stringname but want a diffrent one to reply depending on its state, in several prims ;

--easy confused-- wont start sometimes,
string dostuff = "hello1"
string dostuff = "hello2"
string dostuff = "hello3"
string dostuff = "hello4"
string dostuff = "hello5"

vs a
string dostuffa = "hello1"
string dostuffb = "hello2"
string dostuffc = "hello3"
string dostuffd = "hello4"
string dostuffe = "hello5"

Would having a unique string name make it easier for script to ask and find ?

I am also having issues with llMessageLinked and the execution of llSetPos through these messages.

Basically...I have a menu driven system that is designed to chsnge the arrangement of prims in a linked set . The root prim is sending messages to two child prims through llMessageLinked. All the variables and info is distinct (doExample1 and doExample2, etc), so I doubt it's confusing anything in that way. The child prims wait for the message and put themselves in a new state depending on the result of the message, thus executing in that state the prim positioning I want associated with that menu choice.

Everything worked perfect when I had only two or three choices available...but as I added more (there is designed to be 16 destinct messages, states and prim position sets) it became completely unreliable. Almost random even in which state it put itself into.

Anyone know why this is and what I can do to correct it or bypass it? I am very new to serious scripting, so simple words if possible...hehe. I don't understand why it worked perfect when only 3 or 4 choices, but became totally unpredictable after adding a few more. No way can I sell this product (as cute as it is) if it's this unreliable in how the script is being executed.

Any help is greatly appreciated...

-Zoe

Hmm. I am not sure what the problem you are describing is. Are the child scripts not getting the messages? Have you put in some debug code to dump out what they each are receiving?

Something like:

link_message(integer linknum, integer numberdata, string stringdata, key keydata) {
    llOwnerSay(llGetScriptName() + ": (" + (string)linknum + "," + (string)numberdata + ",'" + stringdata + "','" + (string)keydata + "')");
    // rest of link handling code
}

Other than that, I would either need to see some of your code, or need a more detailed decription of what you are doing to help much more.

*edit* same as below. I hate when it double posts.

I find it unreliable too. So I put a llSleep(0.5); in the script between moving each prim.
Seems to work better but not always.

It's hard to comment without knowing exact code used, but as long as the only thing which changes is prim positioning... using states feels very redundant (since you have up to 16 states with each of them duplicating whole link_message() handler, unless trickery is used to switch states in shared function) ... it's also easy to create mistakes with this sort of approach, because if the link_message() procedure isn't exactly mirrored in each state, things start to go awry by working in some states but not in others etc.

Would probably use something simpler here -- single state and a set of positions stored in array:

integer SET_POSITION = 1;

array position_labels = [ "wing_folded", "wing_opening", "wing_out" ];
array position_data = [ <0.0, 0.0, 0.0>, <1.0, 0.0, 0.0>, <2.0, 0.0, 0.5> ];

link_message( integer Sender, integer InputInt, string InputString, key InputKey ) {

    if( InputInt == SET_POSITION ) {

        integer index = llListFindList( position_labels, [ InputString ] );
        if( index == -1 ) return; // requested position wasn't defined.
        llSetPos( llList2Vector( position_data, index ) );
    } 
}

... then you can have main prim send out message like:

llMessageLinked( LINK_ALL_CHILDREN, SET_POSITION, "wing_opening", "" );

as long as

integer SET_POSITION = 1;

define is also duplicated in the root script. For extra points and more advanced behaviour you could pass name of prim set which is supposed to respond in the InputKey parameter of link_message and only have the child prim react if their name matches it, or something...

edit: in simpler situations the message routine could be also reversed by sending command name in the InputString and index to array in the InputInt... would save look ups in the array, but adds time needed to match the command name and requires the order of positions in array to be the same in each child prim, plus you cannot then skip definition of positions that don't affect that particular prim... so up to you ^^;;