The human on the race paths
2026-10-24, fifth session on the race rules.

The picture: Beltane's race paths (Gold, EASY) drawn by our track decoder, with 5,000 of the 20,000 cases the game's follower ran under the emulator. Un-POD's port gives the same answer in every one.
What was tried
The computer cars move along the race paths through their controller. The player's car does it through a function of its own, which Gold's race loop runs once a frame: FUN_004c688c (FUN_004d09bc in the first edition). It keeps the player's place in the race order between gates. It also counts the frames the car goes the wrong way and sets a bit in the race record while it does. The replays had masked that bit until now.
It is about 3.6 KB of code and calls three searches that were not ported yet:
- putting a tracker back on the paths (
FUN_004aa8a0, ported in the last session); - looking for a place where the path folds back near the car (
FUN_004c6854); - normalising a vector (
FUN_00423bc0).
Each one was ported and run against the game under Unicorn before the follower itself.
What was found
- The fold search walks a few points forward and back from the tracker, down each branch of a fork. It looks for a point where the path has turned back near the car. 2,000 to 20,000 cases per track all match (measured).
- A Gold rule corrected. After a link's last point, Gold's "next point" is the end node's place when several links leave it. The code works out the mean of their first points and then overwrites it (0x4abbf5). The port had kept the mean. The fold search showed the difference on the sixth Beltane case. The tracker tests had never reached it.
- The follower waits until the car has moved 10 units. Then it may put the tracker back on the paths: at forks, when the car is more than 8 units above or below its point, or when it is far off the path. A wait of 6 runs keeps that from happening every frame. Four votes then decide the way: the car's movement along the two steps into the tracker's point and the two out of it. The bit is set when the car is more than 30 units the wrong way along the path, measured on the flat. The original drops the step's height before that test (0x4c6dd4). The port kept the height at first, and case 55 of the first 300 showed it.
- A test that can never pass. One branch compares two squared distances, both 32-bit integers, with a double of about 1.07 × 10¹³ (0x4e8ff5). Their difference can never reach it, so that branch never puts the tracker back. The port keeps it as written.
- 20,000 cases on Beltane and 5,000 on Azthec match the game in all four results: the tracker, the follower's state, the record's word 0 and its byte +4 (measured,
measure/race_paths.py, thehumanset, with the game's start-up tables built first).
The follower sits in pod-ai (pod_ai::human_path), next to the controllers whose lookup tables it needs.
Later: a fourth race
Race-loop recorded a whole race on FACTORY (five laps, EASY), hoping to reach the results screen. The player's car stuck on its fourth lap, so the recording stops with all seven computer cars finished and no final records. The replay now takes such a recording: every one of its 14,450 samples and 14,285 order pairs matches the game. Without the final records, a car's first lap-line crossing takes the frame its positions give it.
A second try on Beltane (three laps) stuck too, on lap 2, but its recorder wrote the final records when its time ran out. That race matches as well: 23,509 samples, 23,407 order pairs, and every word of the eight records at the end.
What is next
- The reference replays still mask the bit. The follower runs every frame, and the recordings hold ten positions a second. pod-race's tests also cannot call pod-ai. A Gold recording with every frame's position would let a replay run it.
- Who reads the wrong-way count and the bit: the HUD's "wrong way" sign, most likely (inferred, not yet traced).
- The results text, once a Gold recording reaches the results screen (a shorter track next).