GUID Type Reference
The Globally Unique Identifier (GUID) is the identity primitive of the Unturned™ asset system. Every item, every object, every vehicle, every resource, and every effect in Unturned™ is identified by a 128-bit GUID — a 32-digit hexadecimal string with no hyphens, no dashes, and no entity-type prefix. The GUID is the system by which assets reference each other across files, across folders, and across mod boundaries without requiring a central registry or a coordination protocol between developers.
This article is the second in the data-types section of the 57 Studios™ Modding Knowledge Base. It covers the GUID format in full detail: the 32-digit hexadecimal representation, the generation workflow, the lifecycle of a GUID from generation through registration through usage in .dat files, .asset files, and blueprint references, the collision-avoidance guarantees that the 128-bit address space provides, and the runtime behavior when two mods accidentally share the same GUID. The companion articles in this section cover the C# built-in types (on which GUID strings depend for their serialization) and the enumerated types (which constrain asset identity alongside GUIDs).

Documentation source: This article references the official Smartly Dressed Games modding documentation Chapter 141 ("GUID") and Chapter 5 ("Asset Definitions") for the GUID format specification and asset-association rules. GUID usage patterns are validated against the shipped Unturned™ asset set at
C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Items\*\*.dat,*/\*.asset, andMasterBundle.dat. The guidgenerator.com tool referenced in the SDG documentation is the recommended manual generation utility.
Who this article is for
This article is written for Unturned™ mod authors who need to generate GUIDs for new assets, who are troubleshooting GUID-related load failures, or who are designing a mod project's identity strategy. Readers should already be familiar with .dat file authoring and the master bundle pipeline. If you are new to Unturned™ modding, read Project Folder Structure and GUIDs before this article.
What you'll learn
- The exact GUID format: 32-digit hexadecimal, no hyphens, no dashes, no entity-type prefix
- How Unturned™ GUIDs differ from standard UUIDs and from Unity GUIDs
- How to generate a GUID for a new asset (manual and programmatic methods)
- The complete GUID lifecycle: generation, registration in source files, usage in
.datand.assetfiles, usage in blueprint recipes (including thethiskeyword), and runtime identity resolution - How GUID collision avoidance works in a 128-bit address space and why the probability of accidental collision is astronomically low
- What happens at runtime when two mods accidentally use the same GUID
- How GUIDs serve as the sole identity key for assets (no versioning metadata, no composite key)
- How to diagnose GUID-related load failures
Background: the GUID as an identity primitive
Before GUIDs were introduced to Unturned™, the engine identified items using 16-bit legacy IDs - a uint16 value in the range 0 through 65535. This system had exactly one advantage: simplicity. It had several catastrophic disadvantages: the 16-bit address space limited the total number of items to 65536 across all vanilla assets and all mods loaded simultaneously. Mod developers had to coordinate ID ranges to avoid collisions, and the coordination was manual, error-prone, and impossible to enforce. When two mods used the same legacy ID, one asset silently overwrote the other - a bug that was near-impossible to diagnose because each mod worked correctly in isolation.
The GUID system solved this problem by widening the identifier from 16 bits to 128 bits. A 128-bit address space contains 2¹²⸠possible values - approximately 3.4Ã-10³⸠unique identifiers. The SDG documentation describes this as "an unimaginably huge range" and notes that GUIDs "can be generated without coordination or registration between developers." The probability of two independently generated GUIDs colliding is so low that, for all practical purposes in the mod-development domain, it is zero. The 57 Studios™ cohort has never observed an accidental GUID collision across hundreds of concurrently loaded mod items.
The GUID system was introduced alongside the .asset file format, which replaces or supplements the legacy .dat file for assets that have been upgraded to the GUID-only identity model. The GUID field appears in both .dat and .asset files and serves as the bridge between the legacy ID system and the GUID system during the transition period.
As shown in the timeline above, the GUID system has evolved from an optional supplement to the legacy ID system into the primary identity key for most asset types. Newly authored mods should use GUIDs as the authoritative identity key and treat legacy IDs as a backwards-compatibility shim.
GUID format specification
A Unturned™ GUID is exactly a 32-digit hexadecimal string composed of the characters 0-9 and a-f (lowercase). The GUID contains no hyphens, no dashes, no braces, no entity-type prefix, and no version-embedded nibbles.
Format example
GUID 3bba8c2b013646fb964932c31060b60aThe GUID above is drawn from the shipped vanilla Axe_Camp.dat file. It contains:
| Property | Value |
|---|---|
| Length | 32 characters |
| Character set | 0-9, a-f (hexadecimal, lowercase) |
| Hyphens | None |
| Dashes | None |
| Braces/Curlies | None |
| Entity-type prefix | None |
| Version-encoding nibbles | Not present (the engine does not parse GUID-internal structure) |
How Unturned GUIDs differ from standard UUIDs
A standard UUID (Universally Unique Identifier) as defined by RFC 9562 is a 128-bit value typically displayed as 36 characters in the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (32 hex digits plus four hyphens). The hyphens are conventionally positioned after the 8th, 12th, 16th, and 20th characters. Certain bits in a standard UUID encode the UUID version and variant, which identify the generation algorithm (v1 time-based, v4 random, v7 time-ordered, etc.).
A Unturned™ GUID differs from a standard UUID in three critical respects:
| Property | Standard UUID (RFC 9562) | Unturned GUID |
|---|---|---|
| Display length | 36 characters (32 hex + 4 hyphens) | 32 characters (hex only) |
| Hyphens | Four hyphens at fixed positions | None |
| Version encoding | Version-encoding nibbles in the UUID structure | The engine does not parse or depend on version-encoding bits; any 32 hex digit string is accepted |
| Generation source | Standard UUID generation algorithms (v4, v7) | UUID v4 generated externally, then hyphens stripped; or any 128-bit random hex string |
The practical implication for mod developers: generate a standard UUID v4 using any reliable tool, then strip the hyphens before pasting the value into the .dat or .asset file. The engine does not validate whether the GUID conforms to any UUID version — it treats the GUID as an opaque 128-bit identifier and performs byte-level comparison only.
How Unturned GUIDs differ from Unity GUIDs
Unity Editor assigns a GUID to every asset in a Unity project. Unity GUIDs are also 32-character hexadecimal strings but are stored in .self-referential files (one per asset) and are used for internal Unity asset referencing, not for game-runtime identity. The key differences:
| Property | Unity GUID | Unturned GUID |
|---|---|---|
| Storage | .self-referential file (one per asset in the Unity project) | .dat or .asset file (one per game-runtime asset) |
| Purpose | Unity Editor internal referencing | Game-runtime asset identity |
| Generation | Unity Editor on asset import/creation | Mod developer (external tool or code) |
| Scope | Single Unity project | Global (across all loaded mods) |
| Format | 32 hex digits, no hyphens | 32 hex digits, no hyphens (identical surface format) |
The surface format is identical — both are 32 hex digits with no hyphens — but the systems are completely separate. A Unity GUID from a .self-referential file should never be used as an Unturned™ GUID in a .dat file. The Unity GUID is scoped to a single Unity project; the Unturned™ GUID is scoped globally across all mods loaded by the game at runtime. Reusing a Unity GUID from another project guarantees a future collision when both projects are loaded simultaneously.
GUID generation
The official SDG documentation recommends guidgenerator.com as a "useful tool for manually generating GUIDs." The 57 Studios™ cohort supplements this with several alternate generation methods.
Method 1: Online GUID generator (recommended for manual generation)
- Navigate to guidgenerator.com in a web browser.
- The page displays a freshly generated UUID v4.
- Copy the displayed value.
- Remove all four hyphens.
- Paste the resulting 32-character string into the
GUIDfield of the.dator.assetfile.
Result example: The tool displays 3bba8c2b-0136-46fb-9649-32c31060b60a. After stripping hyphens: 3bba8c2b013646fb964932c31060b60a.
Method 2: PowerShell GUID generation (for scripted/mod-batch authoring)
Run the following command in a PowerShell window:
powershell
[guid]::NewGuid().ToString("N")The "N" format specifier produces a 32-character hexadecimal string with no hyphens, matching the Unturned™ GUID format exactly.
Result example: a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d
Method 3: C# Guid.NewGuid in plugin code
In a C# server plugin or mod script that needs to generate GUIDs programmatically:
csharp
string newGuid = System.Guid.NewGuid().ToString("N");The "N" format specifier is the C# equivalent of the PowerShell format and produces a hyphen-free 32-character hex string.
Method 4: Python uuid module (for cross-platform scripted generation)
python
import uuid
print(str(uuid.uuid4()).replace('-', ''))The uuid.uuid4() function generates a UUID v4; the replace('-', '') call strips the hyphens.
Auto-generated GUIDs on omission
The SDG documentation states: "if the GUID property is omitted from an asset definition file, then the game will automatically assign a random GUID during a successful load." This behavior applies only when the GUID field is specified at the root level of the file, not within a Metadata { } sub-dictionary. The cohort recommendation is to never rely on auto-generated GUIDs — always supply an explicit GUID. An auto-generated GUID changes every time the asset loads if the field is omitted, breaking any upstream references that depend on the GUID being stable across game sessions. Explicitly authoring the GUID ensures that the identity is fixed from the moment the asset file is first saved.
GUID lifecycle
A GUID passes through five distinct stages from generation to runtime resolution. Understanding each stage is essential for diagnosing GUID-related failures.
As shown in the flowchart above, the GUID lifecycle begins with generation (step 1) and proceeds through registration, usage, blueprint resolution, and runtime identity resolution. A failure at any stage propagates forward: a GUID that is not registered cannot be resolved at runtime; a GUID with a typo in a blueprint reference points to a nonexistent asset.
Stage 1: Generation
The GUID is generated using one of the methods documented in the preceding section. The 128-bit value is encoded as a 32-character hexadecimal string with no hyphens. This stage produces a value that, for all practical purposes, has never been generated before and will never be generated again by any other developer anywhere in the world.
Stage 2: Registration
The GUID is written into the asset's configuration file. The registration location depends on the file format:
In .dat files (root-level):
GUID 3bba8c2b013646fb964932c31060b60aIn .asset files (root-level):
GUID a1456f29b9c9464486c5f5373fd058ceIn .asset files (Metadata sub-dictionary):
Metadata
{
GUID 7e4b847061b64272b42ea8869fd053c7
Type SDG.Unturned.Asset
}The SDG documentation notes that GUIDs placed in the Metadata sub-dictionary do not receive auto-generation on omission (as of the 2023-04-13 date noted in the source extract). The cohort recommendation is to register GUIDs at the root level of every asset file for consistency and to avoid the auto-generation edge case.
In MasterBundle.dat (hierarchy registration):
The MasterBundle.dat file registers the master bundle, which in turn associates every asset in the bundle's folder hierarchy with the bundle. The GUID is not listed in MasterBundle.dat directly; the association is by file path: the engine scans the folder hierarchy and reads the GUID field from each asset file it encounters.
Stage 3: Usage in .dat and .asset files
Once registered, the GUID becomes the asset's identity key. The GUID is used by the engine to:
- Index the asset in the global asset registry
- Resolve cross-references from other assets (e.g., a gun referencing a magazine by GUID, or a blueprint referencing a crafting ingredient by GUID)
- Persist asset identity across folder moves and file renames (GUIDs are preferable to file names "because the files can be moved without redirectors," per the SDG documentation)
- Associate the asset with its Unity prefab in the master bundle
Stage 4: Blueprint reference resolution
Blueprint recipes in .dat files reference assets by GUID. The InputItems, OutputItems, CategoryTag, and Effect fields contain GUID strings. The RequiresNearbyCraftingTags array contains GUID strings. The engine resolves each GUID against the global asset registry at load time.
Example from Axe_Camp.dat:
InputItems "21ede8ebffb14c5580e8c7ad149e335e x 3" // Metal Scrap asset by GUID, quantity 3
OutputItems "21ede8ebffb14c5580e8c7ad149e335e x 2" // Same GUID, different quantity
CategoryTag "732ee6ebff18418985cf4f9fde33dd11" // Repair category tag by GUID
Effect "84347b13028340b8976033c08675d458" // Wrench effect by GUIDThe InputItems value "21ede8ebffb14c5580e8c7ad149e335e x 3" demonstrates the GUID-quantity convention: a GUID string, followed by a space, followed by x, followed by another space, followed by the quantity integer. The engine splits this string, looks up the GUID in the registry, and multiplies the quantity.
The this keyword
Blueprint recipes can reference the containing asset's own GUID using the this keyword:
InputItems thisThe this keyword is a self-referencing mechanism: when the engine encounters this in a blueprint recipe, it substitutes the GUID of the asset that contains the blueprint. This is used for salvage operations: a salvage blueprint that consumes the item itself (to return crafting materials) specifies InputItems this to indicate "this very item."
Example from Axe_Camp.dat:
{
Name Salvage
CategoryTag "7ed29f9101ae4523a3b2e389414b7bd9" // Salvage
InputItems this
OutputItems "21ede8ebffb14c5580e8c7ad149e335e x 2" // Metal Scrap
Effect "84347b13028340b8976033c08675d458" // Wrench
}The salvage blueprint consumes the camp axe itself (InputItems this) and produces two units of Metal Scrap (output asset referenced by GUID).
Stage 5: Runtime identity resolution
At game startup, the engine scans all loaded mod folders and builds a global GUID-to-asset map. Every asset file that contains a GUID field is registered in this map. When a cross-reference is encountered (a blueprint input, a magazine caliber linkage, a spawn table entry), the engine looks up the referenced GUID in the map and resolves it to the corresponding asset.
If two assets share the same GUID (a collision), the engine's behavior depends on the load order and the asset type. The asset loaded last overwrites the earlier asset's entry in the GUID-to-asset map. The earlier asset becomes unreachable by its GUID — references to that GUID resolve to the later asset, not the earlier one. This is the GUID collision problem documented in detail in GUID Conflicts Between Mods.
GUID collision avoidance
The 128-bit GUID address space provides collision-avoidance guarantees that are statistical, not cryptographic. The probability of a collision between two independently generated GUIDs is determined by the birthday problem and the size of the address space.
The 128-bit collision probability
For a 128-bit address space with uniform random generation (UUID v4 uses 122 random bits; 6 bits are reserved for version/variant encoding):
- The expected number of GUIDs needed for a 50% probability of at least one collision (the birthday bound) is approximately 2.7Ã-10¹⸠GUIDs.
- The number of Unturned™ mod items ever created, across the entire history of the game and all mod developers combined, is many orders of magnitude smaller than this figure.
- The probability of an accidental collision between any two GUIDs in a typical player's mod load-out (perhaps a few thousand assets total) is effectively zero for all practical intents.
The actual collision vector: copy-paste
The observed source of GUID collisions in the Unturned™ modding community is not random generation overlap. It is copy-paste. A mod developer who copies a .dat file from another mod as a starting template and forgets to replace the GUID field has duplicated the source asset's GUID. Two mods with that duplicated GUID, when loaded together, collide.
The prevention is procedural: before publishing any mod, confirm that every GUID field in every .dat and .asset file is unique across the project and was generated fresh (not copied from another asset). The Authoring checklist section of this article provides a systematic verification workflow.
Collision table: two mods, same GUID
When the engine encounters two assets with the same GUID during loading, the behavior is deterministic but not obvious:
| Scenario | Behavior |
|---|---|
Two .dat files with same GUID in different mods | The asset loaded last overwrites the earlier asset in the GUID-to-asset map. References to that GUID resolve to the later asset. The earlier asset may still be accessible by its legacy ID (if it has one) but not by GUID. |
Two .asset files with same GUID | Same behavior as .dat files. The file loaded last wins the GUID map entry. |
One .dat and one .asset with same GUID | The file loaded last wins, regardless of file format. The engine does not distinguish .dat-versus-.asset for collision resolution. |
| Blueprint references target a duplicated GUID | The blueprint resolves to whichever asset owns the GUID after loading is complete. If the intended target was the earlier asset, the blueprint resolves to the wrong asset. The effect is typically a wrong item in the crafting output or a broken recipe. |
MasterBundle.dat association with duplicated GUID | The engine's bundle-to-asset association may assign the wrong prefab to the wrong asset, causing visual/behavioral mismatch. |
The takeaway: GUID collisions are silent, destructive, and produce symptoms that are distant from the root cause. A player who reports "my crafting recipe produces the wrong item" may be experiencing a GUID collision between two mods that both contain a duplicated GUID from a common template. The diagnostic process for tracking down the source of the collision is documented in the GUID Conflicts Between Mods troubleshooting article.
GUID collisions and save-file corruption
If a GUID collision causes the engine to resolve a blueprint or spawn table reference to the wrong asset, and the player saves their game, the wrong asset reference is persisted in the save file. Removing the conflicting mod later does not fix the save file — the reference was baked into the save data during the collision window. The only recovery path is to load a save from before the collision or to manually edit the save file (which is an advanced operation beyond the scope of this article). The severity of this outcome makes GUID hygiene (unique, freshly generated GUIDs for every asset) one of the most important disciplines in Unturned™ mod authoring.
GUID as sole identity key
In the Unturned™ asset system, the GUID is the sole identity key for assets that have been upgraded to the GUID system. This has several implications for mod developers.
No versioning metadata in the GUID
The GUID does not carry version information. There is no embedded version number, no date stamp, no author identifier, and no asset-type indicator in a Unturned™ GUID. The GUID is an opaque identifier. If a mod author releases version 2 of an item that replaces version 1, and both versions share the same GUID, the engine treats them as the same asset and resolves to whichever version loaded last. The correct pattern for a replacement item is to assign the new version a new GUID and to update all upstream references (blueprints, spawn tables, vendor definitions) to point to the new GUID.
GUID immutability across file moves
The SDG documentation states that GUIDs are "preferable to file names because the files can be moved without redirectors." This means: if an asset's .dat file is moved from one folder to another (within the same mod or between mods), the GUID remains constant, and any asset that references that GUID will continue to resolve correctly. The file path is not part of the identity. This is the primary motivation for the GUID system over the legacy file-path-based identity.
GUIDs and the this keyword in blueprints
The this keyword in blueprint recipes is the mechanism by which a self-referencing asset avoids hard-coding its own GUID. A blueprint that reads InputItems this works correctly regardless of the asset's GUID — the engine substitutes the containing asset's GUID at runtime. This means a .dat file with this-referencing blueprints can be safely duplicated and its GUID replaced without also needing to update internal blueprint references. The this keyword was designed to support this pattern.
Worked examples from shipped asset files
Example 1: GUID in a .dat file (Axe_Camp.dat)
GUID 3bba8c2b013646fb964932c31060b60a
Type Melee
Useable Melee
Slot Secondary
ID 16The camp axe .dat file demonstrates the root-level GUID registration pattern. The GUID is on the first line, followed by the asset type and other identity fields. This is the standard layout for every .dat file in the shipped vanilla asset set.
Example 2: GUID in a .asset file (CA_Biker_Mask_0.asset)
GUID 640d3b5c486e499a99b85541f5dc777d
Type MaskThe biker mask .asset file demonstrates the same root-level GUID registration pattern in the .asset format. The GUID format is identical regardless of the file extension.
Example 3: GUID in Metadata sub-dictionary (shipped .asset, inferred from SDG docs)
Metadata
{
GUID 7e4b847061b64272b42ea8869fd053c7
Type SDG.Unturned.Asset
}The Metadata sub-dictionary pattern is documented in the SDG Chapter 5 source extract. When the GUID is placed in the Metadata sub-dictionary, the engine cannot auto-generate a GUID if it is omitted — the developer must supply one explicitly. This pattern is less common than root-level GUID registration in the shipped asset set.
Example 4: Blueprint GUID references (Axe_Camp.dat)
Blueprints
[
{
Name Repair
CategoryTag "732ee6ebff18418985cf4f9fde33dd11" // Repair
Operation RepairTargetItem
InputItems "21ede8ebffb14c5580e8c7ad149e335e x 3" // Metal Scrap
OutputItems this // Self-reference
RequiresNearbyCraftingTags
[
"7b82c125a5a54984b8bb26576b59e977" // Workbench
]
Effect "84347b13028340b8976033c08675d458" // Wrench
}
]The blueprint section demonstrates four distinct GUID usage patterns: a category tag GUID, an input item GUID with quantity, a this self-reference, a nearby-crafting-requirement GUID array, and an effect GUID. Every one of these GUIDs is a 32-character hexadecimal string with no hyphens.
Diagnostic table: GUID-related load failures
| Symptom | Most likely cause | Resolution |
|---|---|---|
| Asset does not appear in game | GUID field omitted and not auto-generated | Add an explicit GUID to the .dat or .asset file |
| Asset appears but has wrong prefab/model | GUID collision with another mod; wrong asset owns the GUID at load time | Generate a fresh GUID; verify uniqueness across all loaded mods |
| Blueprint recipe produces wrong item | Blueprint's InputItems or OutputItems GUID references the wrong asset | Verify the GUID string in the blueprint matches the intended target asset exactly |
| Blueprint recipe does nothing | Referenced GUID does not exist in any loaded mod | Verify the target asset's .dat or .asset file contains the referenced GUID and the mod is loaded |
| Salvage blueprint consumes wrong item | this keyword not resolving correctly (asset copied, GUID not updated) | Generate a fresh GUID for the copied asset; the this keyword will resolve to the new GUID automatically |
| Two mods cannot be loaded together | GUID collision between the two mods | Identify the duplicated GUID (search both mods' .dat and .asset files); generate a replacement GUID for one of the colliding assets |
| Asset loads with different GUID each session | GUID was in Metadata sub-dictionary and omitted, or root-level GUID line is missing | Add an explicit root-level GUID to the file |
@give by GUID does not work | Command syntax or the GUID lookup mechanism requires the exact 32-char string | Verify the GUID string has no typos, no hyphens, and matches the file exactly |
| Blueprint requires nearby crafting station but station is not recognized | RequiresNearbyCraftingTags GUID references a station asset that is not loaded or has a different GUID | Verify the station asset's GUID matches the blueprint reference exactly |
Frequently asked questions
What exactly is a GUID?
A Globally Unique Identifier (GUID) is a 128-bit number used as a unique key to identify an asset. In Unturned™, GUIDs are represented as 32-digit hexadecimal strings with no hyphens. A GUID is "globally unique" in the statistical sense: the 128-bit address space is large enough that two independently generated GUIDs have an astronomically low probability of colliding. The term GUID is used interchangeably with UUID in most computing contexts, though Unturned™'s representation strips the hyphens that standard UUID display formats include.
Why does Unturned not use standard UUID hyphens?
The Unturned™ parser uses whitespace and special characters as value delimiters. The hyphens in a standard UUID display format (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) would be interpreted as value terminators by the .dat parser, causing the GUID to be truncated at the first hyphen. Stripping the hyphens makes the GUID a single, contiguous, whitespace-free token that the parser can read in a single pass without requiring quoting.
Can I generate a GUID by just typing random hex digits?
Technically yes — the engine does not validate GUID structure beyond length and character set — but this is not recommended. Human-generated "random" hex strings are not uniformly distributed; humans favor certain digits, certain patterns, and certain sequences. A string generated by a proper UUID v4 algorithm uses a cryptographically strong random number source and is uniformly distributed across the 128-bit space. The small effort of using a generator tool is insurance against the vanishingly low but nonzero probability that a human-chosen pattern matches another developer's human-chosen pattern.
What happens if I reuse a GUID from a vanilla item for my mod item?
Your mod item overwrites the vanilla item in the GUID-to-asset map at load time (or is overwritten by the vanilla item, depending on load order). Either way, one of the two assets becomes unreachable by GUID. If your mod is loaded after the vanilla assets, your item replaces the vanilla item for any blueprint or spawn reference that resolves by GUID. This is, without exception, unintentional and destructive. Always generate a fresh GUID.
Do objects still use legacy IDs?
Objects (the EObjectType category) are "the exception from this legacy restriction because they have been upgraded to fully use GUIDs," per the SDG Chapter 5 source extract. Objects no longer require unique legacy IDs within their category; their GUIDs serve as the sole identity key. Items, vehicles, animals, resources, and effects still carry legacy ID fields alongside GUIDs for backwards compatibility, but the trend is toward GUID-only identity.
How do I find all GUIDs in my mod project to check for duplicates?
Use a text-search tool to search all .dat and .asset files in the project folder for lines matching the pattern GUID (the word "GUID" followed by a space). On Windows, PowerShell: Select-String -Path "*.dat","*.asset" -Pattern "^GUID ". On any platform, grep: grep -r "^GUID " *.dat *.asset. Collect all 32-character GUID strings, sort them, and scan for duplicates. A single duplicated GUID in a project is a collision waiting to happen.
What is the difference between GUIDs used in .dat files and GUIDs used as CategoryTags?
There is no difference. CategoryTag values are GUIDs that reference category-definition assets. The format is identical — 32-digit hexadecimal, no hyphens. The only difference is semantic: a CategoryTag GUID references a crafting category definition rather than an item, vehicle, or other gameplay asset. The engine resolves them identically.
Can I use the same GUID for a .dat file and its companion .asset file?
No. The .dat and .asset files in the same folder represent the same asset. Only one of the two files is loaded per the loading order documented in Asset Definitions Reference. If both files exist and both contain a GUID field, the engine loads only the one that takes priority in the loading order, and the other file's GUID is ignored. The two files should not both contain GUID fields for the same asset.
Is there a central registry where I should reserve my mod's GUID range?
No. The entire purpose of the 128-bit GUID address space is that no central registry is needed. The SDG documentation states: "This allows them to be generated without coordination or registration between developers." The probability of collision between independently generated GUIDs is so low that a registry would serve no purpose beyond ceremony.
What tool should I use to generate GUIDs?
The SDG documentation recommends guidgenerator.com. The 57 Studios™ cohort additionally recommends PowerShell's [guid]::NewGuid().ToString("N") command for developers on Windows who prefer not to use a web tool, and C#'s System.Guid.NewGuid().ToString("N") for programmatic generation in C# plugins. All three methods produce UUID v4 values; the only requirement is that the hyphens be stripped from the standard 36-character display format before pasting into the .dat file.
Best practices
- Generate a fresh GUID for every new asset. Never reuse a GUID from another mod, another asset in the same mod, or a template file.
- Strip hyphens from the standard UUID display format before pasting into the
.dator.assetfile. - Register the GUID at the root level of the file (not in the
Metadatasub-dictionary) for consistency and to avoid the auto-generation edge case. - Use
thisfor self-referencing blueprint recipes rather than hard-coding the asset's own GUID. - Run a duplicate-GUID check across all
.datand.assetfiles in the project before publishing. - Document each asset's GUID in the project's internal asset manifest for cross-reference during development.
- Test the mod in a clean Unturned™ installation with no other mods loaded to confirm the GUID resolves correctly in isolation.
- Test the mod alongside other commonly used mods to confirm no accidental GUID collisions exist.
- If a mod update replaces an item, assign the replacement a new GUID; do not reuse the old item's GUID.
- When collaborating on a mod, agree on a GUID generation protocol (tool and method) to ensure uniform generation across collaborators.
Advanced considerations
GUIDs in spawn tables and economy configuration
Spawn tables and economy configurations (Steam item definitions, Economy.dat) reference items by GUID. A mod that participates in a server's loot economy must have stable GUIDs that do not change between versions. If a GUID changes, the spawn table reference breaks, and the item stops appearing in loot. For mod series that participate in a server's permanent loot economy, the recommendation is to generate GUIDs once per item at the start of the project and never change them, regardless of subsequent updates to the item's stats or appearance.
GUIDs in server-side plugin code
Server-side plugins that spawn items or manipulate the asset registry by GUID must use the exact 32-character string. A plugin that hard-codes a GUID that later changes (because the mod author regenerated the GUID for a new version) will silently break. Plugin developers who reference mod items by GUID should document the dependency in the plugin's README and version-lock the GUID to a specific mod version.
GUIDs in the Steam Workshop ecosystem
Steam Workshop items do not carry embedded GUID metadata at the Workshop level. The Workshop tracks mods by their published file ID (a Steam-assigned integer), not by the internal GUIDs of the assets inside the mod. However, when a player subscribes to two mods that contain a GUID collision, the collision occurs at the game-runtime level, and the Workshop provides no mechanism to detect or warn about it. The burden of avoiding GUID collisions rests entirely on the mod author.
Batch GUID generation for large item packs
For a mod that includes many items (a weapon pack with 50 guns, each requiring its own GUID), batch generation is more efficient than manual generation. The recommended batch-generation workflow:
- Run a script that calls
[guid]::NewGuid().ToString("N")once per item. - Collect the generated GUIDs in a spreadsheet or manifest file.
- Assign one GUID to each item's
.dator.assetfile. - Record the assignment in the manifest for future reference.
- Run the duplicate-GUID check across all generated GUIDs before committing them to files.
A PowerShell one-liner for batch generation:
powershell
1..50 | ForEach-Object { [guid]::NewGuid().ToString("N") }This produces 50 unique GUIDs, one per line, ready for assignment.
Appendix A: GUID quick-reference card
| Property | Value |
|---|---|
| Bit width | 128 bits |
| Display format | 32 lowercase hexadecimal digits (0-9, a-f) |
| Hyphens | None |
| Braces/curlies | None |
| Entity-type prefix | None (no "I-" or "O-" prefix) |
| Version encoding | Not parsed by the engine; any valid 32-hex-digit string is accepted |
| Generation method (recommended) | UUID v4, hyphens stripped |
| Generation tool (SDG-recommended) | guidgenerator.com |
| Generation tool (57 Studios cohort) | PowerShell: [guid]::NewGuid().ToString("N") |
| Collision probability | Effectively zero for accidental collision across independently generated GUIDs |
| Actual collision vector | Copy-paste (human error, not random chance) |
| Registration location | Root-level GUID field in .dat or .asset file |
| Self-reference keyword | this (in blueprint recipes) |
| Immutability | GUID does not change when the file is moved or renamed |
Appendix B: GUID across asset types
| Asset origin | GUID example (32 hex chars) | File type |
|---|---|---|
| Camp axe (Melee) | 3bba8c2b013646fb964932c31060b60a | .dat |
| Classic Alicepack (Backpack) | 53d3ea4a555c44d1824b495c2b337aec | .dat |
| Ace gun (Gun) | 92b49222958d4c6fbeca1bd00987b0fd | .dat |
| Fire axe (Melee) | f779c1dfcc9e44eba9987916cc713799 | .dat |
| Baseball bat (Melee) | bdb0a99f009c42bf92ef8764095f4bae | .dat |
| Baton (Melee) | 0a9b3cf673bf48aaadafcaa61fa2eb98 | .dat |
| Biker mask (Mask) | 640d3b5c486e499a99b85541f5dc777d | .asset |
| Cali2 hat (Hat) | a1456f29b9c9464486c5f5373fd058ce | .asset |
| Cali2 vest (Vest) | 5aad28a7889a4d27b98a6e697ea3b6e7 | .asset |
| Cali2 hat (Hat) | afc82b2beb4f440d88186a218308fbd8 | .asset |
The table above lists GUIDs extracted from the shipped Unturned™ asset set. Every GUID is 32 lowercase hexadecimal characters with no hyphens, no prefixes, and no formatting differences between .dat and .asset files.
Appendix C: GUID lifecycle diagram in detail
As shown in the state diagram above, a GUID moves through a well-defined lifecycle. Deviations from the happy path (orphaned, unresolved, broken, overwritten) produce the failure modes documented in the diagnostic table earlier in this article.
Appendix D: External references
| Resource | URL | Notes |
|---|---|---|
| Smartly Dressed Games modding documentation | https://docs.smartlydressedgames.com/en/stable/ | Chapter 141: GUID; Chapter 5: Asset Definitions |
| guidgenerator.com | https://www.guidgenerator.com | Online UUID v4 generator; SDG-recommended manual generation tool |
| Unturned on Steam | https://store.steampowered.com/app/304930/Unturned/ | Game page and changelog |
| C# Built-in Types Reference | /data-types/csharp-built-in-types-reference | The previous article; covers the string type used to serialize GUIDs |
| Enumerated Types Reference | /data-types/enumerated-types-reference | The next article; covers all 23 enum types |
| GUID Conflicts Between Mods | /troubleshooting/guid-conflicts-between-mods | The troubleshooting article for GUID collision diagnosis and resolution |
| Project Folder Structure and GUIDs | /items/project-folder-structure-and-guids | Folder layout and GUID generation workflow for new mod projects |
| Asset Definitions Reference | /items/asset-definitions-reference | Asset structure, loading order, and bundle association |
| Item Asset Anatomy | /items/item-asset-anatomy | Shared fields on every item asset, including GUID |
Document history
| Version | Date | Author | Notes |
|---|---|---|---|
| 1.0 | 2026-07-26 | 57 Studios | Initial publication. Complete GUID type reference covering format, generation, lifecycle, collision avoidance, runtime behavior, diagnostic table, FAQ, appendices. |
Cross-references
- C# Built-in Types Reference — the previous article; covers the string type that serializes GUID values and the integer types that appear alongside GUIDs.
- Enumerated Types Reference — the next article; covers the 23 enum types whose values define asset type, rarity, slot, and other categorized fields.
- GUID Conflicts Between Mods — the troubleshooting article for diagnosing, isolating, and resolving GUID collisions between mods.
- Project Folder Structure and GUIDs — the foundational article on GUID generation and folder layout for new mod projects.
- Asset Definitions Reference — the asset structure documentation covering GUID registration, loading order, and master bundle association.
- Item Asset Anatomy — the shared field reference documenting the
GUIDfield alongsideID,Type, and other identity fields. - Data File Format Reference — the
.datand.assetfile format specification. - Smartly Dressed Games modding documentation — the official GUID specification.
- Unturned on Steam — the game page.
Authoring checklist
Before publishing a mod, confirm the following GUID-correctness checks:
- [ ] Every
.datand.assetfile in the project contains an explicitGUIDfield (root-level, not inMetadatasub-dictionary) - [ ] Every GUID in the project is 32 lowercase hexadecimal characters with no hyphens, no prefixes, and no formatting
- [ ] Every GUID was generated fresh for this asset (not copied from another asset in this project or any other project)
- [ ] A duplicate-GUID scan across the entire project returns no duplicates
- [ ] Blueprint
InputItemsandOutputItemsGUIDs reference assets that exist in this project or in the targeted vanilla/mod asset sets - [ ] Blueprint
thiskeywords are used where self-referencing is intended; no hard-coded self-referencing GUIDs - [ ] The mod has been tested in isolation (no other mods loaded) to confirm all GUIDs resolve correctly
- [ ] The mod has been tested alongside commonly co-loaded mods to confirm no accidental GUID collisions
- [ ] The project's asset manifest (if maintained) records every GUID-to-asset assignment for future reference
