| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
| |
already had a child agent would stop the eq working for the agent in the new region.
This was because the calculation as to whether a new agent was needed in the receiving region did not take megaregions into account,
unlike the original calculation when the user first teleported into the region.
This meant that on teleport, entity transfer would create a new CAP but this would be ignored by the viewer and receiving region, meaning that the EQ could no longer be used.
This would prevent subsequent teleport, amongst other things.
Currently, regions up to 512m from a megaregion are considered neighbours.
|
| |
|
|
|
|
| |
in statistics for monitoring/debugging purposes
These are recorded as 'entitytransfer' stats as seen by the "show stats entitytransfer" console command.
|
| |
|
|
|
| |
This is relevant to mega-regions where the borders are very different to a regular region.
Also adds some method doc and other code comments.
|
| |
|
|
| |
commit 7471bc7
|
| |
|
|
|
|
|
| |
simultaneously logged out then do not continue.
This aims to reduce any side effects if the process tries to complete after the client has logged back in (e.g. it was delayed due to a slow destination region response).
This introduces a new Aborting entity transfer state which signals that the teleport should be stopped but no compensating actions performed.
|
| |
|
|
|
|
|
|
| |
TeleportFinish in order to avoid a theoretical race condition when teleporting to a neighbour.
If we do this after TeleportFinish, then it's possible for a neighbour destination to request the source to create a child agent whilst its still treated as root.
This closes the original presence which we don't really want to do.
This is probably okay (albeit with warnings on the console) but afaics there's no reason not to move the child agent signal.
|
| |
|
|
| |
completion just to be sure we're not using a thread cached version.
|
| |
|
|
|
|
|
| |
viewer couldn't/didn't connect with destination or if destination didn't signal teleport completion.
Also adds regression test for the case where the viewer couldn't connect with the destination region.
Also refactoring of regression test support code associated with entity transfer in order to make this test possible and the code less obscure.
|
| |
|
|
|
|
|
|
|
| |
section of OpenSim.ini. False by default.
This option allows the simulator to specify that the cancel button on inter-region teleports should never appear.
This exists because sometimes cancellation will result in a stuck avatar requiring relog.
It may be hard to prevent this due to the protocol design (the LL grid has the same issue)
In small controlled grids where teleport failure is practically impossible it can be better to disable teleport cancellation entirely.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
teleports is still not recommended.
Previously, hitting the cancel button on a teleport would cancel on the client side but the request was ignored on the server side.
Cancel would still work if the teleport failed in the early stages (e.g. because the destination never replied to early CreateAgent and UpdateAgent messages).
But if the teleport still completed after a delay here or later on, the viewer would become confused (usual symptom appears to be avatar being unable to move/reteleport).
This commit makes OpenSimulator obey cancellations which are received before it sends the TeleportFinish event queue message and does proper cleanup.
But cancellations received after this (which can happen even though the cancel button is removed as this messages comes on a different thread) can still result in a frozen avatar.
This looks extremely difficult and impossible to fix.
I can replicate the same problem on the Linden Lab grid by hitting cancel immediately after a teleport starts (a teleport which would otherwise quickly succeed).
|
| |
|
|
| |
This is currently disabled pending an improvement in the test code to properly add avatars when an event queue module is present.
|
| |
|
|
|
|
|
| |
happen despite unexpected exceptions.
This means that if such an exception does occur, the region does not need to be reset before that user can teleport from it again.
This is all Oren's code from his patch in http://opensimulator.org/mantis/view.php?id=6374 but I've chosen to split it in two.
|
| | |
|
| |
|
|
| |
out of .addin.xml.
|
| |
|
|
| |
THESE.
|
| |
|
|
|
|
| |
since the call itself does nothing and the return value is ignored by all callers.
This is a very old method (+4 years) so is probably confusing code cruft.
|
| |
|
|
|
|
| |
I believe UseCircuitCode is sent on EnableSimulator EQ message, rather than EstablishAgentCommunication
At least with LL 3.3.4, EstablishAgentCommunication appears unnecessary in the teleport context -
viewer still requests it though possibly only after TeleportFinish(). However, we will continue to send it.
|
| |
|
|
| |
easier for other code to use (e.g. LSL_Api) without having to reference OpenSim.Data just for this.
|
| |
|
|
|
|
|
|
|
|
|
| |
bucket slot for RLV, notify the viewer about inventory folder updates.
The viewer would not see the folder move without this, either on accept or decline.
This commit also updates the TaskInventoryOffered message to better conform with the data LL uses
Changes are, agentID is prim owner rather than prim id, agent name is now simply object name rather than name with owner detail,
message is just folder name in single quotes, message is not timestamped.
However, folder is not renamed "still #RLV/~<name>". Long term solution is probably not to do these operations server-side.
Notes will be added to http://opensimulator.org/mantis/view.php?id=6311
|
| | |
|
| | |
|
| |
|
|
| |
Also, further improvements on HGUuidGatherer: if the assets are already in this grid don't fetch them again.
|
| | |
|
| |
|
|
| |
avies use to visit other grids. Not as good as I wanted, but good enough. Unfortunately we can't switch the appearance from under the avie without getting into a lot of weirdnesses because appearance is viewer-controlled. So instead, when this control is on, I'm disallowing HG-TP unless the user is wearing an allowed HG appearance -- the user gets a warning and needs to switch appearance. WARNING: I'm still not committing the config vars because this is still not ready for ppl to test.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
when an agent teleports to a neighbouring region
|
| |
|
|
|
|
|
| |
before changing properties to avoid hud display race condition with update threads.
This matches behaviour in fatpack crossing, where attachments are cloned before their properties are changed.
This only applies to crossings to simulators running code released before April 2011.
|
| |
|
|
|
|
|
| |
rather than scanning all scene for the presence with the right id
Stop checking IsLoggingOut on these listeners, if called with a root agent then we always want to perform these actions.
This covers cases where the client is closed due to manual kick, simulator shutdown, etc.
|
| |
|
|
|
|
|
| |
ETM.DoTeleport() if an agent needs closing.
This is always done as part of Scene.RemoveClient()
Also refactors try/catching in Scene.RemoveClient() to log NREs instead of silently discarding, since these are useful symptoms of problems.
|
| |
|
|
| |
make code more analyzable
|
| |
|
|
|
|
| |
start the handling.
Also fixes the log warning from ResetInTransit() if the state is cleared direct from Transferring or ReceiveAtDestination, as pointed out in mantis 5426
|
| | |
|
| |
|
|
| |
not before.
|
| |
|
|
| |
return earlier to simplify method
|
| |
|
|
|
|
|
|
|
| |
before the source region has finished cleaning up old agent data and structures.
If this is allowed, then the client usually gets forcibly logged out and data structures might be put into bad states.
To prevent this, the binary state machine of EMT.m_agentsInTransit is replaced with a 4 state machine (Preparing, Transferring, ReceivedAtDestination, CleaningUp).
This is necessary because the source region needs to know when the destination region has received the user but a teleport back cannot happen until the source region has cleaned up.
Tested on standalone, grid and with v1 and v3 clients.
|
| |
|
|
|
|
| |
taking place, rather than just (falsely) logging that we're not going to proceed.
An oversight from recent commit 9ab0c81
|
| |
|
|
| |
to the destination scene actually succeeds.
|
| |
|
|
| |
module once rather than repeatedly via scene presences
|
| |
|
|
|
|
| |
leave the user unable to teleport since the transit flag was not being reset.
This moves the 'already in transit' check further up and resets the flag if dns resolution fails and in the new required places.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
allow an immediate teleport back.
This is to help relieve a race condition when an agent teleports then immediately attempts to teleport back before the source region has properly cleaned up/demoted the old ScenePresence.
This is rare in viewers but much more possible via scripting or region module.
However, more needs to be done since virtually all clean up happens after the transit flag is cleared .
Possibly need to add a 'cleaning up' state to in transit.
This change required making the EntityTransferModule and HGEntityTransferModule per-region rather than shared, in order to allow separate transit lists.
Changes were also required in LocalSimulationConnector.
Tested in standalone, grid and with local and remote region crossings with attachments.
|
| |
|
|
|
| |
This is to eliminate possible race conditions if two teleport calls are made concurrently, where at least one is a local teleport.
This is pretty much impossible on a manual user teleport but can happen on script-invoked teleports.
|
| |
|
|
|
|
| |
the destination simulator. This part of the string is already provided by the viewer.
Also adds more reason logging for diagnostics when teleports are refused/fail.
|
| |
|
|
|
|
|
|
|
|
| |
(i.e. when IsInTransit() was being checked) to close down a race condition.
On EntityTransferModule.DoTeleport() there was an IsInTransit() check to prevent multiple simultaneous teleport attempts.
However, the SetInTransit() was only performed later on, which left a window in which multiple threads could pass the IsInTransit() check.
This has been seen in the field and the results aren't pretty.
This commit effectively combines the IsInTransit() and SetInTransit() checks so there is no such window.
More failure cases are made to to call ResetInTransit() to adjust to this move.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
source region after teleport to resolve Imprudence teleport problems.
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
to be closed because it is no longer in the child's view distance.
This sleep appears unnecessary since a sleep has already occurred in WaitForCallback() whilst waiting for the destination region to notify of teleport success.
There are no async operations between this sleep and the WaitForCallback()
If this sleep is present, then teleporting back to the source region within 5 seconds results in a disconnection.
If this sleep is commented out then teleporting quickly back and forth between two simulators appears to work without issue.
Tested on standalone, local grid and distributed grid.
Please revert if there's something that I've missed.
|
| | |
|
| |
|
|
|
|
|
| |
simulator
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.
|
