C# Built-in Types Reference

Intermediate10-15 minutesCross-platformNotepad++

The C# built-in types are the fundamental data types that underpin every value in every Unturned™ configuration file. Every field in a .dat file, every property in an .asset file, and every parameter in a blueprint recipe is an instance of one of the C# built-in types. A mod developer who understands the range, precision, and serialization conventions of each type will author configuration files that parse correctly on the first attempt and will be able to diagnose parser errors without guesswork.

This article is the first in the data-types section of the 57 Studios™ Modding Knowledge Base. It covers every C# built-in type that appears in Unturned™ mod development: the boolean type (bool), the four signed integer widths (int8 through int64), the four unsigned integer widths (uint8 through uint64), the two floating-point widths (float32 and float64), and the string type. For each type, the article documents the full numeric range, the default value, the serialization format in .dat and .asset files, and the documented usage patterns observed across the shipped asset set. The companion articles in this section cover the GUID type (a 128-bit hexadecimal identifier that is not a C# built-in but is pervasive throughout the asset system), the enumerated types (the named-value sets such as EItemType and ESlotType that constrain key-value fields to specific valid strings), and additional specialized type references.

Documentation source: This article references the official Smartly Dressed Games modding documentation Chapter 135, "C# Built-in Types," for the type table and default values. Field usage patterns are validated against the shipped Unturned™ asset set at C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Items\*\*.dat and */\*.asset. The Microsoft C# built-in types reference is the upstream canonical source for the C# type system.

Who this article is for

This article is written for Unturned™ mod authors at any experience level who need a definitive reference for the types that appear in .dat files. New mod developers should read this article in full before authoring their first .dat file. Experienced mod developers should bookmark the type tables (reproduced in Appendix A as a quick-reference card) for fast look-up during authoring sessions.

What you'll learn

• The complete C# built-in type table: the four signed integer widths, the four unsigned integer widths, the two floating-point widths, the boolean type, and the string type
• The numeric range and default value for every built-in numeric type
• How each type is serialized in Unturned™ .dat and .asset files (key=value lines)
• The boolean representation conventions: true/false, 1/0, and presence/absence flags
• The string representation conventions: quoted versus unquoted, whitespace handling, and the empty string case
• The observed type coercion and parsing rules from the shipped asset set
• How integer width mismatches (e.g., supplying a value outside uint16 range for an ID field) produce parse-time errors
• Worked examples drawn from the shipped vanilla Unturned™ asset files

Background: the C# type system in Unturned mod development

The Unturned™ game engine is built on the Unity game platform, which embeds the Mono runtime and the C# language. Every value in every configuration file the engine reads is ultimately stored in a C# variable. The .dat and .asset file formats are text-based serializations of these C# values: each key=value line is a field name (a string) paired with a value that must be a valid literal for the field's declared C# type.

The parser that reads .dat files is not forgiving. If a field expects a uint16 (a value in the range 0 through 65535) and the file supplies 65536, the parser rejects the value. If a field expects a float and the file supplies text that cannot be parsed as a floating-point number, the parser rejects the value. Understanding the exact type of every field is the prerequisite to authoring configuration files that parse without errors. The alternative is trial and error, which is expensive: a single parsing error in a .dat file can cause the entire asset to fail to load, silently or with a console error that does not name the offending line.

The C# built-in type system is documented comprehensively by Microsoft. The source extract from the Smartly Dressed Games documentation (Chapter 135) reproduces the subset of the C# type system that appears in Unturned™ asset files. The table below is the canonical reference for Unturned™ mod development.

The C# built-in types table

C# Type	Alias(es)	Range	Default Value	Common Unturned™ Usage
bool	Boolean	true or false	false	Flag fields (Pro, Safety, TwoHanded), conditional toggles
int8	sbyte	-128 to 127	0	Rare; small signed values, encoded sub-states
uint8	byte	0 to 255	0	Inventory dimensions (Size_X, Size_Y), round counts (Amount), wear rates (Wear)
int16	short	-32768 to 32767	0	Rarely used in .dat; appears in plugin and server-mod code
uint16	ushort	0 to 65535	0	Item IDs (ID), caliber references (Caliber, Caliber_Reference), magazine references (Magazine)
float32	float, single	approx. -3.4×10³⁸ to 3.4×10³⁸, 7 digits precision	0	Damage values, ranges, multipliers, durability, speed, all decimal-configured fields
int32	int	-2147483648 to 2147483647	0	Asset bundle version (Asset_Bundle_Version), spawn counts, rarity weights
uint32	uint	0 to 4294967295	0	Large count fields; occasionally used for spawn-table capacities
float64	double	approx. -1.8×10³⁰⁸ to 1.8×10³⁰⁸, 15 digits precision	0	High-precision calculations (internal engine use; rare in .dat files)
int64	long	-9223372036854775808 to 9223372036854775807	0	Extremely large signed values (rare in .dat files)
uint64	ulong	0 to 18446744073709551615	0	Extremely large unsigned values (rare in .dat files)
string	,	sequence of zero or more Unicode characters	null	Names, paths, GUIDs, enum value strings, asset bundle names, prefab paths

