A way to deal with no permanent memory

I use my own versions of HUD TPs and store the data into lists. Kind of sucks when you tweak the script and have to loose the destinations you've built up.

Started working on a different type of HUD and came up with the idea of dumping the list to chat. Unfortunately you can't just turn around and open the script and paste that back in thou the same way it is spit out. The script will throw an error if you try pasting this in:

Sandboxes, Sandbox Cordova MONO, Cordova, <100.000000, 158.000000, 21.612890>

I had to put qoutation marks on all the strings. Next test was chatting the data, like above, back to the script and that worked except that the vectors weren't treated as vectors and were returning NULL.

Finally I have it right and it works beautifully and wanted to share(Not the WHOLE script , Just the passing data back and forth part):

list temp = [];
string region;
key owner;
default
{
    state_entry()
    {
        owner = llGetOwner();
        llListen(99,"",llGetOwner(),"");
        llListen(-23123,"",llGetOwner(),"");
    }
    touch_start(integer total_number)
    {
        llDialog(owner,"",["List","Reload","Slurl"],-23123);
    }
    listen(integer channel, string name, key id, string message)
    {
        if (channel == 99)
            temp += llCSV2List(message);
        else if(message == "List")
            llOwnerSay(llDumpList2String(temp,","));
        else if(message == "Reload")
            llOwnerSay("enter data on channel 99");
        else if (message == "Slurl"){
            region = llList2String(temp,1);
            region = llEscapeURL(region);
            string temp = llList2String(temp, 3);
            vector slurl_vector = (vector)temp;
            string x = (string) slurl_vector.x;
            string y = (string) slurl_vector.y;
            string z = (string) slurl_vector.z;
            llOwnerSay("secondlife:///app/teleport/" + region + "/" + x + "/" + y + "/" + z);
        }

    }
}

When "List" is hit it returns:
[7:13] Object:

