This looks like an off-by-one bug since the view distance was already only 256 on the west and south sides.
This reduces the number of child agents being logged into regions neighbouring a megaregion.
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.
with our own and add export permissions as well as a new definition for "All" as meaning "all conventional permissions" rather than "all possible permissions"
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.
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.
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.
It looks like this was happening when AttachmentsModule.RezAttachments was doing a secondary set of each attachment to update with the asset ID (initially they only have the inventory ID).
However, with multi-attach this was appending a second copy of the same attachment rather than updating the data that was already there.
This commit requires both simulator and service to be updated.
This allows region modules to add dynamic objects to SOPs rather than having to continually push and pull OSD dynamic attributes.
This is to explore the original MOAP use case for dynamic attributes where it could be very awkward and possibly time-consuming to keep reconstructing MediaEntrys from stored DynamicAttributes.
This commit adds a DOExampleModule to demonstrate/evolve this code.
Dynamic objects involve no storage or persistence changes - the 'backing store' for any data that does need to be saved will remain the DAMap.
DOExampleModule in this commit only attaches a fresh dynamic object. Actually constructing this from stored dynamic attributes and handling persistence is left for later.
These changes should affect no existing functionality, though it may or may not reveal necessary changes in DAMap down the road.
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.
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).
Existing map settings in [Startup] will continue to work, and if present will override anything in [Map]
However, the proper place for such settings would now be [Map]
This is to reduce the use of [Startup] as a bag for non-generic settings which should really go in sections, in common with other settings.
This commit also extends Diva's previous work to allow a default setting to be given when looking at multiple sections for settings.
