Mono scripts .. actually whats the deal?

[Beowulf Zessinthal]

 

There are no recent clear threads on the mono script.

I thought i knew them, but i just got suprised and so i was hoping someone might give a clear description of their nature.

My (wrong) belief was that all non-reset copies are shortcut to the single server version....

I have made a hud with a customizeable dialog (using .. type new button name in -1 chan, script listens for it and replaces the old button name).

So i thought that if i made a copy of that hud, wore it & made a different custom menu in it .. and then un-wore it and wore the original hud, that the new menu would also appear there... but no .. it shows the earlier original menu. So while i thought i knew so much .. now i think i know so little! 

Whats up with those mono scripts!? :D

[Innula Zenovka]

I think you may have been misled by what the Wiki says:

Mono tip: Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script's size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.

Note the "plus data."   The "plus data" is whatever is contained in the script's own memory, which includes the custom menu. It's only the actual code in the compiled LSL script that's shared, not the contents of any variables in held in the memory of a particular instance of the script.

[Beowulf Zessinthal]

 now the rain has gone, i can see clearly  .. Thanks Innula ..

[Johan Laurasia]

A couple of ways to persist data is to make http calls and store the data in a database on a website, or, a much easier way, if you're looking to store limited values, is to store them in the object description.  Back in the day, you could cram 16k into the object description, but people started making "hard drives" by linking a bunch of prims together and spanning data across the object descriptions of various linked prims, but SL caught onto that and "fixed" the 16k data store that was the object description.  These days, you're limited to 128 bytes, which can be useful if you're just storing a handful of variable data.  For example, I make clocks, and you can set the time to any time, which internally generates an hour and minute offset, also the state of the chime feature (on or off) is saved.  Hence, I need to store the offsets for hour and minute as well as the state of the chime.  The code looks like this:

        string output = (string)hourOffset + ":" + string(minOffset) + ":" + (string)chimeState;        llSetObjectDesc(output);

Then when the object is rezzed, in the state entry I read in the object description, and parse out the data and cast them into the integer variables thus preserving the state of variables.   As long as the data you need to store isn't too big, this system works quite well.