Mod Load Order and Conflict Resolution

Intermediate40-60 minutesWindowsUnturned ServerNotepad++

When an Unturned™ server loads multiple mods from the Steam Workshop, it is inevitable that some mods will conflict. Two mods may define an item with the same ID, a map may include a resource with the same GUID as a Workshop addon, or a plugin may register a command that another plugin also registers. The question that every server operator eventually faces is: when two mods conflict, which one wins?

Unturned™ does not have a load-order manifest file. Unlike some games that let the operator specify an explicit loading priority for each mod, Unturned™ determines conflict resolution at runtime based on the order in which assets are loaded. The resolution is deterministic -- given the same set of mods loaded in the same order, the same conflicts resolve the same way every time -- but the order is determined by factors that the server operator can influence only indirectly.

This article is the 57 Studios™ reference for mod load order and conflict resolution. It covers how the asset loading pipeline processes Workshop content, the order in which assets are loaded, how GUID-based identity determines which asset definition takes precedence, how to diagnose which mod is winning a conflict, and strategies for managing conflicts without removing essential mods.

The console output above shows the Workshop content loading phase during server startup. Each line represents one Workshop item being processed, and the order of these lines determines the conflict resolution outcome when GUID collisions exist.

Documentation source: The conflict resolution behavior documented in this article is based on community observation and empirical testing by the 57 Studios™ team. The official Smartly Dressed Games modding documentation does not include a dedicated section on load-order guarantees.

Who this article is for

This article is written for Unturned™ dedicated server operators who run Workshop content and need to understand why some mods override others when conflicts occur. Familiarity with the Workshop subscription system and the server's Workshop_Download_ID configuration is assumed.

What you will learn

• How the asset loading pipeline processes Workshop content at server startup
• The loading order: vanilla assets first, then Workshop content in subscription order
• How GUID-based identity determines which asset definition takes precedence
• How to diagnose which mod is winning a conflict
• Strategies for managing conflicts without removing essential mods
• How to test whether a conflict exists between two specific mods

Background: how the asset loading pipeline works

The Unturned™ server loads assets in a specific sequence at startup. This sequence determines which asset definition the server uses when two mods define the same asset.

The load order is not configurable by file

Some games provide a loadorder.txt or plugins.txt file that explicitly defines the order in which mods are loaded. Unturned does not have such a file. The absence of an explicit load order manifest means that the server operator must use indirect methods to influence the order: reordering Workshop_Download_ID entries in Commands.dat, controlling which Workshop items are subscribed, and using a custom override mod that loads last.

The lack of an explicit load order is a deliberate design choice by SDG. The Workshop system is designed to be simple for content consumers: subscribe to a mod and it works. Explicit load order configuration is a power-user feature that SDG has not implemented, which means that server operators who need precise conflict resolution must use the indirect methods described in this article.

Loading sequence

1. Vanilla assets. The server loads all assets from the game's installation directory (Bundles/). These are the core game assets and are always loaded first. Vanilla assets define the baseline for every item, vehicle, map, and configuration.

2. Curated content. If the server has any curated content assets, these are loaded next. Curated content is published by SDG as part of the Unturned™ curated system and occupies a middle priority between vanilla and Workshop content.

3. Workshop content. The server loads all subscribed Workshop content in the order that Steam returns the subscription list. The subscription order within the Steam backend is not directly observable or controllable by the server operator. The order is determined by the order in which the items were subscribed, the order in which the Steam backend returns them during the startup query, and the server's Workshop_Download_ID configuration in Commands.dat.

4. Plugin content. If a plugin framework (RocketMod or OpenMod) loads additional assets at runtime, those assets are loaded after the Workshop content and may override Workshop definitions.

The flowchart above shows the asset loading sequence. Conflicts are resolved by replacement: when the server encounters an asset with a GUID that matches an already-loaded asset, the later-loaded definition replaces the earlier one.

The GUID as conflict resolution key

Unturned™ identifies assets by their GUID (Globally Unique Identifier). Every asset in the game -- every item, vehicle, map, NPC, quest, spawn table, and configuration -- has a GUID assigned in its .dat file. The GUID is the primary key for the asset registry. When the server loads an asset, it checks whether an asset with the same GUID is already registered.

