To make totally sure that the compiler understands it can fully compute the value at compile time when dealing with constant inputs, and to make totally sure there are no aliasing problems.
Add a bit of Javadocs, and introduce helper function for reversing directions because the ^2 trick used elsewhere in the codebase is not immediately obvious exactly what it does.
This was a regression from #7435 which introduced threads and caused JNI
to misbehave and fail to load our expected classes. Provide a workaround
based on the description in https://stackoverflow.com/a/16302771 which
stores a main thread's class loader and uses that in neighbouring
threads.
Add 'default' cases to a few enums that were not otherwise handling all possible enum values. This wasn't a problem before because the variables we were switching on were not actually enum types, but now that they are, Clang is warning us about the non-covered cases.
It turns out that trying to just give a peep a pathfinding goal and then let them loose doesn't work, because every time they reach a junction, the pathfinder has them walk 'aimlessly' instead of pursuing their target. That's why we were seeing some very large step counts in previous tests - they were (eventually) walking onto the target square, but only after lots of wandering around in circles.
This commit reworks the test data to contain an actual ride for each test scenario, where the peep will path to the tile in front of the ride entrance. A nice side benefit of this is that the ride names must match the test names, so you can now tell from looking at the rides in the test data which one is used for which test instance.
The 'yellow marker' tiles for goal positions are also removed here, as we're deriving goal positions from the ride entrances instead.
To make it a little clearer what the parameter is for, rename FindPath::maxSteps to FindPath::expectedSteps, and extend the comment to describe what happens in negative test scenarios.
