Saving data on the server

There's a free script, "multi-user locking door" or something like that. It somehow persistently stores a list of the names of avatars who have access to the door. It creates a list variable, auth_list, at the start of the script. In state_entry(), llRequestAgentData() is called. This triggers a dataserver event, in which auth_list is populated from the "data" variable that comes back from the server. However, all that seems to do is add the user's avatar's name to the list.

I have two questions:

1. I see how other avatars' names are added to the list but I can't figure out how the names entered into auth_list get stored back to the server, or how they're retrieved so the script can figure out who is authorized when somebody hits the door.

2. Is auth_list a special hard-coded field on the server, or can I create my own custom fields and have them stored persistently on the server?

Thanks for any help.

I imagine that auth_list is just a list variable, and all the storage is done right there. when someone tries to use the door, it checks auth_list, and allows them if they are found. (so it's not being stored on the server, it's being stored in the scripts variable).

this is just an educated guess, because I can't see the script, but that's the standard model (although I have no clue why it'd be using llRequestAgentData to fill the list, except maybe to validate the keys, which seems a bit pointless.)

But the list of authorized users persists over time. The door owner can add the names of various avatars to the list. That list is permanent unless the owner deletes a name. Weeks or months later, those names are still there, the script continues to allow access only to the names on the list. If the script is restarted, or even if the sim is restarted, the list persists. How is that possible? Where are the list contents stored in that case?

As a test, I added an avatar name to the door authorization list. When I took the door into inventory and then re-rezzed it, the name I added was gone. But if I left the door sitting there and turned the script off (Tools>Set scripts to not running in selection), and then turned it back on (Tools>Set scripts to running in selection), the name was still in the list.

LSL data is persistent and even persists if the object is taken into inventory and then re-rezzed. The behaviour you are seeing is standard for LSL scripts and does not require special handling.

Conversely, if you do want variables to be re-initialised when an object is rezzed you have to take action to ensure that it happens. The state_entry event for the default state is only triggered when the script is first run, or when the script is reset so the simplest way of doing this is to ensure that the script is reset when the object is rezzed:

on_rez(integer param)
{
llResetScript();
}

Thank you. Yes, I understand that.

What I'm trying to accomplish is a prim that remembers its original color no matter what.

My script causes the prim's color to oscillate between two values. When the script stops running, the prim's color is naturally fixed at whatever it was at that time. Even though I initially capture the original color when the script starts, that value is lost if the prim is taken into inventory or if the script is stopped via the Tools menu.

Calling llResetScript() doesn't recover it if, at the time the prim was put into inventory or the script stopped running, it had a color different from the original color. I realize I can either add a notecard containing the original color to the prim, and read that value in each time the script starts, or put the value in the prim's Description property and read it in.

But what I really wanted was a script that would read and store the prim's color just once, the first time the script runs, and store it somewhere *programatically* forever, without human intervention, then thereafter be able to restore it, without having to resort to extra developer steps such as creating a notecard or entering text into the Description property.

It would be trivial to do this only once, for one prim. But imagine a collection of several dozen linked prims, each of which will oscillate between two colors when the script runs, and each of which may have one of four or five original colors, each of which needs to be preserved so when the object is rezzed, each prim always starts at the proper original color, regardless of what color it had when it was taken into inventory.

It appears this is impossible. But does the idea make sense? Am I missing something?

I suppose the alternative would be a script that resets each of the prims' colors on rez--but that's a lot of hard-coding. I just hoped it wouldn't be necessary since the prims' original colors are there to be captured.

stopping a script from running only stopps it at the current execution stage, it doesn't wipe out any variables (exceptions apply for sim crossing and sim resets). to wipe variables, the script must be reset.

see your other thread about saving data outside a script.....

Maybe a simple script will explain, put this script in an object:

integer count;

default
{
state_entry()
{
count=0;
llSay(0, "Hello this is state_entry, you should only ever see this once" );
}
touch_start(integer total_number)
{
count++;
llSay(0, "This item has been touched: "+(string)count+" times";
}
//UN-COMMENT THE THREE LINES BELOW TO ENABLE STATE ENTRY
//on_rez(integer param)
// {
// llResetScript();
// }
}


Touch the object a few times to see the counter increment, Take the object into your inventory, rez it again and touch it, you will see that the count has been maintaned.
Now uncomment the last three lines, take it into inventory again, and then rez it. The counter will be cleared to zero.
I hope that helps

The best way I've seen to maintain a default color is to set a default color in the script and then on state_entry and on_rez set the color to the default value.

Thanks everybody. I had been conflating two issues--data storage and the RGB conversion thing--and getting confused about which thing was causing which problem. I think I have it sorted out now. It's great to get all this help.