If we do this, then viewer 3 crashes when we try and rez a script directly in an attachment's prim inventory.
Sending an empty file name was already being done if the prim's inventory had never been touched.
Now we always do that if there are no items in that inventory.
Hopefully addresses the remaining point in http://opensimulator.org/mantis/view.php?id=5644
Viewer 2/3 will sometimes attempt to rewear attachments, even though they have already been attached during the main login process.
This change ignores those attempts.
This stops script failures during login, as the rewearing was racing with the script startup code.
It might also help with attachments being abnormally put into deleted state.
Hopefully resolves some more of http://opensimulator.org/mantis/view.php?id=5644
As far as I can see, this is only invoked by a PUT request to ObjectHandlers, which is not being used anyway.
Invoking attachments code at this point is probably inappropriate since it would still be invoked when the client entered the scene.
Being commented to simplify analysis of attachments issues. Can be uncommented when in use.
Also, small tweak to lock and log removal of a SOG from the SceneObjectGroupsByLocalPartID collection in SceneGraph.GetGroupByPrim() if an inconsistency is found.
This is the message sent to the client when the object is returned.
We were sending byte[0] in the binary bucket. This didn't kill viewer 1 but did terminate viewer 3 (don't know about viewer 2).
So sending "\0" instead.
This is to address http://opensimulator.org/mantis/view.php?id=5683
Attach and detach packets are processed asynchronously when received from a viewer.
Bugs like http://opensimulator.org/mantis/view.php?id=5644 indicate that in some situations (such as attaching/detaching entire folders of objects at once), there are race conditions between these threads.
Since multiple data structures need to be updated on attach/detach, it's not enough to lock the individual collections.
Therefore, this commit introduces a new IScenePresence.AttachmentsSyncLock which add/remove operations lock on.
Leaving them at UUID.Zero meant that when a viewer 2 logged into a region that had been freshly created, it received UUID.Zero for these textures, and hence display the land as plain white.
On a simulator restart, the problem would go away since when the database adapators loaded the new region settings, RegionSettings itself has code to use default textures instead of UUID.Zero.
This commit resolves the problem by saving the default texture UUIDs instead of Zero.
However, we currently have to do this in a roundabout way by resaving once the RegionSettings have been created by the database for the first time. This needless complexity should be addressed.
This change will also have the effect of replacing any existing UUID.Zero terrain textures with the default ones.
However, this shouldn't have any effect since the UUID.Zeros were already being replaced in memory with those same UUIDs.
Leaving them at UUID.Zero meant that when a viewer 2 logged into a region that had been freshly created, it received UUID.Zero for these textures, and hence display the land as plain white.
On a simulator restart, the problem would go away since when the database adapators loaded the new region settings, RegionSettings itself has code to use default textures instead of UUID.Zero.
This commit resolves the problem by saving the default texture UUIDs instead of Zero.
However, we currently have to do this in a roundabout way by resaving once the RegionSettings have been created by the database for the first time. This needless complexity should be addressed.
This change will also have the effect of replacing any existing UUID.Zero terrain textures with the default ones.
However, this shouldn't have any effect since the UUID.Zeros were already being replaced in memory with those same UUIDs.
This is to prevent the aborting of attachment script threads on teleport from aborting the one actually doing the teleport.
This allows OSSL teleport functions to work when invoked on scripts in attachments (and huds, I assume)
This is to address http://opensimulator.org/mantis/view.php?id=5669
However, if this failure was happening I'm kind of surprised that local HG inventory was working at all.....
We probably weren't seeing these exceptions previously because we weren't logging them when the reached the top of a FireAndForget thread.
This is for http://opensimulator.org/mantis/view.php?id=5669
If we can't retrieve an IUserManagement module we complain, and we also warn in the log when its manually set in XISC by HGInventoryBroker
This is only called by a region console command.
We should also be locking m_partsUpdateQueue when dequeueing the next part, or locking m_pendingObjects in QueuePartForUpdate().
However, I won't do this now since I don't have time to analyze how this would affect liveness.
Strictly speaking, we could also stop bothering to clear the m_updateTimes and m_partsUpdateQueue if we are sure that the whole SceneViewer is shortly to be garbage collected anyway, but we'll leave them around for now.
Justin Clark-Casey (justincc)