Storing Info Permanently

There's a hack where you can store info permanently in the name or description field of an object. And that while only the first 63 characters are visible to the user, you can store/retrieve up to 256 in the name field and 127 in the description field.

That works, and fine. But I just discovered a problem today that I never ran into before.

When an object with info stored in the non-visible part of the name or description gets taken into inventory, then re-rezzed... the name and description get truncated to 63 characters max.

Leave them rezzed in-world, and it's fine. Take them into inventory and rez them out again... truncated.

(sigh)

To quote Roseanne Rosannadanna: "It's always something."

i was under the impression that it was always truncated on rez (from inventory)

Little out of my depth but if it is an object could you store packets of information within each linked prim?

Yes, you could store it in the name of a linked prim. But since I'm trying to make this fully moddable by the customer, I want them to be able to add or remove prims from the object. So I don't want to spread the info across more than 1 prim.

And if it got truncated before, I'd never noticed it before.

You know, if we had a way to READ what some of the permanent parameters of a prim had been set to (like float text, or particles) we could use something like that to store data. Store the data serialized in float text, with the alpha set to 0.0, and it wouldn't be floating above the prim...

thats an interesting idea, altho i am still pushing for script writable notecards

You and me both, brother! Amen! Etc.

But given what an out-of-control (accidentally or otherwise) write/create script could do to the asset server, I highly doubt that we'll ever get those.

Functions to read the float text property, for example, we probably have a better chance at getting.

Variable values are saved when an object is taken into inventory. In the on_rez event you can update the name and description from the same data stored in variables, and use state_entry (like when it's reset) to reset the variables from the name and description.

Lyn

Now I haven't actually tried this, but based on , it sounds like it should be possible to store vectors in the color, and floats in the alpha, of sides not visible on the prim. I'd guess that texture repeats and rotation would give two more floats and texture offset another vector. I can't readily test it at the moment to determine whether the prim must actually have the sides (e.g., cuts and hollows for fully-intact prims). Of course, if the prim were mod-able, this wouldn't be suitable, nor if all the sides were exposed. And doesn't help with strings, barring some ugly transcoding--all for a very few bytes of storage.

(Sudden pang of nostalgia for mag core memory. )

I have in fact been doing that, but it's still too... fragile... for my taste.

As a matter of fact, I did try that very technique first, for several reasons:

1) You don't have to worry about the user editing the name of the object and screwing up the data

2) Unlike the name being changed, changing the color of the object or prim DOES trigger a "change" event... so you could use that to reassert the stored data if the user does a blanket color change on the item

But it turned out there were problems.

I need, basically, 28 bits of storage for one part of the data, another 6 bits for another value, and then lastly the need to store an integer that could be restricted to the range of 1 - 999 (it's not currently, but would be no big deal to do so)

Here's the problem. To store the data bits, I need 34 bits altogether, or 5 values of 8 bits each (obviously with some bits leftover).

A color vector gives potentially 6 numbers of 8 bits each, if you use the form

< a.b, c.d, e.f >

Where all values a, b, c, d, e, and f are restricted to the range 0-255

And then I could use the alpha value, in the range of 0.0 - 0.999 to store the integer value I mentioned that could be restricted to the range of 1 - 999

When I tested this storage method, though, something in the floating point rounding errors kept biting me in the butt. For example, I might store a value such as:

< 206.048, 6.17, 4.0 >

...but when I pulled those values back out and turned them back into their bit values, I'd get the equivalent of

< 206.049, 6.17, 4.0 >

In other words, I kept getting slight changes to some of the fractional parts of the values. And that corrupts the data beyond use.

Which is why I decided to go ahead and use the name for storage, even though it's very vulnerable.

>> Solomon Devoix But given what an out-of-control (accidentally or otherwise) write/create script could do to the asset server, I highly doubt that we'll ever get those.

Well let's hope they do something so we can, or so we can store data elsewhere. Never say never.

i can see that on creation, thats why im not asking for that

writing on the other hand should be handled just like reading, 1 line per request, and therefore would be no more a bigger problem than reading a notecard is today

Hmm. They'd probably stick in one of those "delays the script for 1 second" limiters on it, but I could live with that. Is there by any chance a JIRA on something like this we could vote on?

I don't know if sounds like a clever idea, or there maybe issues involved with this. I've not tried this out, so I can't comment how well this would work.

Say you want to store several lines of text into a prim. The main prim rezzes a new prim and sets the name and description fields with text it needs to store. The new prim is stored in the inventory of the main prim. Then when the main prim reads another line of text, it creates another prim, etc.

I guess you need to check the length of the fields when storing the text. At the moment there is no limit on the max objects you can store in a prim as said here:

http://www.lslwiki.net/lslwiki/wakka.php?wakka=inventory

With that method at least you can store quite a lot of text.

The problem is there's no way for a script to take the rezzed "storage prim" back into inventory. You'd have to do it by hand.

Thanks.