Files
Viano-Core/doc/clientless/group-travel.md
T
Nico cac4142ec1
clang PCH / build (push) Canceled after 0s
GCC PCH / build (push) Canceled after 0s
Implement safe AdventureBot group travel and formations
2026-10-28 23:30:28 +01:00

6.1 KiB

AdventureBot group travel

AdventureGroupTravelMgr is the common local-follow owner for player-led and bot-led groups. Bot-led macro travel retains the existing shared TravelGraph route and flight trail; DungeonBot CreatureAI remains independent.

Formation and ground safety

Group members have stable GUID-ordered formation slots. Standing companions form a small staggered group. Moving companions form one, two or three columns according to checked walkable space; mounts increase spacing. Narrow/uncertain passages use one column. This estimates usable ground, not a semantic road width. Combat positioning and encounter avoidance retain priority.

Local following uses complete, unsuspicious MMAP paths. Phased floor samples along paths reject holes, large height discontinuities and unsupported ground. The same owner-supplied validator runs before every clientless local spline, including graph approaches/repaths, while the bot is grouped. Dynamic LOS is checked for the actual segments. A rejected path stops following and is retried; it does not itself trigger a departure or a teleport.

Recorded graph roads have an optional CPC GroundPathAdapter. The Adventure adapter checks bounded chunks, offsets safe lanes, falls back to single-file, and holds a row behind the moving leader. Edge point indices remain aligned; only an actually reached chunk endpoint advances the next road index. Native portal/boarding endpoints remain unshifted. Optional speculative road exits are disabled for adapted group roads so they cannot bypass the safety adapter. Ungrouped CPC navigation and unrelated scripts have no adapter by default.

Mounted leaders cause capable profile-defined followers to use their own ground mounts even on short follow legs. Nearby followers dismount when the leader is on foot. Ordinary long ground catch-up can also use profile mounts.

Flight

ClientlessFlightMgr::Follow adds a moving-target mode beside existing point flights. Native learned mounts/capabilities, area restrictions, casting and VMAP height/volume collision checks still decide whether flight is possible. Followers update their own formation target and fly bounded segments. Unknown terrain, blocked corridors or insufficient headroom cause a mounted hold. A moving aerial target is never treated as a ground touchdown.

On landing, kick, leader change/loss or excessive separation, a tracking flight lands on verified local solid ground or uses its checked reverse trail. It never removes flight at an unverified height. Own group flights are serviced before self-care/combat actions can replace their movement; death handling still runs for dead characters. Daily-plan date refresh continues while airborne.

Bot-led shared point flights preserve their native shared corridor and use staggered departures to form a single-file column. They finish a safe native flight leg rather than being cancelled in the air. Ground-only followers may follow safe projected ground points while the leader is no more than12 yards above them; greater height or missing ground paths makes them wait.

Known transitions and separation

The leader is observed independently of a follower's self-care or current taxi/ transport state. Taxi destinations use the final node of the native taxi queue. Ships, zeppelins and trams use recorded, matching native services. Fixed-destination SPELLCASTER GameObjects (including temporary portals with native DB destinations) and native AreaTrigger portals are recognized from the actual source and arrival. Bots approach and use the native handler/object; destination teleports are not fabricated. Per-follower queues retain consecutive transitions for late arrivals. Unknown/script-selected portals are not guessed; existing graph routes may still provide a valid way to the known destination.

Player-led groups accumulate a separate10-minute timer beyond500 yards (3D, or separated maps/instances). Coming within500 yards resets it. A missing path alone never advances a special leave reason. Existing combat/death/instance/ transport departure guards apply, and an airborne bot lands before leaving. Pure bot groups retain their previous late-rendezvous rules.

Known actual journeys, own native taxi/transport travel and recorded transport recovery pause separation. Arrival has60 seconds of grace. Further catch-up stays protected only with route execution and recent physical progress; this does not extend unrelated later ground separation. Journey protection is bounded to30 minutes. The ordinary AFK/hour-change departures are deferred during protected travel. No travel marker grants unlimited protection after a failed route.

Lost transport passengers

ClientlessTransportMgr detects loss of an actually boarded recorded service. It retains the ride and attempts a complete, unsuspicious return path to that ride's recorded departure node. A missing/rejected/stuck path, cross-map loss, or a return that has not completed within60 seconds allows a targeted teleport to that same known safe entry point. It never teleports toward the leader or forward to the destination. The next service is boarded normally. Repeated losses are bounded; after three recoveries the ride terminates safely at departure. Ordinary death/resurrection remains owned by combat handling.

Services require valid recorded boarding/alighting transitions and native graph connections. Missing service/portal data causes waiting or route failure rather than invented passenger attachment or a general catch-up teleport.

Diagnostics and validation

clientless interaction <guid> reports formation travel ownership, separation milliseconds, protection, flight, queued transitions and route detail, alongside the existing group/interaction state.

Automated tests exercise the production formation/ground validation, widths, mount choice, flight and kick landing, taxi grace, sequential portals, bounded separation, recorded-road adapters and native transport-loss return paths. Flight adapter tests exercise real corridor geometry and moving-target/landing decisions. Compilation and these adapters do not constitute visual in-game acceptance of player taxi, portal, flight or deck movement.