Is script data persistant???

I've see a few scripts that have changeable data stored in a script variable that is set up via a talk channel or a note card being dropped on the object. But I also read somewhere that you can't rely on the data in your scripts data being persistent? Is this correct?

That is correct. This is why people suggest putting persistent data encoded into the prim the script is in somehow, or notecards, etc.

I can't find anyway to make a note card to store my settings in. The only place I can find is the object description, not tried that yet and its of limited size as well as the data being public.

From what I read persistent data for scripts is a problem, what solutions are there? Seems an oversight not having a private persistent storage on a prim, even a limited one would be good. I can understand why they may have not have done it as it would put up the storage footprint of the whole simulation.

There is no way to write to a notecard from a script. There are technical reasons for this, apart from any practical reasons the Lindens may have. There has been talk of having persistent storage inworld, but when/whether this will show up is anyone's guess.

You can, as you mentioned, store information in the object name and description. Also, you can store floats in other object properties, such as texture rotation, offset, etc., if these are not needed for their normal usage.

Apart from that, the only option is outworld storage and retrieval via HTTP.

Have a look at

/54/69/119570/1.html

its totally persistent when you dont need or want it to be heh

but the second you start to rely on it is when they have to reboot the grid, and then your data goes to the great bit bucket in the sky

There is always the tried and true llSetObjectName, llSetObjectDesc, llGetObjectName & llGetObjectDesc to use as small RAM files. If you do a search in this forum under memory there are many more discussions on the persistent memory limitations and also the ways to get around it without having to go through a server.

Another good place to look is on the homepage of the wiki in the "Hacks" page. With a little bit of ingenuity you can store a fair amount of data in the limited space.

If you're concerned about the data being public, storing it in the name or description of a child prim may help a bit depending on the structure of your object. Just put a script in the child prim to read/write the description and make requests to it from your main script with link messages. It may not completely hide it but if the child prim is buried inside the main object well enough it'll at least make it a lot harder to get to, and most probably won't even think to go looking there.

Just one little warning... llSetObjectDesc does not work correctly when used in an attached object. Once upon a time it did, then LL in their infinite wisdom "fixed" it in an update.

There prob should be a pinned post on this forum as most newbies like my self will do some Googling then post to check their findings/assumptions are correct.

Just so us newbies don't keep digging up this issue.

I have scripts that have been running 2+ years without being reset or losing any data, in a mainland sim that crashes a few thousand times a year.

here have a gold star and a cookie

ive had scripts run less than a week before loosing data

For scripts I use only for personal purposes that is fine. But when you create sripts for customers that are not programmars themself the method of "if I run into a problem I can always solve it" isnt working.
Think of writing a calendar/organizer. Such a tool needs to keep PERSISTENT DATA for a LONG TIME (even after you left SL for good). Your customers rely on that.
And beeing dependant of storing the data outworld is not fine. First it may incure cost, second as it is not an inworld solution it depends on the one operating the outworld service (security, shutting down the service ....)

I'm not sure what you're trying to say, but about a week after I posted that, some Linden tool apparently glitched out and every single script in my whole sim got reset and had its "Running" box unchecked. Linden response basically ended up being "oh well, you're screwed, get over it."

Under ordinary circumstances, though, scripts that are not explicitly reset should be able to keep their state indefinitely. As long as you don't go and jinx it by saying anything about it :x

The point is that you cannot depend on in-world state being reliably persistent.

We've had everything from scripts getting reset, to stopping running, to having an entire server object just vanish, never to be seen again.

Indeed. And not all objects can have permanent stored data without some form of "ram" like ObjectDesc or ObjectName. I have a health bar script that is just text above your head. Basically, every little change to it means a new llSetText to trigger with the stored values. And some of those values are intended to be changed by the user, like Name above your head or text color. I found that for storing text color data, llSetColor and llGetColor work perfectly, if done on a prim you don't want to see (a.k.a transparent) llSetOjcetDesc and llSetObjectName, with their respective "get" calls, seems to be doing fine storing my other two values. Custom title and an active/inactive trigger check. Notecards are good to store data using the dataserver thing. But fail when you need the object to be no mod but the notecard data customizable by the users. In my case, I had to make a separate moddable object with the notecard and comunicate with the no mod object via chat. As you can see, far from practical.