Skip to content

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.

Unturned mod ID conflict in the editor

Prerequisites

  • A working Unturned™ mod that has been exported to a master bundle.
  • Access to the mod's source folder, including the .dat files 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 .dat files.
  • 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' .dat files 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:

  1. The numeric ID. A 16-bit unsigned integer in the range 0 to 65,535. Declared in the asset's .dat file as ID 1234 (for example). The numeric ID is the value players type into commands and is the primary identifier within a single game session.
  2. The GUID. A 128-bit globally unique identifier in the canonical 8-4-4-4-12 hexadecimal format. Declared in the asset's .dat file as GUID 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.

Numeric ID and GUID in an Unturned dat file

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 typeLikelihoodTypical causeUnturned behavior
Numeric ID collisionCommonTwo modders chose the same numeric ID without coordinatingLoads first; warns on second
Numeric ID vs vanillaCommonModder picked an ID in the vanilla rangeLoads vanilla first; warns on mod
GUID collision (same author)OccasionalCopy-paste of a GUID across two assetsLoads first; warns on second
GUID collision (cross-author)RareTwo modders generated the same GUID (mathematically improbable)Loads first; warns on second
GUID collision via copy-paste from tutorialCommonModder copied a GUID from a documentation exampleLoads 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.

  1. Close Unturned.
  2. Confirm that both mods are subscribed in the workshop or copied into the local mods folder.
  3. Launch Unturned with both mods enabled.
  4. Open the developer console with the backtick key.
  5. Enter the world that demonstrates the missing item.
  6. 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.log

Open 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.

  1. Open the first mod's source folder.
  2. Search the folder for files containing the ID. In PowerShell:
    Get-ChildItem -Recurse -Filter "*.dat" | Select-String "ID 1234"
  3. Repeat for the second mod's source folder if access is available.
  4. 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:

  1. The range must not overlap with the vanilla game's ID range (Smartly Dressed Games publishes the vanilla ID ranges on the modding documentation).
  2. The range must not overlap with any of the cohort's published mod ID ranges (the cohort maintains a public ID allocation list).
  3. 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

  1. Open every .dat file that declares an ID in the conflicting range.
  2. Update the ID line in each file to the new range.
  3. If the mod uses cross-references between items (a recipe references the ID of an output item, for example), update every cross-reference.
  4. Save every modified file.
  5. 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

  1. Re-install the renumbered mod alongside the conflicting mod.
  2. Launch Unturned and read the log.
  3. Confirm that no duplicate-ID warning appears for the previously conflicting ID.
  4. Spawn each renumbered item via @give <new-id> and confirm the correct item appears.
  5. If the mod's items appear in vendor lists or quests, confirm those references work.

Successful spawn of renumbered item in-game

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 logMost likely causeResolution
Item from one mod is missingNumeric ID conflict between two modsRenumber the affected mod
@give <id> produces wrong itemNumeric ID conflict resolved in favor of other modRenumber the affected mod
Two mods both show same item iconGUID conflict between two assetsRegenerate one mod's GUID
Save loads but items appear with default modelGUID conflict that persisted into saveRestore from backup save; renumber
Vehicle conflict (one disappears)Numeric ID conflict in vehicle rangeRenumber the affected vehicle mod
Quest references wrong target itemCross-reference points to ID claimed by another modRenumber and update cross-reference
NPC sells wrong itemVendor table references ID claimed by another modRenumber and update vendor table
Recipe produces wrong outputRecipe references ID claimed by another modRenumber and update recipe
All items missingMaster bundle failed to load entirely (not a GUID conflict)See Items Missing in Game
Item present but with vanilla item's nameNumeric ID conflict against vanilla gameRenumber outside vanilla range
Item ID range entirely overlaps another modCatastrophic range overlapRenumber entire range with new prefix
Conflict only on specific serversServer has additional mods with conflicting IDsCoordinate with server owners

Resolution methods

Method 1: Renumber individual conflicting IDs

