Ordinary splash startup audit

Source audit and independently verified control evidence, 2026-09-19. The audit itself launched no engine and changed no installed assets. A subsequent centrally run ordinary vanilla control is recorded below. Four relevant installed archive members were copied read-only into /tmp/erri-splash-audit-resources for source inspection.

Finding

The immediate failure is a vanilla layout/script-module ordering mismatch in this installed ordinary-game environment. Both installed splash layouts require SCR_WidgetExportRuleRoot, whose installed declaration lives in the later Game module. Vanilla GameLib constructs each layout before that module has compiled. The vanilla-only control now reproduces the initial IntroSplashScreen error without any successor addon, addon search path, diagnostic helper or noSplash switch. The successor is therefore unnecessary for that initial error in this environment. This is not evidence of a broken prison mission, a universal defect across game distributions, or a successful visible UI/input test. The separate ScenarioLoadingScreen reload failure remains source-diagnosed and observed in the earlier successor run; this control did not exercise reload.

Exact evidence

docs/evidence/game-2026-09-19-080004/console.log.txt:98–106: GameLib finishes at 08:00:05.616; IntroSplashScreen fails at 08:00:05.617; Game compilation starts afterward at 08:00:05.692. Lines 197–204 repeat the order for ScenarioLoadingScreen at 08:00:09.371 after the explicit header reload. The run still verifies the Core header and MissionSystems, then reaches PRISON. Its separate missing-identity error withheld the player; that identity failure does not explain either earlier GUI error.
game-2026-09-19-080528: the actual CLI remains the same, including -noSplash. Lines 101 and 198 record the new diagnostic skip before Game compilation. Its report contains no splash errors; the still-present identity error leaves the overall run failed. Source manifests differ only in ERR_DiagnosticNoSplash.c and admission diagnostics in ERR_SpawnLogic.c. Thus the disappearance of splash errors is explained by not instantiating the offending layouts; it is not a successful normal-splash test.
Both runner metadata records use regular ArmaReforgerSteam.exe, not SteamDiag or Workbench. The GameLib/Game defines contain neither WORKBENCH nor ENF_WB. Both record owned cleanup. Console hashes and launch/stopped source-manifest hashes were independently recomputed and match; launch and stopped manifest bytes are identical within each run.
The 080004 log lists only engine core, installed ArmaReforger and ERR_Core as loaded addons. It mounts vanilla from the installed ./addons/data package, not /tmp/erri-vanilla or the original Escapists workspace. The profile link points to that same installed data directory. No second replacement vanilla addon or source-layout override was observed.

Stopped vanilla-only control

Archive 102533 retains the failed control and raw console. The ordinary executable runs with only a fresh private profile, noBackend/noSound/noThrow, disabled crash reporting and console logging. The raw CLI is at line 8; the loaded-addon block at lines 29–31 contains exactly engine core and ArmaReforger. No successor addon or activity appears. The engine uses default Enfusion settings in the fresh profile.

GameLib completes at 10:25:34.416, then the installed IntroSplashScreen layout reports the same unknown class at the same offset 282 (console lines 88–93). Game compiles afterward and the engine logs Entered main menu. at 10:25:36.920 (line 148). There is exactly one retained engine error, no script/VM error, no successor participant/header/mission readiness and zero smoke completions/assertions. The runner latches failure despite menu initialization, drains at most its configured thirty-second failure grace and stops after approximately 33.3 seconds total. Cleanup is confirmed. control_only is true and result remains game-failed.

Console bytes were independently hashed against stopped runner metadata; launch/stopped source-manifest bytes and their stored digests match. The successor addon manifest is retained only for provenance bookkeeping and contains unloaded sources; it is not proof that those addons ran. This archive cannot qualify successor gameplay or release acceptance.

Installed source and resources

Installed root: /home/jakub/.local/share/Steam/steamapps/common/Arma Reforger.

addons/data/data007.pak contains scripts/GameLib/LoadingScreens/SplashScreen.c. Its Load() at line 19 creates INTRO_SPLASH_LAYOUT for the first load (line 28) and SCENARIO_PRELOAD_LAYOUT on reload (line 40). This method does not inspect noSplash.
addons/data/data010.pak contains UI/layouts/Menus/MainMenu/IntroSplashScreen.layout and UI/layouts/Menus/LoadingScreen/ScenarioLoadingScreen.layout. Each has a root SCR_WidgetExportRuleRoot component at line 16. It stores layout-code-generator metadata, with a destination pointing to GameLib/LoadingScreens. That destination string is export metadata, not a script-module relocation instruction.
addons/data/data007.pak contains scripts/Game/UI/Components/SCR_WidgetExportRule.c. SCR_WidgetExportRuleRoot is declared at line 82; only its Workbench helper methods are guarded by WORKBENCH (starting line 100). The class itself is available in ordinary Game, but not earlier GameLib. Therefore deleting/adding WORKBENCH defines would not fix the actual module boundary.
Installed addons/core/core.gproj:16–19 maps GameLib to scripts/GameLib. Installed addons/data/ArmaReforger.gproj:17 selects SplashScreen and lines 926–932 add scripts/Game to the Game module. Successor addons/core/addon.gproj only declares its identity/dependency and does not override those script paths or splash class. Current successor sources contain no replacement for the two layouts or export-rule class.

Freshly extracted members exactly match the older recorded docs/ordinary-splash-source-hashes.json, so no asset change between that audit and this inspection was detected. Full file hashes follow below.

Remedy and next discriminator

Already demonstrated safe diagnostic remedy: keep the explicitly gated ERR_DiagnosticNoSplash.Load behavior for -noSplash plus -errOrdinaryScenario core|chat. It skips only these diagnostic splash resources, preserves the per-instance sequence counter, and delegates all unflagged loads to vanilla. 080528 shows the splash errors disappear, while unrelated errors remain visible. This cannot qualify normal visible startup.

No proven normal-splash production remedy yet. The initial vanilla-only discriminator is complete and reproduces the error. Retain the raw failure as installed-native startup evidence and do not spend successor gameplay effort attempting to define or globally replace a vanilla editor class. A separate normal scenario/addon reload control would be necessary to attribute the second layout's runtime failure without the successor. No engine/profile workaround that qualifies normal splash loading has been demonstrated. A successor-owned loading screen using only GameLib/built-in widgets could avoid the dependency while preserving a visible screen, but it is a proposed compatibility feature requiring separate design/native tests, not a proven fix from this read-only audit. Do not create a dummy duplicate SCR_WidgetExportRuleRoot, edit vanilla layouts, move vanilla classes across modules, filter the errors or turn noSplash into an unconditional global startup override: these either risk duplicate definitions/change unrelated startup or hide the unresolved normal path.

Source hashes

UI/layouts/Menus/LoadingScreen/ScenarioLoadingScreen.layout: c98568661b22fcecc1ef7115c8fce24b989346e50282226a7cd881a10969ac49
UI/layouts/Menus/MainMenu/IntroSplashScreen.layout: 832072a8c803126c9e71d1a78b1442fe9f907e4907848049b84f9cb981c832ea
scripts/Game/UI/Components/SCR_WidgetExportRule.c: 3a4b5dc3a8669bf20d903277d249d41ee3ae7e1e74d2c329ed31d435624fa4b5
scripts/GameLib/LoadingScreens/SplashScreen.c: 2df52f7be83c69b056f0022e27b47cb39af5d797577cdd529b99fa07cc385cf5

8.3 KiB Raw Blame History Unescape Escape