14 lines
2.9 KiB
Markdown
14 lines
2.9 KiB
Markdown
# Explicit ordinary diagnostic splash handling
|
|
|
|
The installed GameLib `SplashScreen.Load()` creates IntroSplashScreen on initial startup and ScenarioLoadingScreen on addon reload, without consulting `noSplash`. Both installed layouts contain a `SCR_WidgetExportRuleRoot` component. That class is declared in the later Game module, so creating either layout before Game compiles produces the observed unknown-class error. In ordinary run `game-2026-09-19-080004`, this happened at 08:00:05.617 and 08:00:09.371; both completed Game-module compilations followed later. This identifies the resource/module ordering problem independently of mission gameplay.
|
|
|
|
Core's independently authored GameLib extension honors the already supplied `-noSplash` only together with the explicit successor `-errOrdinaryScenario core` or `chat` diagnostic argument. It skips these diagnostic splash layouts instead of asking the GUI to instantiate their unavailable Game components. Unflagged or visible startup delegates unchanged to vanilla. It preserves the vanilla splash sequence counter once per instance and logs the selected diagnostic behavior once. It adds no replacement layout, asset, dummy class, identity or error filter.
|
|
|
|
The installed base lifecycle supports a deliberately absent root: `BaseLoadingAnim.Show()` requests `Load()` when null, `Unload()` deletes the root, and `SplashScreen.Update()` immediately returns when null. The extension handles repeated Load calls without creating UI or advancing its counter again. Native Show/Hide and script compilation still need a centralized ordinary run. A clean diagnostic run with this option would validate gameplay startup without splash UI, **not** normal visible splash loading. All errors from resources that are actually loaded remain failures.
|
|
|
|
The official [startup parameters](https://community.bistudio.com/wiki/Arma_Reforger:Startup_Parameters) describe `-noSplash` as skipping splash screens. This implementation makes the explicit diagnostic honor that requested behavior at its GameLib layout-loading boundary; it does not claim an undocumented engine switch exists.
|
|
|
|
The actual Load method is executed in a source-local C++ regression across both valid projects, absent/invalid flags, repeated calls and a recreated instance. No native GUI or engine is launched by that test.
|
|
|
|
Offline identity is separate. The ordinary header run created a native local controller and reached successor admission, then withheld spawning because its identity could not bind. A supported local platform/session initialization path would need to supply an acceptable native identity; `-noBackend` is not evidence of such initialization. This change does not initialize accounts, contact the backend, relax admission or invent identities. The installed utility also has a non-dedicated name-derived PeerTool fallback, so its return is not necessarily a verified platform identity.
|