When a chaser's route finishes calculating, the chaser may already be a
few blocks away from the starting position, thanks to movement inertia.
The path finding code finds the point along the route closest to the
chaser's position.
This calculation only considered the xy coordinates when finding the
closest point. This caused issues whenever the calculated route goes
below the chaser's position (for example, when the chaser is on top of a
bridge and the route circled around to go under the bridge). In this
case, there was a chance that the closest point was the one below the
bridge. This caused the chaser to try to move directly to a directly
inaccessible block.
The fix was to remove the xy() filter so that the closest point
algorithm also considered the z coordinate.
We had a random chance of restarting the route to avoid getting the
chaser stuck. This didn't work properly because the rerouting code was
only triggered if `self.route.is_none()` or if the target moved
significantly, and the random chance branch only set `bearing` to `None`.
This change sets `self.route = None` to trigger rerouting.
Set CHUNK_SITE to 10 which results in a mean of 13ms per Slowjob. Its good if it stays under 30ms so it has less influence on ticks.
Some performance values measured with a AMD Ryzen 1700X:
- voxygen and server and swarm (25 clients, 10 vd) on one machine.
- total runtime was 240s
- CHUNK_GENERATOR total time is 486s with a mean of 40ms
- CHUNK_SERIALIZER total time is 18.19s with a mean of 13ms, so in total its a order of magnitude lower
Trancy confirms this, the Serialize backlog is usually handled within 1-2 ticks.
- terrain::sys total time 1.2s, mean 188us
- msg::terrain::sys total time 812ms, mean 125us
- terrain::sync total time 12ms, mean 1,85us
- chunk_serialize::sys total time 69ms, mean 10us
- chunk_send::sys total time 50ms, mean 7us
so all in all total time for serializsation is 20.33 of which 89% are spend outside of the ECS