• If no asset with that GUID exists, the new asset is added to the registry.
• If an asset with that GUID already exists, the new asset replaces the existing one.

This is the entire conflict resolution system. There is no merge logic, no partial override, no inheritance chain, and no compatibility check. The last-loaded asset wins by GUID. This means that the order in which assets are loaded determines the outcome of every conflict.

The GUID-based resolution applies to every asset type equally. A gun mod that uses the same GUID as a vanilla gun replaces the vanilla gun entirely. A map that includes a resource node with the same GUID as a Workshop resource asset replaces that resource. There is no mechanism for partial overrides.

Asset loading and memory considerations

The asset loading pipeline loads every asset into memory. Each asset occupies memory proportional to its data size. When an asset is replaced due to a conflict, the original asset's memory is not immediately reclaimed. The replacement makes the original eligible for garbage collection, but the collection does not run until the next cycle. During this window, both definitions exist in memory.

For servers with many conflicts, this temporary double-allocation contributes to memory pressure. The 57 Studios™ recommendation is to minimize conflicts not only for behavioral consistency but also for memory efficiency.

Workshop load order factors

The order in which Workshop items are loaded depends on several factors that the server operator can partially control.

Subscription order in Commands.dat

The Workshop_Download_ID entries in Commands.dat specify which Workshop items the server downloads and loads. The items are loaded in the order they appear in Commands.dat. If item A is listed before item B, item A loads first, and item B can override item A.

# Commands.dat
Workshop_Download_ID 1234567890   ← Loaded first
Workshop_Download_ID 2345678901   ← Loaded second (can override first)
Workshop_Download_ID 3456789012   ← Loaded third (can override second)

This ordering gives the server operator some control over load order within the Commands.dat list. By placing a mod that should have priority later in the list, the operator ensures that it loads after and can override earlier mods.

Steam client subscription order

When the server uses the Steam client's subscription management (the -NoWorkshopSubscriptions flag is not set), the Steam backend returns the workspace items in an order that the server does not control. Items that were subscribed earlier in time are typically returned before items that were subscribed more recently, but this is not a guaranteed ordering.

WorkshopDownloadConfig.json interaction

The WorkshopDownloadConfig.json file can configure per-item update behavior but does not affect load order. The Should_Monitor_Updates and Should_Auto_Update keys control whether a specific Workshop item triggers an update-triggered restart, not the order in which items are loaded.

Diagnosing which mod is winning a conflict

When a conflict occurs, the symptom is usually a gameplay behavior that does not match the operator's expectation. A gun mod that was supposed to have specific properties behaves differently because another mod with the same GUID overrode those properties. The diagnostic process for determining which mod is winning follows a structured approach.

Step 1: identify the conflicting asset

Determine the GUID of the asset that is behaving unexpectedly. The GUID can be found in the asset's .dat file in the Workshop item's folder structure. If the asset is a Workshop item, the GUID is in the Asset.dat file within that item's subfolder.

Step 2: search for the GUID across all loaded mods

Search every Workshop item's .dat files for the GUID you identified. Any mod that contains a .dat file with that GUID is a potential source of conflict. There will always be at least one (the expected mod); a conflict exists when there are two or more.

Step 3: determine the load order

Using the load order principles described in this article, determine which mod loads last among the mods that define the same GUID. The last-loaded mod wins the conflict.

Step 4: verify by testing

Temporarily remove the suspected winning mod from the server's Workshop list (by removing its Workshop_Download_ID from Commands.dat), restart the server, and observe whether the asset's behavior changes to what you expected. If it does, you have confirmed the conflict.

Managing conflicts

Strategy	How it works	Risk
Reorder Commands.dat	Move the preferred mod later in the Workshop_Download_ID list	Only affects items in the Commands.dat list; does not affect items loaded through client subscriptions
Remove the conflicting mod	Remove the unwanted mod from the Workshop subscription list	Loses all content from that mod, not just the conflicting asset
Use a custom override mod	Create a mod that defines the same GUID with the desired properties and add it last in Commands.dat	Requires mod authoring skills; the override mod must stay updated if the original mod's GUID changes
Accept the conflict	Leave both mods loaded and let the engine resolve the conflict naturally	Produces unpredictable behavior if the conflict affects a critical asset

