Someone clarify the fuss about permanently storing stuff...

So I really try to understand the whole fuss about «permanent storing data»...

As everybody else, I was asking the question about «can I write to a notecard» when I first came here, because I'm used to «write» data into some kind of permanent storage...
But then I found out that - even when I take an object back to my inventory - the data that was stored in the script, while it was running, is still there, when I rez the object again (e.g. the key of the owner, hence the need to do a llResetScript(); when passing the object to someone else...)...

So I assume that when data in a script is changed, it has to be stored _somewhere_, doesn't it? otherwise that data would be lost when the object is taken into inventory. So I guess, whenever data changes, it's stored on the asset server which - in my assumption - is pretty permanent unless the asset server has a crash and all data was lost.

Assuming this - I don't really see the need for any _other_ permanent data-storage, as the asset server does this job for me. As long as I have enough memory in my script (which can be extended just by adding more scripts to an object, I have enough permanent data storage and don't really need to «write» data anywhere else...

This script says the message I entered again, even when it was taken back to my inventory an re-rezzed. When I pass the object to another AV and she/he rezzes the object and touches it, the message will still be there. So the data is pretty permanent to me...?

string my_message;

default
{
    state_entry()
    {
        llListen(1, "", llGetOwner(), "");
        llOwnerSay(my_message);
    }

    touch_start(integer num)
    {
        llWhisper(0, my_message); 
    }

    listen(integer channel, string name, key id, string message)
    {
        if(id == llGetOwner())
        {
            my_message = message;
        }
    }
}

[edit] no flaming please - maybe I oversee something and this kind of permanent storage as I can see it happen is just not enough...?

Script states are indeed saved when you take an object into inventory.

Script memory has always been just about as 'non-volatile' as object names or inventories. There aren't many instances where you really need to worry about your script needing some external storage. If you have issues like mission critical data or large amounts of data, you shouldn't be storing it inside SL. Period. Nothing in a sim is that safe.

I'm with you on the mission critical data. If I really need something permanent, I store it offworld in a database (and make backups from thad db and then backups from the backups). NO data is really safe... according to Mr. Murphy, the more critical it is, the more likely it will get lost

Now take that same script and reset it and touch it again, now it won't say anything. Anything you write into the script or on a notecard and access is permanent. But any variables that are supplied by various means, such as a listen, detected, sensor etc, are lost if the script is reset.

In the case of the Timeless Door;
If you put the info in a notecard, then all is fine and for whatever reason, you can reset it and the data is still there. But if you want to make it reaaaaally user freindly for people that get flustered even editting a notecard then( I know people who have been in SL for a couple of years and still don't know how to change an animation name in an AO notecard and refuse to even try)................................

You change so that at some command from the owner, they can say /99 add Jesse Barnett for example, the script adds my name to the object description and I am on the access list. In this case, until now, that info was still there if the script was reset. Another way to do it and still keep the same interface for the end user is to add the info to a list instead. In that case, the info is lost in case of a script reset.................................

Is it mission critical or the end of the world if the data is lost? Nope and would be ludicrous to have to use a server to store the data. But the reason the Timeless Door is so popular is because people with technophobia don't have to fiddle with anything. Pop it in a door, and go! In fact there are MUCH smaller scripts that could do a better job but people are scared of manullay editting a list in a script, silly yes but true. As I pointed out earlier, it isn't the end of the world and there is nothing we can do to change it but it is a slight inconvenience and does break some content.

I know what you mean, Jesse. That's actually the reason why I gave up making stuff where people have to edit notecards. Either, they can't read the manual and aren't able to properly edit the card, or they simply refuse to buy it, because it seems too complicated for them.

Some of my stuff has pretty heavy configuration menus and if it really gets a reset, it'll be quite some work to re-configure it. Storing that data in the description/name-field wouldn't help _that_ much either, as it would be too much data for it anyway (even before the change). Storing it offworld isn't an option either, as I want my products to be working beyond my presence in SL, means, I do have server space with databases I could provide to store data, but I simply refuse to go there. SL is nice, but it has it's hiccups and downsides and I still don't know whether this will be a long-term relationship. So if I decide to quit one day, I'd have to provide db space for something I'm not even involved with anmyore - I just don't wanna do that.

So: making it easy for the user - yes. Risking the loss of some configuration data - yes... Using some hack that might get fixed some day - no...

Users without mod rights can't press the 'reset' button anymore, although the same is true of mod objects and descriptions. Still, the data is equally safe inside the script's memory. It takes the same amount of effort to press the 'reset' button as it does to accidentally clear the object's name or description by typing at the wrong time when you pull up a menu. By all means, request a new feature. But if you understand what we have right now to work with, you're best off just keeping the data in script memory. It's not THAT risky. There are less and less ways your script can be crashed every day, particularly so because of the very same update that broke your Timeless Door, as the scripting exploit it fixed was rather devastating.

My god Tyken!!!! Where have you been in the Scripting Forums the last couple of years. LMAO! I am a couple of years of coding past using the Timeless Door script and I understand how all of the permutations of how mod rights affect llReset and I also understand how memory works and that llGetFreeMemory actually gets the heap low water mark, which is never recycled until script is reset etc................

Are you having a bad night Tyken???? Are tehre any other scripting principles you feel a need to explain to me

No, but I'd find it quite ideal if you'd stop taking everything I contribute as some kind of demeaning personal comment and start looking at how I'm trying to use logic to come to the conclusion that keeping data in script memory isn't so dangerous.

Don't start a flame war here guys

I for myself followed those discussions about storing data in the description fields pretty closely. As soon as I saw, what _might_ happen, I decided not to use it because i figured it might be broken one fine day. Which, as we all know, happened now. So I'm glad I didn't go into this (not to say that a description field should be used for what it was intended for in the first place: a description of the object).

I am with Tyker when he says, it's not _that_ risky to store data just in the script. When the sh** hits the fan, we are screwed, sure. But as I said, there might be some other bug that just erases all the object's descriptions - and then we're equally screwed.

But I do agree with Jesse, in terms of feeling better if we could store some data in a place where it's secure from resets and minor hiccups.

Thus said, it might be worth talking the Lindens into providing us a way to store some data, that goes beyond those few characters that can be stored in description-fields. Maybe a special notecard, that just holds like 250 characters or so? - I know, people would abuse this as well and just put like a hundred of those cards into their objects, thus overusing the storage capacity again...)

