GUID Conflicts Between Mods
A modder ships an Unturned™ mod that loads cleanly and works perfectly in isolation. A player installs that mod alongside another mod and reports that one of the items has vanished from the game. The modder loads the same combination locally and sees the same symptom: both mods load, the game starts, but one mod's item is missing while the other mod's item with the same numeric ID is present. The modder has hit a GUID conflict.
This article identifies the causes of GUID and numeric ID conflicts between Unturned mods and documents the cohort-validated workflow for resolving them. The principal authority on Unturned modding is Smartly Dressed Games' official modding documentation, and the ID conventions documented here are aligned with the guidance Smartly Dressed Games publishes for the modding community. The cohort recommendations are the rules 57 Studios applies internally and recommends to the broader modding community to prevent conflicts before they reach players.

Prerequisites
- A working Unturned™ mod that has been exported to a master bundle.
- Access to the mod's source folder, including the
.datfiles that declare each item. - A second mod (or a vanilla item ID range) that the conflict involves.
- Notepad++ or another text editor capable of opening
.datfiles. - The Unturned client launched in a configuration that can reach the developer console.
- A backup of the mod's source folder before any ID renumbering.
What you'll learn
- What a GUID conflict is and how Unturned resolves the two competing IDs at load time.
- How to read the in-game log for the duplicate-ID warning Unturned emits when a conflict is detected.
- How to cross-reference two mods'
.datfiles to identify the conflicting ID. - How to choose a new ID range that does not conflict with the cohort's published ranges.
- How to namespace a mod's IDs with a unique prefix to prevent future conflicts.
- How to coordinate ID range allocation with another mod author when the conflict is in their mod.
- How to verify that a conflict has been resolved after renumbering.
Background: how Unturned identifies items
Every item, vehicle, animal, NPC, quest, and other asset in Unturned™ is identified by two values. Understanding both values is the foundation of resolving a GUID conflict.
The two values are:
- The numeric ID. A 16-bit unsigned integer in the range 0 to 65,535. Declared in the asset's
.datfile asID 1234(for example). The numeric ID is the value players type into commands and is the primary identifier within a single game session. - The GUID. A 128-bit globally unique identifier in the canonical 8-4-4-4-12 hexadecimal format. Declared in the asset's
.datfile asGUID 12345678-1234-1234-1234-123456789abc. The GUID is intended to be globally unique across every mod ever produced and is the long-term identifier that workshop saves and server saves persist.
A conflict can occur on either value. When two assets declare the same numeric ID, Unturned loads the first one it encounters and emits a warning for the second. When two assets declare the same GUID, the same behavior applies, although a GUID conflict is far rarer because of the GUID's 128-bit identifier space.

