H02 StampTreatyTurns -- the diplomacy ledger's "this treaty was last in force on turn N" stamp, over every ordered pair of players that holds one, creating the entry on demand. It is a host step, not a phase of either turn driver: its sole caller is the command-application step, which runs after the frame counter has advanced and before both drivers. On a turn with no combat and no diplomatic command it is the only writer of these fields, which is why a whole per-player dipstats vector is its output. Read from the instruction stream; three things an earlier reading had wrong are corrected in findings/subsystems/treaty-turn-stamp.md: the stamped value is the TURN and not the modification counter, the relation codes are 3=allied / 2=NAP / 1=cease-fire and not the reverse, and the bit is the player's index field rather than its position in the player vector -- the opposite convention from the shared-vision mask two files away. Measured, closed and regressed reported separately and never netted: turn1 -> turn2 (reference) 209 -> 132 closed 77 (was 51), regressed 0 turn2 -> turn3 108 -> 73 closed 35 (was 21), regressed 0 human-turn2 -> turn3 closed 76 (was 64), regressed 0 zuul-turn15 -> turn16 closed 30 (was 18), regressed 0 zuul-turn16 -> turn17 closed 29 (was 17), regressed 0 The last three are pairs from a different game at turns 2, 15 and 16 that the model was never fitted to, and it closes exactly the twelve ordered treaty pairs each of them holds. The rule also reproduces the ledger of ten of the eleven corpus saves entry for entry, including each entry's order and every stamped value; the eleventh is the turn-1 save whose ledger no turn has yet written, and it is the reference pair's input. app_test_treaty pins the five things the corpus cannot separate: the relation codes (no save exercises cease-fire), the bit's source, the missing alliance-id guard, the -1 initialiser on a fresh entry, and the append-at-the-end order that makes re-running the step idempotent instead of duplicating rows. The betrayal half of the same function needs the turn's diplomatic commands; with no command stream it is provably a no-op and is not modelled. |
||
|---|---|---|
| cmake | ||
| docs | ||
| include/generated | ||
| src | ||
| tests | ||
| third_party | ||
| tools | ||
| .gitignore | ||
| CMakeLists.txt | ||
| CMakePresets.json | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| README.md | ||
sots-engine
A from-scratch, functional reimplementation of the engine behind Sword of the Stars (2006). Not a byte-for-byte decompilation: behavior-equivalent code, built up one verified piece at a time (OpenRCT2-style) until the tree can build the whole application on its own.
Bring your own game. This repository contains engine code only. Game data, assets, saves, and
the original binaries are never included; tests and tools read an owner-supplied copy via
$SOTS_DATA_DIR. See CONTRIBUTING.md for the clean-room rules.
Status
Phase 2. M0 done — the shim frontend (src/shim/, a proxy binkw32.dll the original game
loads) builds, deploys, hooks, and logs from a real game launch. Engine code accrues under
src/mars/ and src/game/; each module is oracle-verified against the owner's game data before merge:
mars/parse— brace-block +.effectreaders (1,531/1,531 files agree with the reference)mars/text— flat key/value tables, id manifests, CSV (64/64 files agree)game/sim— strategic formulas (economy, research, colonies, movement) as pure functions; 356 hand-computed checksmars/vfs—.gob(ZIP) archive reader + loose-file override; entry counts and bytes verified againstunzipmars/stream— the game's self-describing save/serialization format (reader, writer, typed shapes) + gzip; three real saves round-trip byte-identicalmars/rng— MT19937 with save-state load/store; layout confirmed against real saves, draw mappings read off the binary (docs/mars-rng.md)game/data— typed catalogs (weapons, ship sections, turrets, id registries, tech tree, strings) with cross-reference checks; 229k values agree with the referencegame/design— ship-design assembly/fit/tech-gating rules and derived stats; validates all 127 stock designs from real savesapp— the standalone:sots_turnloads a save, runs one strategic turn over the published phase order of all three turn drivers, and writes a save. 14 of the 44 turn-driver phases are modelled; every phase that is not appears in the run log as a named no-op. How far it is from the byte-match, and what stands in the way, is indocs/S-standalone.md
Build: cmake --preset host && cmake --build --preset host && ctest --preset host (Linux);
tools/sync-build.sh cross-builds the shim on the lab box and stages it for deployment.
Layout (grows with the work)
src/shim/— binkw32 proxy + hooks + old-vs-new compare harness (frontend #1)src/mars/,src/game/— the engine and game reimplementation (accruing)src/app/— the standalone turn driver (frontend #2): load a save, run a turn, write a saveinclude/generated/sots_addresses.h— binary facts (RVAs/prototypes), generated from the RE repotests/— host tests; real-data tests skip unless$SOTS_DATA_DIRis settools/— build (MinGW i686 cross) and deploy scripts
Planning, findings, and verification evidence are tracked in the private RE repo (sots-re).