Dynamic lists lifetime? Like a "whitelist".

I'm trying to make some scripting and right now I try to figure out a dynamic whitelist.

Easy enough to set up a listener for a name spoken in chat, and add it to a list variable. No problems so far.

But for how long does this list variable keep the information? Is it saved in a sim restart? A rolling restart?
I suppose a script reset will definately kill it..

How can I make it as "long life" as possible? I can't write to notecard, and I believe the object description can take 254 characters only.

Advice are welcome!

script reset: definitely resets everything in the script!!

sim reset: -shouldn't-, but can't count on it... unfortunately i don't think that's anything that can be scripted around/anticipated. :\ don't rely on any permanence outside of storing info in a preference notecard and reading it in upon a script startup...

i would recommend a '24-hour purge' of the list, if it's constantly collecting data. email it to yourself, save it to a preference notecard. something handy is to pre-format the email contents to whatever format your script reads, so all you gotta do is copy/paste.

you can also 'purge' to im if you wanna trigger this inworld and copy/paste from there... some different ways to do all that. just takes some footwork, but try to save yourself every last lil' second - really adds up over time.

Hmm.. Thanks Nyoko.
I was actually thinking that I may do a "backup" to a out-of-world database server, to then "download" the backup by command if everything else fails. But that also have some limitations due to the http request sizes.
And I just don't understand the xml thing.. (Yet.. ).

Oh dear Linden Labs, please let us write to notecards!

One other case...

If you take it back into inventory, abnd then rez it again later, it will still be in the same state (unless you reset in the on_rez() ).

I think if you take a copy, then it does NOT get a copy of the state, but I am not sure.

If you are really worried about reliability then go ahead and skip learning xml-rpc. It is no longer a trustworthy option. Just skip straight to http and you can also code it in so that you will send the data automatically once you hit a certain memory limit in your script. Once it is sent then you can wipe your list and keep going.

there are way around it in world, for example, child prims can store up to 255 characters safely in each object description, and object name fields, with the caveat that data in names can be seen on object inspect, and depending on how you handle it names might be a pain to retrieve.

other variables can be stored in various prim attributes, alpha being a popular one, holes size, and cuts, twist, & taper being some others for small hidden prims

Script data is persistent and should stay whatever it is until you reset the script.

Sim restarts usually don't affect it but sim crashes and rollbacks can and will.

Hmm... Seems like there are some "usually", "if", "maybe" etc in all of this...

I think I'll look into posting to a database out of world, the problem with that as I have understood it is that when I recall the data, the recieving script can't handle any bigger amounts of data at a time? Seems like to limit to get whatever any off world website echoes back to SL is limited to just a couple of lines at a time?

llHTTPRequest is limited to data chunks of 2kb or 2048 bytes.

Depending on your data you can fit quite a number of records in that space.

A copy gets a complete copy of the script state, including all variable values.

I believe you can also set the texture key on each face (great if you're trying to store someone's key). So if you want to limit the number of childprims/prims for storage, you might try that.

A better way to store info is to use multiple scripts, rather than multple prims. Why burden the server, physics, and display for stuff that's only there to hold data?

If the prims are there anyway for some other purpose, then I have no objection to using them this way.

You get 16KB of stack space per script. With a simple script, a fair portion of that is available for data. (The smaller the data items are, the more list item overhead there is, and the less of the 16K you get for your data.)

Nothing is guaranteed, not even on an off-world web server. However, the latter is likely to have much higher reliability than an SL object.

I have never noticed a case where an object lost state, in a year of SL & a fair amount of scripting. But I wouldn't put my life savings there!

I had lots of scripts which kept their state for 2-3 years, through several thousand sim crashes, until mysteriously one day every script in the sim was reset and set to not running, and LL pretty much said "oh well, too bad." (they're "not allowed" to roll back mainland sims). That is kind of a freak occurrence and I would not really worry about it in general, unless it is something super important.

because scripts reset, but prim attributes hold across resets...

oh and script do NOT keep their states if given from object inventory to other objects... small annoyance... if they go to/from av inventory they keep states

The wiki says that you can save upwards of 8k... over 7k at least, in the object name and description fields. I've been working on a storage system that uses this 'hack' and have had no issues storing data (as of yet). I've also yet to do any specific tests either. The reason I needed this in the first place is because I wrote a vending system that tracks daily sales, and shoots off a daily report once a day. The idea being that the script could survive restarts and such w/o loosing data. I'll post anything I find out on the issue...

So, don't reset the script. Sim resets do not reset scripts. Well, it could happen, but object descriptions could get munged too, or your object could disappear completely.



This is true when passing just the script, rather than passing an object containing the script, so the suggested means of storing data doesn't apply.

I maintain it's better to keep data in a script than hidden in properties of prims created for the purpose of holding data. I admit that the latter will retain data in the very rare case when all scripts on a sim are reset, but no other object information is lost. Note that it will not help in the case of a rollback.

Just double-checked inworld, and if an object gives an object to another object (using llGiveInventory()), scripts in the given object retain their states.

A script outside an object has no state. A script in your inventory has no state. If you drag a script from an object's inventory to your inventory, and then to another object, it gets reset when installed in the object.

In the above, by "state" I mean the FSM state and all variable values. I didn't test whether permissions are retained, but I would expect them to be. It should be all-or-nothing.

he you're right, scripts in objects, retain states when moving, scripts outside objects don't... having a ablonde moment there I suppose

as for keeping all the data in helper scripts vs prim attributes, I'm gonna want to disagree with you there....

now in most cases I wouldn't add a ton of data prims anyways, because at that point it's just more work to retireve data, same as helper scripts....easier to offload to a webserver... but in my usual case....

the prim properties are already there, cost little to access programaticlly, and don't add much in the way of memory or script prefs for sim overhead. the same setup using helper scripts has more space, but the cost is higher script prefs and memory used by the server, we'll ignore overhead for link messages as it'd be equivalent to overhead for prim properties.

prim properties a less of a risk imo, since resets don't affect them, but may randomly affect scripts. nevermind a user/landowner being able to randomly reset all scripts in an item, or the fact that you might want to if something goes horribly wrong/stops working... you'd not want to lose that data... it also enables data persistence across users, for scripts that use owner functions that don't like to update without some reseting scheme.

I'll grant there are times when helper scripts make more sense, especially for larger amounts of data, when web access isn't an option, they all have their points

Well, there are two ways to look at it. Frankly, when I reset, I WANT to lose all the data. That's the point of the reset. But, with two scripts, well, i'd have to reset both.

But you're right, that the overhead is low for stashing data in a prim that you know will be there (esp if it can hold up to 8K, not just 256 bytes), and it's simpler than writing a data script.

On the other hand, if you write a good data saver script, one that helps you organize the data, you may find that it's worthwhile. But accessing prim data is synchronous, whereas accessing data in a script involves messages so is a lot more complicated and I wasn't thinking about that earlier.

As usual, the best solution depends on the details of the problem.

missed this before, and yes the wiki says you can store loads in there, but that several things can truncate it... the script being reset (which makes it little different than a second script) the user clicking in the field, and pretty much an sim reset/restart/crash/rollback... I haven't seen this because I barely use the limit, but some cases even truncate to 128...

most cases yeah you'd want to reset the holder data, but not always, data persistance has uses, like complex user settings that you'd rather not store or bother w/ in a notecard (users like menus, not editing notecards, in general)