Asset Definitions Reference
An asset definition is the bridge between a .dat configuration file and a Unity AssetBundle. Every item, vehicle, animal, object, and effect in Unturned™ is represented by an asset definition, a .dat or .asset file that carries the asset's identity (GUID and Type), its body properties (the fields that define its behavior), and the metadata that links it to the Unity bundle containing its 3D model and textures. A modder who understands asset definitions completely can trace every asset from its .dat file through to its in-game appearance; a modder who does not will encounter "invisible item" bugs, GUID collision failures, and master bundle resolution errors that a definitions reference would prevent.
This article is the 57 Studios™ canonical reference for asset definitions. It documents the GUID and Type header that every asset carries, the two structural formats (Format A with Metadata and Asset blocks, and Format B with a simple root-level identity), the master bundle linkage fields, the asset loading order the game follows, the inheritance hierarchy that determines which fields an asset type recognizes, and the redirector asset type that remaps asset references. The reference is built from the official Smartly Dressed Games documentation and validated against the shipped .asset and .dat files in the Unturned™ Bundles directory.

Documentation source: This article references the official Smartly Dressed Games modding documentation for the asset definitions specification. Game-file evidence was sampled from the Unturned™
Bundles/Items/andBundles/Assets/directories.
Who this article is for
This article is written for Unturned™ mod authors who have already read the Data File Format Reference and understand the .dat syntax grammar. It presupposes familiarity with GUID generation and the master bundle export workflow. If you are new to Unturned™ modding, start with Project Folder Structure and GUIDs and Master Bundle Export from Unity before returning here.
What you'll learn
- What an asset definition is and how it bridges
.datconfiguration data to Unity AssetBundle content - The GUID property: its format, its role in linking assets together, and the auto-generation behavior
- The Type property: how the type string determines which C# class reads the asset's fields
- The ID property: the legacy numeric identifier and its uniqueness constraint
- The two structural formats of
.assetfiles, Format A withMetadataandAssetblocks, and Format B with root-level identity - When each format is used and which asset types default to which format
- The master bundle linkage fields that control which
.unity3dor.masterbundlefile the asset loads from - The asset loading order: how the game decides which file in a folder defines an asset
- The inheritance hierarchy: how asset types form a class tree and which fields are inherited
- Editor Asset Redirectors: the special
.assetfiles that remap GUID and legacy ID references - Worked examples of both formats from shipped game files
Background: what an asset definition is
An asset definition is a structured text file that associates game data with Unity content. The definition contains two categories of information: identity data (the GUID, Type, and optionally the ID) that tells the game engine what this asset is and how to reference it, and body data (the key-value fields specific to the asset type) that defines the asset's behavior at runtime. The definition also contains bundle-linkage data, fields that tell the game which Unity AssetBundle contains the prefab, texture, mesh, or audio clip that the asset uses for its visual and audible representation.
The asset definition does not contain the 3D model, texture, or audio data itself. Those binary assets reside inside Unity AssetBundles (.unity3d or .masterbundle files). The asset definition tells the game which bundle to load, which path within that bundle to find the prefab at, and which version of Unity the bundle was built for. This separation, text definition file plus binary bundle file, means the modder can edit the text configuration without rebuilding the bundle, and can rebuild the bundle without editing the text configuration, as long as the identity fields (GUID, Type, Name) remain consistent.
As shown in the flowchart above, the asset definition and the binary bundle are separate inputs to the game engine. The engine reads the definition to understand what the asset is and how it behaves, then loads the binary content from the bundle to render the asset visually in the game world.
The GUID property
The GUID field is a 128-bit globally unique identifier written as a 32-character lowercase hexadecimal string with no hyphens. Every asset in Unturned™, every item, vehicle, animal, object, resource, effect, and NPC, has a unique GUID. The GUID is the primary mechanism by which assets reference each other: a gun's Magazine field contains the ID (not the GUID) of the magazine asset, but a blueprint's CategoryTag field contains the GUID of the tag asset. Cross-references between asset types use GUIDs; within-type references (gun to magazine) use IDs.
Evidence from shipped files: every .dat and .asset file in the Bundles directory begins with a GUID line. The format is consistent across every file inspected:
GUID 92b49222958d4c6fbeca1bd00987b0fd| GUID characteristic | Rule | Notes |
|---|---|---|
| Length | Exactly 32 characters | No exceptions in shipped files |
| Character set | 0-9, a-f (lowercase) | Uppercase is parsed identically but never used in vanilla |
| Separators | None | No hyphens, no braces, no spaces |
| Generation | UUID v4 (random) | Generated by tools; hyphens removed before writing |
| Uniqueness | Must be globally unique across all mods | Duplicate GUIDs cause assets to overwrite each other |
| Auto-generation | If left empty, the game prepends a random GUID at startup | Only when GUID is in the root dictionary, not in Metadata block |
GUID placement
The GUID field can appear in the root dictionary or in a Metadata sub-dictionary. Both placements are valid and produce identical behavior, with one important difference:
- Root dictionary: If the GUID field is empty (e.g.,
GUIDon its own line with no value), the game automatically generates a random GUID during startup. This is the standard placement for items, vehicles, and most asset types. - Metadata sub-dictionary: If the GUID field is inside a
Metadatablock, the game does not auto-generate a new GUID when the field is empty (as of the 2023-04-13 parser update). The asset will load with an empty GUID, which will cause reference-resolution failures.
Common mistake
Placing the GUID field inside a Metadata block and leaving it empty, expecting the game to auto-generate it. The auto-generation only triggers when the GUID is specified in the root dictionary. If you are using the Metadata block structure, always provide an explicit GUID value.
The Type property
The Type field is a string that tells the game which C# class to use when reading the asset's body fields. The type string determines the entire set of fields the asset recognizes, fields whose names match properties on the type's class are read; fields whose names do not match any property are silently discarded. The type string also determines the asset's inheritance chain: a Type Gun asset inherits from the ItemAsset class, which inherits from the Asset base class, and the properties from every class in the chain are available.
Evidence from shipped files shows a wide variety of type strings:
Type Melee, melee weapon assetsType Gun, ranged weapon assetsType Magazine, ammunition container assetsType Mask, wearable mask and headgear assetsType Tag, blueprint category and crafting tagsType SDG.Unturned.AirdropAsset, Assembly-CSharp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null, fully qualified type reference
| Type specification | Format | Use case |
|---|---|---|
| Short name | Type Melee | Standard for built-in asset types (Melee, Gun, Magazine, Item, Vehicle, Animal, etc.) |
| Fully qualified name | Type Namespace.ClassName, Assembly | Used for custom or less-common asset types that do not have a short-name alias |
The fully qualified name format includes the namespace, class name, and assembly reference. This format is used when the short-name alias is not available (either because the asset type is not one of the built-in types with a registered alias, or because the modder is referencing a type from a specific assembly). The assembly reference includes the version, culture, and public key token, matching the standard .NET assembly-qualified name format.
The ID property
The ID field is a uint16 numeric identifier (range 0 to 65,535). Unlike the GUID, which is globally unique across the entire asset system, the ID is unique only within the asset's category. The game enforces that no two items share the same ID, no two vehicles share the same ID, and so on, but an item and a vehicle can share the same ID because they are in different categories. Objects are the exception from this legacy restriction because they have been upgraded to fully use GUIDs.
The ID serves two purposes: it is the value used in console commands (@give 107 spawns the item with ID 107), and it is the value used for within-category cross-references (a gun's Magazine 108 field references the magazine with ID 108). Modders should assign IDs in the 50,000+ range to avoid collision with vanilla items and with established community mods.
| ID characteristic | Rule | Recommendation |
|---|---|---|
| Type | uint16 (0 to 65,535) | Whole-number integer; no decimal |
| Uniqueness scope | Per category (items, vehicles, animals) | No two items can share an ID |
| Vanilla range | 1 through approximately 2,000 | Avoid using IDs below 50,000 |
| Mod range | 50,000+ | Assign from a documented range per mod project |
| Cross-reference use | Referenced by other assets via ID | Gun references magazine by ID, not GUID |
Asset type inheritance hierarchy
The asset type system in Unturned™ is organized as a C# class hierarchy. Every asset type inherits from a base Asset class, and specialized types inherit from intermediate classes that add category-specific fields. The modder does not need to understand the full inheritance tree to author .dat files, but understanding which fields come from which level of the hierarchy helps explain why certain fields appear on certain asset types and not on others.
As shown in the diagram above, the ItemAsset class is the intermediate base class for every item type. Fields defined on ItemAsset, such as ID, Size_X, Size_Y, Rarity, and Slot, are available on every item subclass. Fields defined on ItemGunAsset, such as Caliber, Firerate, and Recoil, are available only on gun assets. A magazine asset shares the ItemAsset fields with a gun asset but does not have the Caliber field (the magazine has Caliber_Reference instead, which is a different field on a different class).
Format A: the structured definition
Format A is the standard asset definition structure used by most item and object .dat and .asset files. It is characterized by having the GUID and Type fields at the root level (or inside a Metadata block), with the body fields optionally organized inside an Asset sub-dictionary.
Root-level Format A
In the most common variant, the GUID, Type, and body fields are all at the root level of the dictionary. This is the format used by every vanilla item .dat file:
GUID 92b49222958d4c6fbeca1bd00987b0fd
Type Gun
Rarity Uncommon
Useable Gun
Slot Secondary
ID 107
Size_X 2
Size_Y 2
Size_Z 0.35
Magazine 108
Hook_Barrel
Safety
Semi
Caliber 6
Range 100
Firerate 10
Action Trigger
Player_Damage 50
Zombie_Damage 99
Durability 0.08This variant places all fields in the root dictionary. The parser treats the root level as the implicit dictionary, and the C# asset class reads the fields directly from that dictionary. There is no Metadata or Asset block.
Metadata-and-Asset Format A
An alternative variant places the identity fields in a Metadata sub-dictionary and the body fields in an Asset sub-dictionary:
Metadata
{
GUID 229440c249dc490ba26ce71e8a59d5c6
Type SDG.Unturned.AirdropAsset, Assembly-CSharp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
}
Asset
{
Landed_Barricade
{
GUID fe71781c60314468b22c6b0642a51cd9
}
Carepackage_Prefab
{
MasterBundle core.masterbundle
AssetPath Level/Carepackage.prefab
}
}This variant is used by assets that benefit from explicit structural separation between identity fields and body fields, or by assets whose type is specified as a fully qualified assembly name. As documented in the SDG specification, the Metadata block and root-level placement are functionally equivalent, the parser resolves both to the same internal representation.
Evidence from DefaultAirdrop.asset in the Bundles/Assets/Airdrops/ directory confirms this variant is used in shipped files.
Format A: master bundle linkage fields
Format A assets can include any of the following bundle-linkage fields, which control how the game resolves the asset's Unity content:
| Field | Type | Purpose | Example |
|---|---|---|---|
Master_Bundle_Override | string | Name of a master bundle to use instead of the hierarchy-located bundle | Master_Bundle_Override core.masterbundle |
Exclude_From_Master_Bundle | flag | If present, the asset looks for an individual .unity3d bundle instead of a master bundle | Exclude_From_Master_Bundle |
Bundle_Override_Path | string | Path within the master bundle to load, overriding the default path derived from the file location | Bundle_Override_Path /Objects/Medium/Furniture/Note |
Bundle_Path_Include_Filename | bool | If true, the path within the master bundle appends the asset file name as a subdirectory | Bundle_Path_Include_Filename true |
Asset_Bundle_Version | int | Unity version indicator for the .unity3d bundle | Asset_Bundle_Version 6 |
Format A: Asset_Bundle_Version values
| Value | Unity version | Notes |
|---|---|---|
1 | Unity 5.5 | Earliest supported version |
2 | Unity 2017.4 LTS | |
3 | Unity 2018.4 LTS / 2019.4 LTS | |
4 | Unity 2020 LTS | |
5 | Unity 2021 LTS | |
6 | Unity 2022 LTS | Latest as of the current Unturned™ release |
When Unturned™ upgrades Unity versions, it attempts to maintain backward compatibility based on this number. Mods built against older Unity versions may continue to function after a game update if the version number is correct.
Format B: the simple definition
Format B is the minimal asset definition structure. It consists of a GUID line and a Type line at the root level, with no Metadata or Asset sub-dictionaries, and typically no master bundle linkage fields. Format B is used for assets that do not require a bundle, their identity alone is the entire asset definition, or their content is resolved through other means (the file system hierarchy, a .dat companion file, or a default prefab).
Evidence from shipped files: the BlueprintCategoryTag_Ammo.asset file in Bundles/Assets/Tags/BlueprintCategory/Ammo/ uses Format B:
GUID d739926736374e5ba34b4ac6ffbb5c8f
Type Tag
HasIcon true
IconPath UI/BlueprintCategoryTagIcons/Ammo.pngThe GUID and Type are at the root level. There is no Metadata block, no Asset block, and no bundle-linkage fields. The body fields (HasIcon, IconPath) are also at the root level, after the identity fields. This file is a complete and valid asset definition.
When to use Format B
Format B is used by asset types that are self-contained, their definition does not need to reference a 3D model prefab, a texture, or any other binary content from a Unity bundle. The following asset types consistently use Format B across the vanilla installation:
| Asset type | Directory | Evidence |
|---|---|---|
| Blueprint category tags | Bundles/Assets/Tags/BlueprintCategory/ | All tag .asset files use Format B |
| Crafting tags | Bundles/Assets/Tags/Crafting/ | Same pattern as blueprint tags |
| Miscellaneous tags | Bundles/Assets/Tags/Misc/ | Same pattern |
| Editor redirectors | Editor/Redirectors/ (in Unity project, not in game Bundles) | Same pattern per SDG documentation |
Did you know?
Format B .asset files are structurally identical to root-level Format A .asset files except for the absence of bundle-linkage fields. The distinction between the two formats is a convention (based on what the asset type requires) rather than a syntactic requirement. A Format B file can include bundle-linkage fields if needed; the format label describes typical usage, not a hard parser constraint.
Asset loading order
When the game scans a folder for assets, it checks for definition files in a specific priority order. Understanding this order is essential for diagnosing "asset not found" bugs and for planning the file structure of a mod project.
The loading order, highest priority first:
- A
.assetfile with the same name as the folder. If the folder isEaglefire/and the folder containsEaglefire.asset, that file is loaded as the asset definition. - A
.datfile with the same name as the folder. If the folder isEaglefire/and the folder containsEaglefire.dat(but noEaglefire.asset), that file is loaded. - An
Asset.datfile. If no same-name.assetor.datfile exists, the game looks forAsset.datin the folder. - Otherwise, load all
.assetfiles in the folder. Every.assetfile in the folder is loaded as a separate asset definition. This is the catch-all behavior for folders that contain multiple independent asset definitions.
| Priority | File checked | Example path | When used |
|---|---|---|---|
| 1 | <FolderName>.asset | Eaglefire/Eaglefire.asset | When the folder and file share a name |
| 2 | <FolderName>.dat | Eaglefire/Eaglefire.dat | When no same-name .asset exists |
| 3 | Asset.dat | Eaglefire/Asset.dat | Generic fallback for single-asset folders |
| 4 | All *.asset files | Tags/BlueprintCategory/TagA.asset, TagB.asset | For multi-asset definition folders |
Pro tip
Most item mods use priority 2, a .dat file with the same name as the folder. The Melee/Axe_Camp/Axe_Camp.dat file and the Guns/Ace/Ace.dat file both follow this pattern. The Asset.dat fallback (priority 3) is used by mods that follow the Asset.dat convention in their folder structure.
Master bundle resolution chain
The master bundle resolution chain determines which .masterbundle or .unity3d file the game loads for a given asset. The chain resolves in the following order:
As shown in the flowchart above, the master bundle is the preferred content source for most asset types. Individual .unity3d bundles are the fallback for legacy assets and for assets that explicitly opt out of the master bundle system via the Exclude_From_Master_Bundle flag.
The master bundle hierarchy search works upward from the asset's directory. Starting at the asset's folder, the game checks for a MasterBundle.dat file. If none is found, it moves up to the parent directory and checks again. This continues until a MasterBundle.dat is found or the root of the Bundles/ directory is reached. The first MasterBundle.dat found in this upward search is the one used, this is the "nearest master bundle in the file hierarchy" rule.
Editor Asset Redirectors
A redirector asset is a special asset type that remaps asset references. When an asset reference (GUID or legacy ID) points to a redirector, the asset system returns the asset pointed to by the redirector's TargetAsset field instead of the redirector itself. Redirectors are used primarily during level editing in the Unity Editor; they allow a level designer to change which asset a placed object refers to without modifying every instance of that object in the level.
Redirector .asset structure
A redirector is a Format B .asset file with Type Redirector (or a fully qualified redirector type name). The body fields define the redirector's behavior:
| Field | Type | Required | Purpose |
|---|---|---|---|
AssetCategory | enum | No | If set, the redirector also remaps legacy ID references within the specified category (e.g., AssetCategory Item means @give 4 resolves through this redirector) |
TargetAsset | GUID | Yes | The GUID of the actual asset to return when an asset reference points to this redirector |
Redirector behavior notes
Most features in Unturned™ save the original asset reference, not the resolved asset. When a level is saved after a redirector remapped some object references, the original redirector GUIDs, not the resolved target GUIDs, are written to the save file. This means the redirector must remain present and valid for the level to load correctly; removing the redirector after saving a level will cause the level's references to point to a nonexistent asset.
Redirectors are used exclusively in the Unity Editor workflow for level design and are not typically authored by modders creating item or vehicle mods. They are documented here for completeness and because they appear as .asset files in the Editor/Redirectors/ directory of a Unity project that includes Unturned™'s modding tools.
Worked examples from shipped files
Example 1: Format A, root-level style (Ace.dat)
The Ace pistol demonstrates the most common Format A variant used for item assets. All fields, identity and body, are at the root dictionary level:
GUID 92b49222958d4c6fbeca1bd00987b0fd
Type Gun
Rarity Uncommon
Useable Gun
Slot Secondary
ID 107
Size_X 2
Size_Y 2
Size_Z 0.35
Size2_Z 0.35
Magazine 108
Hook_Barrel
Ammo_Min 2
Ammo_Max 6
Safety
Semi
Caliber 6
Range 100
Firerate 10
Action Trigger
Player_Damage 50
Player_Leg_Multiplier 0.6
Player_Arm_Multiplier 0.6
Player_Spine_Multiplier 0.8
Player_Skull_Multiplier 1.1
Zombie_Damage 99
Zombie_Leg_Multiplier 0.3
Zombie_Arm_Multiplier 0.3
Zombie_Spine_Multiplier 0.6
Zombie_Skull_Multiplier 1.1
Animal_Damage 50
Animal_Leg_Multiplier 0.6
Animal_Spine_Multiplier 0.8
Animal_Skull_Multiplier 1.1
Barricade_Damage 25
Structure_Damage 20
Vehicle_Damage 30
Resource_Damage 20
Object_Damage 25
Durability 0.08
Aim_In_Duration 0.15
Spread_Aim 0.05
Spread_Angle_Degrees 5.71
Recoil_Min_X -4
Recoil_Min_Y 15
Recoil_Max_X -8
Recoil_Max_Y 20
Recover_X 0.5
Recover_Y 0.5
Shake_Min_X -0.01
Shake_Min_Y 0.01
Shake_Min_Z -0.1
Shake_Max_X 0.01
Shake_Max_Y -0.01
Shake_Max_Z -0.15
Muzzle 3
Blueprints
[
{
Name Repair
CategoryTag "732ee6ffeb18418985cf4f9fde33dd11" // Repair
Operation RepairTargetItem
InputItems
[
{
ID "21ede8ebffb14c5580e8c7ad149e335e" // Metal Scrap
Amount 3
}
{
ID "5830b84bf8074caa91cf3f4dde0dd19e" // Blowtorch
Delete false
}
]
RequiresNearbyCraftingTags
[
"7b82c125a5a54984b8bb26576b59e977" // Workbench
]
Effect "84347b13028340b8976033c08675d458" // Wrench
}
{
Name Salvage
CategoryTag "7ed29f9101ae4523a3b2e389414b7bd9" // Salvage
InputItems this
OutputItems "21ede8ebffb14c5580e8c7ad149e335e x 2" // Metal Scrap
Effect "84347b13028340b8976033c08675d458" // Wrench
}
]This Format A root-level file demonstrates: the identity block (GUID, Type, ID), inherited ItemAsset fields (Size_X, Size_Y, Rarity), gun-specific fields (Caliber, Firerate, Recoil), cross-reference by ID (Magazine 108), presence flags (Safety, Semi, Hook_Barrel), and a deeply nested Blueprints array.
Example 2: Format A, Metadata-and-Asset style (DefaultAirdrop.asset)
The default airdrop definition demonstrates the Metadata and Asset block variant:
Metadata
{
GUID 229440c249dc490ba26ce71e8a59d5c6
Type SDG.Unturned.AirdropAsset, Assembly-CSharp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
}
Asset
{
Landed_Barricade
{
GUID fe71781c60314468b22c6b0642a51cd9
}
Carepackage_Prefab
{
MasterBundle core.masterbundle
AssetPath Level/Carepackage.prefab
}
}This Format A variant demonstrates: the Metadata block containing the identity fields, the fully qualified Type string, the Asset block containing body fields, nested dictionaries (Landed_Barricade, Carepackage_Prefab), and bundle-path specification (MasterBundle, AssetPath).
Example 3: Format B, simple tag definition (BlueprintCategoryTag_Repair.asset)
The repair blueprint category tag demonstrates Format B:
GUID 732ee6ffeb18418985cf4f9fde33dd11
Type Tag
HasIcon true
IconPath UI/BlueprintCategoryTagIcons/Repair.pngThis Format B file demonstrates: the minimal identity block (GUID and Type at root level), no Metadata or Asset blocks, simple body fields (HasIcon, IconPath), and no bundle-linkage fields (the tag has no 3D model and does not need a bundle).
Complete asset definition field reference
| Field | Type | Format | Required | Purpose |
|---|---|---|---|---|
GUID | 32-char hex string | Both | Yes | Globally unique identifier for the asset |
Type | string | Both | Yes | Determines which C# class reads the asset's fields |
ID | uint16 | Format A | Yes (items) | Legacy numeric identifier; unique per category |
Master_Bundle_Override | string | Format A | No | Name of a specific master bundle to use |
Exclude_From_Master_Bundle | flag | Format A | No | If present, use individual .unity3d bundle instead of master bundle |
Bundle_Override_Path | string | Format A | No | Path within the master bundle to load content from |
Bundle_Path_Include_Filename | bool | Format A | No | If true, appends asset file name as subdirectory in bundle path |
Asset_Bundle_Version | int | Format A | No | Unity version indicator for the bundle |
AssetCategory | enum | Redirector | No | Category for legacy ID redirector remapping |
TargetAsset | GUID | Redirector | Yes | GUID of the actual asset the redirector points to |
Frequently asked questions
What is the difference between a .dat file and an .asset file?
The file extension signals a historical distinction. Before the 3.23.6.0 update, .dat files and .asset files used different syntax versions ("v1" and "v2"). After that update, both extensions use the same syntax grammar documented in the Data File Format Reference. In current Unturned™ versions, the choice between .dat and .asset is a matter of convention and loading-order priority: a same-name .asset file takes priority over a same-name .dat file in the loading order. The contents and syntax are identical.
Do I need both a .dat and a .asset file for each item?
No. An item requires one definition file. Most vanilla items use a .dat file with the same name as the folder and no .asset file. Some newer assets use a .asset file instead. If both a same-name .asset and .dat exist in the same folder, the .asset takes priority and the .dat is ignored.
What happens if two assets have the same GUID?
The asset that loads later overwrites the earlier asset in the engine's internal registry. The earlier asset effectively disappears, its fields, references, and in-game behavior are replaced by the later asset. This is the GUID collision failure that produces "item invisible" or "item replaced by different item" bugs. GUIDs must be unique across all mods loaded together.
Can I use the same GUID across different mods?
No. If two mods are loaded on the same server or in the same single-player session, any GUID collision between them will cause one mod's asset to overwrite the other. Generate a fresh GUID for every asset and never reuse GUIDs from other mods, tutorial files, or example projects.
How does the game find the prefab for an asset without a Master_Bundle_Override?
If no Master_Bundle_Override is specified, the game searches upward through the directory hierarchy for a MasterBundle.dat file (see the master bundle resolution chain flowchart earlier in this article). If a MasterBundle.dat is found, the game uses that master bundle and resolves the asset's prefab path based on the asset's file path relative to the bundle's asset prefix. If no MasterBundle.dat is found, the game looks for a .unity3d file with the same name as the .dat file in the same directory.
Can I put GUID and Type in a Metadata block for every asset type?
Yes. The Metadata block placement is valid for any asset type. However, the auto-generation of an empty GUID field only works in the root dictionary, not inside a Metadata block. If you use the Metadata block structure, always provide an explicit GUID value. The cohort recommendation is to use the root-dictionary style for item assets (matching the vanilla convention) and the Metadata block style only when the asset type's documentation or tooling expects it.
What is the difference between Type as a short name and Type as a fully qualified name?
The short name (e.g., Type Melee) is an alias that the game resolves to the corresponding C# class internally. The fully qualified name (e.g., Type SDG.Unturned.AirdropAsset, Assembly-CSharp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null) specifies the exact class, assembly, and version. Short names are used for all built-in item, vehicle, animal, and object types. Fully qualified names are used for asset types that do not have a registered short-name alias or when the modder needs to specify a type from a specific assembly.
Can an asset reference another asset by GUID even if they're in different categories?
Yes. GUID-based references work across any asset category. A blueprint's CategoryTag field references a tag asset by GUID; a tag asset is not in the same category as the item that references it. GUIDs are globally unique and category-independent. Legacy ID-based references (e.g., a gun's Magazine 108 field) are category-scoped, they only work within the same category because IDs are only unique per category.
How do I know which asset type a .dat file is for?
The Type field on the first few lines of the file. Open the file in a text editor; the Type field (immediately after the GUID field) tells you which C# class will read the file. The type determines the entire set of recognized fields. If you are unsure which fields a given type supports, refer to the type-specific article in this knowledge base (e.g., Melee Asset for Type Melee).
Can one .asset file define multiple assets?
No. Each .dat or .asset file defines exactly one asset. A folder can contain multiple .asset files (each defining one asset), which is the pattern used by the tags system: the Tags/BlueprintCategory/ folder contains one .asset file per tag. The folder name is not the asset name in this pattern, each .asset file is an independent asset definition.
Best practices
- Generate a fresh GUID for every asset using a UUID v4 generator. Remove hyphens. Never reuse GUIDs.
- Place the
GUIDandTypefields at the root level of the dictionary for item assets, matching the vanilla convention. - Use
Asset_Bundle_Versionto declare the Unity version the bundle was built for, ensuring backward compatibility on game updates. - Use
Master_Bundle_Overrideonly when the asset needs a bundle different from the hierarchy-determined one. - Assign IDs in the 50,000+ range to avoid vanilla and community mod ID collisions.
- Match the file name to the folder name (e.g.,
MyItem/MyItem.dat) unless the folder contains multiple assets (Format B pattern). - Always provide an
English.datfile in the same directory for localization. - Verify the GUID is unique across all assets in the mod project before testing in-game.
- Do not delete redirector
.assetfiles used during level editing, levels save the original redirector GUIDs, not the resolved target GUIDs. - Use root-level Format A for item and vehicle assets; use Format B for tags, redirectors, and assets without bundle dependencies.
Appendix A: Quick-reference field card
GUID <32-char-hex> ← required, globally unique
Type <AssetType> ← required, determines recognized fields
ID <uint16> ← required for items, unique per category
Metadata ← optional block (Format A variant)
{
GUID <...>
Type <...>
}
Asset ← optional block (Format A variant)
{
<body fields>
}
Master_Bundle_Override <name> ← optional, overrides hierarchy bundle
Exclude_From_Master_Bundle ← optional, use .unity3d instead
Bundle_Override_Path <path> ← optional, path within bundle
Bundle_Path_Include_Filename true ← optional, append filename to path
Asset_Bundle_Version <1-6> ← optional, Unity version indicatorAppendix B: Asset loading order reference
Priority 1: <FolderName>.asset ← same-name .asset file
Priority 2: <FolderName>.dat ← same-name .dat file
Priority 3: Asset.dat ← generic fallback
Priority 4: All *.asset files ← multi-asset folder catch-allAppendix C: Master bundle resolution reference
1. Exclude_From_Master_Bundle set? → use individual .unity3d
2. Master_Bundle_Override set? → use named master bundle
3. MasterBundle.dat in hierarchy? → use nearest hierarchy master bundle
4. Same-name .unity3d exists? → use that individual bundle
5. None of the above → no bundle; prefab not loadedCross-references
- Data File Format Reference, the previous article; the complete syntax grammar for
.datand.assetfiles. - Asset Validation Rules, the next article; documents the validation checks the game runs on asset definitions at load time.
- Item Asset Anatomy, the shared field reference for every item type's identity block.
- Melee Asset, the complete reference for
Type Meleeassets. - Project Folder Structure and GUIDs, GUID generation and folder layout conventions.
- Master Bundle Export from Unity, the Unity bundling workflow that produces the
.masterbundlefiles referenced by asset definitions. - GUID Conflicts Between Mods, diagnostic guide for GUID collision failures.
- Smartly Dressed Games modding documentation, the official specification for asset definitions, loading order, and master bundle linkage.
- Unturned on Steam, the Unturned™ store page; game updates may add or modify asset definition fields.
Document history
| Version | Date | Author | Notes |
|---|---|---|---|
| 1.0 | 2026-07-26 | 57 Studios | Initial publication. Complete asset definitions reference validated against shipped game files. |
Glossary
| Term | Definition |
|---|---|
| Asset definition | A text file (.dat or .asset) that associates game data with Unity content via GUID, Type, and bundle-linkage fields |
| AssetBundle | A Unity binary file (.unity3d or .masterbundle) containing 3D models, textures, audio, and prefabs |
| Format A | The structured asset definition with optional Metadata and Asset sub-dictionaries |
| Format B | The simple asset definition with GUID and Type at the root level and no sub-dictionary blocks |
| Fully qualified name | The complete .NET type reference including namespace, class, and assembly |
| GUID | A 128-bit globally unique identifier written as a 32-character hex string |
| Inheritance hierarchy | The C# class tree that determines which fields each asset type recognizes |
| Loading order | The prioritized sequence the game uses to find an asset definition file in a folder |
| Master bundle | A .masterbundle file containing bundled Unity assets for multiple asset definitions |
| Master bundle resolution | The chain of decisions that determines which bundle file the game loads for an asset |
| Redirector asset | A special asset type that remaps GUID and legacy ID references to a different target asset |
| Root dictionary | The implicit top-level key-value dictionary in a .dat or .asset file |
| Type string | The value of the Type field that determines the asset's C# class |
