Skip to content

Building and Running

codingncaffeine edited this page May 3, 2026 · 2 revisions

Building and Running

Prerequisites

  • .NET 8 SDK (latest patch).
  • Windows 10/11. The Runtime uses Silk.NET, which is portable, but the Browser is WPF and the test harness is .bat. Linux/macOS contributors can still work in Core and Runtime headlessly.
  • A legitimate copy of Dungeon Siege. GOG, Steam, or original discs. SiegeFX reads .dsres / .dsmap tank files directly and ships no copyrighted assets.

Build

dotnet build

That's it. Core / Tools / Runtime / Browser all build in one shot.

Point at game data

The default DS1 install paths are searched first; if the engine doesn't find your copy automatically, set the data root in your launch arguments. The Runtime needs at minimum:

  • Logic.dsres — actors, templates, skrits, formulas.gas
  • Objects.dsres — meshes, textures, fonts
  • Terrain.dsres — SNO terrain
  • World.dsres — region definitions

A typical GOG install lands these in …/Dungeon Siege/Resources/.

Running the game

From src/SiegeFX.Runtime:

dotnet run -c Release

Default landing region is fh_r1 (Farmhouse). Controls:

Key Action
LMB Move to clicked point
RMB Target / attack / talk
Q Cast Primary slotted spell
W Cast Secondary slotted spell
I Toggle inventory
Esc Pause menu
F5 Quicksave
F9 Quickload
WASD Free-camera (when camera mode allows)
Shift Sprint
[ / ] Cycle the Primary spell slot through SpellCatalog.All (debug aid until the spellbook UI lands).
\ Cycle which DS1 streak texture the lightning-bolt renderer samples (lightray_01 / _02 / _04 / streaks / sparkle01) for live A/B.

Environment variables

  • SIEGEFX_DEBUG_SPELLS=NAME[,NAME…] — overrides the hardcoded spell loadout. First name slots into Primary, second into Secondary, the remaining names seed the placed-spell list. Until the spell-scroll pickup flow lands (see Phase 21-SC-SCROLL), this is how you test any non-default spell. Example: set SIEGEFX_DEBUG_SPELLS=fireball,iceshard,lightning,shock_wave.

test-all.bat

The project's smoke-test menu. Each shipped phase adds a numbered entry — automated --selftest-* flags for non-visual checks, human-walkthrough scripts for visual ones. Reading the menu top-to-bottom is the fastest tour of what works at the current tag.

Run it from the repo root:

test-all.bat

When you ship a new phase, add an entry. If it isn't in test-all.bat, the next session has to remember to test it manually — and they won't.

CLI tools

The Browser is a WPF asset explorer (open .dsres, peek at templates and .gas files). The unified siegefx CLI (SiegeFX.Tools) is the heavyweight: tank / raw / asp / sno / prs / gas / region / world / anim / skrit / templates / pcontent / loot / formulas / spells / sfx / balance / audio / mood / ui subcommand families. See Diagnostic CLI Tools for the full surface, including the spell-VFX audit (siegefx spells visual-audit) and the headless sfx_script runner (siegefx sfx run).

Development workflow

  • Phase boundary protocol: commit → review → fold findings → push → tag.
  • One sub-slice per session. Don't bundle.
  • Add to test-all.bat as part of the same commit.
  • Log gotchas to Engine Quirks and Stumblesbefore you close the issue, while it's fresh.

Clone this wiki locally