Spontaneous object Reset

I have a picture voting contest system that I develop and sell.
Early this morning the pictures from 2 customer's sites which were mid contest and on the sims (over 40 in total) spontaneously reset losing all data (votes, L$ amounts etc.). One was in front of the customer's eyes and the other was discovered a little later.

The thing is that there is only one way those objects can be reset via script and this is by menu access, it only resets one object for each script you do this for and not all objects with this script in. Obvioulsy the customers could have both done this for 20+ objects and complained or selected all objects and done a "Reset Scripts in Selection" then complained. However both swear it was without them doing anything and I tend to beleive them. Only the owner has access to the menus and ability to reset scripts in both cases.

It seems to be a case of spontaneous script reset. Does anyone know of anything like this happening before? Can it happen when SL gets borky?

I would be interested to hear whether other peoples scripted objects have ever done this.

Hmm, never happened to me before, but it sounds like it's a problem caused by issues with the sim or something.

Sims don't cause script resets.

Sims don't cause script resets. Has to be either bad code, a creator/operator initiating a reset(if owner has mod permissions) or a Linden to reset a script.

OK thanks for your info Jesse, yours too Cypher.
Jesse I need to ask how you can be so sure that some part of the SL system was not responsible for the reported effect?. SL has so much inherent instability with objects disappearing from sims, scripts disappearing from objects etc, how could it be possible to know for sure SL didn't just reset those objects through some bad SL code somewhere? Don't the simulators run the lsl scripts?
I am not nay-saying you I just want to be sure about the causes and you seem very sure a Sim could not do what was observed.

I know to a 99.99999% surety that it is not bad script code, I have been over the code many times to be sure. The said code has had months of operation by over 100 customers without any incidents of this type.

There is only one llResetScript() in the script and it is accessed by listening to a randomly generated neagtively numbered channel just before displaying the menu via llDialog(). Pretty simple, basic stuff - unlikely anything could generate the reset command.
It would have to somehow at the moment the menu was being displayed guess the random channel and the name of the dialog button and be the owner item with the script in it, then send a llSay etc. The negatively numbered channel leaves out straight chat and pushes the possibility only to some other another scripted item the owner may be using. Even then the menu and its listener is not active until the prim with the script in it is touched.

Given all that I fail to see how bad script code could be resetting even a single object let alone multiple objects all at once and across sims.

That leaves owner/operator responsibility and I have to say I trust both my customers when they say it just happened. Perhaps I am too naive in that but never have I had a report of this before and the chances of them both doing the same thing around the same time after months of trouble free operation? Seems tenuous really.

I am open to other things to explore if any one has suggestions?

Thanks in Advance

There have been a couple of times where we wish that LL COULD reset scripts through the server software. Once was back a couple of years ago when target omega went nuts and objects were spinning wildly out of control all over the grid. This was just after LL had plugged a security hole making it so that object owners could not reset a script if they didn't have mod permissions. It took weeks to clean up the mess with creators and Lindens scrambling all over the grid resetting each, one at a time.

We are actually in the same situation again now. A recent bug has broken some scripts and Creators are having to replace them because there is no way for the owners to reset them and the gird is just waaaaay to big for the Lindens to do it.

So yes, the simulator can break scripts, but not cause a script to reset.

Believe me, there would be a HUGE outcry both here in the forum and in pjira if server code was resetting scripts. Too many people have released scripts that count on them not being reset.

I would suggest looking really closely at the listens and make sure they are as tight as possible, including listening only to the owner. Are there any IM's etc also in the code?

Sorry for the problems you are facing but we would be glad to help if you could post the code portions that deal with just messaging.

EDIT: And by the odd chance that there is a new bug then we should be able to narrow it down, make a replicable test case and then file a jira on it.

I am still not convinced, firstly I am not saying LL has any kind of control over bugs, unexpected side effects resetting scripts so how useful it would be is really moot and secondly I am not saying it happens a lot generally but your reasons why it cannot be so don't seem to have any real basis. After all if LL lost people's inventories people would cause a storm too, but that does not mean they don't lose them still from time to time.
I was hoping you had something more concrete as to why the sim could never be responsible. From my own understanding the posibility seems to be present unless you can fault my logic.
The Sim is responsible for placing/removing all objects and persisting/restoring their state including scripts, the sim is also responsible for running the scripts. If a problem were to occur whilst running a script that caused its state to be lost - say buffer overflow or something then surely it is at least conceivable that the script could be reset?
When a rollback happens a script can end up in a previously initialised state so there is obviously some handling of state by the sim and however reliable we think it is perhaps very occaisonally there is a bug that trashes things?
Again if you have some concreate reason why that could never happen, I would love to read them please
I do appreciate you responing though so thanks again

