Files
Viano-Core/doc/clientless/flight-departure-repair.md
T
Nico 54d77d1e4d
clang PCH / build (push) Canceled after 0s
GCC PCH / build (push) Canceled after 0s
Fix AdventureBot group preparation, public portals and flight recovery
Add preparation outings and equipment checks with a five-minute return to the meeting point. Correct static portal visitor casting and level conditions, with native interaction diagnostics. Recover suspended flying mounts, walk to verified takeoff sites, and validate landing and return volumes. Include SQL migrations, targeted regression tests and live validation checkpoints.
2026-10-29 18:21:43 +01:00

5.6 KiB

Flight departure repair (2026-10-29)

Reproduced failures

Read-only native probes showed two distinct cases on map530:

  • Brynli84: position3358.734/1369.172/514.129, upper surface504.148, nearby-feet query no valid supporting surface, mounted1/canFly1/flying0. This is an already suspended native flying mount, not a ground departure.
  • Tholgar92: position-3650.900/316.897/35.852, upper surface48.203, feet surface35.852, mounted0/canFly0. The sky-down query selects an overhead layer rather than the actual supporting floor.

Neither case had liquid present; the raw-water possibility was excluded by native GetLiquidStatus. The existing cruise/landing surface sampling stays unchanged. A missing height/collision map is still a hard rejection.

Changes

An existing learned profile flight mount can resume in a verified airborne volume above the cruise surface and below the ceiling. The existing aura is retained, no dismount/remount is performed. For an emergency breadcrumb return, the ground below or within40yd of a resumed hover is used only after the complete descent column and the flight corridor from the hover pass collision checks; a hover point itself is not claimed as a supported landing. New splines still require the normal volume collision, catalog and clearance checks. A ground mount, falling player, missing surface, ceiling penetration or unknown mount cannot use this recovery.

A grounded visitor under an upper layer must have support within3yd using a bounded query from feet+2. Search nearby open takeoff candidates at8/16/24/40yd, with native vertical volume rays (center plus four2yd offsets), allowed area segment and complete local MMAP route (<=80yd, maxsegment8yd, maxheightstep4yd, endpoint<=1.5yd, no suspicious path). Use the existing local travel manager to walk there. Flight remains in mounting status during this approach but does not cast the mount until real arrival. Interrupt/death/map change/timeout cancels local travel; stale arrival away from the chosen point is rejected. Shared flight trail identity survives the approach. No teleport, forced elevation, disabled collision or invented ground surface.

Departure failures blacklist all flight targets from the same route source for this action's recovery rather than trying five targets from an unchanged source. Ground travel and departures at other nodes remain eligible.

A short final landing step may descend directly to the target when already in flight, within25yd total distance and at most12yd above the landing. The entire native collision/terrain volume must still pass Corridor; high approaches and obstacles retain the existing avoidance logic. This prevents the observed near-ground back-and-forth approach. Touchdown confirms the real support surface from feet+2 (6yd VMAP search), not the sky-down upper floor; the body ray must be clear before dismounting, including on breadcrumb return under an overhang.

clientless flight probe guid x y now includes actual player position, bounded feet height, raw water and native liquid status, mount/flight/falling flags.

Validation

Eight targeted tests passed, including production departure admission and open MMAP search with deterministic layered terrain, mount retention, blocked paths, cliffs, unsupported players and abort cancellation. Real planner test checks source-wide flight exclusion while retaining a ground alternative. Update tests wait for actual ground arrival and reject stale completion before mounting. Existing flight geometry, handoff, group follow, terrain fallback, catalog and native flight eligibility regressions also passed.

Final build /tmp/vcore-flight-safe-return-final-build.log and install succeeded. Latest testserver PID317961, gdb/tmuxvcore-worldserver, console /tmp/vcore-flight-safe-return-final-start.log. Fresh ready and8085/8087 listeners verified. No persistent bot profile, plan or position changes were used for flight validation; native logins requested for84/92 to observe normal behavior. Live outcome is recorded separately in the checkpoint. The pre-existing OutdoorPvP shutdown destructor crash remains separate and was preserved.

Landing candidates and emergency return anchors now use the same five-ray open column check as takeoff candidates, up to the requested clearance within native ceiling limits. This avoids selecting a narrow landing center whose surrounding mount volume is obstructed. Ground return for resumed hovers is never assumed without that column check.

Safe return-anchor search checks0/8/16/24/40yd radii, at most80yd spatial distance, native open landing volume, area eligibility and full Corridor from the resumed hover. A blocked column below the hover can therefore use a nearby checked ground point; unknown/unreachable points do not authorize a landing. Cancelling the takeoff ground approach does not interrupt unrelated combat casts.

Final live result

At18:17:06 Brynli84 resumed the native flying mount and selected a verified return landing near the former hover. At18:17:12 the normal requested flight landed (54.32yd,3segments,zero avoidances); executor confirmed portal_at_4455_target free_flight edge completion with recovery0, then continued its route. Tholgar92 used a real8.18yd MMAP takeoff approach in the preceding run and subsequently completed longer flight legs. The final build resumed his native flight and completed396.61yd/19segments/zero avoidances at18:17:44. See final-live.log. No final dungeon/raid destination or visual in-game acceptance is claimed from these intermediate leg checks. Profiles/plans unchanged; server remains online with normal staged population. No commit or push.