Start here#
SimLOD is a C# library shipped as a separate RimWorld mod. A provider defines an entity's data and simulation rules. Your gameplay code creates entities, keeps their IDs in its own save root, and uses the public API to interact with them.
1. Get the framework and starter#
Download SimLOD.zip and SimLOD.ProviderStarter.zip from the 1.3 release. The framework is ready to install. The starter is source code that needs a build using your own RimWorld assemblies.
Extract the framework so its metadata is at Mods/SimLOD/About/About.xml. Keep one active framework copy and enable it before your provider mod. No example package is required by the framework.
2. Build the example outside the repository#
Extract the starter into a working directory and follow its README. It references the public SimLOD DLL and your installed game; it does not require framework implementation access. Do not distribute game assemblies or embed SimLOD.dll in your own package.
The example creates a clock on explicit request and keeps a saved consumer link. Use a disposable save to create it, advance time, save and reload, and test provider removal/restoration.
3. Define your own entity#
Give the mod and provider unique, stable identifiers. Define a versioned payload, a pure validator, and deterministic scheduled updates. Persist the entity ID in your mod's own Scribe root. The provider authoring guide walks through these decisions.
Keep three concepts separate:
| Concept | Who owns it? |
|---|---|
| What the entity means: a herd, expedition, survey, or outbreak | Your provider and gameplay mod |
| Durable entity identity, scheduled deadlines, RNG, and accepted command receipts | SimLOD |
| UI, physical payments, world-map presentation, and domain-specific recovery | Your gameplay mod |
4. Add the capabilities you need#
- Abstract runtime: records, snapshots, scheduling, and failures.
- Provider commands: changing existing domain state from player actions.
- Pawn lifecycle: generating and preserving supported native individuals.
- Pause and resume: dormancy for eligible abstract-only records.
Start with abstract state. Add native Pawns when they serve a concrete gameplay purpose, with explicit tests for identity, ownership, partial progress, and saved recovery.
5. Plan upgrades and recovery#
Version 1.3 writes abstract archive 4 and reads formats 1–3. Keep pre-upgrade saves for downgrades. Package version, CLR identity, provider API major, payload schema, and model version are different contracts; see API compatibility.
Command-dependent types require the 1.3 capability. CLR assembly identity remains 0.1.0.0, so it cannot establish that commands are available. The command guide explains startup detection.
Missing providers preserve their records. Restoring the matching provider and reloading is supported. Removing a consumer can lose that consumer's own saved metadata; do not treat it as an uninstall/reinstall workflow for a live world.