Log-based conflict detection

The server log is the primary tool for detecting conflicts without manually searching .dat files. The asset loading phase at startup produces log entries for every loaded asset, and conflicts appear as specific patterns in these entries.

Conflict log entry patterns

When the asset registry replaces an existing asset with a new one, the log may contain entries such as:

[Asset] Replacing asset [GUID: a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d] with new definition from [Workshop item name]

Not all conflicts produce a log entry. The log output depends on the server's log verbosity level and the specific asset type. Some asset types silently replace without logging. The absence of a conflict log entry does not guarantee that no conflicts exist.

Log analysis workflow

1. Start the server and wait for the asset loading phase to complete.
2. Open the server log file (typically Servers/<ServerName>/Logs/<date>.log).
3. Search for "replacing", "conflict", "duplicate", "already registered", or "overwriting".
4. For each match, record the GUID, the asset type, and the two conflicting sources.
5. Cross-reference the GUID against the Workshop items in your modlist to identify the conflicting mods.
6. Determine whether the conflict is acceptable or requires resolution.

Log-based conflict detection limitations

The log-based approach has several limitations that operators should be aware of. Not all asset types produce log output when replaced. The log entry format may vary across server versions. The log may not include the Workshop item name for the mod that is doing the replacing. And the log may scroll past during startup on servers with very high numbers of assets, making it difficult to capture all conflict entries in a single read.

For thorough conflict detection, the 57 Studios™ recommendation is to combine log analysis with a periodic manual GUID search across all loaded mods. The log catches conflicts that produce output; the manual search catches conflicts that produce no output.

Diagnostic table

Symptom	Likely cause	Resolution
A Workshop gun has vanilla stats	A vanilla asset with the same GUID loaded after the Workshop gun	Check whether a mod or map redefines the gun's GUID; add the Workshop gun later in Commands.dat
A map's custom resource does not appear in-game	A Workshop mod overrides the resource's GUID	Remove or reorder the conflicting Workshop mod, or change the resource's GUID in the map files
A plugin command does not work	Another plugin registers the same command name	Change the command name in one of the plugins, or use a plugin framework that supports command priority
An item's icon is wrong after adding a new mod	The new mod redefines the item's GUID with a different icon	Check whether the new mod intentionally overrides the item; if not, report the GUID conflict to the mod author
A vehicle appears with the wrong model or stats	Two vehicle mods share the same GUID	Identify both mods and either remove one or create a custom override
Server crashes on startup with a GUID-related error	Two mods define the same GUID and the resulting state is inconsistent	Remove one of the conflicting mods; the crash indicates that the asset engine cannot handle the conflict gracefully
The server logs show "Replacing asset [GUID]" messages	This is normal behavior when conflicts occur	Check the log for unexpected replacement messages that indicate a mod you did not expect to override a specific asset

The role of the Unturned asset registry

The asset registry is the runtime data structure that maps GUIDs to asset instances. Understanding how the registry works helps operators predict conflict behavior.

Registry initialization

When the server starts, the registry is empty. As each asset is loaded from the file system, the registry checks whether an asset with the same GUID already exists. If not, the new asset is added. If yes, the existing asset is replaced. This check-and-replace operation happens for every asset, every time.

Registry identity constraints

The registry enforces GUID uniqueness. No two assets in the registry can have the same GUID at the same time. This constraint is what makes conflict resolution necessary -- if two mods could coexist with the same GUID, there would be no conflict, but there would also be no way to determine which definition the game should use.

Registry and hotloading

The asset registry is initialized during server startup and does not change until the server restarts. Workshop content that is subscribed while the server is running is not loaded until the next restart. This means that adding a new mod while the server is running has no effect on the registry state, and conflicts that exist between the new mod and current mods only surface after a restart.

Conflict detection tools and techniques

Manual GUID search

The most reliable conflict detection method is a manual search across all mod .dat files. This is labor-intensive for servers with many mods but produces definitive results.

Automated GUID scanning

