Due to inventory loss brought up in SVC-674, an object name is now truncated to 63 characters and the object description to 127 characters. This limit will be enforced in scripts also. LL sent out an email from Everett Linden announcing this would be part of the 1.19 server rollout.

So rather than fix the actual bug (failure to rez objects with long desc) you impose a ludicrously small limit and break tons of scripts in the process.

Brilliant.

When, exactly, did Everett Linden send out and email and who exactly did it go to? I never saw it.

There is indeed an issue about notification. It is quite clear that the vast majority of us had no idea this was going to happen: and the first we learned was from customers having trouble with the products they bought from us. I was in personal contact with a Linden about this during the night: I don't want to embarrass him by naming him, as he was helpful, constructive, and frank. But it was clear he thought it was a bug too. If not even the Lindens involved in the upgrade knew, what chance did we have?

But there is a far more fundamental issue here. Even if they do notify us: do the Lindens feel entitled to make changes which they know will break substantial numbers of scripts? Some of which we may have sold to hundreds of people?

It is worth pointing out that this is not some hack exploit which has been closed. EVEN AS I WRITE THIS lsl wiki for llGetObjectName() reads (and I have just cut and pasted this from the browser linked to the LSL editor...)

"The prim name is limited to 255 bytes, any string longer then that will be truncated. This truncation does not always happen when the attribute is set or read."

How can we create, and even accept payment for, content, if Linden Labs feels they can simply break it at any time?

I note that Seraph Linden wrote in 674...

"Thanks for bringing this to our attention and providing a good amount of detail for us to track this down. This is a pretty serious issue but fortunately the fix ended up being relatively straightforward. Please do comment here if you notice any related sorts of behavior and I'll get right on it ."

No: this fix is not straightforward. A fix must be found which does not break documentated behaviour, which we have relied on in creating content for Second Life.

If Second Life does not perform to documentation, then that must be an issue, and it is not resolved. Retrospectively rewriting the documentation is... well, if it wasn't such a disaster, it would be comic.

This was also done to remove the exploit from SVC-997 (issue removed because it described the exploit).

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

If they're going to pull funny-business like this they need to provide some better place to store non-volatile object data.

And blog basically says they will not be fixing this. If you want longer names and descriptions, change this to a feature request or put in a feature request.

And, besides that, 63 characters is very much an English-speakers centric world view! Other languages are not as concise as English, and require more characters for their words.

We need to let them know this is a major screwup.

IMO, what would help is if this is turned into a feature request to give us back longer names and descriptions with solutions to the issues it presents like inventory loss in SVC-674 and security issues in SVC-997.

If someone creates a feature request to remedy the loss of local storage, I would rather it was for a small local data storage object that is more useful than the name and description.

For example, a new object like a notecard, but of limited size and that does not get a new asset entry each time it is editted. It could be of fixed size, and perhaps each line could actually be a key:value pair.

I realize this is dreaming, but objects really do need some sort of associated data store which is writable. The name/description usage was always a rather fragile workaround for this glaring hole in LSL.

there was no simple way for this to be prevented and still retain those ridiculous memory usages. the code is built into the servers AND the veirwers, and it was an oversight not to check the inputs from LSL... let it go. the only major screwup here was people relying on a nasty memory leak that shouldn't have been overlooked this long and may have been causing many more problems than anyone realized.

as for whether it should be capped at 127 or 256? kinda pointless to debate, I'll assume the server code already had a check or read routine with a set number of bytes and they went with it... in fact I seem to remember the old wiki stating it clearly as to the difference between typed in characters, and programatically forced in (through LSL) characters... obviously they went with the typed in version for consistency if nothing else.

This is also somewhat contradictory since the new search works better with longer descriptions rather than shorter ones, and indeed because of this LL increased the description field for land parcels. If anything they should also be increasing the object description field in order to improve the search, not shorten it!

============================================================

• Pipes [lex: "|" characters] in names and descriptions, as well as names longer than 63 characters or descriptions longer than 127 characters, were already broken. You could set all of those things in an in-world object with scripts. However, if you took the object into inventory and re-rezzed it, the names and descriptions would have been truncated, and the pipes would have been silently removed. Yes, I understand that people were using objects in-world that used longer names/descriptions and/or pipes, but the behavior was inconsistent. The new changes make sure that only object names and descriptions can be set that will continue to work even if the object is edited, taken into inventory, given to another user, etc.

============================================================

So while this does break some content that was relying on the fact that you could temporarily set descriptions and names to long values, in reality, that content was already broken. As far as I understand, names and descriptions were truncated to 63 and 127 characters respectively at mostly-random times. You couldn't have built reliable content on this anyway. LL didn't break what wasn't already broken, and their fix does prevent people from using that inconsistent behavior anymore. I just wish they'd sent out a blog post or some other kind of general announcement in addition to the targeted emails.

I think this issue should be closed by the reporter. LL specifically intended to break this unreliable functionality, so it's clear that they're not going to suddenly decide that doing so was a bug. On the other hand, a "new feature" proposal to reliably increase the length of names and descriptions to 256 characters or more might be received well.

One note, though: Chaz said, "Other languages are not as concise as English, and require more characters for their words." Of interesting note is that other languages require more characters for their LETTERS, at least in the Unicode standard most commonly used for international applications. Some languages take up to 4 bytes to represent a single character. That leaves only enough room for 15 characters in some languages. While object names can't currently include Unicode data (I think), they might in the future, at which time the name length will need to be increased.