How to save data from a script?

Hello,
I need to keep text data about events happening in a script (storing log of events and input data for future use)
I found out a script cannot write to a notecard like it would to a file, but only read...

What are the options for a script to store text strings in a permanent file for later retrieval?
Any recommendations, pros and cons, favorite method, etc...

Thank you for your help.

FrenchCHris

Thank you for your response.
email is a good option for low volume and to be read by a human, but I would be receiving 300 emails a day with that method...

What I really need is a data storage that is structured and accessible with a program (either script inside SL or excel/access outside of SL)

For example, I went to places in SL that told me I had been added to the list of visitors: how do those scripts store the information?

I appreaciate any help or advice

there is simple way to store data.

this visitor counters may be using the script internal memory up to 16KB.

there are alot of hackings possible to store data in a "permanent" way:

1. Ideas For Permanent Data Storage?
   
2. Store small amounts of information permanently
   

(u can find more info about storing data on SL)

this LSL limitation is kind frustrated. data is the base for all comunitys to grow. without storing data SL is a volatille comunity - but this is just my opinion.

i wish XML-RPC

Shoulda added this here, not the old thread. OK.

list MEMORY = [ // initial values of the data I manage
    "Fred", "Fred Demo", "Demo Family Patriarch", "101", "Eats his veggies"
];

default
{
    link_message(integer from, integer num, string str, key id)
    {
        if(llSubString(str, 0, 0)=="?")
        {
            llMessageLinked(from, num, llList2String(MEMORY, num), id);
        }
        else if(llSubString(str, 0, 0)=="!")
        {
             list newmem = [];
             if(num > 0)
                 newmem = newmem + llList2List(MEMORY, 0, num-1);
             newmem = newmem + [ llSubString(str, 1, -1) ];
             if(num < llGetListLength(MEMORY))
                 newmem = newmem + llList2List(MEMORY, num+1, -1);
             MEMORY = newmem;
        }
    }
}

(grids down, only desk-checked it)

OK, I'm new so maybe I don't understand this...

Your list MEMORY only exists in the scripts 16k space. That gets released on derez and reinitialized on rez. That's not permanent storage...right???

Since you can't write notecards it seems the only way to get perm storage is through writing a prims description or name.

To get multiples of the 127 byte prim description limit all you have to do is link a bunch of prims and have them communicate the data in their description with the parent.

As long as the script is not reset or recompiled, all variables will keep their values. When an object is stored in inventory, the script's memory state is saved so when the object is rezzed again, the script just continues from where it left off; theoretically, no loss of data occurs.

Even when sims crash, before the sim restarts it saves all scripts' memory states and restores them when the reboot is complete.
==Chris

Wow! OK, this is very useful info, thanks! I completely misunderstood the way it worked.

Is this retained if the object is transfred to another player's inventory as well?

Yes, so long as the script is not reset (or recompiles) transfer does not affect its state.

One itty bitty exception to the redoutable Mr. Omega's post above, I have seen once in two years, a case when the state of scripts in a sim were not successfully saved during a sim-crash.

Please also note that this state persistence also can cause problems if you are not expecting it for example, in:

key gOwner;
default {
    state_entry() {
         gOwner = llGetOwner();
    }
    // ...
}

gOwner will contain the former owner on object transfer. The idiom for keeping that from happening is:

init() {
   ...
}

default {
    state_entry() { init(); }
    on_rez(integer start) { init(); }
    ...
}

Ick.

That could be pretty bad, a lot of objects seem to keep state in their scripts.

I've had stuff stop working, so I had to go back to the vendor and get a replacement, after I reset the scripts in them. That's bad enough when it's my fault, but...

A lot of scripts do reset on rez, but they do it explicitly to make sure they don't leak things like listen handles. It's an ugly hack, but it's very common:

default
{
    state_entry()
    {
        llListen(1, "", llGetOwner(), "");
        //...
    }

    on_rez(integer param)
    {
        llresetScript();
    }

    //...
}

Better is to do something like this (an elaboration on malachi's comment):

integer listener = 0;

init()
{
    if(listener) llListenRemove(listener);
    listener = llListen(1, "", llGetOwner(), "");
    //...
}

default
{
    state_entry()
    {
        init();
    }

    on_rez(integer param)
    {
        init();
    }

    //...
}