For servers with 20 or more Workshop items, automated scanning is recommended. A script that downloads all subscribed Workshop items, extracts all GUID values, and reports duplicates saves significant manual effort. The 57 Studios™ team maintains an internal tool for this purpose.

In-game observation

Some conflicts are detectable through gameplay observation. An item that has the wrong icon, incorrect stats, or unexpected behavior may indicate a GUID conflict. The server operator who knows which mods are installed and what each mod should change can often identify conflicts by noticing that a specific asset behaves according to a different mod's definition than expected.

Server log analysis

The server log is the first place to check when a conflict is suspected. Search the log for lines containing "already" or "replacing" during the asset loading phase at startup. Not all conflicts are logged, but many produce a message that the operator can use to identify the conflicting GUID.

Frequently asked questions

Can I control the exact load order of all Workshop items?

Not completely. The Commands.dat ordering controls items loaded through Workshop_Download_ID, but items that the server loads through other mechanisms (such as content that comes bundled with a map or content loaded through client-side subscriptions) follow a different ordering determined by the Steam backend.

Does the load order on the dedicated server match the load order in single-player?

The loading pipeline is the same, but the set of loaded mods may differ. A single-player client loads the player's personal Workshop subscriptions. A dedicated server loads only the Workshop_Download_ID entries in Commands.dat. The conflict resolution mechanism (last-loaded GUID wins) is the same in both environments.

What happens if two mods use the same GUID by accident?

The second-loaded mod replaces the first-loaded mod silently. The engine does not warn the operator or the player about the GUID collision. The only indication that a conflict occurred is that the behavior of the asset matches the second-loaded mod's definition rather than the first-loaded mod's definition.

Can I see which assets are being replaced in the server log?

The server log includes messages about asset loading. Depending on the log verbosity, the server may print a line indicating that an asset is being replaced. Search the log for "replacing" or "already registered" to find conflict entries.

Is there a way to merge two mods that define the same GUID?

No. Unturned does not support merging asset definitions. The last-loaded definition completely replaces the earlier definition. To combine features from two mods, you must create a custom mod that includes the desired properties from both sources under a single GUID.

How do I check whether a specific mod uses GUIDs that conflict with another mod?

