No mod is synced by Skyrim Together Reborn. The developers say it plainly: there are no mods that are explicitly synced, and mods only sync by accident. Whether a mod survives co-op depends entirely on what it changes. Mods that change only what one player sees - textures, meshes, lighting, most interface mods - are safe, because there is nothing to agree on. Mods that add items or armour usually work if every player has the same plugins in the same order. Mods that change scripts, AI, quests or the engine itself are where co-op sessions fall apart, because each player's Skyrim runs that logic on its own and Skyrim Together only mirrors part of the result. The rest of this guide explains why, sorts common mod categories by risk, and shows how to build and enforce a mod list that a group can actually play on.
The server side of this - installing the server, every STServer.ini key and the admin commands - is covered in the Skyrim Together Reborn server guide. This post is about the part that happens on players' machines, which is where nearly every co-op problem starts.
What Skyrim Together actually syncs#
Every player runs a complete, single-player copy of Skyrim. Skyrim Together hooks into each copy and exchanges a defined set of state through the server: who is where, what they are doing, and a selection of world events. Anything outside that set happens separately on each machine, and two machines running the same game logic independently will drift apart.
| Area | Synced? | Notes |
|---|---|---|
| Player position, animation, equipment | Yes | The core of the mod |
| Combat, damage and magic between players and NPCs | Yes | NPC targeting can get confused |
| NPCs and creatures near players | Yes | Each actor is owned and driven by one client |
| Main quests and side quests | Yes | Through the party leader, see below |
| Miscellaneous quests | Optional | bEnableMiscQuestSync, experimental |
| Experience for combat skills | Yes | bEnableXpSync, on by default |
| Time of day | Yes | The server owns the clock, uTimeScale |
| Calendar date | Optional | bSyncPlayerCalendar |
| Dialogue and scenes | Partly | Driven by the party leader |
| Dropped items in the world | Optional | bEnableItemDrops, off because it has crashed servers |
| Player home chests | Optional | bSyncPlayerHomes, off by default |
| Characters, inventories and saves | No | Each player's own save file |
The quest model explains a lot of "broken quest" reports. The party leader effectively hosts the world: progression syncs to everyone when the leader advances a quest. The official playguide's rules follow from that - only the leader talks to quest NPCs and picks up quest items, the leader enters a location first, there is one party per server and one leader per playthrough rather than per session. Members can kill quest enemies, clear dungeons and solve puzzles while the leader is present.
Now consider what a quest mod does. It adds new quest records and scripts that run on each client. Skyrim Together syncs quest stages for quests it knows how to follow, but the scripts behind a new quest still run independently on every machine, and any script that depends on something only one client did - a trigger box, a dialogue choice, an item pickup - can leave the clients in different states. That is the general shape of every sync failure: logic that runs locally on each machine, reacting to events that only one machine saw.
Why load order matters more in co-op#
Skyrim refers to every object - every sword, NPC, door and spell - by a form ID. The first part of a form ID comes from the position of the plugin that defines it in the load order. A sword from the fifth plugin in your list and the same sword from the sixth plugin in your friend's list are, as far as each engine is concerned, different numbers.
That is why "we have the same mods" is not enough. Same mods in a different order, or the same mods with one extra patch on one machine, gives you a party in which equipment, NPCs and objects can fail to match - the naked NPC or naked player that the troubleshooting pages describe is the most visible symptom, though it has other causes too. Light plugins (.esl) do not escape this: they live in their own slot but their order still matters.
The only arrangement that can be relied on is the same plugins, at the same versions, in the same order, on every machine. Skyrim Together gives you a tool to enforce exactly that.
bEnableModCheck and loadorder.txt#
With bEnableModCheck=true in STServer.ini, the server compares each joining player's loadorder.txt with a reference copy and refuses anyone whose list does not match. It turns a two-hour desync investigation into a rejection at the door.
- On one player's machine, enable exactly the mods the group will use, in the order you want, in Mod Organizer 2 or Vortex.
- Find that profile's
loadorder.txt. In Mod Organizer 2 it is in the profile folder; in Vortex, use Open, then Open Game Application Data Folder. - Stop the server and place the file in a folder called
Data- capital D - beside the server, so the server readsData/loadorder.txt. - Set
bEnableModCheck=true, start the server, and look forModPolicy is activein the console.
[ModPolicy]bAllowMO2=truebAllowSKSE=truebEnableModCheck=trueSkyrim.esmUpdate.esmDawnguard.esmHearthFires.esmDragonborn.esmSkyUI_SE.espImmersiveWeapons.espTwo limits are worth understanding. The check compares the list of plugins, not the files inside them, so two players with different versions of the same .esp pass it. And mods with no plugin at all - texture packs, SKSE DLLs, animation files - do not appear in loadorder.txt and are not checked. The mod check enforces load order parity; it does not enforce mod parity. Versions are still a matter of discipline, which is why the next sections exist.
Edit STServer.ini only while the server is stopped. The running server writes its in-memory configuration back on shutdown, so a change saved to a running server is overwritten.
Mod categories, sorted by risk#
What follows is practical guidance from how the sync model works, not an official compatibility list. For individual mods, the community compatibility tracker on GitHub and the official wiki are more current than any article.
| Category | Typical risk | Why |
|---|---|---|
| Textures, meshes, weather visuals, ENB or ReShade | Low | Changes what one client draws, nothing is exchanged |
| Interface mods such as SkyUI | Low | Local presentation, though menus that pause the game behave differently |
| New weapons, armour, items | Low to medium | Fine with identical load order, needs the plugin on every machine |
| New NPCs and followers | Medium | NPC ownership is handled, follower AI is not reliable |
| Combat, perk and AI overhauls | High | Each client calculates differently; damage and behaviour diverge |
| Quest and story mods | High | Local scripts reacting to events only one client saw |
| Script-heavy gameplay mods (needs, survival, economy) | High | Constant local script state that nobody shares |
| SKSE plugins that hook the engine, renderer or save system | High | Can conflict with Skyrim Together's own hooks |
| Animation frameworks and behaviour patches | High | Every client must have identical generated output |
| The bundled Creation Club files | Remove | The official guide strongly advises removing them |
A few of those deserve detail.
Visual mods
Texture and mesh replacers are the safe end. Another player's armour is drawn with your textures, so a group can even disagree about visuals without consequences - although a mesh replacer that changes a body shape will look odd next to somebody without it. Lighting and weather visual mods are local, but weather itself is driven by the party leader, so a weather mod that adds new weather types is a data mod, not a visual one.
Content mods: new items, armour and NPCs
These add records through a plugin. With matching load order they usually behave: a player wearing modded armour appears in it to others who have the same plugin. Without the plugin, the item cannot exist on the other machine at all. New NPCs work in the sense that Skyrim Together will mirror them like any other actor, but anything they do through custom scripts is local.
Followers are the weak spot even in vanilla. A follower's AI runs on whichever client owns it, and the developers recommend dismissing followers before connecting. A party of players does not need a follower mod.
Overhauls and script-heavy mods
Combat overhauls change damage formulas, stagger, AI packages and perks. Two clients running different maths on the same fight disagree about who hit whom, and even identical copies can drift because each client resolves its own timing. Survival and needs mods run constant scripts on every machine with no shared state, so one player's hunger has nothing to do with another's and the results of shared events - a shared camp, a cooked meal - are not mirrored. These mods can be playable for a forgiving group; they are not something to expect to work.
SKSE plugins and engine hooks
SKSE itself is fine, and the server can allow or refuse it with bAllowSKSE. The risk is DLL plugins that hook the same engine functions Skyrim Together does - renderer, camera, save system, input. The official wiki names several that do not load well, including KiLoader, Smoothcam, Alternate Conversation Camera variants, S.L.A.C.K., Wheeler and Master Occlusion Field, while others such as Engine Fixes 7 and Skyrim Souls RE Updated were reported to load with 1.8 after earlier versions did not. Address Library for SKSE is a requirement of the mod, not an optional extra.
Animation mods
Skyrim Together mirrors animations largely by sending the state of each character's behaviour graph rather than the animation itself. Animation frameworks change that graph by generating new behaviour files on each machine. If two players' generated output differs, the same signal means different animations on each screen, which ranges from cosmetic to broken. If your group runs animation mods, every player needs the identical set and should regenerate from the same mod list.
Building a co-op mod list that holds up#
The approach that works is the boring one: start from vanilla Skyrim Together, add a little at a time, and test each addition with two people.
- Start clean. Get the whole group connected on unmodded Skyrim Together with Address Library, the Creation Club files removed and the same game build. Play one session. Every later problem is now attributable to something you added.
- Add visuals first. They are safe and they make the game feel modded without risk.
- Add content in small batches. Five plugins at a time, then test. Regenerate and distribute
loadorder.txtafter every batch. - Avoid overhauls unless the group accepts the risk. If you add one, add it alone and play a full session before adding anything else.
- Write everything down. Mod name, version, file name and download link, in a shared document. When something breaks in week three, the list is how you find what changed.
Distribute the list as a package rather than as instructions. A Mod Organizer 2 profile copied between machines, or a curated collection that installs identical files, removes the "I installed the newer version" class of problem. Mod managers and collections cannot fix a mod that does not sync, but they can make sure that everyone is at least running the same thing - and mod load order explained covers sorting rules if you have never had to think about them.
A two-player test for any new mod
| Test | What it catches |
|---|---|
| Both equip a modded item and look at each other | Missing records, load order mismatch |
| One drops an item, the other tries to pick it up | Item sync, which is off by default for a reason |
| Fight a group of NPCs together | AI and combat overhaul divergence |
| Leader advances a quest stage, member checks journal | Quest sync with the mod's scripts present |
| Enter and leave an interior together | Cell transitions, the most common crash point |
| Both save, quit, reload, reconnect | Save compatibility with the mod |
Fifteen minutes of that before a session catches most of what would otherwise ruin an evening.
Updates: Skyrim, the mod and everything in between#
Skyrim Together Reborn is tied to a specific Skyrim Special Edition build, currently the latest 1.6.x on Steam or GOG. When Bethesda patches the game, Skyrim Together, SKSE, Address Library and any SKSE plugins all need matching updates, and they do not arrive on the same day. The usual result is a group where some players have updated Skyrim and nothing works.
- Tell the group not to launch Skyrim through Steam on a patch day until the mod authors catch up.
- Update the client mod and the server together. A client on one version and a server on another do not talk.
- Pin the server version rather than tracking the latest image, so it does not move underneath a group still on the old client.
- Keep a copy of every player's working save before updating anything. Removing or changing mods can make a save unloadable - the official guide warns this applies even to removing the bundled Creation Club content.
What to do when a mod update breaks has the general recovery order; for this game, the short version is that the group rolls back together or not at all.
The server's part#
The server holds no world and runs no mods. Its contribution to mod stability is the policy section and a handful of sync switches:
| Key | Recommendation for a modded group |
|---|---|
bEnableModCheck | true, with a Data/loadorder.txt you control |
bAllowSKSE | true if any mod in the list needs SKSE, otherwise false |
bAllowMO2 | true unless everyone uses Vortex |
bEnableItemDrops | Leave false. Item drops are where modded items cause most crashes |
bSyncPlayerHomes | Leave false unless the group wants shared chests and accepts the risk |
bEnableMiscQuestSync | Leave false until vanilla quests are reliable for your group |
On RE:NODE the Skyrim Together server has its one port allocated, STServer.ini is editable in the browser and the Data folder can be created in the file manager, so dropping in a new loadorder.txt is a stop, upload and start. Keep the current loadorder.txt in a backup slot alongside the config; when a new batch of mods goes wrong, restoring the previous policy file is quicker than reconstructing it. Backups that actually restore covers why that restore should be practised once, and keeping a modded server clean the wider habit.
Troubleshooting desync#
NPCs or players appear naked. A well-known problem. Reconnect, or walk into and out of an interior; restart the server if it persists. If it keeps happening only to modded gear, compare load orders.
A player is refused with a mod policy error. Their loadorder.txt differs from the server's. Compare the two files line by line; a single extra patch plugin is the usual culprit.
Everyone has the same load order and items still look wrong. Different versions of the same plugin, or a missing texture or mesh pack the mod check cannot see. Compare versions from the shared mod list.
A modded quest is stuck for one player only. The quest's scripts ran differently on their client. The quest debugger opened with F3 then F2 can unstick a party, with the warning that it may skip the quest entirely. Save before using it.
Enemies only attack one player. Combat targeting lost track. Leave the area and return. Combat overhauls make this more frequent.
The game crashes on connecting to any server. Before blaming mods: the client and server need a CPU with AES-NI support, because the networking library depends on it. Then check for engine-hooking SKSE plugins.
Crashes started after a Steam update. Skyrim updated and the mod, SKSE or a plugin did not. Wait for updates or restore the previous game build.
FAQ#
Which mods are officially supported by Skyrim Together Reborn?
None. The official position is that you should run no other mods for the most stable experience, and that no mods are explicitly synced. Mods that happen to work do so because of what they change, not because of an integration.
Do texture and graphics mods work in co-op?
Generally yes. They change only what one client draws and exchange nothing with the server, so players can even run different visual mods. Weather mods that add new weather types are data mods and behave differently.
Does bEnableModCheck make sure everyone has the same mods?
It makes sure everyone has the same plugins in the same order. It does not compare file versions and cannot see mods without a plugin file, such as texture packs or SKSE DLLs.
Can we use a survival or needs mod together?
You can install one, but its state is not shared between players. Each player's hunger, cold and fatigue runs separately, and shared events are not mirrored. Treat it as a single-player layer that happens to be present in co-op.
Why do followers break in Skyrim Together?
A follower's AI runs on the client that owns it, and that does not hold up well with several players. The developers recommend dismissing followers before connecting.
Do I need to install mods on the server?
No. The server runs no mods. It only needs loadorder.txt in its Data folder if you want it to enforce load order parity with bEnableModCheck.




Comments
Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.