The minimum-effort resolution is to renumber only the specific IDs that conflict.

  1. Identify the conflicting IDs from the log.
  2. For each conflicting ID, choose a new ID in the mod's allocated range.
  3. Update the ID line in the affected .dat file.
  4. Update every cross-reference to the renumbered ID.
  5. Re-export the master bundle.
  6. 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.

  1. Pick a new range that satisfies the three constraints documented above.
  2. 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).
  3. Build a mapping table from old IDs to new IDs.
  4. For each .dat file, apply the mapping to the ID line.
  5. For each cross-reference, apply the mapping.
  6. Re-export the master bundle.
  7. 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.

  1. Reach out to the other author via a public channel.
  2. Document the conflicting IDs and the symptoms players are experiencing.
  3. Propose a resolution: either the modder's mod renumbers, or the other mod renumbers, or both.
  4. Confirm the agreed resolution.
  5. 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.

  1. Identify the conflicting GUID from the log.
  2. Generate a fresh GUID. PowerShell: [guid]::NewGuid() produces a fresh GUID in the canonical format.
  3. Update the GUID line in the affected .dat file.
  4. Update any cross-references that use the GUID instead of the numeric ID.
  5. 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.

  1. Pick a unique prefix in the 1000-65000 range (the lower 1000 is reserved for vanilla and historical mods).
  2. Use the prefix as the high digits of every ID in the mod (e.g., prefix 5700 produces IDs 57000, 57001, 57002, ...).
  3. 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.

  1. Add a "Changelog" section to the workshop description.
  2. Document the IDs that changed and the saves the change may affect.
  3. 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:

  1. Restore the save from backup.
  2. Load the save with the old mod version installed.
  3. Drop or destroy every instance of the affected item.
  4. Save and exit.
  5. Update to the new mod version.
  6. 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.

MethodTime requiredRisk levelWhen to apply
1. Renumber individual IDsFive to fifteen minutesLowOne or two IDs conflict
2. Renumber entire mod into new rangeOne to four hoursMediumEntire range overlaps
3. Coordinate with other authorVariableLowOther author reachable
4. Regenerate conflicting GUIDTwo minutesLowGUID conflict (rare)
5. Force-load order via renameOne minuteHighTemporary workaround only
6. Namespace IDs with prefixOne to four hoursLowLong-term refactor
7. Document in workshop descriptionTen minutesLowAfter any renumber
8. Restore broken saveVariableMediumSave references old IDs

Console commands for diagnosing conflicts

The Unturned developer console exposes commands that can help diagnose conflicts at runtime.

CommandWhat it doesUse case
@itemsLists every loaded item IDCross-reference against expected IDs
@give <id>Spawns the item with the given IDVerify which mod owns an ID
@vehiclesLists every loaded vehicle IDDiagnose vehicle conflicts
@animalsLists every loaded animal IDDiagnose animal conflicts
@npcsLists every loaded NPC IDDiagnose NPC conflicts
@questsLists every loaded quest IDDiagnose quest conflicts
@search <name>Searches loaded assets by nameFind 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 rangeRecommended use
1 to 9999Reserved for vanilla and historical mods. Do not use.
10000 to 19999Available for new mods.
20000 to 29999Available for new mods.
30000 to 39999Available for new mods.
40000 to 49999Available for new mods.
50000 to 59999Allocated to 57 Studios cohort members.
60000 to 65535Reserved 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-rangeRecommended use
Prefix + 000 to Prefix + 099Weapons
Prefix + 100 to Prefix + 199Magazines and ammunition
Prefix + 200 to Prefix + 299Attachments
Prefix + 300 to Prefix + 399Clothing
Prefix + 400 to Prefix + 499Storage and containers
Prefix + 500 to Prefix + 599Food and consumables
Prefix + 600 to Prefix + 699Medical
Prefix + 700 to Prefix + 799Tools and utility
Prefix + 800 to Prefix + 899Building and crafting
Prefix + 900 to Prefix + 999Miscellaneous 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.

PrefixRangeAllocated toModDate allocated
1000010000-10999(cohort member A)(mod name)2024-03-12
1100011000-11999(cohort member B)(mod name)2024-04-08
1200012000-12999(cohort member C)(mod name)2024-05-22
1300013000-13999(cohort member D)(mod name)2024-06-14
5000050000-5099957 Studios(mod name)2024-02-01
5100051000-5199957 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

VersionDateAuthorNotes
1.02024-06-1257 StudiosInitial publication. Four resolution methods.
1.12024-09-2257 StudiosAdded prefix convention and cohort allocation list reference.
1.22024-12-1057 StudiosAdded PowerShell renumbering script appendix.
2.02025-03-0457 StudiosMajor revision. Added eight resolution methods, sub-range conventions, and case studies.
2.12025-05-1757 StudiosAnnual 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 .dat field 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.