Support and retention policy — 1.x#
The target for the first supported release is Windows RimWorld 1.6, Core, framework-generated members, explicit providers, existing maps and ordinary native save boundaries. The tested game build is 1.6.4871 rev591. Package metadata declares 1.6; other 1.6 game builds need validation. The framework remains an opt-in library: enabling it alone creates no populations and changes no existing Pawn ticks.
The Visitor Relay is a first-party consumer pilot. Its separate binary boundary demonstrates public API usability, not independent third-party adoption. DLC/mod combinations listed in the validation matrix certify only the sampled generated visitor lifecycle on the pinned inputs. Special DLC state such as unusual genes, titles, implants and quests requires targeted fixtures before a broader support claim. Multiplayer, arbitrary existing-pawn ingestion, map destruction, caravan/carry holder conversion and transparent map virtualization remain outside the release scope.
API and save versions#
The v1 API contract preserves the supported authoring surface. Packages 1.0–1.3 default provider API major to 1 and accept compatible preview major 0. The historical CLR assembly identity stays 0.1.0.0 through 1.x for preview binary binding. Version 1.3 writes native journal 3 and abstract archive 4, reading formats 1–3 without command history and formats 1–2 as unpaused. The reviewed 386-line metadata baseline preserves all 311 lines from 1.2. Package, API, CLR and save versions are independent. Older frameworks retain the unknown archive as blocked. Use matching packages and keep a pre-upgrade save if a downgrade may be needed. Command-dependent consumers must require the 1.3 capability before loading those types.
Providers own stable IDs, schema/model versions, validation and migrations. Missing or incompatible providers preserve records and pending intent. Restore the matching provider before progressing native work. An overdue locked record must be handled under the documented transition/settlement time contract. A provider must persist request keys, revision expectations and encounter intent in its own save root; a UI-local key is insufficient.
Actual archived 0.3/0.4/0.5 native saves are retained losslessly under Tests/Fixtures/Upgrades with checksums and source-run provenance. tools/test-upgrades.ps1 verifies and expands them into temporary input files, then runs the upgrade fixture. They include generated test-world state, not game binaries.
Actual 0.6 consumer checkpoints at pending arrival and prepared settlement are retained under Tests/Fixtures/VisitorUpgrades. Their manifest pins original framework/consumer binaries, source run and unmodified save bytes. tools/test-visitor-upgrades.ps1 checks and loads them. The optional -OldConsumer test additionally loads the original 0.6 consumer DLL against the candidate; the verified original consumer ZIP is retained beside these fixtures. It contains only this project's DLL/About/Def files, never game binaries.
History and native ownership#
Operation receipts, settlement history, member tombstones and accepted command request keys are durable for the lifetime of the saved world. They are not automatically pruned. IDs and accepted keys are never silently reused. Replaying a known request returns its recorded result; the framework must preserve enough history to reject a changed fingerprint. There is no supported history-compaction API. New provider commands are refused at 4,096 receipts per entity, 65,536 per world or 16 MiB of accounted command data; existing receipts remain replayable. The byte limit is fixed metadata allowance plus exact variable UTF-8 bytes, not a CLR heap or XML-size measurement. See the command contract.
This policy implies save and memory growth with encounter count even when the number of actual Pawns stays fixed. Use indexed current-operation polling; reserve full-history lists for inspection. Any future compaction must explicitly define replay semantics, consumer acknowledgments and migration behavior, with old-save and duplicate-effect tests. Removing journal XML to reduce file size is not a supported operation.
Retained individuals are full native Pawn graphs and remain unticked by SimLOD's holder. Anonymous uncreated population can remain compact provider payload. Ordinary return does not destructively aggregate important individuals. No whole-game TPS improvement, hard frame-time cap or arbitrary-mod reference safety is promised. Native callbacks, reentrant saves inside callbacks and process termination mid-commit are not transactional boundaries.
Keep the framework enabled while its saved entities exist. Removing only a provider is covered by restoration tests. Removing a consumer also removes its own game-specific save root; restoring that mod after saving without it cannot be assumed to recover its lost metadata. Ambiguous uncaptured generation or unverified native ownership stays blocked for investigation; recovery does not invent a body or silently seize a foreign holder.
Exercised scale and installation boundary#
The first supported envelope is a bounded consumer cohort (the included relay has three members) and the measured workloads below. These are exercised combinations, not interchangeable maximums or a performance guarantee for every provider.
| Workload | Exercised envelope |
|---|---|
| Full native visitor lifecycle | One contact, three exact generated Pawns, 500 return visits / 1,002 operations / 100 settlements, at least three native game days. |
| Cancelled claims / cold restore | 20 entities, 2,000 settled admission operations and 6,000 cancelled member tombstones, then a further admission proving IDs are not reused. No Pawn generation in this workload. |
| Native work quota | One member attempt per unpaused update; synchronous operations and an individual native callback remain non-preemptible. |
| Individual plans | Maximum 32 outcomes per native operation; larger cohorts require an explicit adapter. |
| Abstract format guards | 256 KiB UTF-8 payload per entity and 100,000-record capacity guards are format limits, not tested native population/throughput promises. |
Use indexed operation lookup for regular polling. Cold journal validation and whole-history queries can be much more expensive than a warm lookup. No automatic pruning occurs when these exercised sizes are exceeded. The three historical fixed-Pawn runs reached about 0.79 MB journal size; the 6,000-tombstone workload reached about 4.0 MB. See the candidate measurements for the exact tested build.
The public project is https://github.com/traecneh/SimLOD. Native dependency declarations include that real URL because this RimWorld build silently removes declarations without a download/project link. Keep one copy of each package, order framework before providers/consumers, and restart after mod changes. Fresh missing-provider startup preserves an empty contact; saved missing-provider recovery preserves existing intent. Native missing-framework dependency UI is checked independently of provider suspension.
The native relationship investigation reproduces a matching generator/relationship failure with SimLOD absent. No global fix or log suppression ships. English is the supported UI language. Version 1.1 adds keyed relay/recovery/starter text and translatable relay definitions; see the translation guide for coverage and the remaining technical English diagnostics. The supported release does not promise a bug-free base game or arbitrary third-party graph retention.
Beta boundary#
Survey Relay provides a second first-party public API design, with no Pawn materialization or example dependency. Since 1.2, its completed records remain saved and are automatically paused. The native colony scenario exercises both relays using hauling/construction, a drafted builder, moving visitors, one game day and several save/load sessions. This is scripted native gameplay, not independent human playtesting or third-party adoption.
The broader all-DLC matrix remains a sampled lifecycle check, with a known native relationship-reference limitation documented in the beta report. Strict native log checking remains enabled. The original game build and full acceptance binaries are pinned in the 1.0 summary. The current report distinguishes focused 1.3 validation and the copied Frontier consumer test. The actual 1.0 survey checkpoint is retained under Tests/Fixtures/SurveyUpgrades and verified by tools/test-survey-upgrade.ps1. An actual 1.1 completed-history save under Tests/Fixtures/DormancyUpgrades is verified by tools/test-dormancy-upgrade.ps1. Original archived bytes are unchanged; snapshot comparisons permit only the documented default unpaused attribute and a strictly valid empty command section. Nonempty or malformed command histories are never normalized away.