Script stoped to work at the restarted regions

Well...Timeless Door...

It's a scipt on the library...

You can find at // http://www.secondlife.com/badgeo/

The point is...this very populart script cannot works in the regions that has been restarted today after the server update...

probally because something was bad at the llGetObjectName() and llGetObjectDesc() functions....

if U create the script..say /door opened and closed commands...
Yes, works because it's on the memory

if U reset the script this will stops to work because the script cannot read the llGetObjectName() and llGetObjectDesc()


I've bad feelings about it....

BTW..I opened a Jira ! several prefab builders use this script...

Also..if is something bad with the llGetObjectName() and llGetObjectDesc() ...

Well...we are totally in trouble !

I'm at my home region (which is offline btw, nice to walk around an offline region), anyway its running the update and my cages which use a modified version of this door script are working fine.

They are reading the object description with no problem. (and yes I did reset the script)

you perform the modification ?

I found something...

Debugging in both regions...Very instresting...

Linked Object Name: door;<0.55040, 0.83800, 0.00000>;<0.00000, 0.00000, -0.70711, 0
Linked Object Description: door;<0.10991, 0.38390, 0.00000>;<0.00000, 0.00000, -0.00000, 1.00000>;<0.98058, 0.10000, 0.80000>

At the myGetDoorParams() function there is...

list nameWords = llParseString2List(llGetObjectName(), [";"], []);
list descWords = llParseString2List(llGetObjectDesc(), [";"], []);

In a non restarted and not uptaded region...

llGetListLength(nameWords) returns 3

In a restarted region

llGetListLength(nameWords) returns 4 !!!!

This cause the script to fail when...

if (llGetListLength(nameWords) != 4 || llGetListLength(descWords) != 4)
{
FAIL TRAP
}

Modification? My script is just modified with some extra stuff that doesn't effect reading the description line.

There is a blog post about this problem now, it seems to be something to do with the length of the description.

This is a MAJOR problem and will break a fair amount of content. A lot of us use the name and description fiellds as permanent storage. SVC-997 doesn't show up in a search of JIRA, so must be secutiry related. This would mean that this is a PERMANENT change. Guess we will have to do some testing to see exactly what the length limits are now.

Check this...


http://blog.secondlife.com/2008/02/01/fix-may-cause-problems-for-scripts-relying-on-long-object-names-and-descriptions/

But I'm still have problems...

Yes..to be honest..I will replace my scripts instead read from Name and Description...read from notecard...

But I know that's several ppls really need to read/write list of values on the name and description because LSL is not able to write in notecards

Well...In a chat with my consierge support...

the answer was: This bug was not fixed yet...

It's under investigation of how many effect this will cause...

If you've been using the name or desc fields for long
term storage, the rules just got changed.

SVC-674
LL will be truncating all object names to 63
characters and descriptions to 127 characters when
1.19 server code is released (originally scheduled for
1/23/200

http://jira.secondlife.com/browse/SVC-674

yes, Yes...but there is a lot of scripts running on SL that's really depends of long description...

I'm not telling just about my customers....I'm talking about thousands of ppls that's bought something based in scripts like this..

check the example of Timeless Door....It's just s script of the resource library ! So, a public and popular script does not works anymore....Thousands of ppls will freak out !

Oh I know.

I just wish the official blog had explained the limit instead of referring us all to a bug entry that we can't access.

None of the scripts on my land is currently working either. I am not a scripter so I have no idea how to fix this. Can someone kindly direct me to which Jira to report this? I seriously need to voice an opinion here and it aint gonna be good!
Thx.

When it comes to security fixes, we have no say and opinions don't count. Last security change that broke content was last year when LL disabled the ability to reset no-mod scripts.

We are just going to have to work around it as painful as it may be.

I know it's true, but damn I'm tired of hearing that

When you're not a scripter .. you're kind of screwed here. Does anyone know a way I can fix this? *shoots himself in the head*

Yes. Ask Linden labs what is now the preferred way they recommend of storing simple memory parameters in some kind of permanent fashion, and mention that we eagerly await their guidance and enlightenment as we strive to partner with them in creating mission-critical apps that can run on the Second Life platform. (JUST KIDDING>

To be honest, I'd rather they fixed this by making an LSL command to write into notecards than by upping the description/name limits again. If you kept it very very simple, I don't see why this would be so hard to do. Is there something about notecards that makes it impossible?

/me dreams of how wonderful that would be
.

Oh, no! You've raised the topic of writing to notecards! You're going to be deluged with posts slapping you down :}

Apparently there are a zillion reasons why the Second Life platform is incapable of meeting this basic business need -- and just as many apologists for this glaring weakness. (oops, let my own opinion show just now, grin.)

/54/48/176583/1.html

FYI: the LSL wiki has been changed to reflect this (llGetObjectName, llSetObjectname, llGetObjectDesc, llSetObjectDesc).
.

oh? really, it's been updated?

I see the LSL wiki here:
http://wiki.secondlife.com/wiki/LlGetObjectName

saying "The prim name is limited to 255 bytes...."

didn't someone above say " LL will be truncating all object names to 63 chars?" maybe they were wrong, or the wiki page i looked at isn't updated yet.

lol, Chaz, I and someone else updated the old LSL wiki, e.g.
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llGetObjectName

I don't use the official one much.
.

oh right. Me neither, the official one is *deadly* slow, as though they are trying to bring the SL -inworld experience to the web, LOL!

OK, read the thread, and understand. It might be simpler to create a new editable text object with an asset UUID that is permanent, explicitly as a small data storage/retrieval object. It could have a limited number of lines, each of which is a key/value pair with predefined syntax. Make the keys searchable, even.

/me dreams
.

the 997 was a typo apparently, they edited the blog to read 674 now. The issues was content loss due to long names/descriptions. It does seem bad for those who relied on these for permanent storage. I wonder if very long strings still work for temporary storage?

EDIT: I just saw from the other thread that it was in fact a security issue, but only UBER l33t ppl are supposed to know that.