The table above maps every C# built-in type that appears in Unturned™ mod development to its alias, its numeric range, its runtime default, and its typical usage in configuration files. The following sections document each type's serialization conventions in detail.

The boolean type in .dat and .asset files

The bool type is the simplest built-in type in the C# type system. A bool variable holds one of two values: true or false. In Unturned™ configuration files, the bool type appears in three distinct representation conventions.

Representation convention 1: explicit true/false

When a .dat or .asset file contains a field whose value is the literal text true or false, the parser interprets it as the corresponding boolean value. This is the most self-documenting convention.

Example from a shipped .asset file (CA_Biker_Mask_0.asset):

Mirror_Left_Handed_Model false

Example from a shipped .dat file (MasterBundle.dat, inferred convention):

// (hypothetical) SomeFlag true

The literal values true and false are case-sensitive. The parser does not accept True, FALSE, or any other capitalization variant. The shipped asset set uses lowercase exclusively.

Representation convention 2: numeric 1/0

When a .dat file contains a field whose value is the integer 1 or 0, and the field's declared type is bool, the parser interprets 1 as true and 0 as false. This convention is less common than the explicit true/false convention but is observed in some older asset files and in fields that were originally authored as integer-compatible before being reinterpreted as booleans.

Example (inferred pattern from shipped files):

Should_Delete_After_Use 1  // equivalent to true
Force_Reset 0             // equivalent to false

The numeric 1/0 convention is not documented in the SDG Chapter 135 source extract but is observed in the shipped asset set. The cohort recommendation is to use the explicit true/false convention for all newly authored .dat files, as it produces more readable configuration files and avoids ambiguity.

Representation convention 3: presence/absence (flag fields)

The most common boolean convention in Unturned™ .dat files is the presence/absence flag. A field that is a bool flag is written as a key with no value on a line by itself. The presence of the key signals true; the absence of the key from the file signals false.

Examples from shipped .dat files:

Pro            // The item is a PRO/DLC item. Presence = true.
Safety         // The gun has a safety fire mode. Presence = true.
Semi           // The gun has a semi-automatic fire mode. Presence = true.

In the Ace gun .dat file (Ace.dat), the lines Safety and Semi appear as bare keys. The parser reads these as boolean flags set to true. If the key is not present in the file, the field's value is the C# default for bool, which is false.

This convention is the source of a common authoring error: mod developers sometimes write Safety false expecting to explicitly disable the safety, but the parser treats the presence of the key at all as true regardless of the text that follows it. To disable a flag field, omit the key from the file entirely.

Flag fields and explicit values

Do not write Safety false or TwoHanded 0 expecting to disable a flag field. The flag convention (presence/absence) overrides explicit value parsing for fields that the engine treats as flag fields. To disable a flag field, omit the key from the .dat file. If you are unsure whether a particular field uses the flag convention or the explicit true/false convention, consult the field reference for that asset type.

Bool type summary table

Convention	Example	Parser Interpretation	Common Fields
Explicit true/false	Mirror_Left_Handed_Model false	Value is false	.asset properties, some .dat fields
Numeric 1/0	Should_Delete_After_Use 1	Value is true	Legacy fields, older assets
Presence/absence	Pro (on its own line)	Value is true	Flag fields: Pro, Safety, Semi, Auto, TwoHanded, RepairTool

The integer types in .dat and .asset files

Unturned™ uses four widths of signed integer and four widths of unsigned integer from the C# type system. The integer types are the workhorse of .dat authoring: item IDs, caliber references, inventory dimensions, magazine capacities, round counts, and spawn-table weights are all integer values.

Signed integer types

Type	C# Alias	Range	Default	Typical Field Usage
int8	sbyte	-128 to 127	0	Encoded sub-states, directional flags (rare)
int16	short	-32768 to 32767	0	Server plugin configuration values
int32	int	-2147483648 to 2147483647	0	Asset_Bundle_Version, spawn counts, index values
int64	long	-9223372036854775808 to 9223372036854775807	0	Large internal counters (rare in .dat)

Signed integer values in .dat files are written as plain decimal digits, optionally preceded by a minus sign for negative values. No commas, no thousand-separators, no hexadecimal prefixes are accepted.

Example from a shipped .dat file (MasterBundle.dat):

Asset_Bundle_Version 6

The value 6 is an int32 that indicates the Unity version for which the bundle was built. Values 1 through 6 are valid; negative values are technically valid as int32 values but no shipped asset file uses them for the Asset_Bundle_Version field.

Unsigned integer types

Type	C# Alias	Range	Default	Typical Field Usage
uint8	byte	0 to 255	0	Size_X, Size_Y, Amount (magazine capacity), Wear, Pellets, Reloads
uint16	ushort	0 to 65535	0	ID (item identifier), Caliber, Caliber_Reference, Magazine (magazine reference)
uint32	uint	0 to 4294967295	0	Spawn table capacities, large count fields
uint64	ulong	0 to 18446744073709551615	0	Extremely large counts (rare in .dat)

