6.1 KiB
Native powered flight feasibility
This new WORKBENCH-only experiment uses the fixture pilot's native CharacterInputContext collective/cyclic/anti-torque inputs. It does not move an aircraft by setting velocity, angular velocity, transforms or angles, and does not copy original Escapists flight code. Native compilation and actual powered flight remain unverified.
This supersedes the earlier aircraft audit's overly broad suggestion that no direct flight controls were exposed. A search confined to vehicle controllers missed the character input layer. There is still no demonstrated stock helicopter route/landing AI activity, but actual script-callable flight inputs exist:
- Installed
scripts/Game/generated/Character/CharacterInputContext.c:94–107: vehicle throttle, collective, cyclic forward/aside, anti-torque setters and getters. scripts/Game/generated/Components/CharacterControllerComponent.c:82,473:GetInputContextandOnPrepareControls(owner, ActionManager, dt, player).scripts/Game/Character/SCR_CharacterControllerComponent.c:1009: real script override of that native preparation callback. The opt-in hook calls its superclass first, then writes only the exact fixture-owned AI pilot's inputs. Whether that native AI preparation phase occurs and its values survive until vehicle simulation is a central feasibility assertion, not an assumption.scripts/GameCode/Vehicle/SCR_HelicopterControllerComponent.c:72–94: native script callback normally reapplies global device preferences. A second opt-in hook calls its superclass, then changes only the exact fixture aircraft toCollectiveMode.Direct. It never changes global input/preferences. Its prior mode is restored when releasing an unclaimed test aircraft.scripts/Game/generated/Vehicle/BaseVehicleControllerComponent.c:46–65: normalStartEngineandStopEngine; force-start/stop are cinematics-only and excluded.VehicleControllerComponent.OnEngineStart/OnEngineStopconnects/disconnects native fuel consumption; actual fuel decrease is required.VehicleHelicopterSimulation: real rotor state/RPM/target;VehicleBaseSimulation: actual internal transform/velocity/ground contact. These are read-only feedback, not substitutes for control inputs.
Experiment
Core-only opt-in outcome powered-flight, -errBaseSmoke 1. A separate real vanilla unarmed Mi8 is spawned once on one of twelve bounded clear/flat candidate pads 120 m from the registered extraction aircraft. The real extraction aircraft and player are untouched. One stock USSR character (the already-resolved vanilla mortar crew character resource, not a claim of pilot-specific clothing) is created through the actual pilot seat's native SpawnCharacterInCompartment mechanism into its own initially empty USSR group. No HQ response system is involved in this flight-mechanism test.
Initial physics wakes once and must settle naturally. The probe waits for actual original pilot ownership/seat/one-agent group, real finite fuel and strict grounded readiness. It then requires both real native preparation hooks to run and native input readback to match. Only then it makes one normal engine-start request, waits for real engine/rotor spin and observed fuel use, and applies a conservative newly authored height/velocity feedback controller to native inputs.
The target is 8 m above the aircraft's initial resting origin; success requires 7–9 m altitude, no ground contact, bounded speed/tilt/drift continuously for five seconds, then descent through inputs only. Landing requires native ground contact plus low speed/angular velocity/upright attitude continuously for two seconds, followed by normal engine shutdown. Input bounds and feedback signs are experimental; wrong input mapping, missing callbacks, ineffective input application, drift or failed hover must produce a retained failure, never a physics-position correction. Native setters do not document full numeric/direct-mode semantics, so both response and tuning require native evidence.
The controller revalidates server/explicit opt-in, exact unclaimed pilot/group/active seat, conscious pilot, engine/rotor/airframe health and native fuel before writing. Any player aboard prevents writes. Terminal/failure cleanup clears hooks and only the same unclaimed pilot's controls, restores that aircraft's local collective mode without a crew lock. Leaving the seat fails authority. It never kills the engine in midair, deletes an airborne actor, stabilizes a falling aircraft, restores health, changes fuel or creates replacements. Test entities remain mode-owned for the explicit fixture reset/diagnostic inspection. Normal engine shutdown is requested only after actual landing. Capture/fuel/health gates exist but deliberate destructive variants and multiplayer ownership are not exercised in this first probe.
The run is bounded to 240 s after fixture creation (30 s preparation, 5 s callbacks, 65 s startup, 65 s climb/hover, 65 s landing, 15 s shutdown are subordinate maxima; total still wins). A fixture whose native startup consumes most of the total budget may fail rather than overrun. Base runner should allow 420 s including mission preparation. No UI/input emulation is used, and all scripts are excluded outside WORKBENCH.
Evidence limits and next work
Four local tests pass: exhaustive actual authority gate, actual bounded input/height/hover/contact-landing policies, and source guards against physical driving/global input/force-start/fuel-health mutation. They do not compile Enforce or prove native input persistence, cyclic signs, throttle/collective mapping or a flyable control law.
A native failure at the callback/input stage would identify a real integration blocker; a native failure during lift/hover requires reviewing logged actual inputs, RPM, internal position, fuel and motion, not relaxing success. No successful gate should be described as a full autopilot, route following, obstacle avoidance, HQ delivery, aircraft support acceptance or multiplayer proof. If takeoff/hover/landing works, the next independent layer is bounded attitude/position control and explicit loss tests before radio/HQ sortie integration.