From sl docs such as http://community.secondlife.com/t5/English-Knowledge-Base/Managing-Private-Regions/ta-p/700115
agent should apply to avatars only.
This makes sense from a user perspective, and also from a code perspective since child agents with no physics or actions take up a fraction of root agent resources.
As such, the check is now only performed in Scene.QueryAccess() - cross and teleport check this before allowing an agent to translocate.
This also removes an off-by-one error that could occur in certain circumstances on teleport when a new child agent was double counted when a pre-teleport agent update was performed.
This does not affect an existing bug where limits or other QueryAccess() checks are not applied to avatars logging directly into a region.
Will use one of three selected methods to route avatar landing
points when using Telehubs. The setting is in [Startup] using
SpawnPointRouting = closest/random/sequence
closest: The default setting. Routes avatar to the nearest SpawnPoint
to the location.
random: Picks random SpawnPoints to land the avatar.
sequence: Follows a sequence to place the avatar on the next available
SpawnPoint location
Conflicts:
OpenSim/Region/Framework/Scenes/Scene.cs
Viewers 1 and 3 are fine with doing this immediately. However, Imprudence has a small delay (<200ms, >500ms) after receiving the AgentCompleteMovement reply packet on the destination region before regarding that region as the currnet region.
If Imprudence receives a DisableSimulator in this period, it quits.
We are not restoring the full 5000ms delay since this brings back a bug where teleports permanently fail if an avatar tries to teleport back too quickly.
This commit also sends the AgentCompleteMovement packet to the client before telling the source region to release its old agent, in order to further cut down any possibility of the DisableSimulator being recieved before the AgentMovementComplete.
This adds a non-advertised wait_for_callback option in [EntityTransfer]. Default is always true.
Teleport tests disable the wait for callback from the destination region in order to run within a single thread.
This happened because the scripts were notified about control changes (e.g., the user stopped pressing the Forward key) when the animation was still WALK, so the script didn't stop the walking animation. Fixing this required: a) Update the movement animation *before* notifying the script; b) Add locking to prevent clashes with the Heartbeat thread (which also updates the animations); c) Handle the case of a user who stops walking just as the avatar is in the air: the avatar should STAND in that case, not WALK.
This reverts commit feef1dd732.
These are identical apart from setting Velocity = zero, which has no practical effect anyway since this is zeroed when the avatar is added back to the physics scene.
This makes it consistent with other parts of OpenSimulator that are treating ESTATE_MANAGER and ESTATE_OWNER as different entities.
As per opensim-dev mailing list.
However, it looks like we should retain SP.ParentID since it's much easier to use that in places where another thread could change ParentPart to null.
Otherwise one has to clumsily put ParentPart in a reference, etc. to avoid a race.
This involves
1) On forcible teleport, call m_scene.RequestTeleportLocation() rather than ScenePresence.Teleport() - only EntityTransferModule now should call SP.Teleport()
2) When avatar is being forcibly moved due to banlines, use a 'stop movement' tolerance of 0.2 to requested position rather than 1
This prevents the avatar sometimes being stuck to banlines until they teleport somewhere else.
This aims to fix some problems in http://opensimulator.org/mantis/view.php?id=5822
potential bad update that places an object at the opposite side of the
origin sim for a moment before actually crossing it. Especially important in
grids like OSG where lag between sims is high.
Add configuration option - DEBUG to enable debugging methods. This is temporary for helping users testing teleport routing be able to report back the data with the test cases. We can remove when finished with this, or leave it if it proves to be useful.
Users: set DEBUG = true in OpenSim.ini to get more information from teleport routing. The default is false. It presently prints the TeleportFlags value.
Switch to our TeleportFlags enum instead of LibOMV because we need to define a type for HG Logins. Also moved some debugging in ScenePresence into a function to make it simpler to enable/disable.
Incoming HG owner/estate manager, etc. is routed according to the rules defined for teleports within the local grid. Left some commented debugging code inside so we can test other cases. Will remove when tings are settled in.
The viewer warns in the log if it receives this.
Stopping this doesn't appear to have adverse effects on viewer 1 or viewer 3 - the viewer gets its own appearance from body parts/clothes and self-baked textures.
Further filters "debug packet <level>" to exclused [Request]ObjectPropertiesFamily if level is below 25.
Adjust some method doc
Minor changes to some logging messages.
Stop hiding RemoveAvatar failure, add log messages when characters are removed through defects or re-added unexpectedly.
Add commented out log lines for future use.
Use automatic property for PhysicsActor for better code readability and simplicity
The only caller is the LLUDP stack and this has to validate the UDP circuit itself, so we know that it exists.
This allows us to eliminate another null check elsewhere and simplifies the method contract
This means that avatar/appearance data of other avatars and scene objects for a client will be sent after the ack rather than possibly before.
This may stop some avatars appearing grey on login.
This introduces a new OpenSim.Framework.ISceneAgent to accompany the existing OpenSim.Framework.ISceneObject and ISceneEntity
This allows IClientAPI to handle this as it can't reference OpenSim.Region.Framework.Interfaces
This reverts to situation where animation updates are made each frame on SP.PhysicsCollisionUpdate (though a packet is only sent if the anim actually changes).
m_updateCount was not being update on various avatar state changes, causing the correct animations to never be sent.
Always setting in HandleAgentUpdate() is not enough since the avatar is continually sending AgentUpdate packets.
One would need to identify all the conditions under which animations need to play out and set m_updateCount appropriately in SP.HandleAgentUpdate()
Neither of these can have any effect on child agents
Now leaving warning about trying to set animation on a child agent active. Might temporarily pop up now and again.
This involves getting IScene.RequestModuleInterfaces() to return an empty array (as was stated in the method doc) rather than an array containing one null entry.
Callers adjusted to stop checking for the list reference being null (which never happened anyway)
prim update to only triple queuing. Existing method was:
1. Schedule prim for update, adding to scene update list
2. Update on SOGs during heartbeat queues update onto each SceneViewer
3. Update on SPs during heartbeat queues update onto each IClientAPI
4. ProcessEntityUpdates queues updates into UDP send stack
Now the SceneViewer has been eliminated so updates are scheduled at any
time and then put onto the IClientAPI priority queues immediately during
SceneGraph.UpdateObjectGroups.
This is to avoid http://opensimulator.org/mantis/view.php?id=5783 when a collision with a ground sitting avatar causes that avatar to automatically stand and sometimes not be able to move
A better solution may be to keep gound sitting avatars solid but remove their collision status. However, this requires some physics code work.
This means that if the avatar is within 10 meters of the selected target, it sits on it immediately without walking.
Existing autopilot outside this range will be disabled in a later commit
This is to partially address http://opensimulator.org/mantis/view.php?id=5769
We don't need to call SP.HandleAgentSit() again if we are within 10m since the autopilot won't trigger.
By calling it twice, the position of the sitting NPC was wrongly adjusted, ending up near <0,0,0>.
However, this change does mean that NPCs further than 10m away will not attempt to autopilot to the prim, though this code was broken anyway (is actually a different mechanism to normal NPC movmeent).
Hopefully this can be addressed soon.
This was meant to help with the script in http://opensimulator.org/mantis/view.php?id=5772 but it doesn't work.
Probably the event is fired before the physics actor has been set up again for the stood avatar.
Fixing that would be much more complicated, but processing the event last of all seems like a good idea in any case.
from previous commit which sort out which iterator is used are left
intact. A discussion is needed as to what constitutes an avatar vs a
ScenePresence.
the 3 iteration functions so more of them are using the correct
iteration for the action they are performing. The 3 iterators that seem
to fit all actions within OpenSim at this time are:
ForEachAvatar: Perform an action on all avatars (root presences)
ForEachClient: Perform an action on all clients (root or child clients)
ForEachRootClient: Perform an action on all clients that have an avatar
There are still a dozen places or so calling the old
ForEachScenePresence that will take a little more refactoring to
eliminate.
UpdateFlag is now referenced/used only within SOP and SOG. Outsiders are
using ScheduleFullUpdate, ScheduleTerseUpdate or ClearUpdateSchedule on
SOP consistently now. Also started working toward eliminating those
calls to ScheduleFullUpdate, ScheduleTerseUpdate or ClearUpdateSchedule
from outside SOP in favor of just setting properties on SOP and let SOP
decide if an update should be scheduled. This consolidates the update
policy within SOP and the client rather than everywhere that makes
changes to SOP. Some places forget to call update while others call it
multiple times, "just to be sure".
UpdateFlag and Schedule*Update will both be made private shortly.
UpdateFlag is intended to be transient and internal to SOP so it has
been removed from XML serializer for SOPs.
In AvatarFactoryModule.HandleAppearanceUpdateTimer(), we loop through appearance save and send requests and dispatch via a FireAndForget thread.
If there was more than one request in the save or send queue, then this led to a subtle race condition where the foreach loop would load in the next KeyValuePair before the thread was dispatched.
This gave the thread the wrong avatar ID, leaving some avatar appearance cloudy since appearance data was never sent.
This change loads the fields into local references so that this doesn't happen.
Format is osNpcSit(<npc-uuid>, <target-uuid>, OS_NPC_SIT_IMMEDIATE)
e.g. osNpcSit(npc, llGetKey(), OS_NPC_SIT_IMMEDIATE);
At the moment, sit only succeeds if the part has a sit target set.
NPC immediately sits on the target even if miles away - they do not walk up to it.
This method is in development - it may change so please don't trust it yet.
Standing will follow shortly since that's kind of important once you're sitting :)
ways to access the list/dictionary of child regions and locking was
inconsistent. There are now public properties which enforce locks.
Callers are no longer required to create new copies of lists.
Some of the places where agentMS was added were in separate threads launched by the update loop. I don't believe this is correct, since such threads are no longer contributing to frame time.
Some of the places were also driven by client input rather than the scene loop. I don't believe it's appropriate to add this kind of stuff to scene loop stats.
These changes hopefully have the nice affect of making the broken out frame stats actually add up to the total frame time
SP still has an implementation but this is now just a public method on SP rather than an abstract one in EntityBase.
No point making the code more complex until it actually needs to be,
This stops the npc walking backwards if the target is directly behind.
This means that the npc no longer returns to its original rotation once movement has finished.
If you want this behaviour, please store and reset the original rotation after movement.
This is somewhat to address http://opensimulator.org/mantis/view.php?id=5678
When upgrading the previously child agent to a root, the code was setting the Size parameter on the ODECharacter PhysicsActor.
This in turn reset Velocity, which cause the border stall.
I'm fixing this by commenting out the Velocity = Vector3.Zero lines since they don't appear to play a useful purpose
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.
The code in question is over three years old and just be catching an inconsistency rather than being wholly necessary.
This commit still carries out the check and prints all the previous log warnings but a 'failure' no longer prevents avatar region crossing or teleport, and it doesn't give the client the error message.
This will have some kind of impact on http://opensimulator.org/mantis/view.php?id=5672
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
The approach here, as in other parts of OpenSim, is to return a copy of the list rather than the attachments list itself
This prevents callers from forgetting to lock the list when they read it, as was happening in various parts of the codebase.
It also improves liveness.
This might improve attachment anomolies when performing region crossings.
On making a root agent, we need to reset the ScenePresence.m_movement_flag so that it doesn't remember the
movement registered to the client when it exited the initial region.
If this is remember, then the client avatar movement isn't updated and it appears to stall in mid-air, though this is resolved with a prod/release of any other direction key.
This bug was probably introduced a few weeks ago. Surprised that nobody brought it up.
This is done by introducing a PresenceType enum into ScenePresence which currently has two values, User and Npc.
This seems better than a SaveAttachments flag in terms of code comprehension, though I'm still slightly uneasy about introducing these semantics to core objects
this is to allow walking on prims. it will be up to the script writer to be sure that there is a continuous path.
currently implemented in osNpcMoveToTarget(), but none of this is final.
This doesn't help where the target is a prim surface. In these situations, it might be better to provide manual overrides so the script can control whethre an avatar flys there/lands, etc.
This makes the movement exact. Regression test changed to check avatar reaches exact target.
Also has the nice side effect of making NPC animations continue to work after the first movement (which wasn't working). However, avatar still pauses in mid-stride
Avatar moves and stops. However, will stop in mid stride.
And if the move to position is in the air, avatar will continue to make vain and quite hilarious attempts to take off (but never doing so).
Clearly more work is needed.
This now works again except that it requires a click or avatar mvmt to get going
This is because the ScenePresence.HandleAgentUpdate() method doesn't trigger until the client does something significant, at which point autopilot takes over.
Even clicking is enough to trigger.
This will be improved presently.
This is not used for anything - appearances are always properties of objects with ids (ScenePresence, AgentCircuitData) and just has the potential to get out of sync when the appearance is cloned.
Had to stop using AvatarService for now since it doesn't store baked texture IDs (which is why this was failing).
Also failing because cloning appearance was also cloning the AvatarApperance.Owner field, which we weren't then changing.
Extended TestCreate() to check this.
This now creates an avatar but appearance is always cloudy.
Move doesn't work.
Really, creating an NPC should only involve a ScenePresence rather than doing anything with IClientAPI, since an NPC has no viewer to communicate with!
child agents in neighbor regions. This means you can extend
the view on a simulator beyond the default 3x3 regions.
This uses a region default draw distance and should be
replaced at some point by the avatar specified draw distance.
That will require more careful, dynamic recomputation of child
agents every time the draw distance changes.
WARNING: this is experimental and has known instabilities. specifically
all regions "within site" should be running the same default draw distance
or agents will not be closed correctly.
This restores a RemoveFromPhysicalScene() call in ScenePresence.CheckForBorderCrossing() when the agent has been placed in transit.
If we don't remove the agent from the physical scene, then the method continues to be called via ScenePresence.Update()
until the handover of the client between regions is completed. Since this handover can take more than 1000ms (due to the 1000ms
event queue polling response from the server), this results in the avatar pausing on the border for the entire handover period.
Justin Clark-Casey (justincc)