Router Demonstration (ShiftPosition)

[Fate-JH]

As per ticket #134 submitted by @Dethdeath, yada yada, you know the drill.

The following test uses the branch from #1373 as a base and modifies the rendering priority in an attempt that the user as seen from another player's perspective does not linger at their point of origin long before being deleted from the same perspective. Once the teleportation is confirmed, a location flag is set the the destination coordinates and, until the user arrives at that destination point, their rendering priority is turned off. Specifically, the user should be moved far outside of the observing player's field of view. They will stay that way until the shift state is processed and they are moved to the destination client locally, and that will also restore their rendering priority. Once that transition has occurred, they will have their entity creation packet processed and now appear at the destination point. In theory. "Rendering priority," in this case, refers to whether the user identifies to other player's through the event system whether it should be rendered (check AvatarAction.PlayerState). If the object delete packet and the object create packet are both processed before the shift state packet, the user should not erroneously reappear back at the teleportation point from another's perspective.

This was originally it's own test of a possible independent router teleport system fix that did not involve the event system and that is why it is in its own branch separate from #1373's branch. After it was proven that the speed of a PlanetsideStateShiftMessage was faster than the speed of the next proper upstream packet in practice, it was given the #1373 branch as a base in attempts to resolve the occasional lingering user rendering echo. I suppose this is the pirmary test to be performed.

[Fate-JH]

¯\_(ツ)_/¯

[Dethdeath]

This one works flawlessly, even with audio amp on.