Files
Viano-Core/doc/clientless/resumed-transport-passengers.md
T

3.9 KiB

Resume restored clientless transport passengers

Shanron140 retained native Bravery spawn2 attachment after restart but had no CPC ride state. The AdventureBot Lua controller now invokes ResumePassenger before supply/combat/intent actions while a restored exit is owned. Observation and population maintenance still run first. Active ordinary executor rides are never replaced. Dead/combat/pending teleport/taxi and unmanaged players are not adopted. Actual native attachment is required; no passenger is invented.

For an orphaned passenger, ensure stop and graph data are loaded; match a recorded stop to the actual native transport object/pointer, spawn and entry; enforce area/node/faction/level access. Seed a Resumed Riding record without reboarding, relocating, clearing schedules or changing attachments. Unrecorded/forbidden services are untouched. Failed ride records with an attached passenger can also be recovered this way.

While Riding, choose the first actual permitted recorded dock the vehicle stops at (deterministic node tie-break for coincident stops). Do not infer the original journey destination or force a detour back to the seed dock. Native AtDock checks map, position, heading and stopped state. Reuse deck return, stop-time budgets and the ordinary reversed recorded exit. No exit at subsequently denied stops. Native cross-map worldport ACK and transport copies retain the same service. The resumed controller keeps ownership through the land portion after passenger detachment, releasing it on Arrived/Failed so normal day planning can continue. Static tram passenger persistence itself is unchanged: this requires an actual restored/attached passenger, not merely a saved position in the tram tunnel.

Six focused tests passed: real transport methods now cover orphan adoption, no duplicate boarding, normal ride preservation, unmanaged/unknown/denied cases, first actual permitted dock, real exit completion, land-tail ownership and cross-map restored ships. Existing deck controller/native fallback/real mesh, transport grid and group travel tests also pass. Results /tmp/vcore-resumed-passenger-tests.json; final build log /tmp/vcore-transport-resume-final-build.log. Gameplay remains unverified until a later install/restart.

USER HOLD: the user is recording more routes. Do not install or restart now. Current running server349322 and its installed executable remain untouched; changes are source/build only. Existing uncommitted deck-return fallback work is preserved. No DB/profile/plan/action changes are required for this fix.

Final complete build succeeded (/tmp/vcore-transport-resume-final-build.log). Current server process349322 and installed executable timestamp21:00:04 were verified unchanged. Six test results remain successful, including the added land-tail check. Ready for later installation; user recording hold remains in force. No pending build processes or native gameplay verification.

Deployment after recording hold release

User authorized installation/restart. Installed prepared build successfully, log /tmp/vcore-transport-resume-install.log. Fresh PID356681 undergdb/tmux, console /tmp/vcore-transport-resume-start-20261029.log. Freshready12s, process persistence and8085/8087 verified. Known old OutdoorPvP shutdown destructor fault captured before full old process exit. Source/config/DB untouched by deploy.

Native login140 requested to inspect Shanron. Core transport restoration failed for savedGUID2 and moved him to homebind before controller activation. He then arrived at restlocation poi_guard_111 and executed rest micros. No manual position, profile or dayplan override. The new resumed-attachment branch could not be live validated on him because actual attachment was absent; automated tests remain the verification of that branch. Core missing-transport restoration is separate. Earlier no-install notes above record the completed hold, not a current ban.