Lack of variables is really limiting us

Please allow us to store variables on a character, or object, or account, or something... ANYTHING which remembers a couple variables even if the scripts / whatever that set them gets destroyed or reset or the sim crashes.

Its severly limiting not to be able to do so. Most MUDS/MUCK/MUSHES have that as a basic operation.

Something simple, perhaps, like

llSetVariable(owner,"ScoreVariable",myscore);
...
score = llGetVariable(owner,"ScoreVariable";

Where ScoreVariable, etc, would survive if the script setting / getting them die or the sim crashes.

I mean, objects must be at least 2-3k in size to store, yet players have an unlimited inventory.

Even if variables showed up under a folder like landmarks do, and cost linden $'s to keep, it would still amazingly increase the potential for scripts.

llWriteToNotecard

It's been discussed (beaten) to death

I know, but it still needs reminding.

llWriteToNotecard is similar, but not as good... and not as flexible or useful. I mean, variables have to be TINY (memory / spacewise) in comparison to objects.

You do forget that reading from a notecard is tiresome, cumbersome, AND slow.

Im all for a non-notecard variable storage (if it will come before notecards).

Either that or functions like:

integer llGetLinesInNotecard(string notecard); //Returns number of lines in notecard.

list llGetLineInNotecardOf(string toFind); //Acts like a list's llListFindList(), 'cept for notecard text, returns list of the lines in the notecard where 'toFind' occurs

Both dataserver events if necessessarry.

And notecards can be buggy too.

And can die if sim dies

And can be destoyed or other things can occur


Maybe 'variables' can be like 'landmarks'. Just another inventory item that you can delete or examine or trade or whatever.

How about memory states. Basically saves all the variables of the script into an "memory data object thingii". To restore, just reload the memory state. Of course we may need some sort of declaration of what variables to store versus those that are not saved.

it could be something as simple as

persistant float value;

instead of

float value;


But we dont want SL bogged down by persistant variables that never ever change cuz the scripts have been long forgotten

There are several ways to permanently store data in SL:

Notecards are one, and while being the largest in size (64kbyte), they're not writeable via script.

Small amounts of data (integer, float, vector types) can be stored using the hidden faces of an object (like the infinitely small top face of a 4-sided pyramid), or if you don't care about the looks, the visible faces too. Texture offsets, rotation, alpha and color (vector) can be set/get via script, and thus be used to store small amounts of data.

For larger amounts, you'd use a script that acts as a data storage, and responds to read/write commands (preferably via linkmessages). This script should be kept as simple as possible, because you want to avoid editing and thus resetting it. This allows you to store up to 16kbyte *PER* script (you can obviously have multiple, not unlike memory segments in the old days of DOS). It can do backups via email which you can easily restore via cut&paste into a script that feeds it back into the data storage. This will however most likely be only required if you for some reason need to reset it.

I've been using such a data storage script for over a month now (Lindenworld, keeps the Senso highscores), and it proved to be *VERY* reliable. Actually it never lost any data at all. It survived several dozen sim crashes (Coney), and even the upgrade from SL 1.0 to 1.1. Hats off to LL for that. It can be moved, taken into inventory and rezzed back without any data loss.

I used this method for my stock system which ran (and is still running in one case) since May (I think, was a while ago) with no data loss.

My one complaint is that there is most definatly NOT 16k available last time I checked. Every single script I have crashes with a stack heap somewhere around 8k - 6k free memory depending on the size of the script. Before any lists are populated the free memory is already a couple - 6k below the 16k free mark, and the script will crash at 6k - 8k. I don't know if the stack is being counted twice, or something else is happening.

Oh and as for memory storage that would be great! It would be cool if you could have an invisible object called a MemmoryObject or something that is a list with its own key. So you could do:
key myMem = llAllocateMem();
llSetMem(myMem,[1,2,3,4,5]);

And if you wanted to pass the data somewhere else you just pass them the key!

The problem with that system is data clean up. How does the system know when a MemoryObject is no longer used? There could be a method to clean up, but really it needs to be automated in some way.

DISCLAIMER: The following is mostly "educated guessing". I haven't really looked at that stuff (yet), so take this with a grain of salt. It's just my current state of understanding of how certain things might work and I might be completely wrong with this :)

Ok, so how do scripts work? Lets say there are 16kbyte of the servers memory allocated to each script. The LSL source you type into your script editor is compiled into a "bytecode" by your client, and only that is uploaded to the SL server (the script source is kept separately). This bytecode takes up part of those 16k. Now lets assume each script has a heap and a stack. The heap is where it stores your variables, the stack is where it stores stuff needed for itself to work, being return points on function calls (jumps really) and the parameters used in those functions.

Some variable types are of a fixed size (integer, float, vector, rotation, probably key), others are of variable size (string and list). All of these take up room on the heap. So whenever you do str = str + "foobar" that string is gonna take up some additional heap.