Download both mods to a local development machine. Search all .dat files in both mods for GUID values. If any GUID appears in both mods, the mods conflict for that asset. Use a text search tool that supports recursive directory search (grep, Findstr, or a code editor's search function).

Does the asset registry loaded order apply to every asset type equally?

Yes. The GUID-based resolution system applies to every asset type defined in the game. Items, vehicles, maps, NPCs, quests, spawn tables, effects, animals, resources, barricades, structures, and all other asset types use the same registry and the same resolution rule. There are no special-case asset types that use a different conflict resolution mechanism.

Can a map mod override assets from other Workshop mods?

A map can include assets such as custom resources, spawn tables, and objects. If the map defines an asset with a GUID that matches a Workshop mod's GUID, the map's asset wins if the map is loaded after the Workshop mod. Maps are loaded as part of the Workshop content sequence, not separately, so the load order depends on where the map's Workshop_Download_ID appears in Commands.dat.

How does the conflict resolution interact with the -OfflineOnly launch option?

When the server is launched in -OfflineOnly mode, the asset loading sequence is the same: vanilla assets, curated content, then Workshop content from the cache. The conflict resolution mechanism (last-loaded GUID wins) does not change. The only difference is that the Workshop subscription list is read from the local cache rather than from the live Steam backend, which means the ordering is more deterministic -- it is the order in which items were cached on disk.

Can a map's bundled assets override dedicated Workshop items?

A map can include assets within its own file structure. Those assets are loaded when the map loads, which is after the Workshop content loading phase. Assets that are loaded during map loading use the same GUID-based registry, so they can override earlier-loaded assets. This is the mechanism by which map-makers can customize loot tables, resources, and objects for their specific map without requiring a separate Workshop item.

What is the best way to verify the load order for my specific server configuration?

Create a test environment with the same set of Workshop items as the production server. Add a test indicator mod that prints a log message at a specific load order position. Add this test mod at different positions in Commands.dat and observe the log messages to confirm the effective ordering. Do this once after the initial modlist setup and repeat if the modlist changes significantly.

How do I create an override mod?

An override mod is a minimal Workshop item that contains only the asset files that need to be overridden. Each asset file in the override mod defines the same GUID as the original asset but with different field values. The override mod must be listed last in Commands.dat to ensure it loads after all other content. The override mod does not need to duplicate the original mod's entire file structure, only the specific .dat files that define the conflicting GUIDs.

Does the conflict resolution apply to asset IDs (the uint16 ID field) or only to GUIDs?

The conflict resolution applies primarily to GUIDs. The uint16 ID field is used for legacy compatibility and spawn table references, but the asset registry uses the GUID as the primary key. Two mods that use the same uint16 ID but different GUIDs produce two separate assets, each with their own identity. Two mods that use the same GUID produce one asset (the last-loaded definition wins).

Can a plugin deliberately override a Workshop asset at runtime?

Yes. A plugin can register an asset with the same GUID as an existing asset, and the asset registry will use the plugin's definition. Plugin-loaded assets are loaded after Workshop content, so a plugin that defines an asset GUID can override any Workshop mod that loaded earlier.

What is the recommended strategy for a server with many mods?

The 57 Studios™ recommendation for servers with 10 or more Workshop items is: maintain a Commands.dat with a clear ordering convention. List foundational mods first (map, core gameplay changes), then content mods (items, vehicles, guns), then cosmetic mods (skins, sounds), then override mods (your custom patches). This ordering ensures that the most important mods for your server's identity load last and override anything that conflicts.

Do load order conflicts cause save data corruption?

Conflicts that change an asset's properties after a save was created can produce inconsistent save data. For example, if a gun mod defined a GUID with Damage_Player 50 when the player's save was created, and a conflicting mod now defines the same GUID with Damage_Player 25, the saved item on the player retains its original damage value until the item is re-dropped or re-created. This is data inconsistency, not corruption. True corruption (data that cannot be read) is rare from GUID conflicts alone.

Worked example: resolving a GUID conflict between two weapon mods

This worked example traces the resolution of a real conflict between two hypothetical Workshop gun mods: "Tactical Rifle Pack" (TRP) and "Survival Weapons Expansion" (SWE). Both mods define a weapon with the same GUID, but each mod defines different stats for that weapon.

Step 1: identify the symptom

The server operator notices that the "Marksman Rifle" from the Tactical Rifle Pack is behaving with the wrong damage values. The TRP documentation states the rifle should deal 55 player damage, but in-game testing shows it deals 42 player damage. The operator suspects a conflict.

Step 2: find the GUID

The operator navigates to the TRP mod's folder in the Workshop content directory and opens Asset.dat for the Marksman Rifle item. The GUID is found on the GUID line:

GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d

Step 3: search for the GUID in other mods

The operator searches all Workshop content directories for the same GUID. The search reveals that the Survival Weapons Expansion mod also defines a .dat file with GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d. The SWE version of the rifle has Damage_Player 42 -- the value that the server is actually using.

Step 4: determine the load order

The operator checks Commands.dat:

Workshop_Download_ID 1111111111  # Tactical Rifle Pack (TRP)
Workshop_Download_ID 2222222222  # Survival Weapons Expansion (SWE)

SWE is listed after TRP, which means SWE loads later and wins the conflict. The TRP rifle definition is loaded first and then replaced by the SWE version when the server processes the SWE Workshop item.

Step 5: decide on the resolution strategy

The operator considers three options:

1. Reorder Commands.dat. Move TRP after SWE so that TRP loads last and wins. This would restore the TRP damage values but would lose any SWE overrides that are intentional.

2. Create an override mod. Create a custom mod that defines GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d with the desired Damage_Player 55 and list this override mod last in Commands.dat.

3. Remove one mod. Remove SWE from the subscription list, which would lose all other content from that mod.

The operator chooses option 2 (custom override mod) because it preserves both mods' content while ensuring the critical GUID uses the desired properties.

Step 6: create the override mod

The operator creates a minimal override mod with a single .dat file that defines the conflicting GUID with only the fields that need to change:

GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d
Damage_Player 55

The override mod is added as a new Workshop item or as a local file in the server's content directory.

Step 7: test and verify

The operator adds the override mod's ID at the end of Commands.dat, restarts the server, and spawns the Marksman Rifle. The damage value is now 55 as expected. The operator tests other affected items to confirm that the override did not unintentionally change any other assets.

Conflict types beyond GUID collisions

While GUID collisions are the most common conflict type, other conflict types can affect server behavior.

ID collisions

Two items with the same uint16 ID but different GUIDs are separate assets. However, spawn tables and legacy references use the uint16 ID. If two items share the same ID, spawn table entries that reference that ID may spawn the wrong item. The engine resolves this by selecting the item that registered first (earliest in load order), which is the opposite of the GUID resolution rule.

Command name collisions

Two plugins that register commands with the same name produce a conflict that manifests as one plugin's command handler silently replacing the other's. The plugin that registers its command last wins. Plugin frameworks (RocketMod, OpenMod) may provide command priority systems that override this default behavior.

Workshop file path collisions

Two Workshop items that include files at the same relative path within their content folders can conflict if the server's file system merges the directories. In practice, Workshop items are isolated from each other and file path collisions are rare.

Best practices

• Maintain a single Commands.dat with all Workshop items listed in priority order (lowest priority first, highest priority last).
• Create a dedicated "override" mod that defines the specific asset GUIDs with your server's desired properties and list it last in Commands.dat.
• Search for GUID collisions before adding a new mod to the server's modlist. A GUID conflict that is discovered after weeks of playtime is more disruptive than one caught during onboarding.
• Keep a manifest of every asset GUID that your override mod defines, and check it against new mods before adding them.
• Test every new mod combination on a staging server before deploying to production. A silent GUID conflict can go undetected for days.
• Monitor the server log for "replacing" messages after adding new Workshop items.

Conflict prevention through mod authoring conventions

Mod authors can prevent GUID conflicts by following standard practices when creating their Workshop items.

Use fresh GUIDs

Every Workshop item should use newly generated GUIDs for every asset it defines. Reusing a GUID from a tutorial, a template, or another mod guarantees a conflict with whatever other mod uses that same GUID. A fresh GUID generated with a UUID v4 generator has a collision probability that is effectively zero for practical purposes.

Document GUID ranges

Mod authors who release multiple related items should document the GUID range that their mods use. This allows server operators to check whether a GUID from one mod falls within the documented range of another mod before adding both to the same server. GUID ranges are not enforced by the engine but serve as a coordination convention.

Use descriptive asset names

The Name field in an asset's .dat file does not affect conflict resolution (GUIDs are the key), but a descriptive name helps operators identify assets when searching log files and mod directories. A mod that names all its assets "MyItem1", "MyItem2", etc. makes conflict diagnosis harder than a mod that uses descriptive names.

Avoid uint16 ID collision with vanilla range

The uint16 ID field does not affect GUID-based conflict resolution, but ID collisions cause issues with spawn tables and legacy references. The vanilla game uses IDs from 0 to approximately 2000. Mods should use IDs above 50000 to avoid ID collisions with vanilla assets. The SDG documentation recommends this range and the 57 Studios™ team validates it.

Appendix A: GUID conflict detection workflow

Step	Action	Tool
1	Download all Workshop items to a local directory	SteamCMD or manual download
2	Extract all GUID values from every .dat file	Recursive grep for GUID
3	Find duplicate GUIDs across different mods	Sort and compare GUID lists
4	Record each duplicate pair (mod A, mod B, GUID)	Spreadsheet or text file
5	Determine which mod loads last for each pair	Check Commands.dat order
6	Decide whether the conflict is acceptable	Evaluate the gameplay impact

Appendix B: Asset loading order observation technique

The fastest way to determine the actual load order on a running server is to add a test asset that outputs a log message when loaded. Create a minimal test mod with a unique GUID and add it to Commands.dat at a known position. After restarting the server, check the log for the test asset's loading message. The relative position of this message among other asset loading messages tells you the effective load order position.

For servers where the exact load order matters (those with many conflicting mods), the 57 Studios™ recommendation is to create a set of numbered test mods that each register a different GUID. Add them to Commands.dat in a specific order and observe the log to confirm that the loading sequence matches the Commands.dat order.

Appendix C: Conflict resolution decision matrix

Conflict type	Resolution mechanism	Operator control	Detection method
GUID collision	Last-loaded wins	Reorder Commands.dat	GUID search across mod .dat files
uint16 ID collision	First-loaded wins	Reorder Commands.dat	ID search across mod .dat files
Command name collision	Last-registered wins	Plugin framework priority	Server log command registration messages
File path collision	Last-written wins	File system order	File existence check in Workshop directories
Map asset vs Workshop asset	Whichever loads last	Reorder Commands.dat	GUID search in map files

Appendix D: Mod compatibility testing workflow

Phase	Action	Duration	Frequency
Pre-add	Search for GUID collisions between new mod and existing modlist	15 minutes	Per new mod
Pre-add	Test new mod on staging server with full modlist	1 hour	Per new mod
Post-add	Monitor server log for "replacing" messages on first restart	Upon first restart	Per new mod addition
Ongoing	Weekly log review for unexpected asset behavior	10 minutes	Weekly

Appendix E: External references

• Smartly Dressed Games modding documentation -- official documentation for asset format, GUID requirements, and Workshop publishing.
• Workshop Content on Dedicated Servers -- the Workshop content configuration article that covers Commands.dat setup.
• GUID Conflicts Between Mods -- troubleshooting article for GUID conflict issues.
• Airdrop Asset Reference -- the next article in this series.

Document history

Version	Date	Author	Notes
1.0	2026-07-26	57 Studios	Initial publication. Complete reference for mod load order determination, GUID-based conflict resolution, diagnostic process, management strategies, and best practices.

Authoring checklist

• [ ] All Workshop items are listed in Commands.dat with the highest-priority items last
• [ ] A GUID search has been performed across all loaded mods to detect known conflicts
• [ ] An override mod is configured for servers with conflicting mods
• [ ] The server operator understands that the last-loaded GUID wins
• [ ] A staging server is used for testing new mod combinations before deployment
• [ ] The server log is checked for "replacing" messages after adding new Workshop items

Appendix F: Load order and conflict glossary

Term	Definition
Asset registry	The runtime data structure that maps GUIDs to asset instances
Conflict	A situation where two or more mods define an asset with the same GUID
GUID	Globally Unique Identifier, the primary key for the asset registry
Load order	The sequence in which mods are processed during startup
Override mod	A custom mod that defines specific GUIDs with desired properties and is loaded last
Replacement	The operation of discarding an existing asset definition when a new one with the same GUID is loaded
Resolution	The mechanism by which the engine determines which asset definition to use when a conflict exists
Workshop	The Steam platform for sharing and distributing mods

Appendix G: PowerShell script for GUID conflict scanning

# Scan all .dat files in a directory for GUID values
$modsDir = "C:\WorkshopContent"
$guidPattern = "GUID\s+([a-f0-9]{32})"
$matches = @{}

Get-ChildItem -Path $modsDir -Filter "*.dat" -Recurse | ForEach-Object {
    $content = Get-Content $_.FullName -Raw
    if ($content -match $guidPattern) {
        $guid = $matches[1]
        $modName = $_.Directory.Parent.Name
        if (-not $matches.ContainsKey($guid)) {
            $matches[$guid] = @()
        }
        $matches[$guid] += $modName
    }
}

# Report duplicate GUIDs
$matches.Keys | Where-Object { $matches[$_].Count -gt 1 } | ForEach-Object {
    Write-Host "Duplicate GUID: $_"
    $matches[$_] | ForEach-Object { Write-Host "  - $_" }
}

Cross-references

• Debugging Server Exceptions -- the previous article; covers IL offset debugging for server-side errors that may be caused by conflicts.
• Airdrop Asset Reference -- the next article; covers airdrop asset configuration.
• Workshop Content on Dedicated Servers -- Commands.dat configuration and Workshop download management.
• GUID Conflicts Between Mods -- dedicated troubleshooting article for GUID collision scenarios.
• Smartly Dressed Games modding documentation -- official documentation for asset identity and Workshop publishing.
• Unturned on Steam -- Unturned™ store page.