|
|
|
I'm raising this to critical priority like I did to the other issue. My reasoning:
This issue needs to get clarification and roll up all the duplicates together.
It may be possible to create an object that will crash the viewer during inventory load. Linked a couple of other description related bugs.
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
Any hint of what the fix will be? Will the information just be truncated to 256 characters then, or will more data be able to be written in by script without problem?
My current fix just enforces the maximum character limit. If you attempt to put in something longer, then the remainder will be truncated.
I had objects on my land with descriptions longer than 256 characters.
After about two days these objects... 1) ...moved out of my land to a neighboring land, using negative coordinates. Some of these objects were atleast 10m away from the border. 2) ...were unlinked. 3) ...unlinked prims from multiple (partial) objects were randomly returned to L&F as coalesced objects. 4) ...weeks after, unlinked prims are being returned in batches. 5) ...were no longer visible either on the 3d screen nor on the minimap. This happenned twice! Changing the description to a shorter length (at most 128 characters now) seems to stop this random destruction of objects. Unable to confirm due to the random nature of the problem. It may have something to do with the quantity; I had over 100 objects with long descriptions. Individual objects with long descriptions seem to survive. Returned coalesced unlinked prims could be rezzed, so it may be that the prims with long descriptions were destroyed completely and only the other prims were returned. From my recolation of how the objects were constructed this seems true, as I didn't find root prims or single-prim objects in there. Unwilling to try reproduction because this has already cost me enough L$ and time as it is. LL should be able to try reproducing this themselves according to the description I have given or may contact me to help reproduce the situation on their land. Please change this bug to highest priority possible, since it actually destroys objects completely and does not return them in a usable manner. Suggest that descriptions should just be limited for all situations in order to prevent this situation from occurring. 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/2008).
Linked to new SVC-1406 and https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL
It looks like this fix might have broken more than you expected. Here's someone talking in the forums about how all '|' symbols in object names and descriptions were converted to '?' symbols:
The "|" to "?" is
1.19.x simulator code still does not fix the ability to rez objects that have had object descriptions longer than 256 characters set.
Is there not some way that it could truncate the description when reading it out of the stored asset, to allow for recovery of any lost objects? As for the "|" character, its used for metadata storage for inventory objects as was commented on in the viewer source code in both the set name and set description functions. Its not likely that it will ever be an allowed character inside object names or descriptions due to its actual usage inside the database system. This seems to have been fixed - see http://blog.secondlife.com/2008/02/01/scripters-object-name-and-description-changes/
Actually, reopening because of the "existing items in inventory" comment. But there might not be any way to fix that, since editing an object and storing it into the asset server usually creates a new asset, I think. Only if they run something on that database directly, I guess.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
It is a bug in my opinion because object loss can occur.
There are alternate methods of storage such as using HTTP request to an external database, email, and using another script entirely for storage, but this could still be used where a quick simple solution is desired. Having object loss is not good.
If I find time, I will test what happens if this occurs in a child prim in a link set as well.