(Of course it's empty!)

Hit reload, type /99 and paste in data to chat and hit enter like so:

/99Sandboxes, Balance, Balance1, <107.163002, 137.085007, 22.234762>, Sandboxes, Sandbox Cordova MONO, Cordova1, <100.000000, 158.000000, 21.612890>, Sandboxes, Sandbox Goguen MONO, Goguen1, <136.000000, 167.000000, 20.979221>, Sandboxes, Sandbox Wanderton MONO, Wanderton, <178.000000, 161.000000, 21.546143>, Sandboxes, Sandbox Wanderton MONO, air, <178.000000, 162.000000, 726.000000>, Sandboxes, Sandbox Wanderton MONO, air3, <178.000000, 162.000000, 4006.000000>, Nice, Svarga MONO, Svarga, <67.712891, 116.176376, 25.655706>, Temp, Klein, Klein, <135.923004, 155.451996, 55.167561>, Temp, Sanchon, Sanchon, <165.754395, 16.167995, 45.747257>, Nice, Svarga MONO, Svarga2, <130.856171, 68.364899, 45.511467>, Nice, FurNation Gamma MONO, furair, <119.095764, 107.273392, 4001.185059>, Nice, FurNation Gamma MONO, furground, <121.209404, 99.480583, 21.757082>

Now the data is back in the script and returns the following when you hit "List":

[7:14] Object: Sandboxes,Balance,Balance,<107.163002, 137.085007, 22.234762>,Sandboxes,Sandbox Cordova MONO,Cordova,<100.000000, 158.000000, 21.612890>,Sandboxes,Sandbox Goguen MONO,Goguen,<136.000000, 167.000000, 20.979221>,Sandboxes,Sandbox Wanderton MONO,Wanderton,<178.000000, 161.000000, 21.546143>,Sandboxes,Sandbox Wanderton MONO,air,<178.000000, 162.000000, 726.000000>,Sandboxes,Sandbox Wanderton MONO,air3,<178.000000, 162.000000, 4006.000000>,Nice,Svarga MONO,Svarga,<67.712891, 116.176376, 25.655706>,Temp,Klein,Klein,<135.923004, 155.451996, 55.167561>,Temp,Sanchon,Sanchon,<165.754395, 16.167995, 45.747257>,Nice,Svarga MONO,Svarga2,<130.856171, 68.364899, 45.511467>,Nice,FurNation Gamma MONO,furair,<119.095764, 107.273392, 4001.185059>,Nice,FurNation Gamma MONO,furground,<121.209404, 99.480583, 21.757082>

And you can demo it works correctly by hitting "Slurl" which outputs:

[7:14] Object: secondlife:///app/teleport/Balance/107.163002/137.085007/22.234762

It is a clickable link and it does work

I write smaller amounts of data (<127 bytes) to the object description, and for larger amounts, I assemble a string with formatting and such, and email to myself. Then I can copy / paste from my emails... just another option

Just tested the real script and I was able to output or input a list length of 160 entries(40 strides of 4) with no problem. Have it so that it will output to chat in strings of 1024 characters and append the list when it is input.

It would be great if LL gave us some ability to write data in some permenent form but until then I have just set up a routine to read out a list of data that I can cut and paste to a notecard. I have a corrosponding routine to read it back in as needed. This won't work for everything and there can still be some data lost between times I manually back it up but for now its the best I've come up with for saving large lists of data.

I've suggest on the JIRA, under the entry for getting some kind of permanent storage, what SHOULD be a simple addition; maybe I should create a JIRA entry just for it by itself.

We've already GOT 255 characters, PER PRIM, of permanent storage... the float text attribute, which is part of the prim, just like the particle settings. The only problem is that while we can WRITE to the float text, we have no way of READING the float text.

We have llSetText; why in GOD'S NAME don't we have llGetText?!?

With a llGetText function, you could store up to 255 characters per prim, permanently, and just set it to full alpha so it's invisible; people would never see it.

GAH! Such a simple & obvious solution! Or am I missing something that would prevent LL from implementing this?

In my TP HUD, I just have it dump the data out in the same format as the permanent notecard. Then the user just has to copy/paste the chat text back into the notecard. If the in-memory location database gets borked somehow, they just issue a reload command, and all is restored from their last "backup" in the notecard.

..and yes, I think LL should have provided some kind of simple data storage system. More or less, just a simple key/data pair. Maybe limit the number of records per object, maybe not. Problem is, they charge L$10 per image for storage costs of that image data. What should they charge for large-scale persistent data storage like this? 100x1024 byte records, and you're already way larger than the average texture.

LOL. Talarus, I just have to say you inspired the perfect solution. I'VE GOT IT!!!!! They should let us store data in textures, just like sculpty data! (Sorry, I had to. I just love all these long-sighted solutions we're given.)

Argent Stonecutter's JIRA with 70 votes for Non-volatile Memory:

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

Yep, the other logical step. Your idea makes using notecards extremely user-freindly and allows dynamic memory to become permanent. Plus the script ends up doing most of the work for data input, would imagine along the same lines as the one I have in the library.

Click hud button to add destination and chat name for location and the script fills in the region info and position etc.

Don't know why I never really thought about having the script output the data so it was immediately reuseable before now. But hadn't recalled the idea coming up exactly like this before in previous threads about dynamic/permanent data.

Well hopefully my little snippet will give the new people a few ideas to create thier own new uber-cool creations .

I have posted much of my early work on data storage scripts here in the forum, one version in the Library, and I am still working on the concept, largely in anticipation of MONO, though I am getting satisfactory results in the standard LSL VM. The reason for posting is that my latest versions take the concept of the script formatting the output to the extreme. The "Backup TableName" command performs a “Select * from TableName” and dumps it into the chat output as a “Create TableName” command followed by as many “Insert Into TableName” commands as are needed to recreate the dataset. The users can then either copy them to a notecard (I have a batch reader as part of the core system) or issue the same sequence of commands on the command channel to recreate the data table, in the same or another object. In fact another database on any SQL platform in theory, but I have not actually tried that.