diff options
author | Justin Clark-Casey (justincc) | 2013-03-12 22:16:09 +0000 |
---|---|---|
committer | Justin Clark-Casey (justincc) | 2013-03-12 22:16:09 +0000 |
commit | c43d4b557267547d07f6c90dc7e335ce4f7e07be (patch) | |
tree | baa7c11fae0e9c7e51cb173ba4c8182a8a5515c3 /bin | |
parent | minor: remove mono compiler warning in SceneObjectUndoRedoTests (diff) | |
download | opensim-SC-c43d4b557267547d07f6c90dc7e335ce4f7e07be.zip opensim-SC-c43d4b557267547d07f6c90dc7e335ce4f7e07be.tar.gz opensim-SC-c43d4b557267547d07f6c90dc7e335ce4f7e07be.tar.bz2 opensim-SC-c43d4b557267547d07f6c90dc7e335ce4f7e07be.tar.xz |
Improve teleport cancellation in some circumstances, though cancelling 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).
Diffstat (limited to 'bin')
0 files changed, 0 insertions, 0 deletions