If viewers (or at least, Linden Viewer 1.23.5) receive child hud object updates before the root prim, then the children are not displayed.
Updates were being queued in LLClientView in the right order (root first) but were being sent in a random order since they were all at the same prioritization
This commit prioritizes the root prim of a hud to its highest level when queued.
I'm not sure if the periodic reprioritization triggered via ScenePresence might reset this, but boosting priority appears to work so far.
Also committed is a belt and braces mechanism in LLClientView to prevent child hud prim being sent out before their root, but since this doesn't appear to be needed it is currently commented out.
This implements the 'share with group' flag for notecards and scripts in prim inventory since the PermissionsModule checks group membership and permissions.
Other than that, the code in PermissionsModule duplicates the checks in LLClientView so there should be no change other than allowing group members to edit embedded notecards and scripts.
For all other asset types, the permission checking code in LLClientView continues to be used, pending refactoring of suitable permissions code
This means that 'share with group' will not yet work for prim inventory items other than notecards and scripts
If serverside permissions are off then this works as expected. Previously, it was impossible for more than one person to edit such items even if permissions were off.
If serverside permissions are on then this works as expected if the object was created by an avatar who had the required group active.
However, if the group for the object is later set then the contained item is still not editable. This may be linked to a wider bug where the object is still not modifiable by the group anyway
Resolve conflict in LLClientView
If a full update is sent after the kill, the object remains as in the linden viewer but in an undeletable and unowned state until relog
This patch prevents this by recording kills in LLClientView
Backport from master
If a full update is sent after the kill, the object remains as in the linden viewer but in an undeletable and unowned state until relog
This patch prevents this by recording kills in LLClientView
Fixes: Undo, T-pose of others on login, modifiedBulletX works again, feet now stand on the ground instead of in the ground, adds checks to CombatModule. Adds: Redo, Land Undo, checks to agentUpdate (so one can not fall off of a region), more vehicle parts. Finishes almost all of LSL (1 function left, 2 events).
Direct flames and kudos to Revolution, please
Signed-off-by: Melanie <melanie@t-data.com>
These patch should allow people using systems that do not have their locale set to En_US or similar to use OpenSim without suffering effects such as being a million miles up in the air on login.
The problem was caused by parsing strings without forcing that parse to be En_US (hence different decimal and digit group symbols were causing problems).
Thanks very much to VikingErik for doing the legwork on this fix and phacelia for spotting it in the first place.
This resolves the problem where eyes and hair would turn white on standalone configurations
When a client receives body part information, for some insane reason or other it always ends up uploading this back to the server and then immediately re-requesting it.
This should have been okay since we stored that asset in cache. However, the standalone asset service connector was not checking this cache properly, so every time the client made the request for the asset it has just loaded it would get a big fat null back in the face, causing it to make clothes and hair white.
This bug did not affect grids since they use a different service connector.
When an object was deleted, the remove script instance call was aggregating the scripting events as normal.
This would queue a full update of the prim before the viewer was notifed of the deletion of that prim (QuitPacket)
On some occasions, the QuitPacket would be sent before the full update was dequeued and sent.
In principle, you would think that a viewer would ignore updates for deleted prims. But it appears that in the Linden viewer (1.23.5),
a prim update that arrives after the prim was deleted instead makes the deleted prim persist in the viewer. Such prims have no properties
and cannot be removed from the viewer except by a relog.
This change stops the prim event aggregation call if it's being deleted anyway, hence removing the spurious viewer-confusing update.
