Notecard as data storage?

I am a little new to LSL, and I was wondering if a script can, in any way, write to a notecard? If not, would there be any way at all to keep track of data with a script? Other than just storing variables of course. I am trying to create something that stores a list of values, that one could easily show others (ie, give a copy of the notecard).

I tried google, and also did a wide search in the forum and was left empty handed.

There are many posts in this forum about that. As much as we would all like it, it can't be done.

I guess, this question would be worth a sticky

First sticky, third posting

I know - but no one ever reads the manual - guess, what my first question was here on the forums So, I meant that there should be a sticky with the title «writing to notecards»

Hmmm, there must be some Rube Goldberg ways of storing a big list completely in-world ...

1) buy a sim, start with one object - list controller
2) from anywhere in-world, llEmail() the list controller in the empty sim
3) LC rezzes list item prim
3.5) LIP calls LC for data, and sets name to key, description to value
4) you can store a list of up to 14,999 items this way

5) lookups are a bear...



Surely there are some more creative ways!

(but to answer OP, may want to check out http request...)

yeah, store all the data in multiple scripts that are either preloaded into an objects inventory, or stored in a rezzable prim (or both), and you're right, lookups are still a PITA... sadly after much effort it couldn't be automated AND without a cap, because there is no way to rename a script via an LSL call. but the above methods work even if they have limits in preloading, or number of prims, or rezzing restrictions.

There was a post awhile back about storing data in queued link messages. It sounded interesting, but has obvious risks. Not something I would use for long term storage to be sure.

I'm planning on building a SQL/relational database in the near future.

All data to be stored in game. Design is done just clearing out some smaller projects

So yes, I was kidding about rezzing 14,999 objects in an empty sim..

.. but there is a kernel of an idea there if you *just gotta* store data in world...

I was going to say: You can have objects that rez, change their names to be a key / value pair, and then arrange for them to give a copy of themselves to a container object.

But that falls apart because you cant change the name of an item in inventory.

If you have a fixed master list of keys/values.. you could distribute them among a series of containers (where each container represents a topic, a tag, etc). Objects can scan their inventory for matches far faster than waiting for notecards. (and make note.. you can specialize within a topic by using objects, landmarks, textures, etc.. it doesn't matter what those items actually 'are'... it's just a means of storing names)

So to sum up... can have a field of container objects that are doing interesting things with their individual inventories. 10 containers with 100 items each would be pretty doable.
And dont forget that names of objects can be mini-command lines:

PIC.MyPhoto +x4 +z3 +a0.6

One missing call that would make this a lot more interesting would be llGetInventoryDescription()

just make a http call

there is a freebie server to be used
http://w-hat.com/httpdb

