Skip to content

Roadmap

Fievetl edited this page Jul 4, 2026 · 2 revisions

Roadmap

Open issues on the issue tracker, one line each.

Issue Title Summary
#15 future: pre-1.22 compatibility shim for the boot path Isolate the exit-lifecycle API calls behind a version-adaptive shim to support Vintage Story 1.21.x and earlier; open question of whether demand justifies the cost.
#11 test: missing E2E paths Coverage gaps: an actual wall-clock watchdog timeout end-to-end, invoker fail-fast on an already-dead host, and [AtlasScenario] applied to a non-AtlasScenarioBase class.
#8 bug: ServerSystemMonitor.Dispose NRE on repeated in-process boots (VS 1.22.2) Investigate and report upstream the shutdown flake Atlas currently swallows. See Troubleshooting.
#7 future: dimension-aware EntitiesIn/Area Waiting on Manifold. Largely delivered in the Unreleased changelog (WorldArea, dimension-aware EntitiesIn, Area inheriting dimension); full custom-dimension end-to-end coverage still needs a real dimension-creating mod to validate against.
#4 future: simulated player connections Waiting on Manifold. v1 scenarios are server-side only through IWorldSession; no simulated client/player connection for behaviors that need one.
#3 future: atlas run CLI facade A standalone CLI reusing the runner-agnostic engine, without xUnit.
#2 future: world snapshot/rollback for faster isolation Faster per-scenario isolation than a full server/world reboot.
#1 future: parallel scenario execution (multi-process orchestration) Vintage Story's embedding statics forbid concurrent servers in one process; parallelism needs multi-process orchestration instead.

Waiting on Manifold

Two items above are explicitly gated on Manifold (a custom-dimensions mod) becoming a real consumer of Atlas, rather than on further work inside Atlas itself:

  • #7: the dimension-aware query surface (WorldArea, EntitiesIn(WorldArea)) is implemented, but full end-to-end coverage of a second, custom dimension needs a dimension-creating mod to spawn one and assert query isolation against it.
  • #4: simulated player connections are useful once a consumer mod has player-triggered behavior that cannot be exercised purely server-side.

Clone this wiki locally