To understand the stack, lets look at how stuff works for machines. They do not really understand the concept of functions on this low level (I don't think the LSL virtual machine does either). They do know jumps. So calling a function is really broken down to jumping someplace in the code. When it's done with that code, it just jumps back to where it was before, and continues there. For this to work, it needs to remember where it was before it jumped. This information is stored on the stack. So if you do a function call, like myfunction(), it will put the current position it's at onto the stack and just jump to where the code for myfunction is. Once that code is done executing, it will read the adress from the stack back and just jump back to the place right after the call to myfunction. The part of the stack that stored this return address will then be freed.

Parameters you supply to a function are handled in a similar way. When you do anotherfunction(42, "theanswer"), it will put those parameters onto the stack, right next to the return adress. Then it again jumps to the place containing the code for anotherfunction, and starts executing it. This code was made in such a way (by the compiler) that it knows it has a parameter of type integer, and one of type string. This way it will just read those from the place in the stack right next to it's return adress whenever it needs them.

Return values, like in result = yetanotherfunction() are put on the stack as well, and read back upon returning to wherever it was called from.

So what the hell does all this have to do with getting stack/heap collisions around 6-8k? Well, the script *CAN* store 16k. But whenever you try to actually do anything with that data, you will have to call a function. So that means your 6-8k of data has to be put on the stack, so the called function can read it. Ooops. Now it's there twice! It's on the heap, where you stored it, and it needs to be put on the stack as well, so the function can read it. You now have 12-16k of memory used, PLUS the size of the code itself.

The memory itself btw, probably looks something like this:

CCCCHHHHHH.......SSS
0k                16k

C would be the bytecode of your script. The dots are free memory. H is the heap, which grows from the bottom up. S is the stack, which grows from the top down (heap/stack might be reverted, but that doesn't really matter for this explanation). So a stack/heap collision occurs when there is no more free memory and the stack meets the heap (somewhere in the middle).

So for most cases you can really just use:
(16k - bytecodesize - someminorstuff) / 2 bytes of memory.



Again, this might not be whats happening, or how any of this works at all, but it would explain this behaviour ;)

If that IS what is happening then someone made a messed up system.

Stuff in the heap should not be duplicated in the stack. All that gets put in the stack should be a pointer to the data in the heap.

String data should never be in a stack. That is just ugly. Ussually a stack is nice and orderly and everything the same size (or if not, then an expected size). So usually whats in the stack is addresses. Addresses of code to return to, addresses of locations in memory for variable or state data. And if a 3k script with 5k on the heap is pushing 6k - 8k onto the stack when switching context/scope then something is very wrong..

*cue ominous organ sounds*

Actually I think the reason why you cant usually use 16k is quite simple.. I think the 16k is divided into 8k code, 8k data.. If I write a lot of code, I get the heap error near 8k.. same with data.. if I use almost 8k on both, I almost use up all 16k.. So I would assume its because they seperates code and data.. which makes sense. would simplify there(LL's) job, lol.

I'd like to see some of the code you have used to test this CrazyMonkey because my tests show results quite the opposite.

If I have a small amount of code in the script and load lots of small data, the script crashes with a much smaller amount of free mem then if I have a lot of code with less data.

The DarkLife backpack seems to remember stats. The stats dont get saved if the sim crashes. But other than that the stats stay with me when I logoff, log back on...

Jack, scripts run on the server. As long as the server is there the variables will be held in the script and the script will be running. Actually most of the time when the server crashes or goes down for maintenance nothing happens to your script's data since script states are usually saved when something goes wrong with the server.

I guess the crashes in Darkwood more heafty crashes then, my stats got reset.

So do we already have non-volotile storage? Just don't reset your script or initialize them in your on_rez and the value will stick?

Yes.

Ack. Ran into another situation where I'd want persistant variables.

If not persistant variables, then at least let us tell a script to save its state (including the current value of its variables) , and be able to load that state another time (even if script has been inventoried).

Something that lets me store my values beyond when object goes into inventory...

Since when do you lose data when taking an object into your inventory? Scripts maintain state when taken and re-rezzed.

Post 1.1 they don't .... kinda.

Well they do, but the difference is that now when you drag from your inventory it makes a new copy instead of dragging your old one out.

If you shift or alt or ctrl drag (I forget which) from your inventory it will drag the one you put in there out and THAT one will have your saved variables.

Interesting.

So you can save the state of variables, but its utterly useless because you cant give a copy of the object with the script to anyone cuz its killed.

I dont get it. When I first got here, we had a template system. Then before I even understood just what the heck people meant by "templates" we switched to a bag system. Now we're back to the template system again? Why? Cant you just make it an option? Heck, cant you just make EVERYTHING an option? I want my scripts to be visible by default. I'm sick of having to manually set permissions on everything and giving people a second copy without the nasty DRM-ish stuff turned on.

The script state is also something weird.. if you are wearing a item with a script and the server crashes, the data can get lost. To be more precise, I believe it remembers the states of the last time you dropped the item on the floor (or maybe also your inventory).
I think that dropping your backpack forces it to be loaded into the data-storage of the server (Hard Disk) instead of the RAM, which will get lost in a server crash.
So that's why I advise all players to drop their backpack every now and then (server doesn't crash much often anymore, but it used too before some rez-object bug wasn't fixed yet)