Unsigned integer values in .dat files are written as plain decimal digits. No sign prefix. Values outside the declared range produce a parse error.

Example from a shipped .dat file (Ace.dat):

ID 107

The value 107 is a uint16 (the ID field type). The maximum value for a uint16 is 65535. Values above 65535 produce a parse error. The Bypass_ID_Limit field (a boolean flag) relaxes an internal validation ceiling that blocks IDs above 2000 by default, but the uint16 range limit is enforced by the C# runtime and cannot be bypassed.

Example from a shipped .dat file (Axe_Camp.dat):

Size_X 2
Size_Y 3
Size_Z 0.6

The Size_X and Size_Y fields are uint8 values (0-255). The Size_Z field is a float32 value (discussed in the floating-point section below). The mix of integer and floating-point fields on the same asset is typical.

Integer overflow at the uint16 boundary

The legacy Unturned™ item ID system uses uint16 for the ID field, which imposes a hard cap of 65535. If a mod developer assigns an ID of 65536 or higher, the parser rejects the value. The 57 Studios™ cohort recommendation is to use IDs in the 50000+ range, which leaves approximately 15000 available IDs within the uint16 range. A mod that needs more than 15000 item IDs should split into multiple mods or adopt GUID-only referencing patterns that do not depend on legacy ID fields.

Integer serialization format

Integer values in .dat files must be bare decimal digits with no decoration. The parser does not accept:

Invalid Format	Example	Reason
Hexadecimal prefix	0xFF	Parser reads as string, not integer
Thousand separators	1,000	Comma terminates the value; parser reads 1 and ignores 000
Trailing decimal	10.0	This is a valid float literal; the parser may interpret it as a float instead of an int
Leading zeros	00107	Parser may accept this but the leading zeros are stripped; 00107 is parsed as 107
Negative unsigned	-1	Range violation for unsigned types; parse error

The shipped .dat files in the vanilla asset set use only bare, positive, decimal integer values with no decoration. The cohort recommendation is to follow this convention for all mod .dat files.

The floating-point types in .dat and .asset files

Unturned™ uses two floating-point widths from the C# type system. The single-precision float32 (aliased as float in C#) is the dominant type for mod configuration; the double-precision float64 (aliased as double) appears primarily in internal engine calculations and is rare in .dat files.

Floating-point type table

Type	C# Alias	Precision	Range	Default	Typical Field Usage
float32	float, single	Up to 7 significant digits	approx. ±3.4×10³⁸	0	Player_Damage, Zombie_Damage, Range, Strength, Durability, Speed, Stamina, all damage multiplier fields, explosion radius
float64	double	Up to 15 significant digits	approx. ±1.8×10³⁰⁸	0	High-precision physics or timing values (rare in .dat)

Float serialization format

Floating-point values in .dat files are written as decimal numbers with an optional fractional part. The decimal separator is the period (.). The parser accepts both integer-valued floats (e.g., 2) and explicit fractional values (e.g., 0.6, 1.5, 0.375).

Examples from shipped .dat files (Axe_Camp.dat):

Range 2          // integer-valued float: parsed as 2.0
Strength 1.5     // explicit fractional float
Stamina 25       // integer-valued float: parsed as 25.0
Durability 0.1   // low decimal float

Examples from shipped .dat files (Bat.dat):

Strong 0.375          // three-decimal-place float
Player_Damage 34      // integer-valued float
Player_Leg_Multiplier 0.6   // single-decimal-place float

The parser observes approximately seven significant digits of precision for float32 values, consistent with the IEEE 754 single-precision standard. Values with more than seven significant digits are rounded to the nearest representable float32 value at parse time. The cohort recommendation for .dat authoring is to limit decimal places to three or fewer for readability; the engine's internal rounding at the seventh significant digit makes additional decimal places unnecessary.

Observed float precision in shipped files

An analysis of the shipped vanilla asset set reveals the following precision patterns:

Decimal Places	Prevalence	Example Fields
0 (integer-valued)	Most common	Range 2, Player_Damage 34, Stamina 25
1	Common	Strength 1.5, Size_Z 0.6, Durability 0.1
2	Occasional	Size2_Z 0.35, Ballistic_Force 0.002
3	Rare	Strong 0.375, Player_Skull_Multiplier 1.1 (effectively 3 sig figs)
4+	Not observed	No shipped .dat file in the vanilla set uses four or more decimal places for a float field

The cohort recommendation is to match the precision of the vanilla assets: use zero or one decimal place for most float fields, two decimal places for multiplier and physics fields where precision matters, and never more than three decimal places.

The string type in .dat and .asset files

The string type is the most flexible built-in type in the C# type system: a sequence of zero or more Unicode characters. In Unturned™ configuration files, strings appear as GUIDs (32-character hexadecimal identifiers), enum value strings, asset names, prefab paths, bundle names, and prose content.

String serialization format

String values in .dat files are written in one of two forms: unquoted (the dominant form) and double-quoted (for strings containing spaces or special characters).

Unquoted strings

