|
|
|
|
|
127 or 256 characters long?
Where did Lindens state the description length? Change the wiki so that people don't waste their time in this thing! I set it to critical because it causes data loss, as per definition of critical. Sorry.
And "data loss" is both the data that you stored in the description field and, which is more important, the object in the inventory and its content that cannot be rezzed anymore.
So there is a bug to fix here anyway. I have to agree with Rita on this. I'm upgrading this bug to critical because it can result in content loss for an unsuspecting person who's set a long description accidentally when using llSetObjectDesc(). Next time they try to rez their object, they find they've completely lost it.
I wouldn't rate the other issue on this topic (descriptions getting randomly truncated to 256 characters) as critical, because the system was never intended to support descriptions longer than 256 characters; but I would say that llSetObjectDesc() MUST implement bounds checking so as to avoid content loss as described succinctly in this issue. I'd say the object should have it's description truncated to whatever the limit is rather than throwing up an error, THEN it can be sent. But we may as well reduce llSetObjectDesc() to 256 characters as well, a description is just that; a description. It's not intended for data-storage and it's always been touchy at best, just limit it completely, we don't need objects that have an extra 8k of overhead anyway.
No, this would be "Normal: Minor loss of function, or other problem where workaround is present." (The workaround is "don't do that, then".)
The fix here is to fix llSetObjectDesc to prevent someone from accidentally attempting this. llSetObjectDesc() is an LSL command that is run on the server, the bug needs to be refiled as a SVC (Service) bug. Whether the command should fail with a length of greater than 255 characters (a null terminator is required in the binary UDP protocol) or automatically truncate would be a good topic of discussion in the newly filed bug.
"don't do that, then" is only a workaround if you know about the issue *before* you have done so. Otherwise the object will be already lost which isn't expected behavior, I'd say.
I created an issue as a SVC bug and linked it so this doesn't get lost. While it some may not consider it a "Critical" bug I do believe it is something that does need resolving so it shouldn't be closed unless another one is opened.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LL will have to weigh in here, but I'm going to guess they're going to close this as "won't fix" because there is a hard limit of 256 bytes for descriptions (of more or less any sort, but including object descriptions); to fix this, the message template would have to be changed from "Variable 1" to "Variable 2" in many places.
If anything, the bug here is that llSetObjectDesc() doesn't fail when you try to set the description, but if this is fixed, you still won't be able to set a longer description.