Retaining data through llScriptReset

Is there any practical way to, say, retain a single integer, from reset to reset?

I've considered writing the integer to the description, but the description is volatile on attachments (not saved on unwear).

I need a device (worn) to reset on rez... (clears the old llGetOwner on the listens) but I need to keep a "number of times server was contacted"... and alas I can't track that information using the server.

Maybe some way to tag the integer out to the linkset, and then after the reset, tag back asking for that integer again?

What about storing it as a color value or some other property of a prim?

If the only reason you are doing a reset on rez is to reset any owner-listens, then do it another way:

integer iListener = -1;
integer iChannel = 5;    // or whatever

NewListener() {
    if (iListener >= 0)
        llListenRemove(iListener);
    iListener = llListen(iChannel,"",llGetOwner(),"");
}

default {
    state_entry() {
        NewListener();
    }
    on_rez(integer iParam) {
        NewListener();
    }
    // rest of script
}

If you really really really must reset the script, then there's not a lot of options to persist the data. llEmail won't work because the object gets a new key every time it is rezzed, so it can't receive mail it sent to itself in a previous incarnation. The only way to do it would be to store it external to the object somehow; like via storing it on a webserver and saving/reading it via llHTTPRequest.

Edit: or as suggested, some innoccuous readable as well as writable prim property that does get saved.

Some non-new ideas:
* Store the data in the description of the object.
* Send the data from Script A to Script B using llLinkMessage, reset Script A and send back the infro from Script B to Script A
* Store the data in a external database using llHTTPRequest


I think the second one is the best of all three but it depends of the situation. I used the three successfully.

Good luck!

it's important to note that "saving to description" doesn't work on attachments. It storees it there, but on unwear, it reverts to the old description

I think Resolver has the best solution... hide your value in a nonvolatile prim/object parameter vector like color or rotation.

You can encode 24 'small' integers (0-255) into a cube using colour and alpha for each face without trying to do anything clever with the bit patterns.
Or 6 Large (32 bit) ones. Or any combination in between.

If you know the ranges of the values is less than 8 bits then you can obviously store even more.

What sort of values are you trying to store?