e1m6 co-op companion stalls all match at n93, a waypoint seated 14 units past a lava pit lip

[saworbit]

What happens

A co-op companion on e1m6 never gets going. It parks and jumps on the spot for the whole session.

Three tapes, 175 s each, one bot, +coop 1 +deathmatch 0 +skill 1.

build	cells	busiest cell	stalls	goals	routefails
binary d88ba69	13	63.4%	220	3	9
main a7d49cf	14	60.2%	213	3	17
main a7d49cf, repeat	14	59.7%	200	3	14

The behaviour is the same on both builds, so this is not the recent water work.

Telemetry from the main tape: mode 0 on 310 of 327 samples, 91 per cent of samples under 20 u/s, and spd 0.0 with z bouncing between 24 and 62. That is a stall recovery jump cycle in place. The tape holds 213 stall events and 215 jump events. The bot sits at 368 576 50 for the first minute, then at -176 496 47 for the rest. It never dies.

The graph is not the problem

Directed reach is 85 per cent of 198 nodes from all four spawns and from both pin cells. Both keys have a node close by. The gold key at 224 120 56 has n127 at 209 113 56, 17 units away. The silver key at -696 1280 -232 has n16 29 units away.

The companion does commit to the key. The tape holds ARGEVT Carmack goal key and routes of four to six hops to goal 209 113 56.

Root cause

Every stall names the same steering target.

ARGEVT Carmack stallnode '-207.0 305.0  24.0'

That is n93, src/argus_nav_e1m6.qc:297.

A fine floor probe at y 305 puts the ledge lip at about x -193. World floor is -2 at x -191 and east of it, and -306 at x -195 and west of it. n93 sits at x -207, so it is 14 units past the lip.

The column under n93 is solid to -304, lava from -304 to -128, then empty. n93 floats 152 units above the lava surface.

The node is not arbitrary. It sits inside the footprint of brush model *51, a func_door with angle -1 so it rises, and wait -1 so it stays open. Its closed bounds are mins -415 241 -495 and maxs -193 463 -233. Its size_z is 262, so with the default lip of 8 it travels 254 and its top lands near z 21. That matches a waypoint at z 24. The door is fired by targetname t52, which a trigger_once reaches on a 3 second delay.

So n93 is a seat on a rising platform. It is only real once that platform is up.

navgen does not model this. func_plat gets lift links at tools/argus_navgen.py:616. func_door is only read for door AABB typing at tools/argus_navgen.py:1038. A func_door used as a platform is not modelled at all, so the hop into n93 is minted as an ordinary walk link.

The bot routes onto that walk link, walks to the lip, and the hazard guard correctly refuses to step into lava. It stalls, jumps, re-plans, and repeats for the whole match. Nothing is wrong with the guard. The link is a lie.

A second defect on the same link

n94 -207 529 24 to n93 is minted twice. It appears in links as a walk link and in jlinks as a jump link, in both directions.

The pair is 224 units apart on the same z. JUMPREACH is 190 at tools/argus_navgen.py:88 and is applied at line 284, so a 224 unit jump link should not exist. There is also a 64 unit step between the two nodes at y 449 to 465, and then the pit.

Suggested work

1. Refuse to seat a waypoint past a ledge lip when there is no world floor within a step, unless the sample stands on a mover navgen actually models. That alone removes n93.
2. Model vertically travelling func_door movers the way func_plat is modelled, so the hop is typed and the runtime waits and rides. e1m6 needs this to be playable at all, and other id maps use the same trick.
3. Enforce JUMPREACH on jump links, and stop a pair being minted as both a walk link and a jump link.

Short term, e1m6 is not co-op ready. Stripping n93 and its links would stop the stall loop, but the level still cannot be finished until the rising door is modelled, because that platform is the way across.

Also seen

The tape prints this once at spawn, before the first goal is pushed.

ARGUS coop key fail: NO_RIPPLE / KEY_UNCLAIMED

The bot commits to the key later in the match, so this looks transient. Noting it here in case it is separate.

Repro

cd C:\argus\engine
.\quakespasm.exe -dedicated 8 -basedir C:\argus\engine -game argus -condebug +developer 1 +coop 1 +deathmatch 0 +skill 1 +map e1m6

[saworbit]

Correction to the root cause above

The door is not the cause. The arithmetic does not fit. Door *51 opens to a top at z 21, which would seat a waypoint near z 45, not 24. It happens to span that xy and that is all. I got this wrong in the first write up.

The real cause is hull 1.

navgen samples hull 1, the player clip hull. See column_floors at tools/argus_navgen.py:123, which uses HULL1. A clip hull is the world expanded by the player box, so its floor reaches half a player width past every real ledge edge. Measured along y 305:

x	hull 1 floor, what navgen samples	hull 0 floor, the real world
-223	-280	-306
-215	-280	-306
-207	24	-306
-199	24	-306
-191	24	-2
-175	24	-2

The true lip is at about x -193. hull 1 reports standable floor at x -207 and -199 because the ledge is expanded 16 units west. n93 sits out there, over a 304 unit drop, with lava at -128.

The engine does not agree with hull 1. SV_movestep calls SV_CheckBottom, which point traces the box corners against the world, so walkmove refuses the step. Argus_MoveHazard refuses it too. That is why the bot stalls and jumps rather than falling in and dying.

The second defect is not a defect