The majority of string values in .dat files are unquoted. The string value begins after the whitespace following the field name and extends to the end of the line. Unquoted strings must not contain spaces, tabs, or newline characters.

Examples from shipped .dat files:

Type Melee                        // enum-like string: "Melee"
Useable Melee                     // string: "Melee"
Slot Secondary                    // string: "Secondary"
Asset_Bundle_Name core.masterbundle    // string: "core.masterbundle"
Asset_Prefix Assets/CoreMasterBundle  // string with forward slash

Double-quoted strings

When a string value contains spaces, it must be wrapped in double quotes. The parser reads everything between the opening and closing double quotes as the string value, including internal spaces.

Examples from shipped .dat files (Axe_Camp.dat):

InputItems "21ede8ebffb14c5580e8c7ad149e335e x 3"    // quoted string with spaces
CategoryTag "732ee6ebff18418985cf4f9fde33dd11"
Effect "84347b13028340b8976033c08675d458"

The InputItems field in the blueprint section of Axe_Camp.dat demonstrates both conventions: a GUID string followed by a space, a multiplication operator, another space, and a quantity. Without the double quotes, the parser would terminate the string value at the first space and misinterpret x and 3 as separate tokens.

GUID strings (special case)

GUIDs are 32-character hexadecimal strings. In .dat files, the GUID field is always unquoted:

GUID 3bba8c2b013646fb964932c31060b60a

The GUID value contains only hexadecimal digits (0-9, a-f), which are safe for unquoted string parsing. No spaces or special characters are present. The detailed specification of the GUID format is covered in the companion article GUID Type Reference.

Quoted GUID references in blueprints

When a blueprint recipe references a GUID with additional formatting (quantity specifiers, concatenation), the entire expression is wrapped in double quotes:

InputItems "21ede8ebffb14c5580e8c7ad149e335e x 3"
OutputItems "21ede8ebffb14c5580e8c7ad149e335e x 2"

The parser treats the entire quoted string as a single value. The blueprint processing logic parses the internal structure (GUID, space, multiplier token, space, quantity) in a second pass.

Empty string and null

The C# string type distinguishes between an empty string ("", a valid string with zero characters) and a null string (null, no string value assigned). In Unturned™ .dat files:

• A field with no value on the same line (e.g., SomeField with nothing after it) is interpreted differently depending on the field's type. For boolean flag fields, it signals true. For string fields, the behavior depends on the parser's handling of empty or absent values.
• An explicitly empty quoted string ("") would be parsed as a zero-length string, but no shipped .dat file uses this convention.
• The null literal does not appear in .dat files. The SDG documentation lists null as the default value for the string type, but the parser does not accept the text null in a .dat file; it would be parsed as the five-letter string "null", not as the null reference.

String fields and parser fallback

When a string field is omitted from a .dat file, the parser typically assigns the C# default (null) or falls back to an engine-determined default based on the asset type. For example, omitting the Name field from an item .dat file causes the engine to use the file name as the internal name. The fallback behavior is field-specific and is documented in the field reference for each asset type.

Whitespace handling in string values

The parser strips leading and trailing whitespace from unquoted string values. A line like Type Melee (with extra whitespace) is parsed identically to Type Melee. The whitespace between the key and the value is the separator; the whitespace after the value (if unquoted) is trimmed. For quoted strings, the whitespace inside the quotes is preserved, but whitespace outside the quotes (before the opening quote and after the closing quote) is trimmed.

Type coercion and parsing rules

The Unturned™ parser applies a well-defined set of coercion rules when reading values from .dat files. Understanding these rules is essential for diagnosing parsing errors that do not produce obvious error messages.

Integer-to-float coercion

When a .dat file supplies an integer literal (e.g., 2) for a field that expects a float32, the parser performs an implicit widening conversion: the integer 2 becomes the floating-point value 2.0. This conversion is lossless and is the standard behavior observed in every shipped .dat file.

Float-to-integer coercion

When a .dat file supplies a floating-point literal (e.g., 2.5) for a field that expects an integer type (uint8, uint16, etc.), the parser rejects the value. There is no implicit truncation. The field is assigned its default value or the file fails to load. This coercion rule is inferred from the shipped asset set: no vanilla .dat file supplies a float literal for an integer-typed field.

String-to-enum coercion

Many .dat fields expect an enumerated type (see Enumerated Types Reference). The parser attempts to match the supplied string (case-sensitive) against the named values of the enum. If the string matches exactly, the enum value is assigned. If the string does not match any named value, the parser assigns the enum's default value (typically None or 0), which may produce silent incorrect behavior rather than a visible error.

This is a common authoring pitfall: writing Rarity uncommon (lowercase) instead of Rarity Uncommon (capitalized) causes the parser to fail to match and assign the default rarity tier rather than the intended one. The enum value is case-sensitive; the shipped asset set uses PascalCase for all enum values.

Bool coercion quirks

As documented in the boolean section above, the bool type's handling depends on whether the field uses the explicit true/false convention, the numeric 1/0 convention, or the presence/absence flag convention. The coercion behavior is not uniform across all bool fields; it is field-specific. When in doubt, consult the field reference for the specific asset type.

