The heuristic search currently only inludes detection of loops in the current search path - i.e. from where the peep is now.
The peep->pathfind_history includes (limited) junctions that the peep has already passed through for the current search goal to get to their current location. Consider search paths through these junctions as loops as well.
This will prevent peeps getting stuck in some path layouts where looping back through a junction they already walked through and then proceeding via an alternative path (such that there is no loop in the current search path) hits the search limits on a continuing path that is closer to the goal than simply continuing on along the path which then turns (temporarily) away from the goal.
This prevents _some_ cases of alternate, longer routes to nearer tiles being returned as a better result than a route that goes through that same tile (with less steps) and then continues on to end overall further from the goal though closer to getting to the goal (as was previously documented in PR #4527).
The network version is incremented in this PR.
When sending a mechanic to a ride exit/entrance, the original pathfinding was setting the goal to the path next to the exit/entrance with goal.z set to the exit/entrance height. This is wrong when the path slopes up to the exit/entrance. Consequently the original pathfinding included a hack to allow the mechanic to enter the exit/entrance from the goal tile.
The changes in PR #4527 (commit f3cf23f) will ignore the relevant tile when the height is wrong, preventing the original hack from working. To fix this the height of paths sloping up was adjusted in the heuristic search ... which inadvertently broke pathfinding for other goals on such a sloped path (such as the start of a ride queue that slopes up).
To fix, set the goal to the ride exit/entrance itself, make the heuristic search aware of ride exits (code existed but was commented out; entrances are already there for rides without queues) and remove both the original hack and the (incorrect) heigh adjustment made in PR #4527.
Fixes issues #4626, #4629.
Use of zero clearance will no longer block the path finding when paths and other map elements are placed in the same tile at the same height.
Pathfinding recognises map elements for shops, so peeps can find shops again.
Pathfinding recognises the park entrance, so peeps can leave the park again.
This commit also renamed a flag, and corrected the use of one. The
flags in question are WALL_SCENERY_BANNER, WALL_SCENERY_2_FLAG4, and
WALL_SCENERY_2_FLAG5.
Wide tiles are consequently only traversed to reach thin path tiles when in an area of wide path tiles. This fixes peeps getting stuck when the path search limits are all further away from the destination than wide tiles.
- Telemetry information collected includes: end location, steps taken, number of junctions walked through, the list of junctions walked through and the directions taken at each of those junctions.
- Telemetry collection is not optimised and currently has a negative performance impact.
Improve pathfinding debugging framework:
- Include collected telemetry information in the debugging messages.
- Enable debugging only for specific peeps - for guests, debugging is logged for tracked guest(s) only; for staff, debugging is logged for "Mechanic Debug" only.
- Debug messages need a DEBUG build with appropriate log levels enabled: used log levels are VERBOSE and INFO.
