Store small amounts of information permanently

Can anyone elaborate on how to store/retrieve integer values? I would like to store a number 1 - 10,000 and retrieve it. I have it working with llSetAlpha, but I know it is not elegant. Here is what Badgeometry has to say about it (and I think llSetAlpha needs a min of 0.1):

Besides using a script's memory as permanent storage (and just never resetting it), you can store short strings in the object name (using llSetObjectName / llGetObjectName). If you don't want your object to change it's name, use child prims in a link set for that. You can also store floats in other object properties, such as texture rotation, offset, alpha, scale, etc. Basically anything that has a get/set combination. To store integers, you can simply convert them to floats and back by scaling them down to fit into the usual 0 - 1.0 range.

You can also use llSetTexture to store strings using the typecast, as well as llSetAlpha for floats, llSetColor for vectors. - combined you can store a lot of information permanently.

I haven't played with yet, but I know scripts can read notecards.

Can they change the text in the notecard?

Wraith,

No.

Al,

One of the tricks is to set the texture key of a side of a prim (like an interior texture of a hollowed object). I think this is one of the tricks that was discussed before the Great Script Forum Wipe.

> Can they change the text in the notecard?

Ah, you've stumbled upon perhaps the most requested scripting feature of all time

> Can anyone elaborate on how to store/retrieve integer values?

Well, the Wiki says it all really.

To elaborate concretely, scripts dont reset when the server resets I hear, so why not just leave the values in the script memory?

If you have a script you want to maintain - thus resetting the data often - you could create a second script to store the data, and linkmessage between them.

If you want to be able to transfer data to other objects, you could create a central datastore on your land, and just have the other objects email questions to it.

Other than that, I have a storage device that stores strings in the texture keys. I think you get 96-characters per prim, so you actually get better storage density from the object name

And lastly, you can always use email to email an outside server (ie extra-SL) which sends you back the values you stored.

Azelda

Good info. This is going into a sellable attachment. And from my experience, ownership does not get updated when someone purchases an item. So, I have to reset the script to also reset ownership. Changing the name to store the data would be great, except you can't change the name of attached attachments. So that really leaves me with storing it one of these kludge data spots. I could do a data store linked object. But, I felt using a local prim value to store the data was a 'little' cleaner.

What I was really fishing for was a code snippet on translating integers to a value from 0.1 - 1.0 and back.

Oh and about storing data as a texture string, how do you do that without generating a "texture not found" error?

Thanks all.

You can always have llGetOwner update the owner variable in on_rez() or attach(). That way, depending on your script's purpose, you wouldn't have to reset.

Catherine, I don't understand. What I am saying is that until the script is reset llGetOwner() returns MY key. Even if the item has been purchased and rezzed by the next owner.

You're sure of this 100%?

Usually owner-change problems occur when functions that change a value or add a handle that stays resident in the script's memory are passed the return value of llGetOwner at a specific point in time. For example, llListen being passed the return value of llGetOwner at some point within state default:tate_entry().

I've not once seen llGetOwner report the wrong key.
==Chris

Wow. OK, this may be a revelation for me. I had always assumed llGetOwner() was bugged and needed a script reset. But, apparently what has really been happening is that I have had old llListen handles that were set originally to listen to my key. So.... I should just be able to update llListen() on rez and the world will be a better place. Testing....

One common misconception that many have had is that llGetOwner, somehow, maybe since its a ll function, returns a "magic pointer" to the UUID of the owner of the object. The value pointed to by the pointer would change dynamically based on the owner of the object.

This isnt the case LSL doesnt use pointers!! At all! Period!

When you get the return value of llGetOwner, its not guarenteed that that value will actually be the UUID of the owner of the object 0.0001 seconds after calling llGetOwner. The reason why many people re-initilize on-rez is that the owner UUID has the highest chance of changing when an object is rezzed. The only case in which an object's owner will change when an object isnt re-rezzed is when "buy original" is set. AFAIK, there is no way to detect *that* owner change, unless you're calling llGetOwner in a timer and comparing the return value of a previous call stored in a global to the return value of a new call made in the timer.

We need a CHANGED_OWNER changed constant :-/

==Chris, who is in a ranty, chatty mood atm

EDIT: Spelling error.

> Oh and about storing data as a texture string, how do you do that without generating a "texture not found" error?

As long as it's a valid key, ie hex, with the hyphens in the right place, it simply displays a "texture not found" bitmap in place of a texture.

Hide your storage prim(s) inside another prim and noone will see them.

I sell a storage computer that stores strings in texture keys. You can store as many strings as you want, indexed by number. You need one prim per string. Maximum string length: 96 characters.

Azelda

should be able to store 164 characters in a prim's textures. A box has 6 faces then with hollow and cut you get 3 more. Thats 144 bytes or 1152 bits. In SL we only use 7 bits per character so 1152/7 is about 164. Then if you consider the face colors, offset, rotation and size you can squeeze more out of your prim (8 restricted floats per face 72 total). calculations will need to be made as to how many bits each can store... Next there is prim size & rotation (7 restricted floats) with the upcoming romoured llGetPrimitiveParams it might be possible to get the data that makes up the properties. Currently the only way to have an idea is to use the mass & center of mass of the object and use them to calculate the hollow, cut & topsize (5 restricted floats). Have i missed any? I'm running out of ideas.

Now if a restricted float only supported 16 bits of the full 32 then total we have 84 restricted floats coming to 1344 bits or about 192 characters. bringing the total to 356 characters. But i would say don't expect more then 300 characters...

I was thinking about this for fun the other day...

You could use prims with setpos / getloc

Then each prim could report its loc back to a master script witch converts the value to 0 or 1 based on the objects two posibible, predifined locations.

You could even make it base 10 (or base 26 for text, or base 256 if you are insane) with each prim having 10 possible locations.

(imagine something like an abacus, with the position of the little beads just used to store numbers)

Then if you were in the Xylor range of smarts you could turn this thing into some kind of calulating abacus or slide rule type thing to store more data and do calculations even.

I think you could do matricies and calculus this way too.


A large one of these might casue some serious sim lag with all the moving chattering prims. I think the texture idea was better... I dont have the time to figure out how powerfull it would be.


Of course I prefer to not store data and use my 1988 HP calculator for calculations .

Lindens, Listen. All of these wonderful ideas, tricks, and calculations people are coming up with to make an inworld storage mechanism should tell you something.

PEOPLE NEED INWORLD STORAGE!!!

Now, from what the Lindens have said, they won't let us create notecards from LSL because they are afraid that the dataserver will be overwhelmed. However, if somebody takes the ideas in this thread and run with them, they will overwhelm the dataserver as people start using it, probably wasting more space than giving us native database or notecard storage. It's just like with llEmail. 20sec delay got ya down, add 200+ scripts to your prim and get around it! Oh, the 200+ scripts add additional lag to the sim, oops.

Grr

If you just want to store data that you'll still have available after you reset (or edit, or update) your main script, just have a listener script that does this:

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;
    }
}

With MEMORY initialised to the default values for each of your numbered messages (say [ "Fred", "Fred Pocketbook", "Eldest of the Pocketbook family", "101", "Eats his veggies"]). This should allow you to get quite close to the maximum 16k allowed for one script.

(not tested, since the grid is down, only desk-checked)

I just use the prims description field...127 bytes but can be seen by anyone editing the prim. It can be read and written and is permanent.