The code being removed in the patch tries to fast forward a peep into the ride when it is the second peep for a vehicle that is used in pairs. Problem is that funds checking does not happen, so it happens that a peep may pay against its will.
Lets say a rich peep enters in line and a poor peep enters in line right after.
If the price of the ride is such that the rich peep can pay and the poor peep can't, it will be dragged into the ride because funds checking only happened for the first.
The second part of the patch just adjusts we consider the vehicle a full car if the second position is filled.
Add test to verify that a peep is not dragged into a ride it can't pay
This test puts two peeps in a Ferris Wheel. The first peep is rich and the second peep is poor. When they are both in line, the ride price is raised so that the poor peep can't pay.
Make sure the poor peep turns back and leaves the ride.
During development, a mistake in the logic would have broken all rides other than ferris wheels in a way that multiple guests could enter the same car.
Also add a test to make sure that is never broken.
If we want to have more semantically meaningful types (like Direction), it's useful to be able to support those in the DataSerializer too. Swapping bytes for entire structures is probably never going to make sense, but for types that are pure wrappers around integer types, we want to be able to swap them as if they were the integer they wrap.
Introduce some basic scenario-style tests for the pathfinding AI. There
are two tests:
* Test that a peep can get from a given start position to a given end
position, and that it takes them an expected number of ticks to do so.
Also test that they did not walk on any 'forbidden' tiles in the process,
e.g. tiles that are completely the wrong direction from the goal etc.
* Test that a peep can *not* get from a given start position to a given
end position after a given number of ticks.
Each test is parametric, and instantiated for multiple different
start/end positions within the provided test park. If we find a new
situation that needs a test, it should just be a matter of building
that situation in the saved game and then adding a line to the code to
set it up.
Indicating 'forbidden' tiles is done using terrain surface type IDs:
tiles that the pathfinder should never send the peep into should be
painted with the red neon surface type (index 8). This means we have
no way to forbid some path elements on a tile while allowing others,
but we don't need that right now.
Similarly, to help ensure that the test data and code are kept in
sync, the tests also require that peep start tiles are painted with
the green neon surface type (index 11) and that goal tiles are
painted with the yellow neon surface type (index 9).
Breno Rodrigues Guimarães