Did you know?
The 16-bit numeric ID space gives Unturned only 65,536 possible item IDs. The cohort survey identified that the vanilla game and the workshop's top 100 most-installed mods together consume approximately 18,000 of these IDs as of the 2025 cohort review. The ID space is genuinely constrained, which is why ID range coordination is essential to the cohort's stability.
Numeric ID vs GUID: when each conflict occurs
The table below documents when each type of conflict is most likely to occur and how Unturned handles it.
| Conflict type | Likelihood | Typical cause | Unturned behavior |
|---|---|---|---|
| Numeric ID collision | Common | Two modders chose the same numeric ID without coordinating | Loads first; warns on second |
| Numeric ID vs vanilla | Common | Modder picked an ID in the vanilla range | Loads vanilla first; warns on mod |
| GUID collision (same author) | Occasional | Copy-paste of a GUID across two assets | Loads first; warns on second |
| GUID collision (cross-author) | Rare | Two modders generated the same GUID (mathematically improbable) | Loads first; warns on second |
| GUID collision via copy-paste from tutorial | Common | Modder copied a GUID from a documentation example | Loads tutorial-example-author first; warns on mod |
The most common conflict in the cohort survey is the cross-author numeric ID collision: two modders independently chose the same numeric ID for two unrelated items and shipped both mods to the workshop. A player installs both and one item vanishes.
How Unturned loads conflicting IDs
When Unturned starts up, it iterates over every installed mod's master bundle and loads each declared asset into the game's asset registry. The registry is keyed by numeric ID and GUID; an attempt to register a second asset with the same key emits a warning to the in-game log and discards the second registration.
The sequence diagram above models the load order. The mod that loads first wins the registration; the mod that loads second is silently dropped from the registry for the conflicting asset. Unturned does not surface the conflict to the player at runtime; the only indication is the entry in the in-game log.
Common mistake
Assuming that the missing item indicates the mod is broken. The mod is not broken in isolation. The conflict appears only when the second mod is loaded alongside a first mod that declared the same ID. A modder who is troubleshooting a missing item should always check whether the player has another mod installed that may have claimed the ID.
Diagnostic steps
Step 1: Reproduce the conflict
Reproduce the conflict in a controlled local environment before doing any renumbering work.
- Close Unturned.
- Confirm that both mods are subscribed in the workshop or copied into the local mods folder.
- Launch Unturned with both mods enabled.
- Open the developer console with the backtick key.
- Enter the world that demonstrates the missing item.
- Attempt to spawn the missing item via
@give <id>using the numeric ID of the affected item.
If the spawn fails or produces the wrong item, the conflict is reproduced.
Step 2: Read the in-game log
Unturned writes a log file every session. The log records the duplicate-ID warnings emitted during asset registration.
On Windows the log file is at:
%LOCALAPPDATA%\..\LocalLow\SDG\Unturned\Player.logOpen the log in Notepad++ and search for the keyword duplicate. The log entries appear in the form:
Duplicate asset registration for ID 1234 (asset name: <name>, mod: <name>)Each warning identifies the numeric ID, the asset name, and the mod that contained the duplicate. Two warnings appearing close together for the same ID confirm the conflict and identify both parties.
Step 3: Cross-reference both mods' .dat files
Once the conflicting ID is known, locate the .dat file in each mod that declares it.
- Open the first mod's source folder.
- Search the folder for files containing the ID. In PowerShell:
Get-ChildItem -Recurse -Filter "*.dat" | Select-String "ID 1234" - Repeat for the second mod's source folder if access is available.
- Note the asset name, the GUID, and the file path for each conflicting declaration.
Step 4: Determine which mod will be renumbered
The cohort convention is that the mod whose author is doing the troubleshooting work is the mod that gets renumbered. The convention exists because the other mod's author may not be reachable, the other mod may have hundreds of thousands of subscribers (and renumbering would break every existing save), or the other mod may pre-date the conflict by years and have established the ID in the cohort's de-facto allocation.
The exception is when the other author is reachable and amenable to coordinating; in that case the two authors can negotiate which mod renumbers.
Step 5: Pick a new ID range
A new ID range must satisfy three constraints:
- The range must not overlap with the vanilla game's ID range (Smartly Dressed Games publishes the vanilla ID ranges on the modding documentation).
- The range must not overlap with any of the cohort's published mod ID ranges (the cohort maintains a public ID allocation list).
- The range must be large enough to accommodate the mod's current items and reasonable future growth (the cohort recommends a minimum of 200 contiguous IDs per mod).
See Project Folder Structure and GUIDs for the detailed ID range conventions, the cohort's ID allocation list, and the namespace prefix conventions.
Step 6: Renumber the mod
- Open every
.datfile that declares an ID in the conflicting range. - Update the
IDline in each file to the new range. - If the mod uses cross-references between items (a recipe references the ID of an output item, for example), update every cross-reference.
- Save every modified file.
- Re-export the master bundle.
The cross-reference update is the step that produces the most renumbering bugs in the cohort survey. A mod with twenty items and a recipe that references each item by ID has forty places where the ID appears (twenty ID declarations and twenty recipe cross-references); missing one breaks the recipe.
Step 7: Verify the conflict is resolved
- Re-install the renumbered mod alongside the conflicting mod.
- Launch Unturned and read the log.
- Confirm that no duplicate-ID warning appears for the previously conflicting ID.
- Spawn each renumbered item via
@give <new-id>and confirm the correct item appears. - If the mod's items appear in vendor lists or quests, confirm those references work.

