Data File Format Reference

Intermediate40-60 minutesWindowsNotepad++Unity Editor

Every item, vehicle, animal, object, resource, and effect in Unturned™ is defined by a plain-text data file. The .dat file and its companion .asset file share a common syntax that governs how keys, values, arrays, objects, comments, and escape sequences are written and parsed. A modder who understands this syntax completely can diagnose every field-level error a mod can produce; a modder who guesses at it will spend hours chasing bugs that a syntax reference would catch in seconds.

This article is the 57 Studios™ canonical reference for the .dat and .asset file syntax. It documents the character encoding, line-ending conventions, comment rules, full syntax grammar, boolean value notation, numeric types, string quoting rules, enum value formats, GUID representation, nesting depth limits, whitespace significance, and common parser failure modes. The reference is built from the official Smartly Dressed Games documentation and validated against the shipped game files in the Unturned™ Bundles directory. Every syntax element documented below can be confirmed by opening any vanilla .dat file in the game installation.

Documentation source: This article references the official Smartly Dressed Games modding documentation for the syntax specification and parser behavior. Game-file evidence was sampled from the Unturned™ Bundles/Items/ directory and cross-referenced against the documented parser rules.

Who this article is for

This article is written for Unturned™ mod authors at every experience level. New modders should read it before authoring a single .dat file to understand the syntax rules that govern every field they will write. Experienced modders should keep it open as a reference when debugging parse failures, authoring nested data structures, or troubleshooting boolean field behavior. The article presupposes that the reader has Notepad++ installed with UTF-8 encoding configured; if you have not yet done so, read How to Open a DAT File and How to Save a DAT File with Correct Encoding before proceeding.

What you'll learn

• The character encoding of every .dat and .asset file the Unturned™ parser consumes
• The line-ending convention and why it matters for cross-platform mod development
• The comment syntax, including the distinction between standalone comments and inline comments
• The full syntax grammar: how keys are named, how values are written, how arrays and objects are nested
• The three notational forms of boolean values and when each is used in vanilla files
• The numeric types the parser expects and how they map to C# built-in types
• The string quoting rules: when quotation marks are required, optional, or forbidden
• The enum value representation and how enum fields appear in shipped files
• The GUID format convention and the prohibition on hyphens
• The nesting depth limits and practical constraints on deeply nested structures
• The common parser failure modes and the diagnostic messages they produce

Background: how the Unturned parser reads a data file

The Unturned™ game client and dedicated server use a custom line-oriented parser to read .dat and .asset files. The parser does not use JSON, XML, YAML, or any third-party serialization library. It is a custom-built tokenizer that reads the file line-by-line, splits each line into a key and a value on the first whitespace character, and maps those key-value pairs into C# object properties through the asset class hierarchy.

Understanding the parser's expectations is the foundational skill of mod authoring. Every .dat field the modder writes must survive the parser's tokenization step; if the parser cannot tokenize a line correctly, the field either takes on an unintended value or is silently ignored. The parser produces no warnings for syntactically valid but semantically incorrect field values (a float where an int is expected, a value outside the acceptable range), which is why the modder must also know the type system documented later in this reference.

