Saving variables?

Products such as the rez-faux building rezzer must do this. How can a script keep the variables after taken to inventory? Even something simple like having an object listen on rez, and the string it hears becomes string x. When its touched it goes through llSay(0, x). Now is there anyway that i can take that object to my inventory, and when rezzed again it will keep string x what it was before? From my expirience any kind of taking to inventory resets all the variables. But I cannot figure out how some scripts seem to remember the variables. Any help much appreciatd thanks!

Taking something into inventory keeps the script in exactly the same state. The only way that it should lose information on rez is if it resets itself or otherwise deletes variables - granted that this is a very common thing to have scripts do. But it must be done deliberately.

There are a couple of different ways variables can be saved, as the previous poster mentioned the state is preserved when taken into inventory, but script variables DO reset, as a script is reset when it first rezzes. One can http out to a web server and using php and mySQL save information on a website, and do the reverse operation as well to retrieve the data. This is done when there's alot of information. Also, when there's relatively small amounts of data to be stored (configuration settings for example), one can convert the data to a string, and write that information to to the object description, which persists when taken into the inventory and re-rezzed. I use that method myself to preserve the hour and minute offsets and chime state (on or off), in my clocks. Previously, when I sim rebooted or a user took the clock into the inventory and then re-rezzed it, the clock would revert to SL time, and the chimes (if present in that clock), would be set to the default setting of ON. Now however, if one sets my clocks to a different timezone, and changes the chimes to off, the clock will 'remember' this if the user takes the clock into their inventory and re-rezzes it. When my clock scripts start to run, they read the object description, and parse the string into components, and then convert the strings into integers, and use those values to set the hour and minute offsets, and set the chime state.

Right. Remove any calls to llResetScript() from your 'on_rez' event handlers. BUT think carefully about why those resets needed to be in there and rebuild any suitable logic. For example, many scripts simply reset themselves on rez just in case there was a change in ownership and they have a listen filtered by owner. This can be fixed by doing something like:

integer CHANNEL = 3245;

integer listenHandle = 0;
startOwnerListen()
{
   if (listenHandle != 0)
   {
      llRemoveListen(listenHandle);
   }
   listenHandle = llListen(CHANNEL, "", llGetOwner(), "");
}

default
{
   state_entry()
   {
      startOwnerListen();
      ...
   }

   changed(integer changes)
   {
      if (changes & CHANGED_OWNER)
      {
         startOwnerListen();
      }

      ...
   }

   ...
}

It doesn't really matter if llResetScript() is in an on_rez event or not. My clocks are owner only controlled, so there has to be an llResetScript() in an on rez event. Besides, script variables reset when rezzed, weather there's a reset script or not, scripts start running from the beginning, and all variables are initialized on rez. What I'm talking about doing is writing variables to the object description (convert to strings as needed), and then, when the script reset, the first thing it does is read the object description and restore any settings set before the item was taken into the inventory. Resetting the script doesn't matter, it's what the script does when it IS reset that matters. Let's use my clock variables as an example, there's 3 things that need to be saved, hour offset, minute offset, and chime state (on or off). All three variables within the script are integers, so they need to be converted to a string, and then written to the object description. I do both storing and retrieving of the variables within functions.

storeData (integer hr_offset, integer mn_offset, integer chimeState)
{
    string output = (string)hr_offset + ":" + (string)mn_offset + ":" + (string)chimeState;
    llSetObjectDesc (output);
}

getData ()
{
    list vars;
    string temp = llGetObjectDesc();
    vars = llParseString2List (vars, ":", "");
    hourOffset  = (integer)llList2String (vars, 0);
    minOffset  = (integer)llList2String (vars, 1);
    Chimes  = (integer)llList2String (vars, 2);
}

Whenever a user changes the time setting or the chime state, I call storeData(), whenever the script is RESET, I call getData().

That's patently not true. There is no automatic script reset on rez. Try inserting the following script into a prim and then taking the prim and rezzing it several times. Touch it a couple times before each take into inventory.

integer counter = 0;

default
{
   state_entry()
   {
      llOwnerSay("I was just saved or reset.");
   }

   touch_start(integer nDetected)
   {
      counter += nDetected;
   }

   on_rez(integer startParam)
   {
      llOwnerSay("I was just rezzed.  My counter is "+(string)counter+
                 "; if I had just been reset, it would be zero.");
   }
}

You can always implement logic that doesn't REQUIRE a reset. Resets can just be CONVENIENT sometimes. I use them too, but if you are struggling to save data across resets, you might want to weigh whether it might be better just to remove the reset entirely. There are also other means of storing data: external storage, memory scripts, etc. I'd actually advise somewhat AGAINST storing data in object name/description as they are pretty limited in size and not really intended for script storage (that's even why LL fixed up and reduced the character limit a while back).

what has been said by others, is quite true. however.. the idea that a "taken" item will ALWAYS save it's exact state is not true in practice. I HAVE seen "takes" revert to a "less than current" state of the script.. for example, I have had settings I made on a worn item, undo if unworn and reworn.. things not covered by the script itself.

(like having it sometimes discard changes made from the point when it was rezzed).. this is particularly annoying on script revisions, you "take" the latest one, and find that the recent changes you made, didn't save.

This is most likely an asset server issue, and a linden workaround to one of the old "dissappears on take" problems.. item dissappears on take, maybe now they can detect that, and they grab another instance of the last saved item. Either that or the save-item fails, so they query the server for the last "backed up" version of the item.

I've always seen script state save itself consistently for attachments that are removed, but--interestingly enough--changes to the object name and description are NOT saved back to inventory for attachments. So that's an example of where you would actually want to rely MORE on script memory than prim properties.

Ok, I stand corrected, however, my solution to saving variables is still valid.