Oversize integer handling

When a .dat file supplies an integer value that exceeds the declared type's range (e.g., 65536 for a uint16 field), the parser rejects the value. There is no silent wrapping or modulo behavior. The field is assigned its default value or the file fails to load, depending on the parser's strictness for that particular field.

Worked examples from shipped .dat files

The following examples are drawn directly from the shipped Unturned™ asset set. Each example annotates the type of every value, demonstrating how the C# built-in types appear in real configuration files.

Example 1: Ace gun (Ace.dat)

GUID 92b49222958d4c6fbeca1bd00987b0fd    ← string (32-char hex)
Type Gun                                   ← string (enum value)
Rarity Uncommon                            ← string (enum value)
Useable Gun                                ← string
Slot Secondary                             ← string (enum value)
ID 107                                     ← uint16
Size_X 2                                   ← uint8
Size_Y 2                                   ← uint8
Size_Z 0.35                                ← float32
Size2_Z 0.35                               ← float32
Magazine 108                               ← uint16
Ammo_Min 2                                 ← uint8
Ammo_Max 6                                 ← uint8
Safety                                     ← bool (presence flag)
Semi                                       ← bool (presence flag)
Caliber 6                                  ← uint16
Range 100                                  ← float32
Firerate 10                                ← float32 (interpreted as rate)
Action Trigger                             ← string (enum value)
Player_Damage 50                           ← float32

The Ace gun .dat file demonstrates seven of the twelve C# built-in types in nine lines of configuration. The boolean flags (Safety, Semi) use the presence/absence convention. The integer values (ID, Size_X, Size_Y, Magazine, Ammo_Min, Ammo_Max, Caliber) span uint8 and uint16 widths. The floating-point values (Size_Z, Size2_Z, Range, Firerate, Player_Damage) span integer-valued floats and fractional floats. The string values cover GUIDs, enum-like strings, and bare ASCII identifiers.

Example 2: Camp axe (Axe_Camp.dat)

GUID 3bba8c2b013646fb964932c31060b60a    ← string (32-char hex)
Type Melee                                 ← string (enum value)
Useable Melee                              ← string
Slot Secondary                             ← string (enum value)
ID 16                                      ← uint16
Size_X 2                                   ← uint8
Size_Y 3                                   ← uint8
Size_Z 0.6                                 ← float32
Size2_Z 0.6                                ← float32
Range 2                                    ← float32
Strength 1.5                               ← float32
Stamina 25                                 ← float32
Player_Damage 34                           ← float32
Player_Leg_Multiplier 0.6                  ← float32
Player_Arm_Multiplier 0.6                  ← float32
Player_Spine_Multiplier 0.8                ← float32
Player_Skull_Multiplier 1.1                ← float32
Zombie_Damage 34                           ← float32
Zombie_Leg_Multiplier 0.3                  ← float32
Zombie_Arm_Multiplier 0.3                  ← float32
Zombie_Spine_Multiplier 0.6                ← float32
Zombie_Skull_Multiplier 1.1                ← float32
Animal_Damage 34                           ← float32
Animal_Leg_Multiplier 0.3                  ← float32
Animal_Spine_Multiplier 0.6                ← float32
Animal_Skull_Multiplier 1.1                ← float32
Barricade_Damage 15                        ← float32
Structure_Damage 10                        ← float32
Vehicle_Damage 25                          ← float32
Resource_Damage 100                        ← float32
Object_Damage 25                           ← float32
Durability 0.1                             ← float32

The camp axe .dat file is dominated by float32 values. A single uint16 field (ID 16) and two uint8 fields (Size_X 2, Size_Y 3) are the only integer values. The damage multiplier fields (Player_Leg_Multiplier, Zombie_Leg_Multiplier, etc.) demonstrate the typical one-to-three-decimal-place float precision that the vanilla asset set uses uniformly. The Durability field at 0.1 demonstrates a low fractional float value.

Example 3: Blueprint section with quoted strings (Axe_Camp.dat, continued)

Blueprints
[
    {
        Name Repair                        ← string (unquoted)
        CategoryTag "732ee6ebff18418985cf4f9fde33dd11"    ← string (quoted GUID)
        Operation RepairTargetItem         ← string (unquoted)
        InputItems "21ede8ebffb14c5580e8c7ad149e335e x 3" ← string (quoted with spaces)
        RequiresNearbyCraftingTags
        [
            "7b82c125a5a54984b8bb26576b59e977"
        ]
        Effect "84347b13028340b8976033c08675d458"        ← string (quoted GUID)
    }
]

The blueprint section demonstrates the string type in both unquoted and quoted forms. The Name, Operation, and top-level fields are unquoted strings (single words). The CategoryTag, InputItems, and Effect fields are quoted strings (GUIDs or GUID-with-quantity expressions). The RequiresNearbyCraftingTags array contains a single quoted GUID string. The contrast between unquoted single-word strings and quoted multi-word or GUID strings is the canonical pattern for string handling in .dat files.

