Can this problem be associated with sim "Lag"?

I can't post the actual script- because it's for a game system that's already been released (paranoid about griefers/exploiters), but my example code(s) show what is going on without the same data types, quantities or order (although the broadcasting script is almost verbatim).

The essential problem is that I have 4 scripts generating data (which due to needed state changes can't be merged into one script), a 5th script to gather the data and transmit it to a scoreboard, and a 6th script in the scoreboard. The data that is being generated has an expected numerical range that cannot be exceeded with how I'm generating the data, yet once in a while I'll get some off-the-wall data transmission with data that's well outside the expected range, but on the next transmission of data, everything's back into normal parameters. I've checked with identifiers on the listeners and the wierd data is not a problem with the recieving script overhearing some one else's data comms.

example expected data immediately before "wierd" data: 54//32//"rockets"//<1,3,2>
example "Wierd" data: -54930//-49302//""//<1,0,5>
example data immediately after "wierd" data: 48//30//"rockets"//<1,-4,5>


example script 1 (data generator)

integer a=100;

default
{
    collision_start(integer num)
    {
        a -= llFloor(llFrand(10));
        llMessageLinked(LINK_THS,1000,(string)a,NULL_KEY);
    }
}

example script 2 (data generator)

integer b=60;

default
{
    collision_start(integer num)
    {
        b -= 1;
        llMessageLinked(LINK_THS,1001,(string)b,NULL_KEY);
    }
}

example script 3 (data generator)

default
{
    collision_start(integer num)
    {
        string name=llKey2Name(llDetectedKey(0));
        llMessageLinked(LINK_THS,1002,name,NULL_KEY);
    }
}

example script 4 (data generator)

default
{
    collision_start(integer num)
    {
        string pos=(string)llGetPos();
        llMessageLinked(LINK_THS,1003,pos,NULL_KEY);
    }
}

example broadcasting script

string a;
string b;
string c;
string d;

default
{
    link_message(integer sender_num, integer num, string str, key id)
    {
        if(num==1000)
        {
            a=str;
        }
        if(num==1001)
        {
            b=str;
        }
        if(num==1002)
        {
            c=str;
        }
        if(num==1003)
        {
            d=str;
        }
        llShout(-6983469,a + "//" + b + "//" + c + "//" + d);
    }
}

I have run through all the scripts that generate data with llOwnerSay(...) when information is being sent via llMessageLinked, and none of the wierd data that is being broadcast is being sent in the link_messages. I do have other link message events, but since I'm using the integer in the llMessageLinked as a channel/filter (and each link message has it's own unique number which I've double and tripple checked), I can't see how I'm getting this strange data to appear.

The strange data doesn't appear all that often, maybe once every 15 to 20 minutes, but when it does, the other scripts within the transmitting prim exhibit strange behaviour (which I am pretty sure is attributed to lag) until the next "real" data transmission occurs.

wierd, huh?

Not enough information to tell really.

Is one collision triggering all of your data generators? If so, that should mean you get 4 messages shouted for each collision, with 1 value changed each time, which your data example doesn't show.

Also, are your data generator scripts being reset? I assume they must be, or you'll be running into negative numbers for a & b pretty soon.

Your example data does seem to suggest your wierd data is replacing the iteration where "b" becomes 31, and therefore the data is corrupting, but how that would happen I have no idea.

The only other thing Ican think of, if we're not seeing the whole situation, is something else triggering collisions, or multiple collision events for the one actual collision. I know I've had problems with multiple touch_ends with one touch_start before.

More likely there is a bug in the rest of your code somewhere, that we are not seeing, or you have multiple objects of the same type running at once?

I actually only get 1 message shouted for each collision, because of what the scripts are looking for on collisions, they will not fire more than one at a time.


the object dies when one of my data reaches zero, which is why a negative number really throws me for a loop



the idea of my data becoming corrupt is why I'm wondering if it's attributable to lag, since this occurs fairly infrequently, but if I'm running the game for 2-3 hours I'll see it crop up a few times.


I hadn't thought of it seeing multiple collision events for a single collision. I'll go about testing this



right now I only have the single object running when this is occuring. I'm still double and tripple checking my messages being sent via llMessageLinked(...), but I haven't found anything that would produce the behaviour I'm seeing

In high Script-Lag zones, linked messages experience lag. I experienced this personally when I wanted to create two jets of steam that fire at the same time. 2 emitter prims + linked message + sim lag = one jet firing before the other.

What you may be experiencing is when someone causes several hits in a certain time period, that all those hits will then post at the same time. This is simply the message queue catching up. A prim recieves 10 messages over the period of 2 seconds, the processor finally gets around to it's priority and says, "Ok, parse this." and off it goes.

ok. Think about this carefully.. Couple ppl have suggested that it's being corrupted in the messagelinked thing, but you said already that you used llOwnerSay to verify that the wierd stuff isn't being passed via the llMessageLinked.

Try putting the llOwnerSay into the recieving part and make sure they're being recieved correctly. If so, then we know that it's not a problem with lag, or message linked, but something going wrong when you assign the variable str to the permanent variables.

Before you can figgure out what's going wrong, you first need to figgure out exactly where it's going wrong.



I take that, to mean that the four data generating scripts each look for specific situations when triggered via collision_start so that one and only one script sends a llMessageLinked per collision?

If you mean for all four to send the llMessageLinked before the shout, then something needs to be edited from what you show. But if I read what you said correctly it should work as is.