The parser operates in two passes. The first pass reads every line into a key-value dictionary, resolving the nesting structure (dictionaries opened by {, lists opened by [, and their corresponding closing braces and brackets). The second pass maps the dictionary entries to C# object properties by matching key names to field names on the asset class. Fields whose keys do not match any property on the target class are silently discarded; fields whose values cannot be parsed into the target type are coerced to the type's default value.

Character encoding

Every .dat and .asset file in the Unturned™ game installation is encoded as UTF-8 with a Byte Order Mark. The three-byte BOM sequence EF BB BF precedes the file's content and signals to text editors and to the parser that the file is UTF-8 encoded. The parser expects UTF-8 and will correctly read files with or without the BOM, but the cohort recommendation is to always include the BOM because Notepad++ and other Windows text editors use it as the primary signal for encoding detection.

Evidence from shipped files: a byte-level inspection of Arid_Arrowhead.dat from the Unturned™ Bundles/Items/Arid/Arid_Arrowhead/ directory shows the first three bytes as 0xEF, 0xBB, 0xBF (the UTF-8 BOM), followed immediately by the first character of the GUID field. This pattern is consistent across every .dat and .asset file sampled from the vanilla installation.

Encoding characteristic	Value	Evidence
Character encoding	UTF-8	All sampled .dat and .asset files
Byte Order Mark	EF BB BF (3 bytes)	Present at offset 0 in every file inspected
BOM required by parser?	No, but recommended	Parser handles UTF-8 with or without BOM
BOM required in practice?	Yes, for Notepad++ detection	Notepad++ uses BOM as the encoding signal

Pro tip

If you are using Notepad++ for .dat authoring, confirm the encoding is set to "UTF-8" (not "UTF-8-BOM" as a separate option) before saving. Notepad++ appends the BOM automatically when saving as UTF-8. If you are authoring .dat files programmatically (through a build script or a tool), prepend the three BOM bytes to the file output to match the vanilla convention.

Common mistake

Saving a .dat file as "UTF-8" in some text editors (including older versions of Windows Notepad) produces a file without a BOM. This is functionally valid (the parser will read the file correctly) but will cause Notepad++ to display a detection warning on the next open. Always save with BOM to match the vanilla file convention and avoid diagnostic noise.

Line ending convention

The vanilla .dat and .asset files in the Unturned™ installation use Windows-style line endings: a carriage return followed by a line feed, represented as \r\n (hex bytes 0D 0A). This is the standard line-ending convention for text files on the Windows platform and the convention the parser expects.

The parser tolerates Unix-style line endings (\n only) and classic Mac-style line endings (\r only) without error. However, mod files with inconsistent line endings (mixed \r\n and \n within the same file) can produce unexpected behavior in some Notepad++ plugins and version-control diff tools. The cohort recommendation is to use consistent \r\n line endings throughout every mod .dat file.

Line ending	Convention	Parser behavior	Recommendation
\r\n (CRLF)	Windows standard	Expected and accepted	Use for all .dat files
\n (LF)	Unix standard	Accepted but not standard	Avoid for consistency
\r (CR)	Legacy Mac	Accepted but non-standard	Avoid
Mixed endings	Error in other tools	Parser tolerates but diff tools may not	Avoid; use consistent \r\n

Comment syntax

The // sequence denotes a comment. Everything from the // to the end of the line is excluded from parsing and has no effect on the data file's runtime behavior.

Standalone comments

A line that begins with // is a standalone comment. The entire line is excluded from parsing. Standalone comments are the only comment form that does not require the preceding value to be quoted, because there is no preceding value.

// This entire line is a comment. The parser ignores it completely.
// Comments are useful for documenting the purpose of a field block,
// recording the modder's rationale for a particular value, or
// leaving notes for the next developer who opens the file.
GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d
Type Melee

Inline comments

An inline comment appears on the same line as a key-value pair, after the value. Inline comments require the value to be enclosed in quotation marks, because the parser uses the closing quotation mark as the end-of-value delimiter and treats everything after it, including //, as a comment. A value that is not quoted causes the parser to treat // and everything after it as part of the value.

// CORRECT: Inline comment after a quoted value.
GUID "a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d" // This is a comment. It is excluded from the GUID value.

// WRONG: Inline comment after an unquoted value.
GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d // This is NOT a comment. It becomes part of the GUID value.

Evidence from shipped files confirms the inline comment convention. In Ace.dat (the vanilla Ace pistol, located at Bundles/Items/Guns/Ace/Ace.dat), the following line appears:

CategoryTag "732ee6ffeb18418985cf4f9fde33dd11" // Repair

The GUID value is quoted, and the // Repair suffix is excluded from the parsed value. This pattern repeats across every vanilla file that includes inline comments.

Comment type	Syntax	Requires quoted value?	Example
Standalone comment	// at line start	No	// This is a comment
Inline comment	// after value	Yes	Key "value" // comment
Unquoted inline (broken)	// after unquoted value	N/A, does not work	Key value // becomes part of value

Critical warning

An unquoted value followed by // does not produce a comment. The // and everything after it is parsed as part of the value. This is the single most common comment-related error in .dat authoring, and it is especially dangerous because the file parses without error but the value carries unintended trailing content. A GUID field with an unquoted inline comment will contain extra characters after the 32-character hex string, which may or may not be detected as a GUID mismatch depending on how the game validates the field.

Full syntax grammar

Key-value pairs

The fundamental unit of .dat syntax is the key-value pair. A key and a value are separated by whitespace, typically a single space, but any sequence of whitespace characters (spaces, tabs) functions as a separator.

Key1 First value
"Key2 in quotes" Second value
Key3 "Third value"

These three lines are parsed into the following C# dictionary entries:

"Key1" = "First value"
"Key2 in quotes" = "Second value"
"Key3" = "Third value"

Key naming rules

Keys follow the Snake_Case convention: words are separated by underscores, with the first letter of each significant word capitalized. Keys are case-insensitive, the parser treats Use_Cool_Option, use_cool_option, and UsE_cOoL_oPtIoN as identical. Keys must be unique within their containing dictionary; a duplicate key overwrites the earlier value with the later one.

Keys may contain spaces if the key is enclosed in quotation marks, but no key in the vanilla Unturned™ asset set uses a space in its name. Keys may appear in the root dictionary or inside a Metadata or Asset sub-dictionary. The placement of a key determines which C# class processes it; keys in the Metadata sub-dictionary are read by the asset-loading infrastructure, while keys in the root dictionary or the Asset sub-dictionary are read by the specific asset type's class.

Key characteristic	Rule	Example
Naming convention	Snake_Case with leading capitals	Player_Damage, Size_X, Caliber_Reference
Case sensitivity	Case-insensitive	Damage_Player = damage_player = DAMAGE_PLAYER
Uniqueness	Must be unique within the dictionary	Second occurrence overwrites first
Spaces in key	Allowed if quoted, but never used in practice	"Key With Spaces" value is valid syntax
Placement	Root dictionary, or Metadata/Asset sub-dictionary	Depends on asset type

Value parsing rules

A value is the text following the first whitespace after the key, continuing to the end of the line. If the value is enclosed in quotation marks, the parser strips the outer quotes and uses the text between them as the value. If the value is not enclosed in quotation marks, the parser uses the entire remainder of the line as the value, trimmed of trailing whitespace but including any // sequences (because the parser cannot distinguish a comment prefix from part of an unquoted value).

Quotation marks within a quoted value can be escaped with a backslash (\"). The sequence \n within a quoted value is interpreted as a newline character, allowing multi-line string values to be expressed on a single line in the data file.

// A value containing quotation marks, correctly escaped:
Description "This item uses the \"Slash\" attack action."
// Parsed as: This item uses the "Slash" attack action.

// A multi-line value using the \n escape:
Text "First line\nSecond line\nThird line"
// Parsed as three lines:
// First line
// Second line
// Third line

Objects (dictionaries)

A child dictionary is opened by placing { on the line immediately following a key, and closed by a matching } on its own line. The lines between the braces form the child dictionary's key-value pairs. The opening brace must appear on the next line, it cannot appear on the same line as the key, because this would break backward compatibility with the oldest .dat files, which may have { as the first character of a value.

// root-level key opens a child dictionary:
Metadata
{
    GUID 7e4b847061b64272b42ea8869fd053c7
    Type SDG.Unturned.Asset
}

Child dictionaries can be nested arbitrarily:

object1
{
    object2
    {
        key value
    }
}

The parser treats the root level of every file as an implicit dictionary. Fields at the root level are entries in this root dictionary. The Metadata and Asset sub-dictionaries are optional organizational conventions, the parser does not require them, and a file with all fields at the root level is functionally identical to one with the same fields inside an Asset sub-dictionary.

Arrays (lists)

An array is opened by placing [ on the line immediately following a key, and closed by a matching ] on its own line. As with objects, the opening bracket must appear on the next line, never on the same line as the key.

values
[
    first value
    second value
    third value
]

Arrays can contain simple values (strings, numbers) or child dictionaries:

List_Of_Objects
[
    {
        x 1
        y 2
    }
    {
        x 3
        y 4
    }
]

Evidence from shipped files shows extensive use of nested arrays of objects. The Blueprints array in Ace.dat demonstrates the canonical form:

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
    }
]

Legacy array notation

Many older asset properties predate the addition of array syntax. These use a count key followed by zero-indexed entries:

Elements 2
Element_0 A
Element_1 B

The Elements field declares the count, and each Element_N field provides the value at index N. This notation persists in many vanilla asset types for backward compatibility and is recognized by the parser alongside the bracket-array notation.

Boolean value notation

Boolean values in Unturned™ .dat files are expressed in three distinct notational forms, each with its own rules and use cases.

Form 1: explicit true or false

The parser recognizes the literal tokens true and false for boolean fields. This is the clearest and most common notation for fields that can be either true or false.

Delete false
Mirror_Left_Handed_Model false
HasIcon true

Evidence from shipped files: Ace.dat includes Delete false inside the repair blueprint's InputItems array. BlueprintCategoryTag_Ammo.asset includes HasIcon true. CA_Biker_Mask_0.asset includes Mirror_Left_Handed_Model false.

Form 2: numeric 1 or 0

The parser accepts 1 as true and 0 as false for boolean fields. This notation is less common in shipped files but is documented in the Smartly Dressed Games specification and is valid syntax.

SomeBool 1
SomeOtherBool 0

Form 3: presence or absence

For flag-type boolean fields, the mere presence of the key name on its own line (with no value) is interpreted as true. The absence of the key entirely is interpreted as false. This is the notation used for capability flags that default to false.

Safety
Semi
TwoHanded
RepairTool
Hair
Beard
Pro

Evidence from shipped files: The Ace.dat gun file includes the lines Safety and Semi on their own lines to declare that the weapon supports safe and semi-automatic fire modes. The Axe_Camp.dat melee file does not include TwoHanded (it is absent, so the default is false). The Bat.dat melee file does not include TwoHanded either. The Arid_Arrowhead.dat mask file includes Hair, Beard, and Pro as presence-only flags.

Notation	Syntax	Use case	Evidence from shipped files
Explicit	true / false	Fields that can be either value	Delete false in Ace.dat; HasIcon true in BlueprintCategoryTag_Ammo.asset
Numeric	1 / 0	Alternative for fields that accept both	Documented in SDG specification; less common in shipped files
Presence	Key name alone	Capability flags defaulting to false	Safety, Semi in Ace.dat; Hair, Beard, Pro in Arid_Arrowhead.dat

Did you know?

The presence/absence boolean notation is the source of a common authoring mistake in which the modder writes Safety true expecting to enable the safe fire mode, but the explicit true is parsed as the value, which is also true. The field functions correctly, but the modder has written redundant syntax. The parser does not reject the redundant notation, which is why the mistake is never caught.

Numeric types

The parser maps numeric values to the C# built-in types used by the asset property system. The type mapping determines the acceptable range of values and the default value when a field is missing.

C# type	Alias	Range	Default	Common .dat fields
bool	Boolean	true / false	false	Safety, Semi, Pro, TwoHanded
int8	sbyte	-128 to 127	0	Rarely used in .dat files
uint8	byte	0 to 255	0	Size_X, Size_Y, Wear, Reloads
int16	short	-32,768 to 32,767	0	Infrequent in item assets
uint16	ushort	0 to 65,535	0	ID, Caliber_Reference, Magazine reference
float32	float, single	Up to 7 significant digits	0	Damage_Player, Range, Strength, Durability, Speed
int32	int	-2,147,483,648 to 2,147,483,647	0	Asset_Bundle_Version
uint32	uint	0 to 4,294,967,295	0	Less common in item .dat files
float64	double	Up to 15 significant digits	0	Used primarily in internal engine calculations
int64	long	-9.22e18 to 9.22e18	0	Rarely used in mod .dat files
uint64	ulong	0 to 1.84e19	0	Rarely used in mod .dat files
string	-	Sequence of Unicode characters	null	Name, GUID, Type, Model, AttackAudioClip

The parser performs type conversion at load time. A value that is not parseable into the target type is coerced to the type's default value without producing a warning. For example, writing Durability high (where a float is expected) results in Durability taking the default value 0, which makes the item instantly destroyed.

Common mistake

Integer fields (ID, Size_X, Amount) require whole-number values. Writing Size_X 2.5 for a field typed as uint8 results in the parser failing to parse the value and coercing it to the default 0. An item with Size_X 0 cannot be picked up or may be invisible in the inventory grid. Always match the value format to the field's C# type.

String values

String values in .dat files are the default value type, most values the parser reads are strings that are later converted to the appropriate C# type by the asset class. The parser distinguishes between quoted and unquoted strings.

Quoted strings

A quoted string is enclosed in double quotation marks ("). The parser strips the opening and closing quotation marks and uses the text between them as the value. Quoted strings support the \" escape sequence for embedding quotation marks and the \n escape sequence for embedding newlines. Quoted strings are required when:

• The value contains a // comment on the same line (so the parser knows where the value ends and the comment begins)
• The value contains leading or trailing whitespace that must be preserved
• The value contains quotation marks that must be preserved
• The modder wants to embed a multi-line value using the \n escape

Unquoted strings

An unquoted string is simply the text following the key on the same line. The parser reads everything after the first whitespace to the end of the line, trims trailing whitespace, and uses the result as the value. Unquoted strings cannot contain inline comments (because the // sequence is treated as part of the value). Unquoted strings are sufficient for most field values in .dat files, GUIDs, numeric values, enum values, and simple name strings all work correctly without quotation marks.

Value characteristic	Use quoted string?	Example
Simple word or number	No	Type Melee
Value with inline comment	Yes	"732ee6ffeb18418985cf4f9fde33dd11" // Repair
Value with internal spaces	No (space is the separator)	Name MyItem, only MyItem is the value
Multi-word value	Yes	"My Item Name"
Value with embedded quotes	Yes, with \"	"\"Slash\" attack"
Multi-line value	Yes, with \n	"First line\nSecond line"

Enum values

Enum fields in .dat files accept the enum member name as a string value. The parser maps the string to the corresponding C# enum member. Enum values are case-sensitive at the parser level but case-insensitive at the C# enum-mapping level, meaning the parser resolves them by name.

Evidence from shipped files shows enum values written in plain text without quotation marks in most cases:

• Type Melee, Type Gun, Type Magazine, Type Mask
• Rarity Common, Rarity Uncommon, Rarity Rare, Rarity Epic
• Slot Primary, Slot Secondary, Slot None
• Action Trigger, Action Pump, Action Bolt, Action Break
• Operation RepairTargetItem

The enum value corresponds to the member name in the C# enum definition, not to a display name or a translated string. Writing an incorrect enum value (e.g., Rarity SuperRare where the enum does not contain a SuperRare member) results in the parser coercing the value to the enum's default member (typically the first member defined in the enum, which is often None or Common).

GUID format

A GUID (Globally Unique Identifier) in Unturned™ .dat files is a 32-character hexadecimal string with no hyphens, no braces, and no other formatting characters. The 128-bit identifier is written as a continuous string of lowercase hexadecimal digits.

GUID 92b49222958d4c6fbeca1bd00987b0fd

Evidence from every shipped .dat file confirms the format: 32 hex characters, lowercase, no separators. The standard UUID format (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) is never used in .dat files, the hyphens must be removed before the GUID is written to any .dat or .asset file.

GUID characteristic	Rule	Evidence
Length	Exactly 32 characters	Every vanilla .dat file inspected
Character set	Hexadecimal: 0-9, a-f	Lowercase in all shipped files
Separators	None (no hyphens, no braces)	Confirmed across Bundles/Items/*/
Case	Lowercase in shipped files; uppercase is parsed correctly	Parser is case-insensitive for hex
Generation source	UUID v4 (random), hyphens removed	Standard practice; online generators used

Nesting rules and depth limits

Dictionaries and arrays can be nested to arbitrary depth, objects within arrays within objects, and so on. The parser imposes no hard depth limit. The practical constraint on nesting depth is readability: a file with more than four or five levels of nesting becomes difficult to scan and to diff in version control.

The Blueprints array in the vanilla Ace.dat demonstrates three levels of nesting: the root dictionary contains the Blueprints key, which opens an array of { } objects, each of which contains InputItems which opens another array of { } objects, each of which contains simple key-value pairs. This is the deepest nesting level encountered in any vanilla item file.

Nesting level	Structure	Example
0	Root dictionary	Top of file
1	Direct child dictionary or array	Metadata { }, Blueprints [ ]
2	Object inside root array	{ Name Repair ... } inside Blueprints
3	Array inside level-2 object	InputItems [ ] inside a blueprint object
4	Object inside level-3 array	{ ID ... Amount 3 } inside InputItems
5	Not observed in vanilla files	Hypothetical deeper nesting

The cohort recommendation is to keep nesting to four levels or fewer. If a data structure requires deeper nesting, consider whether the design can be flattened by extracting some of the nested data into separate assets referenced by GUID.

Whitespace significance

Whitespace in .dat files serves as a token separator but is otherwise not significant to the parser. The specific whitespace rules are:

• Line breaks separate key-value pairs. Each line is one pair (with the exception of multi-line values using the \n escape, which embed newlines inside a single value).
• Spaces and tabs between a key and its value are collapsed to a single separator. Multiple spaces, mixed spaces and tabs, and leading/trailing whitespace on the value are ignored.
• Indentation (leading whitespace before a key) is cosmetic. The parser ignores indentation entirely. Indentation is used in vanilla files for readability but has no syntactic meaning.
• Blank lines between key-value pairs are ignored. Blank lines are used in vanilla files to separate logical blocks of fields and improve readability.
• Whitespace before { and [ on the opening line is ignored. The brace or bracket can be flush left or indented.
• Whitespace before } and ] on the closing line is ignored.

Pro tip

The vanilla .dat files use a consistent indentation style: root-level keys are flush left, dictionary and array contents are indented by one tab, and nested contents increment by one additional tab per level. Adopting this style makes your .dat files visually consistent with the vanilla set and easier for other modders to read.

Worked examples from shipped files

Example 1: simple item identity block (Arid_Arrowhead.dat)

The shortest complete .dat file in the vanilla item set that demonstrates the essentials:

GUID 137cf1616d5f42c3b55074be7e593f26
Type Mask
Useable Clothing
ID 1709

Size_X 2
Size_Y 1
Size_Z 0.6

Hair
Beard

Pro

This file demonstrates: the root-level GUID and Type fields, a uint16 ID, float dimensions (Size_Z 0.6), presence-only boolean flags (Hair, Beard, Pro), and blank lines between logical blocks.

Example 2: melee weapon with damage fields (Axe_Camp.dat)

A .dat file demonstrating damage categories, durability, and nested blueprint arrays:

GUID 3bba8c2b013646fb964932c31060b60a
Type Melee
Useable Melee
Slot Secondary
ID 16

Size_X 2
Size_Y 3
Size_Z 0.6
Size2_Z 0.6

Range 2
Strength 1.5
Stamina 25

Player_Damage 34
Player_Leg_Multiplier 0.6
Player_Arm_Multiplier 0.6
Player_Spine_Multiplier 0.8
Player_Skull_Multiplier 1.1

Zombie_Damage 34
Zombie_Leg_Multiplier 0.3
Zombie_Arm_Multiplier 0.3
Zombie_Spine_Multiplier 0.6
Zombie_Skull_Multiplier 1.1

Animal_Damage 34
Animal_Leg_Multiplier 0.3
Animal_Spine_Multiplier 0.6
Animal_Skull_Multiplier 1.1

Barricade_Damage 15
Structure_Damage 10
Vehicle_Damage 25
Resource_Damage 100
Object_Damage 25

Durability 0.1

Blueprints
[
    {
        Name Repair
        CategoryTag "732ee6ffeb18418985cf4f9fde33dd11" // Repair
        Operation RepairTargetItem
        InputItems "21ede8ebffb14c5580e8c7ad149e335e x 3" // Metal Scrap
        RequiresNearbyCraftingTags
        [
            "7b82c125a5a54984b8bb26576b59e977" // Workbench
        ]
        Effect "84347b13028340b8976033c08675d458" // Wrench
    }
    {
        Name Salvage
        CategoryTag "7ed29f9101ae4523a3b2e389414b7bd9" // Salvage
        InputItems this
        OutputItems "21ede8ebffb14c5580e8c7ad149e335e x 2" // Metal Scrap
        Effect "84347b13028340b8976033c08675d458" // Wrench
    }
]

AttackAudioClip Sounds/MeleeAttack_01.mp3

This file demonstrates: float damage values, nested arrays of objects, inline comments on quoted values, string values containing paths, and the structured block layout using blank lines.

Example 3: gun with nested blueprint array (Ace.dat)

A .dat file demonstrating the most complex nesting pattern observed in vanilla item files:

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 file demonstrates: the presence-only boolean flags (Safety, Semi), an integer reference to a magazine asset (Magazine 108), explicit false boolean (Delete false), a nested array of objects inside another array object, and the full damage-field block organized by target category.

Complete syntax element reference table

Syntax element	Notation	Example	Parser behavior
Key-value pair	Key Value	Type Melee	Parsed as "Type" = "Melee"
Quoted key	"Key Name" Value	"My Key" My Value	Key parsed as My Key
Quoted value	Key "Value"	Description "An item"	Value parsed as An item (quotes stripped)
Standalone comment	// comment	// This is a comment	Entire line excluded
Inline comment	Key "Value" // comment	GUID "abc123" // note	Must use quoted value
Object open	Key\n{	Metadata\n{	Brace must be on next line
Object close	}	}	Closes most recent {
Array open	Key\n[	Blueprints\n[	Bracket must be on next line
Array close	]	]	Closes most recent [
Array of objects	[\n{\n}\n{\n}\n]	See Blueprints in Ace.dat	Standard pattern
Boolean explicit	true / false	Delete false	Parsed as C# bool
Boolean numeric	1 / 0	SomeFlag 1	1 = true, 0 = false
Boolean presence	Key alone	Safety	Key present = true; absent = false
Integer	Digits, no decimal	ID 107	Parsed as int/uint based on field type
Float	Digits with decimal	Durability 0.08	Parsed as float/double
Negative number	- prefix	Recoil_Min_X -4	Parsed as signed numeric type
GUID	32 hex chars	92b49222958d4c6fbeca1bd00987b0fd	No hyphens, no braces
String	Any text after key	Name Eaglefire	Default value type
Enum value	Member name string	Rarity Uncommon	Matched against C# enum
Escape \"	\" inside quoted value	"\"Slash\"" → "Slash"	Embed quotation marks
Escape \n	\n inside quoted value	"Line 1\nLine 2"	Embed newline character
Path string	Forward-slash separated	Sounds/MeleeAttack_01.mp3	Unity asset path convention
Blank line	Empty line	Between field blocks	Ignored by parser
Indentation	Leading tabs/spaces	Contents of { } blocks	Cosmetic only

Common mistakes and parser behavior on malformed input

The parser is designed to be tolerant and to fail silently rather than emit errors. This design philosophy, present since the earliest versions of the .dat format, means that syntactically invalid input rarely produces a visible error message at load time. Instead, the parser coerces invalid values to defaults, skips unrecognized keys, or concatenates content in ways the modder did not intend.

Mistake	What the modder wrote	What the parser does	Result
Inline comment on unquoted value	GUID abc123 // comment	Treats // comment as part of value	GUID is abc123 // comment, not abc123
Opening brace on same line as key	object { key value }	Treats { as part of the key's value	Child dictionary not created
Opening bracket on same line as key	list [ item1 item2 ]	Treats [ as part of the key's value	Array not created
Duplicate key in same dictionary	Type Melee then later Type Gun	Second value overwrites first	Final value is Gun; no warning issued
Float value on integer field	Size_X 2.5	Parser fails to parse as uint8; coerces to 0	Item has zero-width grid footprint
String value on numeric field	ID one-two-three	Parser fails to parse; coerces to 0	Item ID is 0; console spawn fails
Wrong enum value	Rarity SuperRare	Enum mapping fails; coerces to default	Rarity defaults (often Common); no warning
Missing closing }	Forgot } at end of object	Parser reads to end of file	All subsequent fields absorbed into object
Missing closing ]	Forgot ] at end of array	Parser reads to end of file	All subsequent lines absorbed into array
GUID with hyphens	GUID a1b2c3d4-e5f6-...	Hyphens become part of the 39-char string	Field longer than 32 chars; may fail GUID validation
Quoted value without closing quote	Name "My Item	Parser reads to end of line; quote is part of value	Value begins with ", may fail field validation
Unescaped quote inside quoted value	"Quotes "inside" value"	First internal " terminates the quoted string	Value is Quotes ; inside" value" is ignored or causes parse error

Critical warning

The silent-failure behavior of the parser means that a .dat file with multiple syntax errors can load without any warning, and the resulting item may appear to work correctly in-game while carrying incorrect values for several fields. The modder discovers the error only when a player observes that the item's damage, capacity, or behavior differs from the intended design. The cohort recommendation is to compare every .dat field against this reference before testing in-game, and to test every field explicitly during the single-player verification step.

Frequently asked questions

Why do braces and brackets have to be on the next line?

Backward compatibility. The oldest .dat files (predating the introduction of dictionary and array syntax in update 3.23.6.0) could have { or [ as the first character of a value. If the parser allowed braces on the same line as the key, it would break these older files by interpreting a value that happens to start with { as the opening of a child dictionary. Requiring the brace on the next line preserves backward compatibility with every .dat file ever written for Unturned™.

How does the parser handle a key with no value on the line?

If a line contains only a key (no value after the whitespace separator), and the next line is not { or [, the key is recorded with an empty string value. If the key is a presence-type boolean flag, the empty string is interpreted as true. If the key expects a typed value, the empty string is coerced to the type's default.

Can I use tab characters for indentation?

Yes. The parser ignores all leading whitespace on a line, regardless of whether it is spaces or tabs. The vanilla .dat files use tabs for indentation within dictionaries and arrays. The cohort recommendation is to match the vanilla convention and use tabs.

What happens if I include a comment on a line with no key?

The line is a standalone comment and is excluded from parsing, the same as any other comment line. There is no distinction between a // line at the root level and a // line inside a dictionary or array.

Can I use single-line array or object syntax?

No. The [ and ] brackets and the { and } braces must be on their own lines. The parser does not support inline array or object literals like [1, 2, 3] or {key: value}. Every element in an array must be on its own line, and every key-value pair in an object must be on its own line.

How do I represent an empty array?

An empty array is written as an opening bracket followed immediately by a closing bracket on the next line:

MyEmptyList
[
]

An array with no elements is valid and parses correctly. Some asset types treat an empty array as equivalent to the field being absent; others distinguish between an empty array and a missing array.

Does the parser care about the order of keys in a dictionary?

No. The parser builds a dictionary from the key-value pairs and the C# property-mapping step matches keys to properties by name, not by position. Keys can appear in any order. However, the vanilla .dat files follow a consistent key ordering (identity block first, then dimensions, then damage categories, then blueprints), and the cohort recommendation is to match this ordering for readability and diff-compatibility.

Can I use the \n escape outside of a quoted string?

No. The \n escape sequence is only recognized inside a quoted string. An unquoted value containing the literal characters \n is parsed as the two-character string \n, not as a newline.

How are negative numbers represented?

A leading hyphen (-) before the digits. Evidence from shipped files shows negative float values: Recoil_Min_X -4, Shake_Min_Z -0.1. The parser treats the hyphen as part of the numeric literal and correctly maps it to a signed type (int16, int32, float32).

What is the maximum line length the parser can handle?

The parser imposes no documented line length limit. Practical limits are determined by the text editor and the modder's ability to read long lines. The vanilla .dat files keep lines under approximately 120 characters. Lines that exceed this (rare) are typically long path strings or escaped multi-line values.

Best practices

• Include the UTF-8 BOM on every .dat and .asset file to match the vanilla file convention and ensure correct text-editor encoding detection.
• Use consistent \r\n line endings throughout every mod file.
• Use the explicit true/false boolean notation for fields that can be either value; use the presence-only notation for capability flags that default to false.
• Enclose values in quotation marks whenever the line includes an inline comment, to ensure the comment is correctly excluded from the parsed value.
• Match the vanilla indentation convention: tabs for one level of nesting inside { } and [ ], with root-level keys flush left.
• Organize key-value pairs into logical blocks separated by blank lines, matching the vanilla file layout.
• Verify every field against the type reference table before testing in-game, silent coercion to defaults is the dominant source of undetected .dat errors.
• Remove hyphens from GUIDs before writing them to any .dat or .asset file.
• Test every boolean flag field explicitly in single-player after authoring, presence-only flags are easy to miss because the absence produces no error.
• Keep nesting depth to four levels or fewer; extract deeply nested data into separate assets if the structure demands more.

Appendix A: Quick-reference syntax card

Copy this card and keep it open while authoring .dat files.

Key value                     ← key-value pair
"Key With Spaces" value       ← quoted key
Key "value with spaces"       ← quoted value
// standalone comment         ← standalone comment
Key "value" // inline         ← inline comment (value MUST be quoted)
Key                            ← presence-only boolean flag (true)
Key true                       ← explicit boolean
Key 1                          ← numeric boolean
Key 42                         ← integer value
Key -4                         ← negative integer
Key 3.14                       ← float value
Key
{                              ← child dictionary (brace on next line)
    ChildKey childValue
    NestedKey
    {
        DeepKey deepValue
    }
}
Key
[                              ← array (bracket on next line)
    value1
    value2
    {
        subKey subValue        ← object inside array
    }
]

Appendix B: Diagnostic table for parser failure modes

Symptom	Most likely cause	How to verify	Resolution
Field takes default value silently	Value type mismatch (string where int expected)	Check field type against C# type table	Write value in the correct format
Item invisible in inventory grid	Size_X or Size_Y coerced to 0	Check for decimal on integer field	Write whole-number values for Size_X and Size_Y
GUID field length wrong	Hyphens not removed from UUID	Count characters; should be exactly 32	Remove hyphens from generated UUID
Inline comment not working	Value not quoted before //	Look for // in parsed field value	Quote the value: Key "value" // comment
Child dictionary not parsed	{ on same line as key	Check that { is on its own line	Move { to the line after the key
Array not parsed	[ on same line as key	Check that [ is on its own line	Move [ to the line after the key
All lines after point X parsed into wrong structure	Missing closing } or ]	Count opening and closing braces/brackets	Add the missing closing character
Item spawns with wrong rarity	Enum value not recognized	Verify enum value against known set	Use a documented rarity enum value
Boolean flag not taking effect	Flag key omitted entirely	Check for the flag key's presence	Add the key on its own line
File opens with encoding warning in Notepad++	BOM missing	Check encoding: should be UTF-8	Resave as UTF-8 (BOM will be added)

Cross-references

• Asset Definitions Reference, the next article; documents the .asset file structure, GUID and Type properties, Format A and Format B, and the asset-to-bundle resolution chain.
• Asset Validation Rules, documents the validation checks the game runs on .dat and .asset files at load time.
• Item Asset Anatomy, the shared field reference for every item type; builds on the syntax documented here.
• How to Open a DAT File, the Notepad++ configuration guide for opening .dat files with correct encoding.
• How to Save a DAT File with Correct Encoding, the companion guide for saving files with the BOM and line endings documented here.
• Project Folder Structure and GUIDs, GUID generation and the folder layout that .dat files must reside in.
• Master Bundle Export from Unity, the bundling workflow; the .dat and .asset files reference the bundles built through this workflow.
• Smartly Dressed Games modding documentation, the official specification for the .dat file format and the C# built-in type system.
• Unturned on Steam, the Unturned™ store page; game updates may add or modify syntax features.

Document history

Version	Date	Author	Notes
1.0	2026-07-26	57 Studios	Initial publication. Complete syntax reference validated against shipped game files.

Glossary

Term	Definition
BOM	Byte Order Mark, the three-byte UTF-8 prefix EF BB BF that signals file encoding
CRLF	Carriage Return + Line Feed (\r\n), the Windows line-ending convention
Dictionary	An unordered collection of key-value pairs, denoted by { } in .dat syntax
Enum	A fixed set of named constant values in C#; represented by the member name in .dat files
Escape sequence	A backslash-prefixed character sequence (\", \n) that represents a special character inside a quoted string
GUID	Globally Unique Identifier, a 128-bit hexadecimal value used to uniquely identify every asset
Inline comment	A // comment on the same line as a key-value pair; requires the value to be quoted
Parser	The game's line-oriented tokenizer that reads .dat and .asset files into C# object properties
Presence flag	A boolean field whose mere presence on a line (without a value) is interpreted as true
Root dictionary	The implicit top-level dictionary containing all key-value pairs in a .dat file
Snake_Case	The naming convention using underscores between capitalized words (e.g., Player_Damage)
Type coercion	The parser's behavior of converting a value to a field's declared C# type, or to a default if conversion fails