| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
race condition checks.
This is to allow a second attempt to remove an avatar even if "show connections" shows them as already inactive (i.e. close has already been attempted once).
You should only attempt --force if a normal kick fails.
This is partly for diagnostics as we have seen some connections occasionally remain on lbsa plaza even if they are registered as inactive.
This is not a permanent solution and may not work anyway - the ultimate solution is to stop this problem from happening in the first place.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
last commit 205f2326
|
| |
|
|
| |
This better reflects the long-term purpose of that project and matches Monitoring modules.
|
| |
|
|
| |
It seems that the mono 2.10.8.1 doesn't choke on this but for some reason 2.4.3 fails.
|
| |
|
|
| |
start of script rather than just the script status reported by SOG.ContainsScripts()
|
| |
|
|
| |
correct running status on a re-rezzed attachment
|
| |
|
|
|
|
| |
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!
|
| |
|
|
| |
GroupsModule, since these led to a private blank method
|
| |
|
|
|
|
|
|
|
| |
receivers to accept/decline.
This appears to be a regression from back in commit db91044 (Mon Aug 22 2011) where we started to send TaskInventoryOffered msg dialog rather than InventoryOffered dialog.
This is probably correct, but failed because the bucket was too large and because we wouldn't have handled the TaskInventoryDeclined option anyway.
This patch handles both of these and make llGiveInventoryList() use TaskInventoryOffered as well
Fixes http://opensimulator.org/mantis/view.php?id=6089
|
| |
|
|
|
|
|
| |
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 is only currently meant for use by regression tests that don't have any issues if XEngine is started up quickly, since no other operations will be occuring simultaneously.
Therefore, this is not yet documented externally.
|
| |
|
|
| |
This currently only does a relatively crude check for a ScriptState node in the serialized xml
|
| |
|
|
| |
currently only checks for the presence of script items, not for started scripts
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
the scene graph
|
| |
|
|
| |
AttachObject() for better code comprehension
|
| |
|
|
|
|
|
| |
This works like osForceAttachToAvatar() but allows an object to be directly specified from the script object's inventory rather than forcing it to be rezzed in the scene first.
Still only attaches objects to the owner of the script.
This allows one to bypass the complicated co-ordination of first rezzing objects in the scene before attaching them.
Threat level high.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
| |
OpenSimTestCase.SetUp()
|
| |
|
|
| |
AttachmentsModule.
|
| |
|
|
|
|
|
| |
confined to a single test if it's turned on.
This involves making test classes inherit from a common OpenSimTestCase.
This will be applied to more classes as required.
|
| |
|
|
| |
local variables
|
| |
|
|
| |
This also avoids confusion between tests where one sets up m_attMod and another accidentally uses it after failing to set one up itself.
|
| |
|
|
| |
since it doesn't need to be global and some tests set up more than one sp
|
| |
|
|
| |
when an agent teleports to a neighbouring region
|
| |
|
|
| |
AvatarFactoryModule.SetAppearance() for future use
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
attachment item setup
|
| | |
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
| |
See "help teleport user" on the console for more details
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
seen on inter-simulator teleports where avatar baked textures are not available from the asset service.
|
| |
|
|
| |
LocateClientObject() and GetClientScene(), do the lookup just once in LocateClientObject()
|