Here are my code snippets: -

integer MENU_CHANNEL;
integer listener = -1;

integer openMenuChannel()
{
integer channel = ((integer)(llFrand(-1000000000.0) - 1000000000.0));
listener = llListen(channel, "", NULL_KEY, "";
return (channel);
}

default
{
touch_start(integer numdetected)
{
if (llGetOwner() == llDetectedKey(0))
{
MENU_CHANNEL = openMenuChannel();
llDialog(llDetectedKey(0), "\nPlease Select an Option:",
[ "Reset All", "XXXX", "YYYY","ZZZZ" ], MENU_CHANNEL);
}
}

listen(integer channel, string name, key id, string message)
{
if (llGetOwner() != id)
return;

if (MENU_CHANNEL == channel)
{
llListenRemove(listener);
listener = -1;

if ("Reset All" == message)
llResetScript();
}
}
}

No, in this case the script errors out and will not work again until it is reset. Presently due to another bug, even another script in the same prim can not reset it using llResetOtherScript. And in the case of a rollback, the script is put back in the condition it was, it isn't reset.

Do a search in jira for "reset" and you will only find a mention one time of a bug where a script could be reset when crossing a sim border in specific conditions. That bug was filed by my friend Gearsawe Stonecutter and even thou it was filed a year ago, only one other person has reported that same problem.

If nobody jumps in before hand, I'll go over the script tomorrow.

OK thanks for the reply and I really do appreciate it

no offense but something just pulled my attention

      listen(integer channel, string name, key id, string message)
      {
          if (llGetOwner() != id)
              return;
  
          if (MENU_CHANNEL == channel)
          {
              llListenRemove(listener);
              listener = -1;
  
              if ("Reset All" == message)
                  llResetScript();
           }
      }

it prolly doesn`t matters but from every piece of code i`ve seen, you allways add the rest of the code within the if statement, even if "just in case", just from my little expirience

    listen(integer channel, string name, key id, string message)
    {
        if (llGetOwner() == id && MENU_CHANNEL == channel)
        {
            // Code
        } else {
            // Kill the listener
        }
    }

again, might not be relevant at all, just strikes me odd on first glance

i did have a script reset spontaneously quite a few months ago, it was just a simple door script that worked on collision, but i had chatted some access names to it. and it was supposed to IM me when someone collided/opened it. if it failed it would tell me So&So was not granted access, and if it worked, it would say So&So has entered your house. (all the access list gave them access to was opening it, only the owner is allowed to change the list, lock/unlock, etc) one day i was in another sim, and it told me it failed for someone that was supposed to be on the access list. so i went to check it out, and the door seemed to have reset it's closed position as being open, and there was no one on the list anymore.

on another occasion:
i did have a different door with sorta the same script. but it was touch and it would say on the public channel So&So has opened the door, or sorry So&So, this door is locked. i was in my house and i knew i had the door locked. some newb came and tried to open it and it said it was locked, but they didn't get the hint and started clicking it multiple times, and then somehow it ended up opening even though it still said it was locked

Hi Alicia, I appreciate you taking a look. My code is just a different way of writing lsl - still all good and valid syntax though.
I basically do it that way because often there are more tests for things in the listener and I like to get basic fails dealt with first so they are easy to see and manage. It is not mandatory for "if" statements to have "else" clauses in any language, lsl is no exception.

If I were to rewrite using your example it seems I would only close the listener if the owner did not initiate the message and/or it was not on the MENU_CHANNEL. I actually need to close the listener if it is the opposite way round - if the owner did initiate the message and it is on the MENU_CHANNEL.

Thank you for posting this Ruthven as I must admit I thought that I thought I had seen it before this incident too though I cannot be very sure about those times. Jesse claims it is not possible but I remain unconvinced.

A few more people coming and saying they had it happen too and I might open a jira on it.

no problem, but i did say this was quite a few months ago, there's been a few server changes, and client updates since then. but this is sl, one thing could be fixed, and then broken again later on lol

gotcha

something new to add to the book

Thank you for trying to help though, I really do appreciate it