strange behaviour from identical scripts

I've had some rather strange behaviour occur in one script, while an two other identical scripts/objects behave normally. the only way to get the strange behaviour to stop is to delete and re-rez the object.

Specifically what is happening is this: I have a command broadcasted at a set rate on a channel, the object(s) in question listen for the command and then execute it. occasionally, one object will either lag behind the others when executing the command, or randomly ignore commands given.

once this strange behaviour starts occuring it persists until the object is deleted and re-rezzed or the script within is reset. This is a rare occurance, but in the course of about 18 hours of non-stop use, I've seen it twice. Putting in debugging info to see what's going on with the objects returns values that are identical between the erratic objects and the normal ones.

My current working theory is that perhaps just the bugged object is getting lagged and is missing the commands and/or recieving them late because of this. Since the application my script is going in is something that will probably be "on" for days on end, it'd be really helpful if there was some kind of work-around for it.

Try a script reset on a timer filtered by an activity set timestamp. If no activity for some period the script resets. Probably wont work if the problem is an infinite loop.

...Assuming that it isn't something as simple as your objects talking back to eachother on the same channel as the input command, and getting caught in a loop. Alternatively, the ensure bugged object hasn't just drifted out of chat range. ...Oh - and the most likely some simple time or command sequence dependent infinite loop - maybe a state change loop?

Is it always the same object? Or is there another pattern to the one that fails?

Kind of difficult to guess without code.

the code is really simple:

string slc_sep = "#!$"; // funky name for clean namespaces
//This is for recieving a list via llSay with different kinds of values for the data and retaining their flags.
list string_2_list(string s) {
    list l = [];
    list result = [];
    l = llParseStringKeepNulls(s, [slc_sep], []);
    integer len = llGetListLength(l);
    integer i;
    for (i = 0; i < len; ++i) {
        integer type = (integer) llList2String(l, i);
        ++i; // CLEVERNESS WARNING...BE VERY AFRAID
        if (type == TYPE_INTEGER) result += (integer)llList2String(l, i);
        else if (type == TYPE_FLOAT) result += (float)llList2String(l, i);
        else if (type == TYPE_KEY) result += (key)llList2String(l, i);
        else if (type == TYPE_VECTOR) result += (vector)llList2String(l, i);
        else if (type == TYPE_ROTATION) result += (rotation)llList2String(l, i);
        else result += llList2String(l, i);
    }
    return result;
}



default
{
    state_entry()
    {
        llListen(70,"",NULL_KEY,"");
    }

    listen( integer channel, string name, key id, string message)
    {
        if (llGetOwnerKey(id)==llGetOwner());//Checks to see if the owner of the control box is the owner of this object
        {
            llSetPrimitiveParams(string_2_list(message));
        }
    }
    
}

I can have 3 of these objects, and just one will go funky while the other 2 operate normally. I haven't seen how long this off-behaviour lasts, since the times I've seen it I deleted and re-rezzed or reset the script within 10-15 seconds.

Update:


I had the problem occur again- I was running 7 of the objects at once, and after about 15 hours of use, one of the objects bugged out. It stayed bugged for about 45 seconds and then magically went back in synch with the rest. I still have no definate reason why this happens, but I'm heavily leaning towards the single object somehow getting lagged behind for an unknown reason, and when object stops lagging, it catches back up.

What's the rate at which the chat commands are issued? I think llSetPrimitiveParams has a 0.2s delay, so if your commands are coming in at close to that rate, things might get a little tight. I've seen that happen on some of my scripts, and it seems to be very sim dependent. Remember that events are queued, so if one object falls behind, it's hard for it to catch up unless it has some breathing time. It'll keep processing the commands in sequence. So if the commands arrive at the same rate as the time it takes to process a command, you'll pretty much never catch up once you get out of sync.