This involves implementing a boolean in UndoState to signal whether the undo needs to be done for an entire group/linkset or just a single prim
Resizing individual components of linksets is still dodgy.
Resizing still has to be down twice, since for some reason the client is sending two multiobjectupdate packets on every resize except the very first. This applies to single prims and linksets. Need to look into this.
Undo rotation and position appear to be working.
Resizing a single prim appears to be working, though the undo has to be done twice.
Resizing a group of prims still does not work properly - possibly because in the UndoState we don't store a knowledge of when we're resizing a whole group rather than individual prims.
This needs to be addressed.
Also fiddle a bit with undo. This is not currently working properly, though to be fair it also didn't appear to work in 0.7.1.1 either (at least for resize).
Will get some more attention soon.
to the entity update queue. The number of property packets can
become significant when selecting/deselecting large numbers of
objects.
This is experimental code.
This updates prim counts correctly if an object is moved by something other than an avatar (e.g. scripts, region modules)
Create TestMoveOwnerObject() regression test for this case.
save properly, as will the results of a resizer script working. Attachment
positions are no longer saved on each move, but instead are saved once on
logout. Attachment script states are saved as part of the attachment now
when detaching.
The separate remove and set operations is SOG.set_UUID() are both locked under m_parts.SyncRoot since they are logically atomic (though this isn't such an issue if the SOG isn't part of a scene)
Added unit test for this behaviour.
Also changed the second m_parts.AddOrReplace() to m_parts.Add(). As the old reference is now removed we never end up replacing an identical uuid. And if we replace a uuid that's already there (from a child part) then this is an error.
Previously, deadlock was possible because deleting a group took a SOG.Children lock then an m_entityUpdates.SyncRoot lock in LLClientView
At the same time, a thread starting from LLClientView.ProcessEntityUpdates() could take an m_entityUpdates.SyncRoot lock then later attempt to take a SOG.Children lock in PermissionsModule.GenerateClientFlags() and later on
Taking a children list in SOG appears to be a better solution than changing PermissionsModule to not relook up the prim. Going the permission modules root would require that all downstream modules not take a SOG.Children lock either
* Removed StorageManager
* CONFIG CHANGE: There are no more database settings in OpenSim.ini. Check the config-include configuration files for region store and estate store database settings
Previously, Scene.Inventory.DeRezObjects() forced the persistence of prims before deletion.
This is necessary so that freshly delinked prims can be deleted (otherwise they remain as parts of their old group and reappear on server restart).
However, DeRezObjects() deleted to user inventory, which is required by llDie() or direct region module unlink and deletion.
Therefore, forced persistence has been pushed down into Scene.UnlinkSceneObject() to be more general, this is still on the DeRezObjects() path.
Uncommented TestDelinkPersistence() since this now passes.
Tests required considerable elaboration of MockRegionDataPlugin to reflect underlying storing of parts.
Added a MockRegionDataPlugin to do in-memory persistence for tests since adding this to OpenSim.Data.Null.NullDataStore doesn't seem appropriate
NullDataStore can do nothing because OpenSim only ever retrieve region objects from the database on startup. Adding an in-memory store here would be unecessary overhead.
Justin Clark-Casey (justincc)