Example 4: .asset file with bool, string, and flag fields (CA_Biker_Mask_0.asset)

GUID 640d3b5c486e499a99b85541f5dc777d    ← string (32-char hex)
Type Mask                                  ← string (enum value)
Mirror_Left_Handed_Model false            ← bool (explicit false)
Bundle_Path_Include_Filename true         ← bool (explicit true)
Pro                                        ← bool (presence flag)

This .asset file demonstrates the three boolean conventions in a single file: explicit false and true values (Mirror_Left_Handed_Model false, Bundle_Path_Include_Filename true) and a presence/absence flag (Pro). The GUID field demonstrates the 32-character hexadecimal string convention. The Type field demonstrates the enum-like string convention (Mask).

Type errors and parser diagnostics

When the Unturned™ parser encounters a value that cannot be converted to the field's declared type, the behavior depends on the strictness of the parser for that field and the severity of the error. The following table documents the known error cases and their observed behavior in the shipped asset set.

Error Case	Example	Parser Behavior	Detectable?
Integer overflow (uint16)	ID 65536	Value rejected; field assigned default (0) or file fails to load	Yes , item ID is 0 or file not found
Integer overflow (uint8)	Size_X 300	Value rejected; field assigned default (0)	Yes , inventory size is 0
Float literal for integer field	Size_X 2.5	Value rejected; field assigned default (0)	Yes , inventory size is 0
Non-numeric for numeric field	ID abc	Value rejected; field assigned default (0)	Yes , item ID is 0
Case-mismatched enum string	Rarity uncommon	Enum match fails; assigned default (Common)	Subtle , rarity displays as Common, not the intended tier
Unknown enum string	Type UnknownType	Enum match fails; type assignment fails; asset not loaded	Yes , asset does not appear in game
Malformed GUID length	GUID abc123 (too short)	GUID validation fails; asset may load with auto-generated GUID	Subtle , GUID changes on each load
Unclosed quoted string	Name "My Item (no closing quote)	Parser may consume subsequent lines or reject the file	Yes , file fails to load or consumes unexpected content

Pro tip

The quickest way to validate a .dat file's type correctness is to launch Unturned™ in single-player, spawn the item with @give, and confirm it behaves as expected. A field that is silently assigned its default value due to a type error will produce behavior that is visibly different from the intended configuration , an item with ID 0 will not spawn, an item with Rarity defaulted to Common will display as a white-quality item, and a gun with Caliber 0 unintended will accept any magazine with caliber 0. Testing catches type errors that the parser does not report.

Best practices

• Use the explicit true/false convention for bool fields that accept it; use presence/absence for flag fields as documented in the asset type's field reference.
• Always supply integer values in bare decimal format with no commas, no hexadecimal prefixes, and no trailing decimal points.
• Limit float decimal places to three or fewer. The engine's float32 precision makes additional decimal places invisible at runtime.
• Match the enum value casing exactly: PascalCase as observed in the shipped asset set.
• Wrap string values that contain spaces in double quotes. Unquoted strings must not contain spaces.
• Verify the ID field against the uint16 range (0-65535) before shipping. An out-of-range ID is a silent failure.
• Verify Size_X and Size_Y against the uint8 range (0-255) before shipping. An out-of-range size produces an invisible or unusable inventory slot.
• Use the worked examples from this article as a reference when authoring a new .dat file. The patterns in the shipped asset set are the canonical serialization format.
• Test every .dat file in single-player before publishing. A single type error can cause the entire asset to fail silently.

Frequently asked questions

What is the difference between float32 and float in .dat files?

float32 and float refer to the same type: the C# float type, which is a 32-bit single-precision floating-point number (IEEE 754). The term float32 is used in the SDG documentation table to make the bit width explicit alongside float64 (double). In .dat files, there is no distinction , both refer to the identical type. The parser accepts decimal literals for any field whose declared type is float32/float.

When should I use uint16 versus int32 for an ID field?

The ID field in Unturned™ item assets is declared as uint16, meaning its maximum value is 65535. You cannot use an int32-width value (above 65535) for an item ID. If you need an identifier larger than 65535, use a GUID instead , items upgraded to the GUID system are identified by their GUID field rather than by a legacy ID field. The ID field is a legacy system; new items should rely on GUIDs for identity and use ID only when required for compatibility with mods or systems that depend on integer IDs.

Why does the parser accept 2 for a float field?

The Unturned™ parser performs an implicit integer-to-float widening conversion. The integer literal 2 is converted to the floating-point value 2.0 at parse time. This conversion is explicit in the C# language specification (an int can be implicitly converted to a float without loss of precision for values within the representable range). The cohort recommendation is to write 2 rather than 2.0 for integer-valued float fields, matching the vanilla asset set convention.

How do I know whether a bool field uses the flag convention or the explicit true/false convention?

The convention is field-specific and documented in the field reference for the asset type. In general: fields whose presence alone indicates a state (e.g., Pro meaning "this is a PRO item," Safety meaning "this gun has a safety fire mode") use the presence/absence flag convention. Fields that toggle a setting on or off with an explicit choice (e.g., Mirror_Left_Handed_Model false) use the explicit true/false convention. When in doubt, consult the field reference for the specific asset type or examine the shipped vanilla .dat files for the field's usage pattern.