Follow the link in my sig to my user page and then to the teleport HUD link, which I happen to use everyday. You will plainly see that I am not afraid of storing data dynamically in lists. I have pointed out multiple times today in this forum that I understand completely why the fix was uploaded and it's importance. I was also using logic to show why this fix does cause problems that we are going to have to work around.

I am not the only fully qualified scripter that shares the opinion that any other alternative is again, less then ideal for some circumstances. This is why Argent Stonecutter already filed this JIRA feature request:

https://jira.secondlife.com/browse/SVC-1406

"Non-volatile storage for meta-information"

to redirect the focus here, the 'fuss' is in the convenience.

it's convenient to store data programatically that will survive a reset.

it's also convienent to configure items from those fields...(and still possible, within limits)

that's about it.

I'm not motivated enough about Timeless Linked Door to do this myself at the moment, but I'd bet that with some basic data packing--and possibly a little geometry--everything that really had to be preserved could fit in the smaller fields that are still available for reset-tolerant data storage. Some broken content may not be that lucky, but looking forward, at least now we know how large those fields are supposed to be. I'm satisfied with those lengths, but if somebody wants an additional, more capacious object property, that's cool, and/or writing to notecards--with all the asset complexities magically solved--sure, not all that essential, but fine. (Personally, I'd find it more useful if a script could read and write its own description field within the object's Inventory, for reasons tangential to this thread.)

To my mind, the fault here really lies in how horridly underspecified the SL "machine" is, so of necessity, content is generated that depends on tacit assumptions about that machine. Under the circumstances, it's really amazing that everything doesn't break with every update.

The current limits have always been there. They just weren't enforced at the time of the modification llFunction call.

I'm with you, Jesse. The one's who don't want to use non-volatile storage, wouldn't have to. But like you, I won't accept them telling me why I shouldn't want it.

It is so common to want to reset (stuck or out-of-memory or whatever) scripts, to create new versions, to copy them elsewhere, that keeping "persistent" data in script memory isn't very useful at all in my opinion.

Well, so as to avoid a flame war :}, lets just say that those who don't want to use persistent memory already have the option they like. It would be nice if those of us who *wanted to* had the option we liked. That being said, if it comes at all during Second Life's life span, it will likely be a long time coming.

of which those resets can easily be scripted in, say, on rez handlers to clear variables etc... there are many cases where it's not desirable to reset data, which is a large part of why states persist across scripts being stopped (by call or by inventory takes)

I'm not saying by any means that I don't WANT to keep persistent data, or that others shouldn't want to. I'm saying I think very common tasks pretty much preclude doing it in script memory. Think about it: one minor little defect in your code may require a recompile, and that will destroy your whole database. Oops.

There are other reasons too. In the case that multiple objects are considered part of one application, it makes data sharing very difficult. There goes distributed computing/load balancing (which can make an even bigger difference in SL than in, say, normal web applications, since script/object/sim resources are awfully limited).

that's presuming non-volatile storage is linked to the specific script, and not to (for instance) the prim, or object. even if tied to a script, you could use a single script to data store and have all others comunicate with it, which would also mean an error requiring recompile would have likely corrupted your data anyways much as would be the likely case for all in one scripts (plus one really should add a 'dump' function if it's critical)


not sure if I follow you there, since presumably if a script can read it, it can also transmit it. having an object or prim level data pool whould actually simplify some script data sharing and load distribution providing a repository in which several scripts could act on the data, although implementation might be a pain.

Everyone wants to have access to permanent data storage; it's one of the major lacking features of scripting. But until we get it as a real feature, it's important for serious programmers to understand most of the existing methods are just hacks, and to take into account the calculated risk associated with using them in products.

Exactly. With the exception of storage on an external webserver, which actually starts to take on the nature of a full internet application with a database persistence back end. But this can't QUITE be considered a full solution, because it's not readily available to your average scripter.

and that's why I still want it =)

not to be taken that I can't run my own php/sql server, I already do, but limits on bandwidth prevent widespread use, and reliability of free low cost options is suspect, and not everyone has the same options or knowledge I do, so it'd be great for those just getting their feet wet, without needing to spend a bundle.

Some very good points have been made in the past in regards to this topic:

/54/dc/191471/1.html

Of course like most developers I've given up contemplating that oneday we might have real data storage in world and use off-world instead.

The usual solution to that is to have a tried-and-tested "database script" which responds to link messages, and is where the data's actually stored. (That's the best idea anyway because it ensures that you have the maximum space available for storage.) When you need to reset your main code, you don't have to reset the database script too, because it's already been tested as a separate unit.

The one thing nobody seemed to mention, which is mostly applicable to attachments, is that if the user crashes, or doesn't log off properly, the script states are lost. So if you depend on the script to store you precious data, you can quite easily lose it. And it does happen more often than one may think. Especially to those that crash every 15 minutes, and we all know someone like that, I'm sure.