Skip to content

Corter ModSync v0.13.2 (SPT 4.1.x)

Latest

Choose a tag to compare

@github-actions github-actions released this 23 Aug 16:34
· 0 commits to main since this release

Requires SPT 4.1.3 (specifically) - use v0.13.0 if you are still on SPT4.1.2.

Still on SPT 4.0.x? Use v0.12.7. That line is still supported on the SPT4.0.x branch - both versions get the same features.

Changes

This is the first full release since v0.13.0. It carries everything from the v0.13.1-pre1 plus new support for headless clients on SPT 4.1.3.

Headless clients can get their asset bundles on SPT 4.1.3

SPT 4.1.3 moved bundle downloading out of the game client and into the launcher. A headless never runs the launcher, so on 4.1.3 it cannot download bundles.

ModSync now fetches them itself on a headless, before the game loads them. Bundles are CRC-verified and cached, so this happens once.

**If your headless shares a machine with your server, this shouldn't be an issue as SPT still falls back to reading a bundle out of its mod folder when the cache misses. If using docker and headless is in the same stack you can use:

# headless service
volumes:
  - ../headless:/opt/tarkov
  - ../server/SPT_Runtime/user/mods:/opt/tarkov/SPT_Runtime/user/mods:ro

Nothing is copied and no extra disk is used. ModSync then sees that every bundle is already reachable and downloads nothing - a 7 GB modset goes from a ~50 minute first boot to about two minutes. Without the mount, ModSync downloads them, which works everywhere but is limited to roughly 2-3 MB/s by Unity's Mono HTTP stack. Either way you end up with a working headless.

Note

Bundle fetching is a stopgap. It exists because there is no headless image for SPT 4.1.3 yet.
Once an official one ships and handles bundles itself, this will be removed from ModSync.

The mod-folder mount shown above is not affected and will keep working - that is SPT's own
lookup behaviour, not something ModSync adds.

Also, its slow without the mount, painfully so, but it works. If you have a networked setup with gigs of bundles, go have a Fika break!

New: optional per syncPath

Set "optional": true and the client gets a working checkbox for that path in the F12 menu, starting in whatever state enabled gives it. Until now the only path a player could tick or untick was an opt-IN one ("enabled": false); this adds the other half, a mod that is synced by default but can still be refused. Unticking uninstalls what ModSync installed there.

Do not put it on the three catch-alls (../BepInEx/plugins, patchers, config) - they carry the mods your players need to connect, so one untick would strip the modset.

New: removing a mod from your config now removes it from clients

Delete a mod's files from the server and delete its syncPaths entry, and every client uninstalls its copy on the next sync, with the usual prompt. Previously the entry disappearing meant clients never heard about it again and kept the mod permanently.

ModSync records what it served in .modsync-served.json next to config.jsonc, and keeps offering a removed entry as empty until you re-add it or clear that file. Deleting the entry but keeping the files still does the opposite, by design: the entry is what carves a mod out of the catch-alls, so without it they sync it to everyone.

Fixed: renaming a syncPath no longer resets your players' F12 choices

Each client stored its toggles under the syncPath's name, so relabelling an entry made every player's setting for that mod revert to default and left a dead line in their config. Toggles are now stored under the path and merely displayed using the name. Each client carries its existing choices over on the first launch and tidies the old lines away; nobody has to do anything.

This mattered more once optional existed: a reset re-ticks an opt-out path, which would have silently reinstalled a mod the player had refused.

Upgrade notes

Unzip into your game/server root as usual - clients update themselves via sync, no manual steps.

Your existing config.jsonc is untouched and behaves exactly as before; optional defaults to false.

If you already have an entry you expected players to be able to untick, it needs "optional": true adding. An "enabled": true path has never been shown in the F12 menu, and still isn't without that option.

Testing status

The four items carried over from v0.13.1-pre1 were tested on the 4.0 line through the v0.12.7 pre-releases, on live servers with headless and player clients, before being ported here unchanged.

Bundle acquisition is new in this release. It was tested on a live SPT 4.1.3 stack with a 1214-bundle / 7 GB modset, both ways: with the mount present (every bundle resolved from the mod folder, nothing downloaded) and with bundles deliberately hidden from it (fetched, CRC-verified and cached). Both test suites are green in CI.

Docs

Full Changelog: v0.13.0...v0.13.2