Major Bork Bork Bork after the restarts today

At least for me

I store memory params in some name and desc of prims, with the params separate by pipe symbols.

The restart converted all the pipe symbols with question marks, everywhere.

Welcome to thje club ! you are not the only one, dude..

check my thread...

/54/88/238595/1.html

Timeless Door Script..uses parameters on the name and descriptions of the prims...


So, after the restarts...this popular and consagrated script stops to works if reseted...because they are unable to read the parameterns in the object name anymore...

That is interesting, as it is one of the first issues rased about the MONO beta.
I wonder if part of that code ended up in the release code by mistake.
I had beter go and change my World time scripts to handle it befor any more of them sell.

I just went in world to test and mine reset and ran fine.
I have updated the code to take "?" as a seperator just in case, but it looks like It may be a random issue.

Ok so it's not Random

As part of the rolling restart we implemented a fix for an issue on the Public Issues Tracker, SVC-997.

This fix may cause problems for scripts relying on long object names and descriptions. Should you experience any difficulties please contact us via the support portal.

Here is WarKirby's post re SVC-997. (I always kept mine below 200 chars just to be safe, but got whacked anyway.)

_________________________

From no-reply at smtp.cascadeo.com Sat Nov 24 07:44:51 2007
From: no-reply at smtp.cascadeo.com (WarKirby Magojiro (JIRA))
Date: Sat Nov 24 07:45:55 2007
Subject: [JIRA] Created: (SVC-997) llSetObjectName / Desc not properly
capped.
Message-ID: <2321508.1195919091513.JavaMail.root@lindenlab1>

llSetObjectName / Desc not properly capped.
-------------------------------------------

Key: SVC-997
URL: http://jira.secondlife.com/browse/SVC-997
Project: 2. Second Life Service - SVC
Issue Type: Bug
Components: Scripts, Simulation
Affects Versions: 1.18.3
Reporter: WarKirby Magojiro
Priority: Critical

Below is a script demonstrating a hack to detect when someone mouse hovers over a prim.

Now, as to how it works. There seems to be an issue with llSetObjectName and llSetObjectDesc. Although those fields are capped at 256 chars, a script can set them much higher. And the field is merely truncated when the sim feels like it. ie, when it has to do something with the name. mousing over a prim makes the sim resolve it's name and description, to display a hovertip. In doing this, both fields are truncated to 256. With this script, it sets the object description to at least 300 chars on startup. And checks it in a tight timer loop. When the prim is moused over, the name is resolved and truncated. The script detects this, and gives a message. Then sets the name back to 300+ so it can be used again.

As far as I can tell, there is no limit at all to the maximum size of the fields, except the setting script's memory limitations. The simplest way to correct this problem is to truncate the fields as they are set, rather than when the name is resolved.

This hack does have nice uses, true. But it also has security implications, which I'm not going to explain here. I'll supply the information to any linden who needs it, but it's generally best that it not be public knowledge. The point is, this needs to be fixed.

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

This hack definitely has no nice uses. It was emailed to the security list a while back. It's veeery bad, and posting a JIRA publicly about it was not very wise.

Perhaps WarKirby Magojiro wasn't wise in posting it [you do realize that was all a quote, right?], if one believes that one has security through obscurity. I don't happen to.

As for me, I only found it because I have access to -- shhh! -- a secret tool called Google, which found his post in .17 seconds.

In any event, veering wildly back on topic, it's too bad that their enforcing lengths on name and desc fields happened to have the side effect of converting characters such as | into ? marks. Surely that is a bug.

Also the length chosen for name, 63 characters, is a very American, anglophone-centred approach. In English, we're very lucky to have access to a lot of short words we can use. Such is not the case in other minor languages spoken around the globe, such as French.

Yes, I know he posted it. That's his problem. Security through obscurity doesn't work, but posting an issue publicly instead of talking it to LL directly is the exact opposite of helping.

whatever.

i happen to think he did the right thing and in a very responsible manner so i disagree with you. You may wish to start another thread with that topic to discuss the overall principle, as that topic is quite different from this one.

