4.5 KiB
Shared-flight landing and continuity fix — 02.11.2026
User observed followers turning away above the Bastion platform and repeated pauses in flight. No group-refill policy changes are part of this fix.
Root cause
09:34:53: leader Winienwi163 walks8yd to open takeoff column. His prepared Flight Record already has Target but does not have a validated Landing yet. 09:34:55: followers166/159/161 attach to the leader trail BEFORE the leader's landing-search result is published. Old Begin copied Status.Landing immediately, which at this phase is the default zero Position. The shared pointer to the trail survives preparation, but the copied landing never updated. 09:37:33: leader lands correctly at827.765625 and subsequently enters instance2. 09:37:49..52: followers reach the hover point837.765625. The zero-goal corridor retains the8yd safety floor margin at the true touchdown and rejects descent. Fail() therefore starts a checked breadcrumb return; this is not a successful arrival or a deliberate new destination. Evidence root-cause-evidence.jsonl.
Implementation
SharedTrail now publishes Landing and LandingReady. Begin does not copy the leader's potentially uninitialised Record Position. Advance binds the validated landing from the shared object, waiting for publication if preparation continues. Followers retain a shared object even after the leader leaves for the instance. Native attachment logs now include landingReady.
For continuity, handoff begins while up to1500ms remain rather than600ms. Followers may advance to the next published endpoint before stopping at the old endpoint, but only if the complete shortcut corridor is clear. Escape-leg corners are retained. Aborted trails still fail closed. Explicit shared-reject diagnostics include index, point count, abort flag and effective landing.
Eight targeted tests PASS. New regression reproduces the zero-goal terminal failure, exercises the real Advance landing-binding prefix with delayed publication, tests terminal descent, early running handoff, blocked corners, escape legs and aborted trails. Existing ordinary/elevated flight, native handoff, group follow, policy, landing search and terrain tests retained.
Build and recovery
Build-j10 and install PASS. Safe logout requested09:49:23.822668; configuration loader0 initially did not stop the cached loader. Explicit population reload then confirmed enabled0 (loader-paused.log). This pause correction happened after the build had begun and is documented rather than treating the earlier pause as verified. Before installation, the full five-minute drain elapsed. Remaining14 bots, positions, native available flags and diagnostics were preserved in final-remaining.json / final-remaining-native.log / last-available-remaining-flags.json. Five-minute exception allowed clean server shutdown; no individual forced logout or flight interruption was used to install. Process/tmux absence verified before install. Fresh startup ready PID258518, ports8085/8087 verified.
Original ten-bot test evidence preserved. Only ten test bots' previous handoff and instance-visit records were backed up and cleared to start a fresh run; all ten natively teleported offline to the Golden Rose, reloaded, slots09formation and 10raid6354_d0 applied. Complete group1, leader163, all ten confirmed. Normal loader restored (including explicit population reload); all14 recovery bots requested login. Moving native taxi/flight actors left intact. Six unsupported stationary actors74/77/91/93/102/121 received native capital recovery after login checks; post-restart-native.log and recovery-capitals.log preserve findings/results. Temporary GM teleport destination removed and cache reloaded. No production use. Live result of the new10:00 run is recorded separately below when available.
Live follow-up limitation
10:00 retry remains a complete ten-bot group led by163 with unchanged raid goal. The initial route now stalls on the separately known ground safety issue: native MMAP taxi_2 -> stormwind_tradecenter is complete (path189.55yd) but execution returns PathRejected. Repeated departure approaches are interrupted. The group has not reached the tower again as of10:02, so this run does NOT prove the final follower descent or visually smooth flight. New landingReady=1 attachment and short native flights were logged, but they are not a substitute for that proof. All110 bots online, loader enabled1, original group still intact. Existing observer remains active until11:00; no automatic chat report is promised. The next independent blocker is the local ground safety/recovery behavior.