The e1m2 co-op companion pins in water and stays there for the rest of the match. It happens in roughly half of all e1m2 co-op tapes, on every build measured including current main, and #248 did not fix it.
Signature
Worst example, from a 175 s tape on the seat-filter build:
top cell '1624 1104 148' holds 327 of 341 samples (96%)
mode 0 on 338 of 341 samples
328 of 341 samples under 20 u/s
701 swim events, 234 stalls, 4 goal pushes, zero routes
The bot sits at the surface bobbing. ARGEVT swim is edge triggered on water entry, so 701 events in 175 s means it is crossing the surface about four times a second, which is the swim bob skimming a shallow surface.
It is not rare
Cells covered in a 175 s co-op tape, across builds:
| tape |
build |
cells |
busiest cell |
| e1m2_ctl2 |
pre water fix |
52 |
21% |
| e1m2_fix2 |
water fix |
55 |
31% |
| e1m2_nav1 |
seat filter |
55 |
27% |
| e1m2_new1 |
fast path |
24 |
86% |
| e1m2_new2 |
fast path |
24 |
90% |
| e1m2_dfix2 |
door fix |
21 |
43% |
| e1m2_allyfx |
ally guards |
6 |
96% |
Bimodal. Either the companion works the map at 45 to 55 cells, or it pins at 6 to 24. Nothing between. The pin is not attributable to any of those builds: it appears on all of them, including the ones whose changes are provably inert on the tape in question.
Why #248 did not cover it
That fix addressed a swimmer steering at a node above the water it could not reach, which is mode 2 with a route. This is mode 0 with no route at all and no goal, four goal pushes that never became routes, and 234 stalls. Different failure.
Notes for whoever picks it up
The 20.2 s human session on 2026-09-05 shows the same swim rate, 33 events in 20 s, so it is not a headless artifact.
Do not judge a fix for this on one tape. The bimodality means a single good tape proves nothing, and this issue is itself the evidence for that: two of the builds above look terrible on one tape and fine on another.
--what water and --what swim in tools/argus_pointfile.py draw the underwater seats and the swim exits, which is the fastest way to see what the bot has to work with at that spot.
The e1m2 co-op companion pins in water and stays there for the rest of the match. It happens in roughly half of all e1m2 co-op tapes, on every build measured including current main, and #248 did not fix it.
Signature
Worst example, from a 175 s tape on the seat-filter build:
The bot sits at the surface bobbing.
ARGEVT swimis edge triggered on water entry, so 701 events in 175 s means it is crossing the surface about four times a second, which is the swim bob skimming a shallow surface.It is not rare
Cells covered in a 175 s co-op tape, across builds:
Bimodal. Either the companion works the map at 45 to 55 cells, or it pins at 6 to 24. Nothing between. The pin is not attributable to any of those builds: it appears on all of them, including the ones whose changes are provably inert on the tape in question.
Why #248 did not cover it
That fix addressed a swimmer steering at a node above the water it could not reach, which is
mode 2with a route. This ismode 0with no route at all and no goal, four goal pushes that never became routes, and 234 stalls. Different failure.Notes for whoever picks it up
The 20.2 s human session on 2026-09-05 shows the same swim rate, 33 events in 20 s, so it is not a headless artifact.
Do not judge a fix for this on one tape. The bimodality means a single good tape proves nothing, and this issue is itself the evidence for that: two of the builds above look terrible on one tape and fine on another.
--what waterand--what swimintools/argus_pointfile.pydraw the underwater seats and the swim exits, which is the fastest way to see what the bot has to work with at that spot.