02 · Quick start

Install the framework, then add a mod

Mod authors need a Windows x64 C++ toolchain to build DLLs. Players need the Shroudtopia loader release plus the separate mod package. Follow the exact release notes for proxy conflicts and supported versions.

  1. Install Shroudtopia. Download the current maintained release from GitHub Releases. Close Enshrouded first. Back up existing winmm.dll, shroudtopia.dll, and shroudtopia.json outside the game folder. The current standalone release requires both root DLLs. Resolve any other mod’s winmm.dll proxy before replacing it.
  2. Extract the loader. Put the standalone archive in the Enshrouded game directory, beside the game executable. Keep an existing config and enabled-mod list. Create a config only when one is absent, using the release’s supplied example.
  3. Build or download one mod. A mod is a separate Windows DLL. Check its own page for game-version and client/server support; the framework cannot certify those claims for it.
  4. Install the mod files. For a manifest-based mod, place its folder under Enshrouded/mods/<folder>/ with mod.json and the matching DLL inside. A supported legacy layout places a DLL directly in mods/.
  5. Configure and launch. Set the mod’s entry in shroudtopia.json, launch the intended game mode, and inspect shroudtopia.log. Start unverified memory patches disabled.
  6. Roll back safely. Close the game before replacing or removing a DLL. Restore your backed-up loader files if proxy startup fails. Keep Shroudtopia installed if another mod still depends on it.

Development requirements

Compiler

Visual Studio 2022 C++ build tools, MSVC v143, Windows SDK, and x64 target.

SDK header

Include shroudtopia.h from the maintained repository. Build against the exact headers and release you intend to support.

Test target

Separate client and dedicated-server testing. Use a disposable install or isolated test profile for native patches.

Release facts: fork 0.2.1-shroudweave.1 reports SDK/API 0.1.1. Its notes claim a specific Creative Mode 3.0.0 compatibility change; that does not establish compatibility with every mod combination or future game build.
03 · Discovery and config

Files, folders, and manifest defaults

The current maintained loader scans each subfolder in mods/ for mod.json. The manifest’s id selects the preferred DLL name and its optional Shroudtopia defaults. If no ID is present, the folder name is used. If the ID-named DLL is missing, current code takes the first DLL found in that folder. The loader also retains root-level mods/*.dll discovery.

Enshrouded/
├─ winmm.dll                 # loader proxy
├─ shroudtopia.dll           # framework loader
├─ shroudtopia.json          # shared settings; preserve on upgrades
└─ mods/
   └─ example_mod/
      ├─ mod.json
      └─ example_mod.dll

Minimal manifest

{
  "id": "example_mod",
  "shroudtopia": {
    "default": {
      "active": false,
      "show_notice": true,
      "refresh_ms": 500
    }
  }
}

Defaults are written only when that mod key is missing from the main config. If active is omitted, the loader adds true. For memory-changing code, default to false until the user opts in.

Keep the identifiers aligned. Manifest defaults are stored under id (or the folder name). Runtime activation and the examples’ typed getters use ModMetaData.name. Set both to the same exact string, or the initial defaults and runtime settings can land under different keys.

Main config shape

{
  "active": true,
  "bootDelay": 3000,
  "updateDelay": 500,
  "enableLogging": true,
  "logLevel": "INFO",
  "mods": {
    "example_mod": {
      "active": false,
      "show_notice": true,
      "refresh_ms": 500
    }
  }
}

Those top-level values come from the current default config. Use the mod’s metadata name as the key in mods. Keep user settings during upgrades; do not replace the whole file with a template.

↑ Top