Variables lose settings over time?

I have a linkset.

The root reads a configuration card and uses a linked message to tell child prims information they need.

At some point- the child prims seem to forget what they were told and they start generating errors becuase things like strings that should be populated- are empty.

Is this normal behaviour? Is there a work around?

Thank You!

normal? no.

would have to see the scripts to know, but i'm guessing something is either causing them to replace the original data (like a link message) or the script has a reset that's getting triggered in an un accounted for test case

post the child script, use php tags please, because there's no telling witout seeing it

There is no reset.... it's not even complicated code.....

The link message is only called from the root prim on rezz or inventory change.

After resetting it works normally again.... until it starts throwing texture '' not found errors....

So it certainly looks like it's forgetting the settings on strOnlineTexture and strOfflineTexture

string strLocation;
string strName;
string strOnlineTexture;
string strOfflineTexture;
list lisData;
key keyTrackingUUID;
key online_query;

default
{
    state_entry()
    {
        llSetTexture("8dcd4a48-2d37-4909-9f78-f7a9eb4ef903",2);
    }
    touch_start(integer total_number)
    {
        integer i;
        for (i=0;i<total_number;i++)
        {
            key target = llDetectedKey(i);
            llInstantMessage(keyTrackingUUID, llKey2Name(target) +" is paging you from " + strLocation);
            llInstantMessage(target,strName +" has been notified of your request and will be in touch with you as soon as possible.");
                        return;        
        }
    }
    link_message(integer sender, integer channel, string data, key id) {
        if (id != NULL_KEY) {
            keyTrackingUUID = id;
            
            lisData = llParseString2List(data, [","],[]);
            strLocation = llList2String(lisData,0);
            strName = llList2String(lisData,1);
            strOnlineTexture = llList2String(lisData,2);
            strOfflineTexture = llList2String(lisData,3);
            online_query = llRequestAgentData(keyTrackingUUID,DATA_ONLINE);
            llSetTimerEvent(channel);
        }
        else {
            llSetTexture("8dcd4a48-2d37-4909-9f78-f7a9eb4ef903",2);
        }
    }
    
        timer()
        {
            online_query = llRequestAgentData(keyTrackingUUID,DATA_ONLINE);          
        }


    dataserver(key queryid, string data)
    {
        if(queryid == online_query)
        {
            integer online = (integer) data;
        
            if(online)
            {
                llSetTexture(strOnlineTexture,2);
                return;   
            }
        
            else
            {
                llSetTexture(strOfflineTexture,2);
                return;
            }
       
        }     
    }
} 

The child script is clean. I would suggest checking the mother script to see if it can send a null message under some circumstances. Also check if there are any other scripts sending IM's, if they are properly filtered.

The only time the root prim calls the message on loading. In fact, all the root prim does is read the config and pass it out to the children....

Nothing in this gives me any reason for the variables to go blank....

I have some scripts a few years old now that have retained their string and list data. So no, there is no reason for it to just go "blank" unless it is reset or null info sent.

I usually use a header with integers to use in link messages. Each value is a different "command" or message type, used to ensure that any particular script doesn't interpret a link message not intended for it. I typically generate each message type or block of message types used in a particular application randomly from -2^31 to 2^31-1. An example might look like (very contrived example, but it'll give you the idea):

// Resident list management header

// key param: <residentKey>
integer ADD_RESIDENT_KEY_LINK = 910047744;
// key param: <residentKey>
integer REMOVE_RESIDENT_KEY_LINK = 910047745;
// both params unused
integer CLEAR_RESIDENT_LIST_LINK = 910047746;
// key param: <residentKey>
integer QUERY_RESIDENT_KEY_IN_LIST_LINK = 910047747;
// key param: <residentKey>
// string param: <boolean>
integer REPORT_RESIDENT_KEY_IN_LIST_LINK = 910047748;
// both params unused
integer QUERY_WHOLE_RESIDENT_LIST = 910047749;
// string param: <residentKey1>,<residentKey2>,...
integer REPORT_WHOLE_RESIDENT_LIST = 910047750;


// Variables

list residents = [];


// States

default
{
   link_message(integer sender, integer cmd, string stringParam, key keyParam)
   {
      if (cmd == ADD_RESIDENT_KEY_LINK)
      {
         integer index = llListFindList(residents, [ keyParam ]);
         if (index < 0)
         {
            residents = (residents=[])+residents+[ keyParam ];
         }
      } else if (cmd == REMOVE_RESIDENT_KEY_LINK)
      {
         integer index = llListFindList(residents, [ keyParam ]);
         if (index >= 0)
         {
            residents = llDeleteSubList((residents=[])+residents, index, index);
         }
      } else if (cmd == CLEAR_RESIDENT_LIST_LINK)
      {
         residents = [];
      } else if (cmd == QUERY_RESIDENT_KEY_IN_LIST_LINK)
      {
         integer index = llListFindList(residents, [ keyParam ]);
         llMessageLinked(
            sender,
            REPORT_RESIDENT_KEY_IN_LIST_LINK,
            (string)(index >= 0),
            keyParam);
      } else if (cmd == QUERY_WHOLE_RESIDENT_LIST)
      {
         llMessageLinked(
            sender,
            REPORT_WHOLE_RESIDENT_LIST,
            llList2CSV(residents),
            NULL_KEY);
      }
   }
}

