Script-accessable persistent storage

Hi,

I have a concern regarding the availability of storage for scripts. Currently, there is no way to store any data so that it survives beyond the runtime of the script. There's also no way to store an arbitrary amount of data for any length of time at all. This prevents the creation of any large systems that need to maintain state over a long period of time.

Here's a demonstration of the problem:

string storage;

default
{
    state_entry()
    {
        llSay(0, "Entering default state");
        llListen(0, "", "", "");
    }
    
    state_exit()
    {
        llSay(0, "Exiting default state");
    }

    listen(integer channel, string name, key id, string msg)
    {
        if (name == "Bob Brightwillow")
        {
            llSay(0, "Stored: " + msg);
            storage = msg;
        }
    }

    touch(integer num)
    {
        llSay(0, "Storage: " + storage);
    }
}

When I create this script on an object, and it compiles and saves, it prints out "Entering default state". I touch the object, and it prints out "Storage: ". I say Hello, and it says back "Stored: Hello". I touch the object again and it says "Stored: Hello". All's well and good.

Now I edit the script, typing in a space and erasing it again -- in effect doing nothing but flagging the script as modified -- and compile it and save it again. It prints out "Entering default state". I touch the object, and now it says "Stored: ". It has lost its memory.

Of course that's unsurprising, given the environment in which scripts run, but nonetheless frustrating. If I wanted to maintain a database of UUIDs for some reason, I would have to re-register every object every time I make the tiniest change in the database script. If I wanted to maintain a guestbook, I would lose all entries every time I change the script. Any sort of data storage is instantly vapourized whenever the script holding it is disturbed.

I'm also informed that scripts have a maximum space of 16kB in which to execute. That's not a lot of space to use to remember even a list of objects' keys, even if UUIDs are (assuming I counted correctly) only 16 bytes long a piece. And the script's bytecode, I'm sure, takes up plenty of that space by itself.

So I would like to make a request for any sort of persistent storage. One way to do this might be to allow a script to write to and read from a notecard attached to the same object. If methods could be provided to write to and read from a certain range of bytes stored on the notecard, a script could store arbitrary amounts of data, and rely on the same data to exist beyond its own runtime.

Thanks for your consideration.

Even though this has been discussed before, that is an excellent argument.

I also believe this kind of functionality is needed. Another possibility from this would be the creation of personalized note cards. That could be interesting.

I think though that writing to notecards has been stated as impossible or not going to happen.

Here is an alternative:
Some functions:

key llStore(list StufftoStore)

Stores the list in an invisible data store object, and returns the key to that object. I might suggest charging the script owner each time this method is used.

llUpdate(key storeID, list StufftoStore)

Replaces the data at the storeID key with a new list, assuming the script owner owns that dataStore.

list llRetrieve(key storeID)

Takes the ID of a dataStore that the owner of the script owns, and returns the list.

llDelete(key storeID)

Deletes the dataStore and returns any money that llStore() takes.

list llGetStores(integer OWNER | SCRIPT)

Returns a list of keys that are the dataIDs of all dataStores owned by the owner of the script, or owned by the script. Whichever would work, or both if possible.

The money required could be fixed or dependant on the size of the list. There could be maxes implemented for number of dataStores per script or per owner or maxes on the size of the data stores individually, by owner or by script. I think this would allow enough control and flexibility at the same time to implement state persistant scripts.

Problems would be the same as any multi-user db system: access controls if more than one script accesses the dataStore at the same time, data integrity.

i can't help but wonder if we will be able to use the email to and from object calls to set up this type of database, that is of course when the commands get fully fixed.

The simplest solution, which was mentioned above, is to read and write from notecards in the objects inventory.

I don't see why this would be difficult at all, and it would provide all the persistant data capabilities you want.

-Pat Murphy

A very old thread, but as current today as it was back then.

The simple reply to "Writing to Notecards won't happen" (and there may indeed be very valid implementation reasons why it can't) is "So create a new Datacard object that can be written by scripts."

Where there is a will to listen to players' suggestions, there is always a way.

Addendum: a pretty strong hint that an llCreateNoteCard() was in the works appeared on a different forum, which is exceedingly good news for those who wanted the write facility to store parameters and similar brief data. Writing cumulative logfiles probably still won't be possible directly, but it's a very good start.