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 original function suffered from unexpected results due to rounding
errors. An error of only 1 or 2 ulps would cause the code to not detect
a singularity at Y rotation +/- PI/2 and take the non-singularity code
path. The replacement code does not suffer from wildly inaccurate
results at the +/- PI/2 singularity. The check in the code for the
singularity isn't strictly needed, but gives more consistent results
At the singularity, the X and Z rotations add. The if check simply
forces the X rotation to be zero so the entirety of the X+Z rotation is
carried by Z.
Additionally, the test code has been updated to include test cases that
caused the old code to fail. The test algorithm is also updated to
perform a more meaningful test. The original code checked if the values
against expected values. This could fail at +/- PI rotations since a
rotation around an axis by PI causes the identical effect as a rotation
by -PI. The new test code checks that the returned angles can be used
to recreate a quaternion that causes the same rotation.
Not yet enabled by default. You can enable this by setting Cap_FetchInventory2 = "localhost" in the [ClientStack.LindenCaps] section of OpenSim.ini
Enabling both FetchInventory2 and FetchInventoryDescendents2 improves the situation with properly fetching attachments and hud objects
Probably because viewers are never expecting the odd situation where FetchInventoryDescendents2 is present but not FetchInventory2
However, for some reason attachments and hud objects occasionally fail to appear, though their status is correct in inventory
For attachments, focussing on the avatar makes them appear. Hud objects have to be reattached.
This is not as useful as it sounds, since you can only request rebakes for texture IDs already received.
In other words, if the viewer has never sent the server this information (which happens quite often) then it will have no effect.
Nonetheless, this is useful for diagnostic/debugging purposes.
BlueWall