Why? In prinicple, a queue connected to a path should not be seen as causing a junction in that path. Rather a ride queue should be treated equivalently to ride entrances/exits. For the path finding search this means that maxNumJunctions are not consumed when walking past ride queues (unless there is a legitimate path junction there).
Remove the unused arguement 'dist' from get_ride_queue_end().
Remove gPeepFindAltStationNum replacing it with numEntranceStations, which is much simpler to understand.
For rides with multiple entrance stations that sync with adjacent stations, generalise cycling the station entrance selected by the peep through all of the ride's entrance stations (not limited to only stations 0 and 1) to enable this entrance cycling behaviour for rides with >= 2 entrance stations including rides with split entrance/exit stations (where the entrance stations are not stations 0 & 1).
Remove earlier optimisation to heuristic search that was preventing searching for shorter paths once a path to the goal was reached.
Resolve Travis warnings.
With the changes to the path finding, a similar search space to the original now corresponds to half the maxNumJunctions value.
Added warning message when maxTilesChecked is exceeded - path finding issues are to be expected in that case.
Removed some commented out code left over in the previous commit.
In the heuristic search, tiles in wide path were always being handled as junctions. Changed to handle junctions according to the path thinning.
There was no search loop detection. Added loop detection for returning to the starting location and any of the junctions visited in the current search path.
Various other optimisations added.
When a new peep thought was created, the peep window action widget is invalidated. This would only be valid if the first tab is active. Instead just invalidate the whole window.