Can I use hexadecimal notation for integer values?

No. The Unturned™ .dat parser does not accept C# hexadecimal integer literals (0xFF, 0x1A). All integer values must be written in decimal format. This is a limitation of the text-based parser, not of the C# type system. Hexadecimal values appear only in GUID strings (where they are part of a 32-character string, not an integer literal).

What happens if I omit a required integer field entirely?

If a field with an integer type is omitted from the .dat file, the parser assigns the C# default value for that type (typically 0 for all integer types). The behavior of the asset at runtime depends on whether the engine treats a value of 0 as a valid configuration. For fields like ID, a value of 0 is typically treated as "not present" and the item may fail to load or behave unexpectedly. For fields like Size_X, a value of 0 produces an item with no inventory footprint, which may be invisible in the inventory UI. Always supply explicit values for required fields.

Are strings in .dat files case-sensitive?

The string values themselves are case-sensitive as far as the parser is concerned. However, the interpretation of the string depends on the field. For enum-typed fields (e.g., Type Melee), the parser performs a case-sensitive match against the enum's named values, meaning Type melee (lowercase) will not match Melee (PascalCase) and will produce a parser error or assign the default enum value. For display-name string fields (in English.dat), the case is preserved as authored and displayed to the player exactly.

What is the difference between null and an empty string in .dat files?

In C#, null is a reference that points to no string object, while "" is a valid string object containing zero characters. In .dat files, the null literal does not appear. Omitting a string field entirely typically results in the field being assigned null at the C# runtime level, which may trigger fallback behavior (e.g., using the file name as the default name). The empty quoted string "" would theoretically produce a zero-length string, but no shipped .dat file uses this convention and the parser's behavior with an empty quoted string is not documented.

How many significant digits can I use in a float32 value?

