6.7 KiB
Native error investigation, 2026-09-19
Read-only investigation of installed vanilla assets, their actual script implementations, and successor archived runtime logs. No engine launched, installed resource altered, existing mission edited, or logs suppressed.
Seven vehicle schema errors: actual source identified
The 04:12:33 two-round early-helicopter-loss archive traces all seven errors to faction resource initialization, before GameMode initialization. See docs/evidence/native-2026-09-19-041233/console.log.txt lines 265–290 in the successor repository.
| Count | Source asset, extracted line | Invalid property | Logged offset |
|---|---|---|---|
| 1 | Prefabs/Vehicles/Wheeled/M151A2/M151A2.et:548 |
SCR_VehicleDustPerWheel.SlidingTrackMaterial |
19441 |
| 2 | Prefabs/Vehicles/Wheeled/BRDM2/BRDM2_base.et:1044,1068 |
Wheel.Parent |
35955, 36915 |
| 4 | Prefabs/Vehicles/Wheeled/BTR70/BTR70_Base.et:1273,1307,1340,1373 |
Wheel.Parent |
42646, 43645, 44617, 45590 |
Correct previous attribution: the SlidingTrackMaterial error is M151A2, not Mi8. The load chain is FactionManager_USxUSSR → M151A2_M2HB_MERDC → M151A2_M2HB → M151A2. The six wheel errors load through BRDM2_Conflict and BTR70_Conflict variants. Actual extracted property byte positions match the logged parser offsets (the error points just after the keyword).
Installed scripts/Game/Vehicle/SCR_VehicleDustPerWheelComponent.c declares no SlidingTrackMaterial attribute in either its class-data or component class. This is an actual mismatch between installed vanilla resource data and script schema. M151's field concerns wheel dust/track appearance; it is not an extraction seat or flight setting. The BRDM/BTR fields concern wheel differential parent references; do not call them harmless without vehicle-driving validation. Engine internals for the Wheel type are not script source, so the exact replacement field is not established here.
There is no justified successor code change that repairs these installed base-prefab fields. Adding dummy script attributes, overriding a global vehicle base asset, or excluding errors from the parser would hide the failure rather than validate compatibility. An independently authored narrower faction catalog may eventually avoid loading unneeded vehicles; that would need intentional catalog scope, inherited reference removal, and a real native test. It would not establish those vanilla vehicles as compatible. Keep clean-runtime acceptance failed in the meantime.
Intermittent resupply error: teardown validation path exists
The same archive emits exactly two SCR_BaseResupplySupportStationComponent needs a entity catalog manager! errors at 04:13:53.548/.553, immediately before Starting new playthrough at .653 and before the new world's entity load. They do not occur during that round's startup/play assertions.
Actual class name is SCR_BaseItemSupportStationComponent; the printed class name is stale in vanilla source. Its InitValidSetup at line 30 reads cached m_EntityCatalogManager and prints this error if absent. DelayedInit at line 17 obtains the manager using SCR_EntityCatalogManagerComponent.GetInstance().
Crucially, SCR_BaseSupportStationComponent.OnDelete at line 1187 also calls virtual InitValidSetup() before unsubscribing damage/support events. Thus teardown after the catalog manager has been destroyed can produce the same error as bad initialization. The successor already inherits SCR_EntityCatalogManagerComponent through GameMode_Base.et:58; adding a second manager is incorrect.
Inference requiring a diagnostic runtime test: dependent support-station deletion occurs after the old round's catalog manager is gone, invalidating the cached reference. The archive timing plus actual OnDelete implementation supports this explanation, but the logs do not name the station owner or call site, so they cannot yet prove it. A delayed-init callback crossing teardown is another possibility: vanilla EOnInit queues DelayedInit, while OnDelete does not explicitly cancel it.
The opt-in WORKBENCH diagnostic is ERR_NativeStationTeardownDiagnostic, enabled by --station-teardown-diagnostics. It logs station owner/prefab, OnDelete entry and manager availability before calling super unchanged, capped at 64 lines. A two-round restart is required to observe this teardown path. Do not guard-return the error away. If the deletion ordering is confirmed for successor-owned site assets, arrange their disposal in an explicit pre-restart lifecycle step while the game mode manager still exists, and verify site cleanup, extraction result retention, startup rollback, and two restarts. Do not delete extraction occupants or their helicopter on ordinary victory merely to silence teardown.
Only if source-level teardown correction is necessary should an addon-scoped class fix be considered: initialization must still reject a missing manager during play; OnDelete should cancel its pending DelayedInit and release subscriptions based on what was actually initialized, instead of revalidating destroyed dependencies. This is larger and needs full native lifecycle checks, so no untested override is supplied as a fix.
Installed runtime / dedicated server inventory
The inspected log reports Workbench engine 192142 and game version 1.8.0.13, built 2026-08-21 14:30:18 UTC. Steam manifests currently report game build 24903726 and Tools build 24870687. Those are separate app build IDs and by themselves do not prove a version mismatch.
The single configured Steam library is /home/jakub/.local/share/Steam. Read-only filename inventory of its installed common directory, /home/jakub/devel, /opt, and /usr/local/bin found no ArmaReforgerServer/ReforgerServer/server executable. The installed Reforger runtimes are Windows client and client diagnostic executables, plus Workbench. There are Arma 3 server executables, which are unrelated. Experimental game/tools are installed but were neither opened nor changed. There is no local dedicated-server executable established for the successor's required dedicated/network test.
Source extraction hashes are in the audit manifest. Extractions in /tmp/erri-vanilla came directly from the installed Arma Reforger data PAKs through the existing read-only extractor.
Observed diagnostic restart
050515 completes two Core rounds. At05:08:52 the opt-in diagnostic identifies the US and USSR medical-kit prefabs in the OnDelete/InitValidSetup path. Both cached and global catalog references are still valid, while the current game mode is absent. No catalog error occurs. This confirms the relevant teardown call path but does not reproduce the missing-manager condition; the intermittent issue remains open.