| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
justincc's original work. Sample scripts before doing so. Also refactor some
crucial common code and eliminate parameters that were only ever used with
the same constant value.
|
| |
|
|
|
| |
while still in the scene to avoid losing important script state.
DeleteSceneObject can not be called before doing this!
|
| |
|
|
|
|
|
| |
update the name if this has been changed whilst attached.
Note, this behaviour appears to be at variance with the ll grid as of Tues 17 July 2012, testing with viewer 3.2.1.
The item name in inventory does not change either at the point of detach or after a relog.
|
| |
|
|
|
|
|
| |
item is updated.
This doesn't seem to make any sense and probably stems from a period when this code was directly involved in attaching objects directly from the scene.
This message is already being sent by InventoryAccessModule code instead.
|
| |
|
|
| |
This currently only does a relatively crude check for a ScriptState node in the serialized xml
|
| |
|
|
|
|
| |
the known item with script state still in the script engine and then remove the scripts.
This is to fix a regression starting from 5301648 where attachments had to start being deleted before persistence in order to avoid race conditions with hud update threads.
|
| |
|
|
|
|
| |
This prevents a stack overflow where a get position on the avatar will refer to the attachment which will in turn refer back to the avatar.
This required recording of all sitting avatars on a prim which is done separately from recording the sit target avatar.
Recording HashSet is null if there are no sitting avatars in order to save memory.
|
| |
|
|
| |
AttachObject() for better code comprehension
|
| |
|
|
|
|
|
| |
directly instead of an item ID to then shuffle through attachments, saving CPU busywork.
Almost all callers already had the sog to hand.
Still checking that it's really an attachment, but now by inspecting SOG.AttachedAvatar
|
| |
|
|
| |
matches out fromItemID on detach, go through the agent's attachment sog list instead.
|
| |
|
|
|
|
|
| |
RezSingleAttachmentFromInventoryInternal() returned null.
null would only ever be returned if the item couldn't be located within inventory and this would happen immediately.
In this case, derezzing wouldn't work anyway since there is no item to derez.
|
| |
|
|
| |
AttachmentsModule.
|
| |
|
|
|
|
| |
delete first to avoid a hud race condition with update threads.
If delete doesn't occur first then the update thread can outrace the IsAttachment = false necessary to save attachments and send hud artifacts to other viewers.
|
| |
|
|
|
|
|
|
|
| |
attachment before changing properties for correct inventory serialization.
Serialization of attachments requires IsAttachment = false so that correct positions are serialized instead of avatar position.
However, doing this when a hud is still attached allows race conditions with update threads, resulting in hud artifacts on other viewers.
This change sets SOG.IsDeleted before serialization changes take place (IsDeleted itself is not a serialized property).
LLClientView then screens out any deleted SOGs before sending updates to viewers.
|
| |
|
|
|
|
|
|
| |
AttachmentsModule.UpdateAttachmentPosition() in order to avoid a hud update race condition.
Previously, setting IsAttachment to false then true was necessary to serialize the updated attachment object information.
However, UpdateAttachmentPosition no longer does this update.
Whilst IsAttachment is set to false there is a race condition where the update thread can wrongly send hud object updates to clients that do not own the hud, resulting in screen artifacts.
|
| |
|
|
| |
AttachmentsModule
|
| |
|
|
|
|
| |
disappear for other avatars.
We do this by sending a kill message for that object to all other avatars apart from the one that has the hud.
|
| | |
|
| |
|
|
|
|
| |
AddRegion()
The reference is not guaranteed to be there when AddRegion() is called but will definitely be present at RegionLoaded() if it's going to be present at all.
|
| |
|
|
|
|
|
| |
llAttachToAvatar() or osForceAttachToAvatar() would wrongly have next permissions come into play when they detached that object and rezzed it in scene.
This is because the attachments module code was setting the 'object slam' bit by using PermissionMask.All
Solution here is to route the attachment item creation call through the existing inventory code in BasicInventoryAccessModule rather than copy/pasted code in AttachmentsModule itself.
|
| |
|
|
|
|
|
| |
changed owners is rezzed.
This needs to occur after the script is resumed rather than before, when the event is just dropped.
Addresses http://opensimulator.org/mantis/view.php?id=5890 and http://opensimulator.org/mantis/view.php?id=5952
|
| | |
|
| |
|
|
| |
Eliminated an extra newline in the console if the log line doesn't contain a category (example of a category: "[ASSETS]").
|
| |
|
|
|
|
| |
only ever using the root part entry.
This eliminates some pointless memory use.
|
| | |
|
| |
|
|
|
| |
visitors at all. On Leaving a sim, save only the changed ones. Don't save
all scripted stuff when leaving a sim.
|
| | |
|
| |
|
|
| |
Haven't been able to resolve issue where attachments are removed by the viewer on relog on a localhost
|
| |
|
|
| |
packet per prim. More to come as we change to make use of this.
|
| | |
|
| | |
|
| |
|
|
| |
handlers for attachments to call public interface and rearranged module file into sections
|
| |
|
|
| |
converted back and forth between ScenePresence and IClientAPI. More to be done still.
|
| | |
|
| |
|
|
|
|
| |
allow attachments to be temporarily turned off.
This is for debugging purposes. Defaults to Attachments Enabled
|
| |
|
|
| |
all parts, now that we're performing this check in UpdateKnownItem() for other purposes
|
| |
|
|
| |
itemID is always taken taken from the group's stored item id, and agentID is never used.
|
| |
|
|
| |
It's not appropriate for code outside the attachments module to call this.
|
| | |
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
itemID) for now
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.
|
| |
|
|
|
|
|
|
|
| |
IScenePresence.AttachmentsSyncLock object
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.
|
| |
|
|
| |
variables in different contexts
|
| | |
|
| |
|
|
| |
IAttachmentsModule.RezSingleAttachmentFromInventory() with the updateInventoryStatus switch, since this is never called with false
|
| | |
|
| |
|
|
| |
The second was already being filtered out so this has no user level effect
|
| |
|
|
|
|
|
| |
This was happening because we were using the source avatar's item IDs in the clone appearance.
Switch to using the asset IDs of attachments instead for NPCs.
The InventoryAccessModule and AttachmentModule had to be changed to allow rezzing of an object without an associated inventory item.
Hopefully goes some way towards resolving http://opensimulator.org/mantis/view.php?id=5653
|
| |
|
|
| |
It's never possible for SOG to have no RootPart, except in the first few picosends of the big bang when it's pulled from region persistence or deserialized
|
| | |
|
