|Anonymous | Login | Signup for a new account||2019-01-18 00:37 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007990||opensim||[REGION] OpenSim Core||public||2016-08-10 13:46||2016-08-12 19:35|
|Product Version||master (dev code)|
|Target Version||Fixed in Version||master (dev code)|
|Summary||0007990: Detached items become permanent corrupt when RLV/RLVa is enabled|
|Description||When RLV or RLVa (depending on the viewer) is enabled, detached items become corrupt, especially when detached in bulk such as when switching outfits. The detached objects will have no name "", and the whole linkset (for example a shoe) is nano sized and permanently messed up (even if enlarging it more or less to the original size again). The linksets breaks (1 prim left).|
The bug happens on detached items within the #RLV shared folder, and also outside the #RLV shared folder (in 'regular' inventory).
I already confirmed this bug for RLVa in which the bug manifests more often (Firestorm, Singularity which has it on by default)
And now I can also confirm it for RLV viewers (Cool VL Viewer, Kokua uses it also)
Seems more prevalent if the asset server is slow responding, such as is the case (at least for now) with OsGrid. This problem occured in Metropolis as well on a 0.9 region, but on Metro more likely in Singularity/Firestorm than my tests with Cool VL Viewer.
|Steps To Reproduce||It's hard to get 100% reliable reproduction, often the bug occurs but for some random items not.|
Make 2 outfits with copies of a lot of objects you will be wearing in them, like shoes, jewelry etc.
Take care when initially detaching your current outfit for testing, items may become corrupt forever.
When testing, try right click one of the two outfits, and detach all or individual items (in that folder). Or click the other and click replace all so the previous folder is detached and replaced. Most items that are being detached are now permanently destroyed will be unnamed objects.
|Additional Information||One mention about this specific bug between RLV and opensim was here:|
It's strange I don't hear more people about it considering Singularity has RLVa enabled by default.
Also possibly related is that if objects that attach to the same attachpoint are mixed in the Current Outfit (when changing).
RLV was already quite broken in that the shared folder #RLV isn't accesible by scripts when visiting a hypergrid destination, and neither is a shadow copy I made in My Suitcase (if a grid I tested uses a suitcase). So the shared folder only works on your home grid. This is perhaps better reported for a new bug but might be related also.
|Git Revision or version number|
|Run Mode||Grid (1 Region per Sim)|
|Environment||Mono / Linux64|
|Viewer||All viewers with RLV/RLVa|
Took me a while to figure out but this is the exact commit from where this bug starts occuring:
I also noticed that before this commit, detaching stuff would be near-instant and when this commit is introduced it becomes very slow.
The commit is linked to mantis http://opensimulator.org/mantis/view.php?id=7858 [^] which is about llDie() leaving prims behind
could not repo with FS, but then I never used RLV...
how are those issues
http://sldev.free.fr/forum/viewtopic.php?f=6&t=1646 [^] [^] ?
are they also only related to attachments under RLV?
do they have
Cap_FetchInventoryDescendents2 = "localhost"
Cap_FetchInventory2 = "localhost"
in region config?
No RLV script calls or relay are necessary, merely having RLV enabled in the viewer is enough
Both those Caps are on our sims stock OpenSim so set to localhost. I don't know about the forum post I just assume they use the standard OpenSim.ini
This happens on attachments in and outside RLV. My friend had most of her outfits in My Outfits corrupted and she doesn't use or link inside the RLV folder with her outfits. Whatever the links in her My Outfits (and also Current Outfit) point to are total broken with no name (and linkset messed up for shoes etc), and it seems to happen on attachments only, not system layers.
When objects are unworn, they are not just removed from Current Outfit, the objects are total destroyed. This seems worse if at the same time new stuff is added to Current Outfit, like switching between two object-heavy outfits.
I looked a bit in the code (but I'm no coder) and with the commit mentioned above there is some newly added extra killing of objects to make sure they are gone (for bullets with llDie etc), which I think should not be done on attachments but a check for that misses I think.
Also did you, in your testing see a difference in detach speed if you compile/run OpenSim at the revision checked out just before the commit mentioned and later revisions? The delay introduced is really huge/laggy.
We encounter this with opensim master at our own sims, and at Sandbox Plaza III in OsGrid just 2 days ago.
I just did change that code, but not because of the extra kill but because adding updates to queue on a deleted object, That should not be needed
But I did not notice much difference on attach/detach
Also see no relation btw sending kills to viewer and inventory, so issue must be elsewhere. that I can't repo
well I also don't have a complex avatar
mb we can meet at sandbox III ?
I tested your patch and can't repro the problem anymore, plus detaching goes much faster now. Looks very good!
Will test this more extensively in the afternoon, hopefully also on OsGrid and then report back here
Thank you Ubit
Tested all good
|2016-08-10 13:46||Lotek||New Issue|
|2016-08-10 13:52||Lotek||Tag Attached: rlv|
|2016-08-11 02:07||Lotek||Note Added: 0031003|
|2016-08-11 20:19||UbitUmarov||Note Added: 0031007|
|2016-08-11 21:01||Lotek||Note Added: 0031008|
|2016-08-11 21:10||UbitUmarov||Note Added: 0031009|
|2016-08-12 06:24||Lotek||Note Added: 0031010|
|2016-08-12 19:34||Lotek||Resolution||open => fixed|
|2016-08-12 19:34||Lotek||Category||[GRID] Inventory Service => [REGION] OpenSim Core|
|2016-08-12 19:34||Lotek||Fixed in Version||=> master (dev code)|
|2016-08-12 19:35||Lotek||Note Added: 0031016|
|2016-08-12 19:35||Lotek||Status||new => resolved|
|2016-08-12 19:35||Lotek||Assigned To||=> Lotek|
|Copyright © 2000 - 2012 MantisBT Group|