We need someone to run a custom client service, like the one that looks up keys. Make a protocol where you can send an e-mail or IM from a script, get queued up for the avatar to TP over, listen to chat to get notecard lines, compose the notecard, deliver it to the object (which'll use llAllowInventoryDrop() to receive it), and then TP off to the next assignment or back home if nothing's queued up. LOL.

and for fun you can probably store ~8k in each of those messages... not sure what kind of storage the queue would hold up to, and retrieval is a PITA. but assuming the queue doesn't blow up in some way with all that data floating around in it, almost a half meg of storage for a prim doesn't sound too bad =X

too bad it does nothing to solve my permissions storage problem =/

You can store full 16k, although the receiving script would likely crash on triggering the event, so probably a little less. This is a brilliant idea, IMO, and I have plenty of ways to implement it. I just can't come up with a project that would need it.

well you have to figure that the message will need to be parsed, and that will require some memory, even with preservation techniques that's going to run quite high in the best of circumstances, probably around double (hence the reason for only 8k messages), but for further preservation, you could halve the storage between the string and key portions, so that you'd only have need to process half at a time, per cycled message, which could reduce your internal memory needs, and allow more processing code, or maybe more storage space per cycle.....

for a quick calculation that's ~ 226 keys stored in a single message, times ~60 messages, means you could store over 13.5k keys in a single prim using this method... and that's with margin for error. I'd be willing to bet if you pushed it you could store the key of every prim (not just object) used in a region (assuming you had a way to collect all those keys)... even if the region was filled.... or a visitor counter that tells you when you've hit your 10,000th unique customer ( I swear I'm going to build this now ).

biggest problem is that it's likely to be completely wiped out by a sim reset, crash, or return to inventory.... but it'd be a good way to cache daily data for compiled emails or some such

What I'm wondering is how queued events are stored in comparison to normal state memory. I know they aren't THAT fragile, but I've never tested it; I don't even know if they survive when the object is taken into inventory.

I believe queue data is lost/dropped in all of those scenarios...

I do know that scripts that aren't running don't queue new messages, and queued messages are lost in those scripts when the are stopped (which is analogous to inventory take).

a definitive test would be to trigger a message from the message handler code, change the name of the object, then enter an polling loop checking for the old name of the object. once taken to inventory, the original name is restored ( IIRC only attachments that do this), re rez the object, polling loop exits on detection of original name... if the queue is still intact it should trigger and process the message sent before it was taken.

I can imagine a similar polling test using llGetTime on a region where you have the ability to restart.

both should be definitive tests of volatility

come to think of it, get time would work for both, since script time resets on_rez, and on sim reset....

There is no SLS command to write a notecard.
There are commands to delete and copy existing notecards.
notecards can become relatively big (64k limit?), and an automatic writing would cause a lot of traffic.

Using UTF8 compressions, you can store 1200 bits (150 bytes) of data in an objects description (stored in 84*15-bit words) and 1200 bits of data in an object name.
llSetObjectName, llSetObjectDesc, integer2utf8() utf82integer()
But the bytecode for these procedures is roughly 4000 bytes, so that rarely makes sense, you could just use globals instead.

One method I use for storing large amounts of data off-world, but without using any calls at all, is to have the data spoken in chat. All my chat goes to my chat log on my hard drive, and I have a little VBA script that parses the data out of the chat log.

I use this when mapping entire sims into raw files (64K), but size is virtually unlimited.

Rock

I have been working on data storage for quite a while now, and have placed a few of my earlier working examples in this forum. The most recent iteration allows the storage of quite a lot of data in just 2 prims with minimal overhead, see the “2 quick questions" thread.
With all the methods I have posted so far, the stumbling block becomes the data retrieval process. I am nearing completion now of what I call the SQL-Slice, and I will post it here for review/use when I get some more bugs out of it.
I am aiming it squarely at MONO though, relying on the extra script capacity and performance to obviate the overhead of my SQL parser.
It has been a fun project and I hope many will find it useful.

SQL parser? I hope you're joking. At least until there's some kind of regular expression capability....

(of course, http is the real answer, as has been covered elsewhere)

I just had a slight drizzle of a brainstorm...

topic containers that have inventories of temp on rez data prims...

request comes into a specific topic, it rezzes a dozen prims or so, each packed with data and a listener on a specific channel. The topic container emits the search request, data prims do the lookup, and route any results back through the topic container. Topic container handles the response back to the requesting client. The data prims die after their search, or via their temp-on-rez setting.

The distributed, on-demand nature of this would allow somewhat speedy responses, and would minimize impact on a sim by minimizing the number of active scripts most of the time.

quick scenario : topic containers for movies, music, and art. Returned results might include web addresses, landmarks, textures, objects, etc. (data prims might include their own small inventory to distribute back to requester)

not a bad idea... for pre-gathered/static data.... no good for storage of dynamic data.

not sure where olj is getting numbers but the current adjusted (1/31/0 limits for name/desc fields are 503 bits (63*, and 1016 bits (127*... (those are 8bit character fields right? or no?) anyways, tiny compared to previously, not the same for both fields.

I believe they are CHARACTER limits. I think characters in SL are encoded in UTF-8 or UTF-16, so you MIGHT be able to get away with more than 63 or 127 bytes of storage. I hate these hacks though myself. Go with a real solution like HTTP if you need it. Really.

No, I'm not Joking.
And to make the project even more fun, I had to learn SQL to attempt it. In a way I think that learning it by dissecting the server and working up to the language was not such a bad way . It will not be the full language of course but so far it supports:
CREATE TABLE table_name(field1,field2,field3,.....)
INSERT INTO table_name VALUES (value1, value2,....)
SELECT *|field1,field2,field3,.....) FROM table_name WHERE field LIKE %mask%
UPDATE table_name SET field = [new value] WHERE {condition}

I have tried to keep the syntax correct so that the same command will work via http to external servers, but I disagree that that is the only way to go. I don’t want to be dependent on a 3rd party for my systems to work (linden Labs being a given) and apart from that a lot of applications only need transient data such as Contest boards and visitor trackers. And in practice I have had scripts with the data still intact after nearly 2 years of use. Many RL hard drives are not that reliable.