Script stoped to work at the restarted regions

You can vote for this issue here:

https://jira.secondlife.com/secure/ViewVoters!addVote.jspa?key=SVC-1394

(might be another place too, but I ran out of time to search.)

large chunks of uncapped memory = bad
abusing it without thinking it'll be fixed = also bad (but useful while it lasted =X )

too many issues tied to this, security, stability, functionality... end of an era, but it needed to happen.

>> Void Singer: it needed to happen.

Needed to happen? Yep, gawd forbid people should have a place to store memory parameters. Zheesh! What have you people got against other people having someplace, no matter how pathetic, to store memory parameters????

I like to use strings.

>_>

Here's a new enhancement request to replace the somewhat dubious name/description storage with something more robust:

https://jira.secondlife.com/browse/SVC-1406

I voted for it.
.

Don't really think the ability for a script to write to notecards is going to happen. Too many Linden's have stated it won't for variuos reasons.

But I did raise the question in the mailing list about LL entertaining the idea of a new function or way to have a limited amount of dynamic, permanent memory allocated to a script if it needs it. We already lost being able to write to texture UUID's and now we have nothing left outside of using an external db.

This enhancement request:

https://jira.secondlife.com/browse/SVC-1406

is for exactly that, metadata. I understand why the notecard idea is a bad one.
.

Yep, I see Argent JIRA'd it already!
voted!

It'd be nice to have, but hardly something that I think will happen, and I'm usually overly optimistic.

Anyhow, with script memory being quadrupled come Mono, the issue of no longer having extra space to store data in the description becomes almost meaningless.

I have nothing against the ability to store non volatile memory...

I do have alot against random large memory leaks that cause inventory loss, script failures, potential viewer and server crashes, etc...

if you are that desperate for storage, I have a wonderful concept for an auto extensible storage script, or you could use http like most everyone else has been doing.

Normally I would agree but this is actually a double whammy, of which the other part won't hit the MG for quite a while. Mono has broken the use of llGetFreeMemory. So now we have lost any permanent memory and have no way to tell how much memory we have.

Losing the permanent storage breaks a couple of baby scripts I have but no major impact. But not being able to see how much memory is left broke a major script of mine. Created and use a teleport HUD that stores a strided list with sim,name,vector. It was setup to stop taking entries at a certain point. Even 64K could possibly be used doing something like this, although we are talking a few hundred entries.

So definitely a bad day for scripters but O well!! I already know what I will do to work around both new limitations. w-hat's free db for dynamic storage and I am just going to check the list length before the script crashes in the second case and check against that number instead of llGetFreeMemory.

Mono hasn't 'broken' anything yet. They haven't even decided how llGetFreeMemory will report under it yet. If you're concerned, report bugs on the beta. I'm sure you'll have working llGetFreeMemory when it's in production status. Anyhow, given that we know how much memory data types take up, it's not hard to predict your script's limitations. I wouldn't rely on llGetFreeMemory to determine when to stop adding entries in a list, especially because it's a low water mark, not a current amount.

A lot of scripts that use object description are currently being broken because many people use the "|" (pipe) symbol to seperate their data fields. The length of the description field hasn't changed...as far as I know, it was also previously 127 characters.

But what has changed is that these "|" symbols are getting converted to a "?" symbol when the llSetObjectDesc function is called. This prevents the description from being parsed into seperate data elementswhen being read back. (very bad).

I first noticed this bug the other day on the Mono sandbox regions on the Beta grid when re-compiling my scripts under Mono for test purposes. I sent in a bug report..but they obviously know about it.

I'm looking for answers too. In the mean time, you might be able to work around this particular issue by using a different field seperator such as a "#", "~", "_" or some other seldom used character.

As far as the new reduced length limits on the object name, your on your own. I was lucky enough to only use object descriptions in my scripts.

- Zolen

Here is a simple code snippet that reproduces the bug that many people are having when they store data in the description:


default
{
state_entry()
{
string desc ="Data1|Data2|Data3";
llSetObjectDesc(desc);
llSay(0, llGetObjectDesc()); //object says: Data1?Data2?Data3
}
}


As you can see...DataIn != DataOut.


(I might be available to help people fix this issue in their scripts for their mission critical applications that use the description fields to store persistant data. My fees are reasonable and I have also been known to accept good karma in leiu of payment on occasion if you ask nice. )

Anyone who has this problem should just replace all instances of pipes with some other not normally used symbol which doesn't turn into a question mark. Not exactly a tough problem to solve, it's just that broken scripts are broken scripts. If you can't modify it, you're pretty dead in the water.

depends on the system you're using... if there is no method for removal of data, it's pretty accurate.... it's also good for geting a count to cap at if you're only working with a single list...

example would be if freememory < x store the current count of the list for a max. (this does assume all data entryies take a similar size, like keys)

True, but this obviously limits your applications. If I have something important that needs an upper bound on memory usage, I calculate how much I want to use and just hard-code that limit in.

Well..I found a way to update my products...


Well....

I'm updating my products to not read anymore from the desc and name...

Ok, Good for me...Nice !

But I just cannot stop to though about others builders and scripts that's sell things around the SL, delivery products full functional, reliable and maybe someone paid too much money for this...and maybe these ppls is freaking out...

Not good, not good...too much radical !

If people didn't rely so much on script resets.... Heh. Sorry. Often you DO have to plan on them happening at some point (e.g. if the object is modifyable), but I am a little fed up with the fact that putting llResetScript() in every 'on_rez' handler and such has become such common practice, and then people wonder why they can't seem to remember data for very long. Shame on all those folks who put that in early script examples!

if there's data that need to be reset on rez (or on ownerchange) it's a good practice.... or if variables need to be cleaned.

however for a few minor variables it's often better to just reinitialize them in the changed event.

I tend not to store much in the description fields except perhaps small amounts of user config (for example my clocks store GMT offsets here) if I need large amounts of data I either sub it out to extendable storage scripts or use a notecard (like in the multi-lingual menu builder I worked on with my sister)

it is nice though to be able to clean up internal data, since LL has decided to make it so hard for customers to do it in titghtly controlled items.

While we are on the subject of llResetScript thou. .............

I raised the point a year ago that if you are going to be selling a no-mod script then you should think about putting a reset backdoor in for the owner such as an unused touch_start, llSetSitTarget or a listen. We should have learned that lesson back when llTargetOmega was really broken(instead of just goofy like now). This was shortly after LL stopped the ability to reset no-mod objects. Everyone was scrambling around for a few weeks trying to stop all of the runaway spinning objects. Lindens were having to run around and reset quite a few of them themselves.