In the meanwhile, i'd like to stay on topic in this thread, as it may become of importance -- more and more people are waking up to the issues today as reports start flooding in.

frankly it should have been jira'd ages ago, I mean really, large amounts of uncapped memory just eating up space on a server, that's not exactly smart or sane. and the hack both for mousover and datastorage has been pretty much public knowledge since ~2004 at least.

frankly the jira issue (which didn't describe the 'bad' usage) was probably the ONLY reason LL chose to finally do something about it, since they've been made aware of it by several people privately already in the past.

@Chaz
63 characters isn't so much an anglophone number as it is a computing number, you have to cut things of somewhere, and 63+1byte blocks scale nicely, never mind being more than many applications allow for a name field

>> Void Singer writes: not anglophone-centric

Ah right. That would explain why prims have always allowed object names with French accents in them, right?

I think it has more to do with the asset server/database and the limitations needed on object names' characters/lengths to keep it from exploding.

@Tyken Hightower: not to belabour the point, but you've got to admit that if English happened to have accented characters in it, meeting that challenge would be a whole different priority, wouldn't it?

That's what Unicode is for. However, for a database with a few billion entries, there's no point in making each character 4 bytes long when 1 will do just fine.

huh? what's that got to do with being able to type é in a prim name, in terms of the end user experience. There is *every* point in SL becoming capable of functioning on a global level in more languages.

I disagree with your viewpoint that there is no point in letting people spell things correctly in other languages. Clearly you think differently than me, so we'll leave it at that. You wouldn't get away with that up here in Canada, though, in terms of service provision. We are forced to make an effort.

what accents have to do with a block size limit is beyond me, but I'm glad I don't live in your world.... so much paranoia, thinking that it's all about people out to slight you...

seriously, it's about storage space and history.... ansi and ascii were the first real standards, if they'd been developed by the japanese they'd be hiranga or katakana, but they weren't... that's the history part.

as the need for extended characters to cover other languages was realized and institueted into a standard, you got unicode, except to be able to cover all that possible usage, also took more space to allow for them all to live happily side by side. so what once could be crammed into a half byte, now takes more... if you support all the extras. that's the storage part.

there is no way to "figure out" how to cram different characters into the same byte code, that's not how it works, you can either support more and take up more space, support less but take up less space, or build some custome solution that'll just piss everyone off, be more confusing, and prone to being broke because it doesn't interface with existing tech...

storage size also relates to bandwidth size. more bandwidth consumption is bad. putting a cap on that is realistic and doesn't have the slightest bit to do with what language is spoken or written. removing memory leaks is also good, and doesn't have anything to do with where someone lives.

And i'm glad i dont' live in your narrow unilingual world. There, we've agreed, we each like our own world! topic done!

I know you're feeling angsty because of stuff breaking today, and that's fine. We're not out to get you. But seriously, if you can't accept the logic behind an argument, there's no need to resort to telling us we're close-minded.

::blink::


yeeeeaaaaahhhhhh........let's go with that.

You are technology focussed rather than customer and end-user focussed.

>> so much paranoia, thinking that it's all about people out to slight you...

It's not so much that as the narrow scope of American thinking at times. Who's next on the list to invade?

</Thread>. You've derailed your own train.

But America is becoming increasingly close minded, and it shows even in your defence of programming that won't allow correct spelling in other languages. You've got to keep up. You may argue all you wish about technocratic reasons why you don't, but if you don't, someone is going to come along who *will*, and people will switch to that product.

>> as the need for extended characters to cover other languages was realized

Even this is very telling -- "was realized"

SL, to succeed as a global development platform, has to realize that the USA is becoming an increasingly smaller customer base. Which I welcome. My mother tongue is English, but I'm willing to step up to the plate and accept the challenge of serving my customers in other languages, even if it means I have to do the hard work of learning them, and making changes to accommodate them.

And I think still, if you can't type é, then something is wrong, whatever the techno reasons. That's just as *basic* as typing e. If we don't offer that in SL, then someone else who will, will bury us.