The float32 type (C# float) has approximately 7 significant digits of decimal precision per the IEEE 754 single-precision standard. Values with more than 7 significant digits are rounded to the nearest representable float32 value at parse time. The vanilla asset set does not use more than three decimal places for any float field, which is well within the 7-digit precision limit. The cohort recommendation is to limit float values to three decimal places for readability.

Can I put comments on the same line as a key=value pair?

The .dat file format supports // single-line comments that can appear at the end of a key=value line:

ID 107 // Ace pistol

The parser ignores everything from the // to the end of the line. Comments are used extensively in the MasterBundle.dat file and in well-organized mod projects. Comments do not affect type parsing; the value before the // is parsed as if the comment were not present.

What happens if I put a space in an unquoted string field intended to be a single identifier?

The parser treats the space as the end of the value. For example, Name My Item would be parsed as the value My (the text up to the first space), and Item would be treated as the beginning of a new key (or ignored, depending on parser strictness). To include a space in a string value, wrap the entire value in double quotes: Name "My Item".

Advanced considerations

Integer type selection for mod scripting

When writing C# server plugins or custom components for Unturned™, the choice of integer type affects memory layout, arithmetic overflow behavior, and compatibility with the game's API. The general rule is to match the type declared in the Unturned™ API for fields that interact with game systems, and to use int (which is int32) for general-purpose counters and loop indices. The full C# integer type table is relevant for plugin development even though .dat files primarily use uint8 and uint16.

Float precision and networked synchronization

Damage values, position offsets, and physics parameters that are serialized as float32 in .dat files are transmitted over the network as part of the game's state synchronization. The 7-digit precision of float32 is sufficient for all gameplay-relevant values. A damage value of 34.12345 would be rounded to approximately 34.12345 by the IEEE 754 representation, but the extra decimal places are invisible to players (the damage display rounds to whole numbers or one decimal place) and are lost in the integer conversion step of the damage calculation.

DotNet float parsing and locale sensitivity

The C# runtime's float parsing is locale-sensitive in some contexts, but the Unturned™ parser appears to use invariant culture parsing (period as decimal separator). A .dat file authored on a system whose locale uses a comma as the decimal separator (e.g., German or French Windows) should still use the period (.) as the decimal separator because the engine's parser expects it. This is consistent with the game's internal use of CultureInfo.InvariantCulture for parsing configuration files.

Unicode in string fields

The C# string type supports the full Unicode character set. In .dat files, string values may contain Unicode characters, including accented characters and non-Latin scripts. The English.dat localization file convention supports Unicode display names and descriptions. The cohort recommendation is to use ASCII for field names and enum value strings (matching the vanilla convention) and Unicode for display text in localization files.

The Asset sub-dictionary and type scoping

When a .dat file uses the Asset { ... } sub-dictionary convention (documented in Asset Definitions Reference), the fields inside the sub-dictionary are scoped to the asset's body and follow the same type rules as top-level fields. The type of each field is determined by the asset's Type, not by the presence of the Asset block. The sub-dictionary is a syntactic grouping, not a type system construct.

Appendix A: C# built-in types quick-reference card

C# Type	Alias(es)	Range	Default	.dat Serialization	Common Fields
bool	Boolean	true or false	false	true, false, 1, 0, or bare key	Pro, Safety, Semi, Auto, TwoHanded, RepairTool, Bypass_ID_Limit, Tracer, Incendiary, Sticky
int8	sbyte	-128 to 127	0	Bare decimal integer, optional -	Rare
uint8	byte	0 to 255	0	Bare decimal integer	Size_X, Size_Y, Amount, Wear, Pellets, Reloads, Ammo_Min, Ammo_Max
int16	short	-32768 to 32767	0	Bare decimal integer, optional -	Plugin config
uint16	ushort	0 to 65535	0	Bare decimal integer	ID, Caliber, Caliber_Reference, Magazine
float32	float, single	±3.4×10³⁸, 7 digits	0	Decimal with .	Player_Damage, Zombie_Damage, Range, Strength, Durability, Speed, Stamina, all damage multiplier fields
int32	int	±2.1×10⁹	0	Bare decimal integer, optional -	Asset_Bundle_Version, spawn counts
uint32	uint	0 to 4.3×10⁹	0	Bare decimal integer	Large counts
float64	double	±1.8×10³⁰⁸, 15 digits	0	Decimal with .	Rare in .dat
int64	long	±9.2×10¹⁸	0	Bare decimal integer, optional -	Rare in .dat
uint64	ulong	0 to 1.8×10¹⁹	0	Bare decimal integer	Rare in .dat
string	,	0+ Unicode chars	null	Unquoted or "quoted"	GUID, Type, Name, Asset_Bundle_Name, Asset_Prefix, Useable, Slot string enums, Master_Bundle_Override, Bundle_Override_Path

Appendix B: Type coercion rules summary

Source Type	Target Type	Behavior	Example
int literal	float32	Implicit widening conversion (lossless for values within precision)	Range 2 → 2.0
int literal	bool (numeric convention)	0 → false, any non-zero → true	Flag 1 → true
float literal	int type	Not accepted , parser rejects or field gets default (0)	Size_X 2.5 → rejected
string "true"/"false"	bool (explicit convention)	Exact case-sensitive match	Mirror false → false
string (any)	bool (flag convention)	Presence → true, absence → false (ignores value text)	Safety → true
string (PascalCase)	Enum	Case-sensitive match against named values	Type Melee → Melee
string (wrong case)	Enum	Match fails → default enum value (typically None/0)	Type melee → default
string	int type	Not accepted , parser rejects or field gets default (0)	ID abc → rejected

Appendix C: External references

Resource	URL	Notes
Smartly Dressed Games modding documentation	https://docs.smartlydressedgames.com/en/stable/	Chapter 135: C# Built-in Types; official field reference
Microsoft C# built-in types reference	https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/built-in-types	Upstream canonical source for the C# type system
Unturned on Steam	https://store.steampowered.com/app/304930/Unturned/	Game page
GUID Type Reference	/data-types/guid-type-reference	The next article; covers the 128-bit GUID type
Enumerated Types Reference	/data-types/enumerated-types-reference	The article after GUID; covers all 23 enum types
Data File Format Reference	/items/data-file-format-reference	The .dat and .asset file format specification
Asset Definitions Reference	/items/asset-definitions-reference	Asset structure, headers, and body conventions
Item Asset Anatomy	/items/item-asset-anatomy	Shared fields on every item asset

Document history

Version	Date	Author	Notes
1.0	2026-07-26	57 Studios	Initial publication. Complete C# built-in types reference covering all twelve types, serialization conventions, type coercion rules, worked examples from shipped files, FAQ, appendices.

Cross-references

• GUID Type Reference , the companion article covering the 128-bit GUID type in detail, including generation, lifecycle, and collision avoidance.
• Enumerated Types Reference , the companion article documenting all 23 Unturned™ enumerated types with every named value and usage context.
• Data File Format Reference , the .dat and .asset file syntax specification, including comment syntax, array format, and nesting rules.
• Asset Definitions Reference , the asset structure document covering headers, body, bundle association, and loading order.
• Item Asset Anatomy , the shared field reference for all item types; maps each field to its C# type.
• Smartly Dressed Games modding documentation , the official field reference and type documentation.
• Unturned on Steam , the game page and community hub.

Authoring checklist

Before publishing a .dat file, confirm the following type-correctness checks:

• [ ] All integer values are within the declared type's range (e.g., ID is between 0 and 65535)
• [ ] All float values use the period (.) as the decimal separator
• [ ] All boolean flag fields use the presence/absence convention (bare key, no value)
• [ ] All boolean explicit fields use lowercase true or false
• [ ] All enum string values match the documented named values exactly (case-sensitive)
• [ ] All string values containing spaces are wrapped in double quotes
• [ ] GUID strings are exactly 32 hexadecimal characters with no hyphens
• [ ] No thousand-separator commas appear in numeric values
• [ ] The field names match the documented field names exactly (case-sensitive)
• [ ] The file has been tested in single-player for at least loading, equipping, and usage