jlinks is a typed overlay on links, not a separate list, so a pair appearing in both is normal. On e1m6 all 32 jump links and all 134 door links also appear in links, while lift, rocket and sprint links do not. JUMPREACH governs the fine jump edge, not the length of the waypoint link whose path crosses it, so a 224 unit waypoint link tagged as a jump is by design. Withdrawn.

Not specific to e1m6

Every shipped map carries these seats. Waypoints whose real floor is more than 96 units below the hull 1 floor they were sampled from:

e1m1 20, e1m2 22, e1m5 7, e1m6 32, e1m7 25, e1m8 6, dm2 12, dm3 39, dm4 15, dm6 18.

Fix

navgen now runs the engine's own test. A new section 4c applies SV_CheckBottom against the world, with the same constants and the same order. Corners solid just under the feet is the fast accept. Otherwise the midpoint must find floor within 2 * STEP, and every corner must sit within STEP of it.

On e1m6 that drops 536 lip overhang samples.

	nodes	seat by the lava lip	seats over a 96 unit void	worst spawn reach
before	198	-207 305 24	32, 11 of them over lava	85%
after	188	-175 305 24	0	95%

The seat moved onto real ledge instead of disappearing, and reach improved.

Other maps are not regenerated here. Their graphs are accumulated and tuned, so each wants its own ladder.

Still open, separately

navgen does not model a func_door used as a rising platform. func_plat gets lift links, func_door is only read for door AABB typing. e1m6 cannot be finished without riding *51, so that remains real work. It is just not what pins the bot.

[saworbit]

Second correction: modelling the mover would not fix this either

I said above that navgen not modelling a func_door platform was still real work. It is, but it is not the fix for e1m6, and it is worth being exact about why before anyone spends a session on it.

The seat filter in #250 removes n93. That also removes the only route the old graph had to the gold key, because that route crossed the lava pit through n93. So the failure mode changes rather than clearing: routefails go from 9 per tape to 400, coverage from 13 cells to 9, while stalls fall from about 210 to about 5.

The crossing is func_door *51. It has angle -1 so it rises, and wait -1 so it stays up once open, and it is fired by targetname t52 which a trigger_once reaches on a 3 second delay. In a botmatch nothing fires that chain, so the bridge never rises and the crossing does not exist at runtime. Seating waypoints on its raised top would recreate exactly the same lie 21 units higher: a seat no bot can reach, on a surface that is not there.

So e1m6 needs level progression handling, not mover geometry. A bot has to reach and fire the trigger chain that raises the bridge. That is much larger work than this issue implied, and it is the same family as #119.

Also tried and reverted

A routefail shelf on Argus_CoopCommitKey, mirroring the ar_failtime rule Argus_PickGoal applies to every other item. It looked like the obvious cure for the storm and it is not: the 400 routefails come from the goal already sitting on the co-op goal stack, not from re-commitment, so the guard changed nothing on e1m6 (401 and 403 against 400 and 377) and cost e1m2 routefails 0 to 77 and stalls 40 to 73. Reverted.

The real cure is popping a co-op FETCH goal after repeated routefails, in the goal stack layer. Worth doing on its own, because an_busy serialises the router and one bot failing twice a second can starve the others on a populated server.

[saworbit]

Status

Two fixes merged against this issue. e1m6 is still not co-op ready, so it stays open.

#250, the seat. navgen now runs SV_CheckBottom against the world instead of trusting hull 1's expanded floor. n93 is gone and the seat relocated to -175 305 24 on real ledge. e1m6 worst spawn reach 85 to 95 per cent, seats over a 96 unit void 32 to 0. Stalls fell from about 210 a tape to about 5.

#251, the storm. Removing the fake seat removed the fake route, and routefails went to 400 a tape because the GOAL_FETCH branch re-adopts its subject every think while Argus_AI clears ar_goal on every failure. A routefail on the current fetch subject now rests that bot 20 s, per bot rather than on the global item shelf. Routefails 400 and 377 to 8 and 9, coverage 6 and 9 cells to 23 and 22, busiest cell 57 per cent to under 10.

Together the companion stops being parked and works the map. It still cannot finish the level.

What is left

The gold key sits behind func_door *51, which rises on a trigger_once chain and stays up. In a botmatch nothing fires that chain, so the crossing does not exist at runtime and the key is genuinely unreachable. That is level progression work, not geometry, and it is the same family as #119. A bot has to reach and fire the trigger that raises the bridge.

Until then e1m6 co-op degrades honestly rather than wedging: the objective rests, the bot shops, and the router is not hammered.

Reverted along the way, so nobody retries them

• A swimmer reach ceiling measured from the water surface. Offline it looked decisive, dm3 drag-down 45 per cent of wet samples to 0. It readmitted 1585 1185 208, the exact seat the graveyard entry names, because that seat and dm3's lip both sit 36 above their surface. No height rule separates them.
• A reach test on the Argus_NearestNode fast path. A real hole, the neighbour loop applies no reach test and returns early at 120 units, but it cost e1m2 co-op half its coverage, 55 cells to 24 on two tapes.
• A routefail shelf on Argus_CoopCommitKey. It patched re-commitment when the retries come from the goal already on the stack, so it changed nothing on e1m6 and cost e1m2 routefails 0 to 77 and stalls 40 to 73.

Measurement note

e1m2 co-op read 31 and 50 cells against 52, 55 and 55 on code that provably cannot behave differently there, since both tapes log zero routefail events and the guard only fires on one. Single co-op tapes cannot settle a coverage question on that map. e1m2 also carries a pre-existing 6 to 8 second freeze class; the shipped build's own tape has one.