That kind of approach might help you if you have other scripts in your object that you use link messages in.

looks like any valid key in the link message ID field will cause the script to update it's textures... which definitely makes it seem that it's getting a link message not formated for it, trying to read a blank or improperly formatted string data, then bombing out when the parse for that either encounters a blank string/key or an invalid one.

some kind of validation command like hewee suggested will secure that, even just a special value like 12345 in the integer field.

you can catch it happening by throwing in in a temporary test that checks if your parsed list has 2 valid keys in it, and if not, spits the whole message out to you, including sender prim number.... that will tell you were the bad data is coming from too

I did notice one really minor thing... the return statements in the data server event... they aren't needed, since at the point both occur, there are no actions to skip, and you'd be exiting the event normally anyway.

By the way, the timer is never reset, unless a link message sends channel==0. The script will be making dataserver events forever.

Ok- so I figured out what the problem is....

Don't have a Mono compiled script call an LSL Compiled script and expect it to remember the variables a long time..... I realised I had not compiled the linked prim scripts in Mono. Changed it- and now it works fine.


Thanks everyone for the tips!

I am not sure I follow you here. This is a "are they online" script- why wouldn't I want it to make the call "forever" (or at least till it's removed from world)?

I doubt that's the problem. Perhaps your LSL-compiled scripts were running out of memory.

LMs look the same regardless of whether they come from a Mono or LSL script.

I frequently use a little LM debug script that echoes every LM it receives (using llOwnerSay()). I have both Mono and LSL-compiled scripts, and all LMs look the same regardless of whether they came from Mono or LSL scripts. And sometimes I've compiled this script with Mono, other times with LSL.

You didn't say what the script was intending to do, and there are no comments, so I was only examining it quickly and out of context. Yes, you would want it to poll forever once the one-shot link_message was received.

I guess it's possible it was a memory problem- the only change I made was to compile them in mono... I don't see anything in there that should be chewing up memory. I was thinking that more likely the Mono script, not seeing a hook into the data (since the other side wasn't running mono) was doing a Garbage collection- I do not know how the Interop between LSL and Mono was done....

Yeah, I didn't see anything that would chew memory either.

But LMs are compatible between Mono and LSL, or I'll eat my hat.

/me makes a note to go buy a tasty hat, just in case ...

LMs are *messages*. Messages contain data. The data formats are not specific to Mono vs. LSL -- integer is integer, string is string, key is key. (The technical terms for this are "transfer syntax" and "marshalling", depending on your background.) The transfer syntax for LMs is the same for Mono and LSL.

Huh. Could it possibly be that LSL scripts compiled before Mono was introduced can't parse link messages sent by Mono scripts or something? Anyone (like Strife ) know if LSL compilation has changed for this kind of thing?

I've had no problems sending link messages back and forth between lsl and mono scripts. Seriously I would just pass this off as a mistake on the part of someone just learning LSL.

Seconded (or thirded?) -- I have some pretty involved link messaging in some products and not a sign of any LSL/Mono link message differences/issues.

Many times I have found a "bug" that turned out to be me not a platform problem under further testing, which of course is not to say that I haven't found my fair share of genuine ones too -- oh wait -- I'm going to go seriously off-topic now...

-- as platforms go, SL is still pretty buggy - which has the interesting effect of protecting us from a big corporate takeover. Big corps can't stand the pain of it - which basically kills any possibility of making a corp-style profit here. I imagine that they consider this platform to be in continual "beta" much as I do.

I cannot tell you how many products I have had stop working properly after an indeterminate period of time. No corp would take the time to struggle to figure out what changed and recode the whole damn thing again. Not to mention the fact that about 70% of customer service for any released product is US doing proxy support for LL owing to platform instability (esp with regard to delivery of sold product or important/vital messages such as emails/IMs that we/our objects never get).

I'm almost certain that the above explains why corporates seem to experiment here but give up after a while. Maybe we should thank LL for all the bugs?!??!

/esc

Hmm. What I was wondering is about the time of compilation. Do you know that any of those perfectly functioning non-Mono scripts were compiled BEFORE the introduction of Mono?

My LSL debug script was compiled in LSL prior to Mono, and prints all received LMs just fine. I've been using it for a long time, just drop it in the object and I get to see all the LMs. (Very helpful with MLP developement.) I continued to use it the same way when converting MLP to Mono, and never saw any problems interpreting the LMs.

I'm convinced that the IM issue is a red herring. However, there might be some other ramification to converting to Mono that's biting the OP in the derriere here. I suggested running out of memory, but that doesn't quite seem to fit the facts as stated or appear to apply to the code posted above.

Ah. Okay. Good deal. Yeah, I suspect myself that it is some script that is sending link messages other than the ones he means to be interpreting. Could be as simple as a texture/alpha script tucked away in a child prim somewhere. Who knows. Bad idea to blindly interpret every link message that comes your script's way without any attempt to filter for meaning.