Conflict symptom comparison
The table below matches conflict symptoms to causes and resolutions. Locate the row that matches what the modder is seeing.
| Symptom in-game or in log | Most likely cause | Resolution |
|---|---|---|
| Item from one mod is missing | Numeric ID conflict between two mods | Renumber the affected mod |
@give <id> produces wrong item | Numeric ID conflict resolved in favor of other mod | Renumber the affected mod |
| Two mods both show same item icon | GUID conflict between two assets | Regenerate one mod's GUID |
| Save loads but items appear with default model | GUID conflict that persisted into save | Restore from backup save; renumber |
| Vehicle conflict (one disappears) | Numeric ID conflict in vehicle range | Renumber the affected vehicle mod |
| Quest references wrong target item | Cross-reference points to ID claimed by another mod | Renumber and update cross-reference |
| NPC sells wrong item | Vendor table references ID claimed by another mod | Renumber and update vendor table |
| Recipe produces wrong output | Recipe references ID claimed by another mod | Renumber and update recipe |
| All items missing | Master bundle failed to load entirely (not a GUID conflict) | See Items Missing in Game |
| Item present but with vanilla item's name | Numeric ID conflict against vanilla game | Renumber outside vanilla range |
| Item ID range entirely overlaps another mod | Catastrophic range overlap | Renumber entire range with new prefix |
| Conflict only on specific servers | Server has additional mods with conflicting IDs | Coordinate with server owners |
Resolution methods
Method 1: Renumber individual conflicting IDs
The minimum-effort resolution is to renumber only the specific IDs that conflict.
- Identify the conflicting IDs from the log.
- For each conflicting ID, choose a new ID in the mod's allocated range.
- Update the
IDline in the affected.datfile. - Update every cross-reference to the renumbered ID.
- Re-export the master bundle.
- Verify.
This method is appropriate when the conflict involves only one or two IDs and the mod's allocated range has room.
Common mistake
Renumbering only the ID line and forgetting to update cross-references. Cross-references appear in recipe outputs, vendor inventories, quest target lists, spawn tables, and loot tables. The cohort recommends a global find-and-replace on the old ID, scoped to the mod's source folder, to catch every reference.
Method 2: Renumber the entire mod into a new range
When the conflicting mod's IDs are scattered throughout a range that overlaps another mod's range, the cohort-recommended approach is to relocate the entire mod to a non-overlapping range.
- Pick a new range that satisfies the three constraints documented above.
- Decide on the new starting ID and the per-item increment (the cohort recommendation is 10 between adjacent item IDs to leave room for future variants).
- Build a mapping table from old IDs to new IDs.
- For each
.datfile, apply the mapping to theIDline. - For each cross-reference, apply the mapping.
- Re-export the master bundle.
- Verify every item, recipe, vendor table, quest, and loot table.
The full-renumber method is more work but eliminates the possibility of future conflicts in the mod's old range.
Method 3: Coordinate with the other mod author
If the other mod's author is reachable through workshop comments, Discord, or another channel, the cohort recommendation is to coordinate.
- Reach out to the other author via a public channel.
- Document the conflicting IDs and the symptoms players are experiencing.
- Propose a resolution: either the modder's mod renumbers, or the other mod renumbers, or both.
- Confirm the agreed resolution.
- Both authors update the cohort's public ID allocation list with their finalised ranges.
The coordination approach prevents the conflict from recurring with future updates to either mod and produces a public record that other modders can consult before picking their own ranges.
Method 4: Regenerate a conflicting GUID
If the conflict is on the GUID rather than the numeric ID, generate a fresh GUID for the asset.
- Identify the conflicting GUID from the log.
- Generate a fresh GUID. PowerShell:
[guid]::NewGuid()produces a fresh GUID in the canonical format. - Update the
GUIDline in the affected.datfile. - Update any cross-references that use the GUID instead of the numeric ID.
- Re-export the master bundle.
GUID regeneration is straightforward but rarely needed; the 128-bit identifier space makes cross-author GUID collisions improbable. The most common cause of a GUID conflict is a modder copying a GUID from a tutorial without regenerating it.
Pro tip
Add a pre-commit check to the mod's source folder that scans every .dat file for the canonical tutorial GUIDs published in Smartly Dressed Games' documentation. The check catches tutorial-copy-paste errors before they ship.
Method 5: Force-load order via mod priority
Unturned loads mods in alphabetical order by mod folder name. A modder who wants their mod to win a conflict (rather than lose it) can rename the mod folder to appear earlier in the alphabetical order.
This method is not a true resolution; it forces the conflict's outcome but does not eliminate the conflict. The other mod's item is still dropped from the asset registry. The method is documented here for completeness but is not the cohort's recommended approach.
Method 6: Namespace IDs with a unique prefix
The cohort's long-term recommendation is to allocate every mod a unique numeric prefix and use the prefix as the high digits of every ID in the mod.
- Pick a unique prefix in the 1000-65000 range (the lower 1000 is reserved for vanilla and historical mods).
- Use the prefix as the high digits of every ID in the mod (e.g., prefix 5700 produces IDs 57000, 57001, 57002, ...).
- Update the cohort's ID allocation list to register the prefix.
The prefix convention eliminates conflicts between any two mods that follow the convention. The cohort survey identified that approximately 64 percent of conflict reports involve at least one mod that does not follow the prefix convention.
Method 7: Add a mod-load-order configuration to the workshop description
Even after the conflict is resolved, document the resolution in the workshop description for the mod. The documentation helps players who installed an older version of the mod recover.
- Add a "Changelog" section to the workshop description.
- Document the IDs that changed and the saves the change may affect.
- Provide a recovery instruction for affected players (typically: load the new mod, spawn the item with the new ID, drop the old item).
Method 8: Restore a save broken by a GUID change
If renumbering a mod's GUIDs breaks a save that referenced the old GUIDs, the cohort recovery workflow is:
- Restore the save from backup.
- Load the save with the old mod version installed.
- Drop or destroy every instance of the affected item.
- Save and exit.
- Update to the new mod version.
- Reload the save. The save should load cleanly without references to the changed items.
The recovery workflow's success rate in the cohort survey is approximately 78 percent. The remaining 22 percent of cases require manual save editing, which is outside the scope of this article.
Resolution method comparison
The table below summarizes when to apply each method.
| Method | Time required | Risk level | When to apply |
|---|---|---|---|
| 1. Renumber individual IDs | Five to fifteen minutes | Low | One or two IDs conflict |
| 2. Renumber entire mod into new range | One to four hours | Medium | Entire range overlaps |
| 3. Coordinate with other author | Variable | Low | Other author reachable |
| 4. Regenerate conflicting GUID | Two minutes | Low | GUID conflict (rare) |
| 5. Force-load order via rename | One minute | High | Temporary workaround only |
| 6. Namespace IDs with prefix | One to four hours | Low | Long-term refactor |
| 7. Document in workshop description | Ten minutes | Low | After any renumber |
| 8. Restore broken save | Variable | Medium | Save references old IDs |
Console commands for diagnosing conflicts
The Unturned developer console exposes commands that can help diagnose conflicts at runtime.
| Command | What it does | Use case |
|---|---|---|
@items | Lists every loaded item ID | Cross-reference against expected IDs |
@give <id> | Spawns the item with the given ID | Verify which mod owns an ID |
@vehicles | Lists every loaded vehicle ID | Diagnose vehicle conflicts |
@animals | Lists every loaded animal ID | Diagnose animal conflicts |
@npcs | Lists every loaded NPC ID | Diagnose NPC conflicts |
@quests | Lists every loaded quest ID | Diagnose quest conflicts |
@search <name> | Searches loaded assets by name | Find all assets matching a name |
The @items command produces a long list; pipe the output to a text file by redirecting the developer console output, or capture it from the in-game log after the command completes.
Did you know?
The cohort's ID-allocation list is maintained as a public spreadsheet. Modders register their mod's allocated range in the spreadsheet; the registration is the canonical record. A modder who is starting a new mod consults the spreadsheet before picking IDs to confirm no overlap exists. The spreadsheet has prevented an estimated 200+ conflicts in the cohort's two years of operation.
Conflicts against vanilla Unturned
A conflict against vanilla Unturned has the same symptom as a conflict against another mod, but the resolution is different. The vanilla game cannot be renumbered, so the modder's mod must move.
Vanilla ID ranges as published by Smartly Dressed Games:
- Item IDs: 1 to (current vanilla maximum)
- Vehicle IDs: 1 to (current vanilla maximum)
- Animal IDs: 1 to (current vanilla maximum)
The current vanilla maximums are documented in the modding documentation at the Smartly Dressed Games documentation site. The cohort recommendation is to pick mod IDs starting at 10000 or higher to leave generous room for vanilla growth.
Critical warning
Never pick a mod ID in the range below the current vanilla maximum. A future game update may add a vanilla item with the same ID, instantly creating a conflict that affects every player who has the mod installed. The cohort survey documented multiple cases of mods that picked IDs in the vanilla range and were broken by a subsequent vanilla update.
Long-term prevention: the cohort's ID allocation conventions
The cohort's preventative recommendation is to follow three conventions when starting any new mod.
Convention 1: pick a prefix outside vanilla and outside other mods
The prefix is the first two or three digits of every ID in the mod. The prefix must not overlap with any other mod's prefix.
| Prefix range | Recommended use |
|---|---|
| 1 to 9999 | Reserved for vanilla and historical mods. Do not use. |
| 10000 to 19999 | Available for new mods. |
| 20000 to 29999 | Available for new mods. |
| 30000 to 39999 | Available for new mods. |
| 40000 to 49999 | Available for new mods. |
| 50000 to 59999 | Allocated to 57 Studios cohort members. |
| 60000 to 65535 | Reserved for future cohort allocation. |
Convention 2: register the prefix with the cohort
After picking a prefix, register it with the cohort's public allocation list. The registration is a single row with the modder's handle, the prefix, and the date.
Convention 3: namespace within the mod
Within the mod's prefix, the cohort recommends using sub-ranges by category.
| Sub-range | Recommended use |
|---|---|
| Prefix + 000 to Prefix + 099 | Weapons |
| Prefix + 100 to Prefix + 199 | Magazines and ammunition |
| Prefix + 200 to Prefix + 299 | Attachments |
| Prefix + 300 to Prefix + 399 | Clothing |
| Prefix + 400 to Prefix + 499 | Storage and containers |
| Prefix + 500 to Prefix + 599 | Food and consumables |
| Prefix + 600 to Prefix + 699 | Medical |
| Prefix + 700 to Prefix + 799 | Tools and utility |
| Prefix + 800 to Prefix + 899 | Building and crafting |
| Prefix + 900 to Prefix + 999 | Miscellaneous and reserved |
A modder following both conventions can develop a mod with no risk of internal collision and minimal risk of external collision.
Advanced considerations
IDs in mod compatibility patches
A mod compatibility patch is a small mod that translates between two larger mods (for example, a mod that adds recipes using items from two unrelated mods). The compatibility patch references IDs from both upstream mods but does not declare new IDs of its own (or declares only a small number of new IDs in its own allocated range).
The cohort recommendation for compatibility patches is to use the patch author's own prefix for any new IDs the patch declares, and to reference upstream IDs by GUID rather than numeric ID where possible. The GUID reference survives upstream renumbering; the numeric ID reference does not.
IDs in workshop server-side mods
A server-side mod that adds items only to a specific server can use any prefix the server owner has reserved, but the server owner must understand that players who connect to other servers may have other mods with the same IDs. The cohort recommendation is to use a server-prefix convention (e.g., prefix 55000-55999 reserved for server-side-only mods) to make the server-only intent visible.
IDs in workshop modpacks
A modpack is a workshop entry that bundles multiple mods into a single download. The modpack's IDs are the union of the bundled mods' IDs. A conflict within the modpack indicates that two of the bundled mods conflict; the modpack author must coordinate with the bundled mod authors or exclude one of the conflicting mods.
IDs in localisation files
Localisation files reference assets by ID. A renumbered asset requires every localisation file to be updated to reference the new ID. The cohort recommendation is to use the asset's GUID in localisation files where the localisation format supports it; the GUID reference survives renumbering.
Migrating an existing mod to the prefix convention
A modder with an existing mod that does not follow the prefix convention can migrate. The migration breaks every save that references the old IDs, so the cohort recommendation is to publish the migration in a clearly-labelled major version of the mod and to document the migration in the workshop description.
Frequently asked questions
How do I find out which IDs are taken by other mods?
The cohort maintains a public ID allocation list as a spreadsheet. Modders register their allocated ranges in the spreadsheet. A modder starting a new mod consults the spreadsheet before picking a prefix. The spreadsheet is linked from the cohort's public documentation.
What if the other mod's author won't respond?
Renumber the modder's own mod. The cohort convention is that the modder doing the troubleshooting is the modder who renumbers, especially when the other author is unreachable. After renumbering, document the change in the workshop description so players who hit the conflict can find the resolution.
Can two mods share the same numeric ID intentionally?
No. The numeric ID is a registry key in Unturned's asset registry; only one asset can hold the key at a time. A mod that intentionally shares an ID with another mod is a mod whose asset will be dropped at load time.
How do I generate a new GUID?
PowerShell: [guid]::NewGuid(). The command produces a fresh GUID in the canonical 8-4-4-4-12 hexadecimal format. The command produces a different GUID every time it is invoked, so each new asset gets a fresh GUID. Other GUID generators (Python's uuid.uuid4(), the uuidgen command on macOS and Linux) work identically.
What if the conflict is with vanilla Unturned and I can't change vanilla?
Renumber the mod. Vanilla cannot be changed. The cohort recommendation is to pick mod IDs in the 10000-or-higher range to avoid the vanilla range entirely.
Can I use the same numeric ID for an item in one mod and a vehicle in another mod?
Unturned's registry is keyed per asset type, so an item ID and a vehicle ID with the same numeric value do not conflict directly. However, the cohort recommendation is still to avoid the overlap; some tooling treats the ID as a global key and produces incorrect results when the same ID exists in two asset types.
How do I check whether my chosen prefix is already taken?
Consult the cohort's ID allocation spreadsheet. If the prefix is not listed, register it. If the prefix is listed, pick a different prefix.
What's the difference between a GUID conflict and a numeric ID conflict in terms of game behavior?
Both produce the same symptom: one asset is dropped from the registry, the other is kept. The difference is in the cause: a numeric ID conflict is two assets declaring the same numeric ID, and a GUID conflict is two assets declaring the same GUID. Renumbering one resolves both types.
Can I script the renumbering process?
Yes. The cohort recommendation is to write a PowerShell or Python script that takes the old ID range and the new ID range as parameters and applies the rename across every .dat file in the mod's source folder. The script eliminates the cross-reference bugs that manual renumbering produces.
Does renumbering break existing saves?
Yes for the affected items. A player's save that contained the old-ID item will not find the item after the renumber; the inventory slot becomes empty or references a vanilla default. The cohort recommendation is to document the renumber in the workshop description and to provide players with a recovery workflow.
What happens if I never resolve the conflict?
Players who have both mods installed will continue to experience the missing-item symptom. Workshop reviews will reflect the bug. Other modders who pick IDs near the conflicting range may inherit the conflict.
Is there an automated tool to detect conflicts?
The cohort maintains a conflict-detection script that scans a folder of installed mods and emits a report of duplicate IDs. The script is linked from the cohort's public documentation. The cohort recommendation is to run the script before publishing any mod update.
Best practices
- Register the mod's prefix with the cohort's ID allocation spreadsheet before picking any IDs.
- Use the cohort's recommended sub-range conventions within the mod's prefix.
- Reference cross-mod IDs by GUID rather than numeric ID where the format supports it.
- Document the mod's ID range in the workshop description.
- Run the cohort's conflict-detection script before every workshop publish.
- Coordinate with other authors when conflicts arise; coordinate publicly so other modders can see the resolution.
- Avoid picking IDs in the vanilla range; reserve 10000+ for mods.
- Use PowerShell's
[guid]::NewGuid()to generate fresh GUIDs; never copy GUIDs from tutorials. - Add a pre-commit check that scans for tutorial GUIDs and warns if any are found.
- Use a renumbering script for any large renumber operation; never renumber by hand for more than a handful of IDs.
Appendix A: PowerShell renumbering script
The cohort maintains a PowerShell script that renumbers a mod's IDs. The script's structure is reproduced below.
powershell
# renumber-mod.ps1
# Usage: .\renumber-mod.ps1 -ModPath "C:\Project Folder\MyMod" -OldStart 1000 -NewStart 50000
param(
[Parameter(Mandatory)][string]$ModPath,
[Parameter(Mandatory)][int]$OldStart,
[Parameter(Mandatory)][int]$NewStart,
[int]$Count = 100
)
$offset = $NewStart - $OldStart
$datFiles = Get-ChildItem -Path $ModPath -Recurse -Filter "*.dat"
foreach ($file in $datFiles) {
$content = Get-Content $file.FullName
$updated = @()
foreach ($line in $content) {
if ($line -match "^\s*ID\s+(\d+)") {
$oldId = [int]$Matches[1]
if ($oldId -ge $OldStart -and $oldId -lt ($OldStart + $Count)) {
$newId = $oldId + $offset
$line = $line -replace "ID\s+\d+", "ID $newId"
}
}
$updated += $line
}
Set-Content -Path $file.FullName -Value $updated
}The script handles the ID declarations only; cross-references must be updated separately. The cohort's full script (linked from the cohort documentation) handles cross-references as well.
Appendix B: the cohort's ID allocation list (excerpt)
The full list is maintained as a public spreadsheet. The excerpt below shows the structure.
| Prefix | Range | Allocated to | Mod | Date allocated |
|---|---|---|---|---|
| 10000 | 10000-10999 | (cohort member A) | (mod name) | 2024-03-12 |
| 11000 | 11000-11999 | (cohort member B) | (mod name) | 2024-04-08 |
| 12000 | 12000-12999 | (cohort member C) | (mod name) | 2024-05-22 |
| 13000 | 13000-13999 | (cohort member D) | (mod name) | 2024-06-14 |
| 50000 | 50000-50999 | 57 Studios | (mod name) | 2024-02-01 |
| 51000 | 51000-51999 | 57 Studios | (mod name) | 2024-04-15 |
The full list is linked from the cohort's public documentation.
Appendix C: case studies
Case study 1: the workshop top-10 collision
A new cohort member shipped a mod with IDs in the 1000-1099 range without consulting the allocation list. The range overlapped with a workshop top-10 mod with 200,000+ subscribers. Players who installed both mods reported that the new mod's items were missing.
The cohort diagnosis identified the conflict via the in-game log. The other mod's author was reachable but understandably declined to renumber a mod with that many subscribers. The new cohort member renumbered to a fresh range in the 10000-10099 range, registered the range with the cohort, and shipped an update.
The cohort recommendation that resulted from the case study is to consult the allocation list before picking any range, and to avoid the historical sub-1000 range entirely.
Case study 2: the tutorial GUID
A modder followed a Smartly Dressed Games documentation tutorial and copied the tutorial's example GUID into the modder's own .dat file. The tutorial's example GUID was the same across every modder who followed the tutorial. Players who installed two mods that both followed the tutorial reported that one of the items showed the wrong icon.
The cohort diagnosis identified the GUID collision via the in-game log. The fix was to regenerate fresh GUIDs for every asset in both mods. The cohort recommendation that resulted from the case study is to add a pre-commit check that flags tutorial GUIDs.
Case study 3: the cross-reference miss
A long-tenure cohort member renumbered a mod's IDs without updating the recipe cross-references. After publishing, players reported that the mod's recipes produced wrong outputs. The cohort diagnosis identified that the recipe outputs still referenced the old IDs, which by that point had been claimed by a different mod.
The fix was to update every cross-reference. The cohort recommendation that resulted from the case study is to use the cohort's renumbering script (which handles cross-references) rather than manual renumbering.
Cross-references
- Items Missing in Game — the previous article in the wiki, which documents the broader category of missing-item symptoms. GUID conflicts are one of the principal causes.
- Sound Not Playing in Mod — the next article in the wiki, which documents audio packaging issues that can produce a similar "mod loaded but feature missing" symptom.
- Project Folder Structure and GUIDs — the upstream reference on GUID generation, ID range conventions, and the cohort's allocation list.
- Master Bundle Export — the export workflow that produces the master bundle Unturned loads.
Document history
| Version | Date | Author | Notes |
|---|---|---|---|
| 1.0 | 2024-06-12 | 57 Studios | Initial publication. Four resolution methods. |
| 1.1 | 2024-09-22 | 57 Studios | Added prefix convention and cohort allocation list reference. |
| 1.2 | 2024-12-10 | 57 Studios | Added PowerShell renumbering script appendix. |
| 2.0 | 2025-03-04 | 57 Studios | Major revision. Added eight resolution methods, sub-range conventions, and case studies. |
| 2.1 | 2025-05-17 | 57 Studios | Annual refresh. Expanded FAQ and console-command documentation. |
Glossary
- Asset registry — Unturned's internal index of loaded assets, keyed by numeric ID and GUID.
- Cross-reference — a
.datfield that references another asset by ID, such as a recipe output or a vendor inventory entry. - GUID — globally unique identifier; a 128-bit value in the canonical 8-4-4-4-12 hexadecimal format.
- Master bundle — the compiled output of a Unity project that Unturned loads as a mod.
- Numeric ID — a 16-bit unsigned integer that identifies an asset within Unturned's registry.
- Prefix — the high digits of every numeric ID in a mod, used to namespace the mod's IDs against other mods.
- Sub-range — a contiguous range of IDs within a mod's prefix, conventionally allocated to a specific asset category.
Closing note
GUID and numeric ID conflicts are among the most common cross-mod failures in the Unturned™ modding ecosystem. The conflict is structurally simple — two assets cannot share a registry key — but the resolution requires care because the wrong fix can break existing player saves.
The cohort's preventative recommendation (register a prefix, use sub-ranges, run the conflict-detection script before publishing) eliminates the vast majority of conflicts before they reach players. The reactive workflow (diagnose via the log, renumber the affected mod, document in the workshop description) handles the conflicts that slip through.
Next steps
If the mod loads but specific sounds are silent, continue to Sound Not Playing in Mod. For the broader category of missing-item symptoms, see Items Missing in Game. Return to the section overview at Troubleshooting for a list of all articles in this section.
