2.9 KiB
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 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.