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

96 lines
5.6 KiB
Markdown

# 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.