aussie/EscapistsReintroduced
1
0
Fork 0
forked from escapists/EscapistsReintroduced
Code Pull Requests Activity

Capture current mission, AI, map and administration development

Browse Source 
Include the current addon, terrain integrations, tools, regression tests and recorded development evidence.
This commit is contained in:
jakub
2026-10-13 22:52:53 +02:00
parent a951a96edc
commit 6a667d8deb
8104 changed files with 2124945 additions and 2061 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ordinary-game-startup.md
+14 -1
View File
@@ -1,5 +1,13 @@
# Ordinary game startup validation
Ordinary rounds use progressive mission generation: startup waits for the prison
(or crash scene), its initial population/supplies, and the extraction vehicle.
The remaining camps, scouting posts, roadblocks and support are prepared after
player admission. The server logs separate `[generation]: spawn-ready` and
`[generation]: background complete` elapsed times. They measure scenario
preparation, not engine boot or client loading. Explicit historical Workbench
smoke fixtures retain their full-world preparation contract.
`tools/headless_game.py` prepares a bounded **ordinary game** run using the installed stable `ArmaReforgerSteam.exe`, rather than Workbench. It loads either Core or the full Chat dependency chain and the authored successor scenario header. It does not activate any WORKBENCH smoke plugin or add a server flag.
Example, only when other runners have stopped:
@@ -12,6 +20,11 @@ Use `--project chat` for the companion dependency chain. The program constructs
## Isolation
Automated tests must stay hidden. Use the existing headless game, Workbench,
and packaging runners; never place test windows on a physical monitor or
change the user's Steam launch options. The obsolete right-monitor KWin
helper has been removed. Normal Steam play is independent of these runners.
- Read-only `/proc` enumeration refuses **any** existing ArmaReforgerSteam/SteamDiag game instance before launch, including a Wine/Proton launcher command or truncated process name. Unreadable process state fails closed. It does not stop the existing game.
- The disposable cloned prefix must already exist outside Steam. The same `.erri-workbench.lock` used by the Workbench runner prevents concurrent use. Existing Wine, Proton, Gamescope and Windows process candidates carrying that prefix also cause refusal. Readable native process metadata excludes unrelated services; ambiguous candidates fail closed. The read-only `--inspect-processes` mode reports all process blockers without launching, locking, configuring audio or creating profiles. Do not use the actual Steam compatdata prefix or user game profile.
- The game profile is separate from source, Steam and the prefix tree. An existing directory must have this runner's exact private-profile marker. Unexpected symlinks/addons are rejected; only the installed vanilla data link is created. This does not import the user's game profile or workshop subscription folder.
@@ -88,7 +101,7 @@ Direct `-world Worlds/ERR_Everon.ent` did compile the ordinary Game module (5,72
The ordinary runner now starts the normal main menu and explicitly requests `-errOrdinaryScenario core` or `chat`. Core owns the opt-in `ERR_OrdinaryScenarioLaunch.c`; Chat adds only its own header/addon selection override, preserving the dependency direction. Both are absent from WORKBENCH compilation and inert without the explicit argument. The launcher queues one attempt per game instance, validates the selected installed successor header/addon pair and only calls the native transition from an idle main menu. Active worlds and pending native transitions are never replaced. World cleanup cancels an outstanding callback. No click, user identity, audit callback or backend state is synthesized.
The exact installed API is `GameStateTransitions.RequestScenarioChangeTransition(ResourceName missionOrWorld, ResourceName worldSystemsConfig, string addonList)`: its documentation accepts a mission header or world. Vanilla `game.c:1246` uses it in `PlayGameConfig`. Core passes `{AD62322D5213C440}Missions/ERR_Everon_Base.conf`; Chat passes `{C1E20667DCE324ED}Missions/ERR_Everon.conf`; both specify `{C50579A2EC48E8EF}Configs/Systems/MissionSystems.conf`. Once a successor world starts, the diagnostic only inspects its active header and actual `GetSystemsConfig()`; the runner requires that verification plus ordinary module/phase/settle evidence. Existing splash errors still permanently fail the run, even if downstream header verification succeeds.
The exact installed API is `GameStateTransitions.RequestScenarioChangeTransition(ResourceName missionOrWorld, ResourceName worldSystemsConfig, string addonList)`: its documentation accepts a mission header or world. Vanilla `game.c:1246` uses it in `PlayGameConfig`. Both current fixture selectors pass `{C1E20667DCE324ED}Missions/ERR_Everon.conf` after retirement of the duplicate Base header; both specify `{C50579A2EC48E8EF}Configs/Systems/MissionSystems.conf`. Once a successor world starts, the diagnostic only inspects its active header and actual `GetSystemsConfig()`; the runner requires that verification plus ordinary module/phase/settle evidence. Existing splash errors still permanently fail the run, even if downstream header verification succeeds.
This uses the documented [native transition API](https://community.bistudio.com/wikidata/external-data/arma-reforger/ArmaReforgerScriptAPIPublic/interfaceGameStateTransitions.html), not an invented `-scenario` engine parameter. The official `-worldSystemsConfig` startup parameter is marked Diag-only, so it is not assumed to configure the regular executable. Native compilation and actual header transition are pending; failure to reach an idle main menu is retained as a failed diagnostic, without retries that could replace gameplay.