Measure door contact as an overlap, not a radius

[saworbit]

Shane's e1m2 session lost 35 s of 157 to five freezes in one cell. Each began with an ARGEVT door, held spd 0 at an identical position with yaw locked, ran to the 8 s give-up, abandoned, re-routed, and came straight back.

The defect

The door handler decided it was touching its opener when the opener's centre was within 40 units, flattened in z, and then stood still to be touched.

An opener is a brush, not a point. e1m2's t120 door is fired by a trigger 110 wide and 6 thick. Standing at 442 -119 254 put the bot 38 units from that centre, inside the radius, while its own box still stopped 18 units short of the volume. So it froze waiting for a touch, and the engine only fires touch on movement, so the touch could never arrive.

Same deadlock as the v3.43 lift statue: a parked bot cannot summon the thing it is parked for.

The fix

Argus_TouchingBox compares our absmin/absmax against the opener's, the same boxes SV_LinkEdict uses to decide a touch, with 2 units of slack so a solid func_button pressed against still counts.

While the overlap is false the bot keeps walking in, which is what fires the trigger. By the time it is true, the movement that got us there has already fired it, so the existing near-door hold stays safe. The 8 s give-up remains as a backstop.

Ladder

e1m1 co-op is the only map in the tree whose botmatch drives the door path hard. It is bimodal: the companion either reaches the door area or never leaves the start pocket, which happened once in three tapes on both arms. On the four tapes where doors actually ran:

	freezes	worst freeze	stalls	cells
control	6, 6	13.4s, 16.9s	87, 85	25, 28
fix	2, 4	8.2s, 8.8s	47, 61	29, 28

The worst-freeze figure is the mechanistic one. 8 s is the door give-up, and the control exceeds it because the bot re-enters the hold the moment it is released; with the overlap test the give-up actually bounds it. Every freeze in both arms sits within 70 units of func_door *38, so the cell being measured is a door.

What the other maps can and cannot say

dm2, three tapes a side, is parity and shows no regression: cells 90, 95, 130 against 113, 94, 70; stalls 216, 101, 20 against 100, 19, 114. It carries 28 door links of 1082, so door traffic is 2.6% of movement and it can only ever show absence of harm.

Recorded deliberately: the first dm2 pair looked like a large win, stalls 216 to 100 with door events 4 to 33, and did not reproduce. dm2's control alone swings 20 to 216 stalls on identical code.

dm4 unaffected: stalls 7, cells 70, no freezes, no door links.

e1m2 cannot test this at all. Its botmatch logs zero door events in every tape, because without a human in the level the companion never routes through that door. Shane's session logged eleven. His next e1m2 run is the real verification.

Residual

e1m1's door cell at 1072 1072 -248 still freezes two to four times a tape, bounded by the give-up. Halved, not cured.

Refs #249

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.