Vector3 Type Reference

Intermediate10-15 minutesCross-platformNotepad++

The Vector3 data type is the three-dimensional vector format used throughout the Unturned™ .dat file system. Every spatial property in the game -- the position of an object on a map, the scale of an item in the player's hand, the rotation of a vehicle turret, the offset of a weapon attachment hook, the recoil pattern of a firearm, and the center of mass of a physics-enabled entity -- is expressed as a Vector3 value. Understanding the three valid Vector3 representations and the coordinate system conventions is essential for every modder who authors items, vehicles, map objects, or any asset that occupies or interacts with three-dimensional space.

57 Studios™ has documented and validated the full Vector3 format specification as defined in the official Smartly Dressed Games modding documentation and as observed in shipped Unturned™ game files. This article covers all three valid Vector3 representations -- space-separated, parenthesized, and dictionary -- along with the Unity coordinate system conventions that govern which axis is up, which is forward, and how rotations are expressed. It also documents the legacy-parsed Vector3 fields that predate the unified Vector3 type, provides a complete table of the Vector3 fields that appear across asset types, and includes worked examples from shipped game files.

The Vector3 type is deceptively simple. A modder who has only ever seen the space-separated representation (1, 2, 3) may not realize that two alternative formats exist and that six legacy fields accept a fourth representation that splits the vector into separate float properties. Understanding the full specification prevents the common frustration of authoring a Vector3 field in one format and finding it silently ignored or partially parsed because the field expects a different representation.

Documentation source: This article references the official Smartly Dressed Games modding documentation for Vector3 field definitions and game behaviour. Community-validated notes are marked where the official documentation is silent on a detail.

Who this article is for

This article is written for Unturned™ mod authors who have completed at least one item mod and are familiar with the .dat file authoring workflow. Modders who are encountering a Vector3 field for the first time -- a Position on a map object, a Scale on a vehicle, a Recoil_Min on a gun -- should read this article in full before authoring the field. Modders who are building item types that include LOD_Center, LOD_Size, Explosion_Min_Force, Explosion_Max_Force, or Center_Of_Mass should read the legacy parsing section of this article carefully; these fields support both the unified Vector3 format and the legacy float-component alternative.

If you are new to Unturned™ modding, start with Project Folder Structure and GUIDs and Item Asset Anatomy before returning here. The Vector3 format is a subordinate data type that assumes familiarity with the .dat file structure documented in those articles.

What you'll learn

• The three valid Vector3 representations: space-separated, parenthesized, and dictionary
• The Unity coordinate system conventions: which axis is up, which is forward, and the handedness of the coordinate space
• The legacy-parsed Vector3 fields and their float-component alternative syntax
• The complete table of Vector3 fields that appear across Unturned™ asset types
• How the parser selects between Vector3 representations at load time
• Worked examples drawn from the official SDG documentation and shipped game files
• Common mistakes that cause Vector3 fields to parse incorrectly or produce unexpected spatial behaviour
• How Vector3 values interact with the struct system when embedded within nested dictionary configurations

Background: what the Vector3 data type is

The Vector3 data type in Unturned™ is a parser-level type, not an asset-level type. It is a value format that the game's .dat parser recognizes and converts into an in-memory Vector3 structure (Unity's UnityEngine.Vector3) whenever a field declares that it expects a three-dimensional vector value. The parser performs this conversion at asset load time -- when the game reads the .dat file into memory, encounters a Vector3-typed field, and constructs the corresponding data object with its x, y, and z components.

The Vector3 type is one of several core data types that the parser supports alongside integers, floats, strings, enums, flags, colours, and structs. Each of these types is documented in its own reference article within the data types section of the 57 Studios™ Modding Knowledge Base. The Vector3 type is unique among them in its connection to the Unity coordinate system -- the meaning of the X, Y, and Z components depends on the context in which the Vector3 is used. A Vector3 used as a position is interpreted differently from a Vector3 used as a rotation, which is interpreted differently from a Vector3 used as a scale, even though all three use the same underlying data format.

The parser resolves which representation is in use at the point of reading the field value. If the value contains commas and no surrounding parenthesis, the parser treats it as a space-separated Vector3. If the value is surrounded by parentheses and contains commas, the parser treats it as a parenthesized Vector3. If the value begins with {, the parser treats it as a dictionary with X, Y, and Z keys. The resolution is unambiguous because each representation has a distinct syntactic pattern.

The flowchart above shows the parser's single-pass resolution of the Vector3 representation. The syntactic pattern determines the parse path unambiguously, and the result is always the same in-memory structure regardless of which text representation was used.

The Unity coordinate system

Before examining the Vector3 format in detail, it is necessary to establish the coordinate system conventions that govern how Vector3 values are interpreted in three-dimensional space. Unturned™ is built on the Unity game engine, which uses a left-handed coordinate system with the following axis conventions:

Axis	Direction	Convention
X	Right (positive), left (negative)	Horizontal axis in the world plane
Y	Up (positive), down (negative)	Vertical axis; this is the "up" axis
Z	Forward (positive), backward (negative)	Depth axis in the world plane

The left-handed coordinate system means that if you point the fingers of your left hand in the positive X direction and curl them toward the positive Y direction, your thumb points in the positive Z direction. This is the opposite of a right-handed coordinate system (used by some 3D modelling tools, including Blender's default configuration), where the same finger-curl test produces the opposite Z direction. Modders who export meshes from Blender should be aware that Blender's default coordinate system is right-handed with Z-up, while Unity's coordinate system is left-handed with Y-up. The FBX exporter handles the axis remapping automatically when the correct export settings are used, but modders who author Vector3 values directly in .dat files must use the Unity convention, not the Blender convention.

The Y-up convention is the most important single fact about the coordinate system for Vector3 field authoring. When a field called Position specifies a Vector3, the Y component controls the height of the object above the ground plane, not the Z component. When a field called Offset specifies a Vector3 for a weapon attachment hook, the Y component controls the vertical offset of the attachment, not the Z component. Modders coming from other game engines or 3D tools where Z is the up axis must mentally remap their coordinate expectations.

Axis meanings by context

The same three components (X, Y, Z) carry different meanings depending on the context in which the Vector3 is used:

Context	X	Y	Z
Position	East-west offset (east is positive)	Height above/below ground (up is positive)	North-south offset (north is positive)
Scale	Width multiplier	Height multiplier	Depth multiplier
Rotation	Pitch (nose up/down, in Euler degrees)	Yaw (left/right turn, in Euler degrees)	Roll (tilt left/right, in Euler degrees)
Offset (attachment hooks)	Lateral offset from attachment point	Vertical offset from attachment point	Forward offset from attachment point
Recoil	Horizontal recoil component	Vertical recoil component	Depth recoil component (rarely used)

The rotation convention uses Euler angles in degrees. Positive rotations around an axis follow the left-hand rule: when your left thumb points in the positive direction of the axis, your fingers curl in the direction of positive rotation. For the Y axis (yaw), a positive rotation turns the object counter-clockwise when viewed from above.

The three Vector3 representations

Space-separated format

The space-separated format is the most common Vector3 representation in Unturned™ .dat files. It encodes the X, Y, and Z components as three space-separated floating-point values, optionally separated by commas.

The canonical syntax for the space-separated format is:

Position 1, 2, 3
Position 1 2 3

Both forms are valid. The commas are optional -- the parser accepts 1, 2, 3 and 1 2 3 as identical values. The cohort recommendation is to include the commas for readability; they visually separate the three components and reduce the chance of misreading a value during manual editing.

The component values are float32 values. They can be expressed as integers (1, 2, 3), as decimals (0.5, 1.25, 3.0), or in scientific notation (1e-3). Negative values use the minus sign (-1, -2.5). The parser expects exactly three components; a value with two components or four components will fail to parse.

The following is a complete worked example from the official SDG documentation:

Position 1, 2, 3

This specifies a position with X=1.0, Y=2.0, and Z=3.0 in the Unity coordinate system (1 unit east, 2 units above ground, 3 units north of the origin).

Parenthesized format

The parenthesized format encloses the three components in parentheses. The parentheses serve as syntactic grouping and do not change the parsed value.

The canonical syntax for the parenthesized format is:

Offset (4, 5, 6)

The opening parenthesis ( must appear immediately after the whitespace that follows the field name. The three components are separated by commas (mandatory in this format). The closing parenthesis ) terminates the value. The component values follow the same float32 convention as the space-separated format.

The parenthesized format is functionally identical to the space-separated format. The choice between the two is a matter of authoring preference. The parenthesized format is preferred by modders who work with coordinate systems in other contexts (programming, mathematics) where parentheses conventionally group multi-component values. The space-separated format is preferred by modders who value compactness and who primarily author values that are visually simple (integers or single-decimal floats).

Dictionary format

The dictionary format represents a Vector3 as three separate key-value pairs enclosed in curly braces. Each key specifies one component: X, Y, or Z.

The canonical syntax for the dictionary format is:

Scale
{
  X 7
  Y 8
  Z 9
}

The opening brace { must appear on the same line as the field name or on the line immediately following it. The parser expects each component key-value pair on its own line. The closing brace } appears on its own line. The X, Y, and Z keys take float32 values.

The dictionary format is the most verbose of the three representations but offers the clearest readability when individual components need to be clearly labelled. A modder iterating on a scale value might author it in dictionary form during development so that the X, Y, and Z components are explicitly named, then convert to the space-separated shorthand for the final published file.

The following is a complete worked example from the official SDG documentation:

Scale
{
  X 7
  Y 8
  Z 9
}

This specifies a scale with X=7.0, Y=8.0, and Z=9.0. The same value could be expressed equivalently as Scale 7, 8, 9 or Scale (7, 8, 9). All three representations produce the identical in-memory Vector3 value.

The dictionary format does not support parentheses or commas. The parser distinguishes the dictionary format from the space-separated and parenthesized formats by the presence of the opening { brace. The X, Y, and Z keys match the component names exactly -- x, y, z in lowercase is not recognized; the keys are case-sensitive.

Legacy-parsed Vector3 fields

Six Vector3 fields in the Unturned™ .dat system predate the unified Vector3 data type and support an alternative legacy representation in addition to the standard three Vector3 formats. These legacy fields are:

Legacy field	Typical asset context	Purpose
LOD_Center	Object assets	Center point of the level-of-detail bounding volume
LOD_Size	Object assets	Size (extents) of the level-of-detail bounding volume
Explosion_Min_Force	Explosive item assets	Minimum force vector applied by the explosion
Explosion_Max_Force	Explosive item assets	Maximum force vector applied by the explosion
Center_Of_Mass	Vehicle and physics-enabled item assets	Offset of the physics center of mass from the object's pivot

The legacy representation splits the Vector3 into three separate float32 properties, each with a _X, _Y, or _Z suffix:

LOD_Size_X 0
LOD_Size_Y -12
LOD_Size_Z -1

This is functionally equivalent to a Vector3 with X=0.0, Y=-12.0, Z=-1.0. In the unified Vector3 format, this would be expressed as LOD_Size 0, -12, -1.

The legacy format exists for backward compatibility with older Unturned™ .dat files that predate the unified Vector3 type. The engine's parser recognizes the _X, _Y, and _Z suffixed variants of the six legacy fields and interprets them using the float-component convention. These legacy fields can coexist with the standard Vector3 format -- a .dat file can use either representation for these fields, but not both representations simultaneously for the same field. If both the unified field (e.g., LOD_Size 0, -12, -1) and the legacy split fields (e.g., LOD_Size_X 0) are present, the parser's behaviour depends on the specific game version and is not documented; the cohort recommendation is to use exactly one representation per field.

Field	Standard representation types	Legacy representation type	Legacy example
LOD_Center	Space-separated, parenthesized, dictionary	Three float32 properties with _X, _Y, _Z suffixes	LOD_Center_X 0
LOD_Size	Space-separated, parenthesized, dictionary	Three float32 properties with _X, _Y, _Z suffixes	LOD_Size_Y -12
Explosion_Min_Force	Space-separated, parenthesized, dictionary	Three float32 properties with _X, _Y, _Z suffixes	Explosion_Min_Force_Z -1
Explosion_Max_Force	Space-separated, parenthesized, dictionary	Three float32 properties with _X, _Y, _Z suffixes	Explosion_Max_Force_Z -1
Center_Of_Mass	Space-separated, parenthesized, dictionary	Three float32 properties with _X, _Y, _Z suffixes	Center_Of_Mass_X 0

The legacy format is not recommended for new mods. New modders should use the standard space-separated format for all Vector3 fields unless they are maintaining an older mod that already uses the legacy representation and do not wish to migrate the existing files.

The flowchart above documents the decision path for choosing between standard and legacy Vector3 representation. New mods always take the standard path.

Where Vector3 fields appear in the Unturned asset system

Vector3-typed fields appear across the majority of asset categories in the Unturned™ .dat system. The table below documents the known Vector3 fields organized by asset category.

Gun asset Vector3 fields

Field	Type	Purpose
Recoil_Min_X, Recoil_Min_Y	Legacy float pair (not unified Vector3)	Minimum horizontal and vertical recoil per shot. These are not unified Vector3 fields; they use the legacy _X/_Y suffix convention as individual float fields.
Recoil_Max_X, Recoil_Max_Y	Legacy float pair	Maximum horizontal and vertical recoil per shot.
Recover_X, Recover_Y	Legacy float pair	Horizontal and vertical recoil recovery rate per frame.
Shake_Min_X, Shake_Min_Y, Shake_Min_Z	Legacy float triple	Minimum camera shake offset components per shot.
Shake_Max_X, Shake_Max_Y, Shake_Max_Z	Legacy float triple	Maximum camera shake offset components per shot.

The gun recoil and shake fields use the legacy _X/_Y/_Z suffix convention for individual float fields, not the unified Vector3 type. These are not Vector3-typed fields in the parser's type system; they are separate float fields that happen to represent spatial components. They are documented here because modders often assume they can be expressed as a unified Vector3, which is not the case for the recoil fields in the current game version.

Object and vehicle asset Vector3 fields

Field	Type	Purpose
Position	Vector3 (unified)	World-space position of the object
Scale	Vector3 (unified)	Scale multiplier of the object
Offset	Vector3 (unified)	Offset from the parent object's pivot
LOD_Center	Vector3 (unified or legacy)	Center of the LOD bounding volume
LOD_Size	Vector3 (unified or legacy)	Extents of the LOD bounding volume
Center_Of_Mass	Vector3 (unified or legacy)	Offset of the physics center of mass

Map asset Vector3 fields

Field	Type	Purpose
Position	Vector3 (unified)	World-space placement position
Rotation	Vector3 (unified)	Euler rotation in degrees
Scale	Vector3 (unified)	Scale multiplier

Explosive item Vector3 fields

Field	Type	Purpose
Explosion_Min_Force	Vector3 (unified or legacy)	Minimum force vector applied to affected rigidbodies
Explosion_Max_Force	Vector3 (unified or legacy)	Maximum force vector applied to affected rigidbodies

Worked examples from the official documentation and shipped files

Example 1: Space-separated and parenthesized positions

The official SDG documentation provides the following worked example of both the space-separated and parenthesized formats:

Position 1, 2, 3
Offset (4, 5, 6)

The Position field uses the space-separated format with commas. The Offset field uses the parenthesized format. Both produce valid Vector3 values, and the choice between the two formats within the same file is valid.

Example 2: Dictionary scale

The official SDG documentation provides the following worked example of dictionary format:

Scale
{
  X 7
  Y 8
  Z 9
}

This is a scale vector with X=7.0, Y=8.0, Z=9.0. A scale value of 7.0 on the X axis means the object is seven times its base width. A scale value of 8.0 on the Y axis means the object is eight times its base height. A scale value of 9.0 on the Z axis means the object is nine times its base depth. Non-uniform scale values (where X, Y, and Z differ) are fully supported by the engine for most asset types.

Example 3: Legacy LOD_Size from shipped object files

The official SDG documentation provides the following worked example of the legacy LOD_Size representation:

LOD_Size_X 0
LOD_Size_Y -12
LOD_Size_Z -1

This specifies a LOD bounding volume with zero X extent (the bounding volume has no width), a Y extent of negative 12 units (extending 12 units downward from the center), and a Z extent of negative 1 unit (extending 1 unit backward from the center). The negative values are valid and indicate that the bounding volume extends in the negative direction along that axis from the center point defined by LOD_Center.

Example 4: Center of mass offset for a vehicle

A typical Center_Of_Mass Vector3 in unified format for a vehicle asset:

Center_Of_Mass 0, -0.5, 0

This offsets the physics center of mass half a unit downward from the vehicle's pivot point. A lower center of mass improves vehicle stability by reducing the tendency to roll during sharp turns. Vehicle modders iteratively tune this value by adjusting the Y component (usually negative) to move the center of mass downward.

Example 5: Explosion force vectors

Explosion force vectors specify the minimum and maximum force applied to rigidbodies (players, zombies, vehicles, loose objects) caught in the blast radius. A typical configuration:

Explosion_Min_Force 0, 500, 0
Explosion_Max_Force 0, 2000, 0

The minimum force vector specifies a purely upward force of 500 units on the Y axis. The maximum force vector specifies a purely upward force of 2000 units on the Y axis. The engine interpolates between the minimum and maximum force based on the rigidbody's distance from the explosion center; objects nearer the center receive force closer to the maximum; objects at the edge of the blast radius receive force closer to the minimum. Setting the X and Z components to zero produces a purely vertical blast (ragdolls launch straight up). Setting X and Z components to non-zero values produces directional blast patterns (ragdolls are launched in a specific direction).

Example 6: Gun recoil as individual float fields (not unified Vector3)

The recoil fields on gun assets use individual float32 fields with _X/_Y suffixes. These are not unified Vector3 fields despite their spatial nature. From the shipped Eaglefire.dat:

Recoil_Min_X 0.5
Recoil_Min_Y 3
Recoil_Max_X 1.5
Recoil_Max_Y 4

Recover_X 0.4
Recover_Y 0.4

Shake_Min_X -0.0025
Shake_Min_Y 0.0025
Shake_Min_Z -0.01
Shake_Max_X 0.0025
Shake_Max_Y -0.0025
Shake_Max_Z -0.02

The Recoil_Min_X and Recoil_Min_Y fields specify the minimum horizontal and vertical recoil per shot, respectively. The Recoil_Max_X and Recoil_Max_Y fields specify the maximum. The engine randomly interpolates between the min and max on each shot, producing variable recoil. The Recover_X and Recover_Y fields specify how quickly the recoil returns to center. The Shake_* fields specify the camera shake offset, which is a purely visual effect and does not affect the actual recoil pattern.

Note that these fields cannot be written as Recoil_Min 0.5, 3, 0 in the unified Vector3 format because the parser does not recognize Recoil_Min as a Vector3-typed field. The individual _X and _Y suffixed fields are the only valid representation for gun recoil. This is a common authoring error: assuming that any field with X and Y components can be expressed as a unified Vector3.

Comparison of Vector3 format representations

Dimension	Space-separated	Parenthesized	Dictionary	Legacy float
Precision	float32 per component	float32 per component	float32 per component	float32 per component
Compactness	Most compact (variable width)	Compact (adds two characters)	Least compact (multiple lines)	Intermediate (three separate fields)
Readability	Good (commas separate components visually)	Good (parentheses group the value explicitly)	Best (components are explicitly labelled with keys)	Good (each component is a named field)
Available on all Vector3 fields	Yes	Yes	Yes	No (six legacy fields only)
Cohort recommendation	Preferred for most fields	Acceptable for coordinate-oriented fields	Acceptable for iterative tuning	Not recommended for new mods

The cohort recommendation for new modders is to use the space-separated format with commas for all Vector3 fields. It is the most compact, the most interoperable with the values shown in the official SDG documentation, and the format most commonly observed in shipped game files.

Frequently asked questions

Which axis is up in Unturned?

The Y axis is up. This is the Unity engine convention: positive Y points upward, positive X points to the right, and positive Z points forward. Modders coming from Blender (where Z is up by default) or Unreal Engine (where Z is up) must mentally convert their coordinate expectations when authoring Vector3 values in .dat files. The FBX export pipeline handles the axis remapping for 3D meshes automatically, so the modder only needs to use the Unity convention for values authored directly in .dat files.

Does the parser accept scientific notation for Vector3 components?

Yes. Component values can be expressed in scientific notation using the e or E exponent marker. 1e-3 is a valid float value representing 0.001. 1.5e2 is a valid float value representing 150.0. Scientific notation is rarely used in .dat files because most Vector3 values are in the range where decimal or integer notation is more readable, but the parser supports it for all float-valued fields.

Can I omit the commas in the space-separated format?

Yes. Position 1 2 3 and Position 1, 2, 3 are functionally identical. The commas serve only as visual separators and are optional. The cohort recommendation is to include the commas because they reduce the risk of misreading a multi-digit or negative value during manual editing.

What happens if I specify only two components instead of three?

The parser expects exactly three components for a Vector3. A value with fewer than three components (e.g., Position 1, 2) will fail to parse. The behaviour on parse failure depends on the specific game version and field -- some versions fall back to a default value (typically zero for all components), while others emit a warning to the log. Always provide all three components.

Can I mix representations within the same file?

Yes. The parser resolves the representation independently for each field. One field can use the space-separated format, another can use the parenthesized format, and a third can use the dictionary format, all in the same .dat file. There is no file-level constraint on representation consistency.

Do Vector3 values in the dictionary format support floating-point values for the X, Y, and Z keys?

Yes. The dictionary format's component values are float32, not integers. A value of X 7.5 is valid and sets the X component to 7.5. A value of Y -0.25 is valid and sets the Y component to -0.25. The integer values shown in the SDG documentation (X 7, Y 8, Z 9) are examples; float values are fully supported.

How do I specify a rotation Vector3?

Rotations in Unturned™ are expressed as Euler angles in degrees using the same Vector3 format as positions and scales. The X component controls pitch (rotation around the X axis, tilting forward/backward), the Y component controls yaw (rotation around the Y axis, turning left/right), and the Z component controls roll (rotation around the Z axis, tilting side-to-side). All values are in degrees, not radians. A value of Rotation 0, 90, 0 rotates the object 90 degrees around the Y axis (a quarter-turn counter-clockwise when viewed from above, following the left-hand rule).

What is the difference between a position Vector3 and an offset Vector3?

The format is identical. The difference is in the context in which the value is used. A Position field specifies a world-space location (an absolute coordinate in the map's coordinate system). An Offset field specifies a relative displacement from a parent object's pivot point (a local-space offset). The parser does not distinguish between the two -- it constructs a Vector3 struct identically for both -- but the game code interprets the value differently based on the field name. A value of Position 10, 0, 0 places the object 10 units east of the world origin. A value of Offset 0.5, 0, 0 places the child object 0.5 units to the right of its parent's pivot.

Do I need to quote Vector3 values?

No. Vector3 values are never quoted in .dat files. The parser expects unquoted numeric values in all three standard formats. Quotation marks surrounding a Vector3 value will cause the parser to fail to recognize it as a valid Vector3. The dictionary format's X, Y, and Z keys are also unquoted.

Are there Vector3 fields where I must use the legacy format?

For new mods, no. All six legacy fields (LOD_Center, LOD_Size, Explosion_Min_Force, Explosion_Max_Force, Center_Of_Mass) accept the unified Vector3 format in addition to the legacy split-float format. The unified format is the recommended choice for new mods. The legacy format exists only for backward compatibility with older .dat files.

Can gun recoil fields be written as a unified Vector3?

No. The gun recoil fields (Recoil_Min_X/Recoil_Min_Y, Recoil_Max_X/Recoil_Max_Y, Recover_X/Recover_Y, Shake_Min_X/Shake_Min_Y/Shake_Min_Z, Shake_Max_X/Shake_Max_Y/Shake_Max_Z) are individual float32 fields with alphabetic suffixes, not Vector3-typed fields. They cannot be written as Recoil_Min 0.5, 3 in the unified format. This is a common authoring mistake -- the _X and _Y suffixes look like Vector3 component labels but are part of the field name, not a Vector3 decomposition. Author each recoil component as a separate field.

What coordinate system should I use for Blender-exported mesh positions?

Use the Unity coordinate system (Y-up, left-handed) for Vector3 values authored directly in .dat files. Blender-exported meshes are automatically converted by the FBX exporter when the correct export settings are used (scale 1.0, forward direction -Z, up direction Y, apply transform enabled). The modder does not need to manually convert mesh vertex coordinates; the FBX exporter handles the axis remapping. The modder only needs to author .dat file Vector3 values in the Unity convention.

How do I test Vector3 values without rebuilding the Unity bundle?

Vector3 fields in .dat files do not require a Unity bundle rebuild. The .dat file is read each time the game launches. To test a Vector3 change: edit the .dat file, save it, and launch Unturned™ in single-player. Spawn or navigate to the object with the changed Vector3 field. If the object is already present in the world from a previous session, the existing instance may carry the old Vector3 value -- objects already placed in the world are not re-parsed from the .dat file. To force the game to read the updated value, spawn a fresh instance or restart the single-player session with a new map.

How do game updates affect Vector3 field compatibility?

Unturned™ game updates rarely change the Vector3 data type itself, because Vector3 is a foundational parser type that maps to Unity's built-in Vector3 struct. However, game updates may add new Vector3-typed fields to existing asset types or change how existing Vector3 fields are interpreted (e.g., a field that was previously a world-space position may be re-interpreted as a local-space offset). A mod that relies on a specific interpretation of a Vector3 field may behave differently after an update if the interpretation changes. The cohort recommendation is to test all Vector3-dependent mod behaviour after each major game update.

Can I use the Vector3 format for two-component values (Vector2)?

No. The parser does not recognize a two-component vector type. A value like Position 1, 2 (only two components) will fail to parse. If a game system conceptually operates on two-dimensional coordinates (e.g., a 2D map UI position), it uses separate float32 fields for the X and Y components, not a unified Vector3. Do not attempt to pass two-component values as Vector3s with the third component omitted or set to zero as a placeholder -- the parser requires exactly three components.

How do negative scale values behave?

Negative scale values are technically parseable but produce mirrored (flipped) geometry that may not render correctly with the standard shader. A scale of -1, 1, 1 mirrors the object across the YZ plane, producing a left-right reversed version of the mesh with inverted face normals. Most Unturned™ shaders render back-face culling on by default, so a negatively scaled mesh may appear invisible from the front because the reversed normals point away from the camera. Negative scales are not recommended for standard item and object mods; use the Rotation field to achieve mirroring or flip effects if those are the intended visual result.

What is the practical difference between a Position Vector3 and a Unity Transform position?

The .dat file's Position Vector3 maps directly to the Transform.position property in Unity. There is no abstraction layer between the .dat value and the Unity transform -- the parsed Vector3 is assigned directly to the transform's world-space position. This means that any Unity transform behaviour that a modder is familiar with from Unity Editor work applies identically to .dat-configured objects: parent-child transform composition, local-to-world matrix multiplication, and the interaction between position, rotation, and scale all follow standard Unity conventions.

How precise are Vector3 float values?

The Vector3 components are stored as single-precision (float32) values, which provide approximately 7 significant decimal digits of precision. For typical Unturned™ coordinate values (positions in the range of a few hundred units, scales in the range of 0.1 to 10.0, offsets in the range of a few units), float32 precision is more than adequate. The practical precision limit is approximately 0.0001 units (0.1 mm) at the scale of a typical map coordinate, which is far finer than any visible artifact in the rendered game.

Best practices

• Use the space-separated format with commas (Position 1, 2, 3) for all Vector3 fields in new mods. It is the most compact, the most commonly observed in shipped game files, and the format most consistent with the official SDG documentation.
• Always provide all three components, even if one or two are zero. A Vector3 with fewer than three components is a parse error.
• Use the Unity Y-up convention for all Vector3 values authored directly in .dat files. Do not use Blender's Z-up convention, even if your modelling workflow uses Blender.
• During development, use the dictionary format for Vector3 fields that need per-component tuning (e.g., Scale, Center_Of_Mass). The explicit component labels reduce the risk of editing the wrong component. Convert to the space-separated format for the final published file.
• When authoring LOD_Center, LOD_Size, Explosion_Min_Force, Explosion_Max_Force, or Center_Of_Mass for a new mod, use the unified Vector3 format rather than the legacy _X/_Y/_Z split properties.
• Test all Vector3 fields in single-player before publishing. Small sign errors (positive instead of negative, or vice versa) produce dramatically wrong spatial behaviour that is obvious in visual testing but easy to miss during text-only .dat review.
• When migrating a legacy .dat file that uses split-float Vector3 fields, convert all legacy fields to the unified format during the same migration pass. A file that is partially migrated is harder to debug than one that is uniformly in one format.
• Document the intended meaning of Vector3 values in comments if the spatial relationship is non-obvious (e.g., // Center of mass lowered for stability on slopes).

Advanced considerations

Vector3 interaction with hierarchy transforms

When a Vector3 is used as an Offset on a child object of a parent with its own Position, Rotation, and Scale, the effective world-space position of the child is the result of applying the parent's full transform matrix (translation, rotation, scale) to the child's Offset. This means that rotating a parent object rotates the direction of the child's Offset as well. A child with Offset 0, 1, 0 (one unit above the parent) whose parent is rotated 90 degrees around the Z axis will appear one unit to the left of the parent in world space, because the Y-up offset has been rotated by the parent's Z rotation. Modders authoring hierarchical object configurations should test the combined transform at each expected parent rotation to confirm that the visual result matches the intention.

Floating-point accumulation in large map coordinates

Unturned™ maps can span thousands of units in each direction. At the extremes of a large map (positions exceeding approximately 10,000 units from the origin), the float32 precision limits begin to produce visible artifacts: objects may appear to jitter slightly, vertices may not align perfectly, and physics interactions may exhibit small instabilities. This is not a Vector3 format limitation specifically -- it is a fundamental property of float32 arithmetic in any game engine -- but modders authoring large maps should be aware of the practical coordinate range where float32 precision remains adequate. The cohort recommendation is to keep map coordinates within approximately 5,000 units of the origin where possible and to position the most precision-sensitive gameplay areas (spawn points, precise puzzle rooms, PvP arenas) near the map origin.

Euler angle gimbal lock

Rotations specified as Euler angles (the standard Rotation Vector3) are subject to gimbal lock, a mathematical property of Euler angle representation where two of the three rotation axes align, causing a loss of one degree of rotational freedom. In Unity's Euler angle convention, gimbal lock occurs when the X rotation (pitch) approaches 90 degrees, aligning the Y (yaw) and Z (roll) axes. At exactly 90 degrees of pitch, yaw and roll become indistinguishable -- rotating around Y and rotating around Z produce the same visual result. Modders authoring objects that rotate freely in three dimensions (e.g., aircraft, thrown physics objects) should be aware that Euler angle values near 90 degrees of pitch may behave unexpectedly. For objects that require full 360-degree rotation in all axes without gimbal lock, the engine's internal quaternion representation (not directly authorable in .dat files) provides the mathematically correct solution. In practice, most modded objects operate within rotation ranges where gimbal lock is not encountered.

Vector3 fields in server-side plugins

Server-side plugin code (C# OpenMod or RocketMod plugins) can read and write Vector3 values from asset objects at runtime through the Unturned Dedicated Server API. The API exposes Vector3 values as Unity Vector3 structs with float components (x, y, z). A plugin that dynamically adjusts an object's position, scale, or rotation based on server state reads the asset's Vector3 field, constructs a new Vector3 struct, and writes it back through the appropriate API method. The API-level component names use lowercase (x, y, z), while the .dat file dictionary format uses uppercase (X, Y, Z). This casing difference is a common source of confusion when translating between .dat file authoring and plugin code.

Appendix A: Vector3 format quick reference card

Format	Syntax	Example	Available on all Vector3 fields	Use case
Space-separated	X, Y, Z or X Y Z	Position 1, 2, 3	Yes	Preferred, compact, most common in shipped files
Parenthesized	(X, Y, Z)	Offset (4, 5, 6)	Yes	Coordinate-oriented fields
Dictionary	{ X v Y v Z v }	Scale { X 7 Y 8 Z 9 }	Yes	Per-component tuning
Legacy float	_X v _Y v _Z v	LOD_Size_X 0	Six legacy fields only	Backward compatibility (not for new mods)

Appendix B: Unity coordinate system reference

Axis	Positive direction	Negative direction	Typical context
X	Right (east in top-down view)	Left (west)	Width, lateral offset, horizontal recoil
Y	Up	Down	Height, vertical offset, vertical recoil
Z	Forward (north in top-down view)	Backward (south)	Depth, forward offset, depth recoil

Appendix C: Common Vector3 values used in Unturned modding

Value	Meaning	Typical use
0, 0, 0	Zero vector / origin	Default position, no offset, no scale (identity)
1, 1, 1	Uniform scale of 1.0	Default scale (no scaling applied)
0, 1, 0	One unit upward	Offset for an attachment above the parent pivot
0, -0.5, 0	Half unit downward	Center of mass lowered for vehicle stability
0, 90, 0	90-degree yaw rotation	Quarter-turn around the vertical axis
90, 0, 0	90-degree pitch rotation	Object pointing straight upward
0, 500, 0	500 units of upward force	Explosion force vector (vertical launch)

Appendix D: Vector3 field authoring checklist

Before publishing a mod that includes Vector3 fields, confirm the following:

• [ ] All Vector3 fields provide exactly three components
• [ ] All Vector3 values use the Unity Y-up coordinate convention
• [ ] Components are separated by commas (space-separated format) or enclosed in parentheses (parenthesized format) or specified as key-value pairs (dictionary format)
• [ ] Legacy fields (LOD_Center, LOD_Size, Explosion_Min_Force, Explosion_Max_Force, Center_Of_Mass) use the unified Vector3 format for new mods
• [ ] Gun recoil and shake fields are authored as individual float32 fields with _X/_Y/_Z suffixes (not as unified Vector3)
• [ ] Rotation values use Euler angles in degrees (not radians)
• [ ] Negative values use the minus sign prefix (not parentheses or other notation)
• [ ] Vector3 values tested in single-player: spatial behaviour matches the modder's intention
• [ ] Hierarchical offset values tested at each expected parent rotation to confirm combined transform correctness

Appendix E: Diagnostic table for Vector3 format errors

Symptom	Most likely cause	Resolution
Object appears at wrong position or orientation	Coordinate system mismatch (e.g., using Z-up instead of Y-up, or right-handed instead of left-handed convention)	Verify all .dat Vector3 values use the Unity Y-up, left-handed convention
Object does not render at the expected scale	Scale Vector3 has wrong components or non-uniform scale exceeds engine limits	Confirm all three scale components; test with uniform scale (1, 1, 1) as baseline
Attachment (sight, grip, barrel) appears at wrong position on the gun	Hook offset Vector3 has wrong sign or wrong component assignment	Verify offset sign: positive Y moves the attachment upward relative to the hook bone
Vehicle tips over or handles poorly	Center of mass offset is too high or has wrong sign	Move center of mass downward (negative Y) for stability; test on slopes
Explosion launches entities in wrong direction	Explosion force Vector3 has wrong component signs	Verify positive Y for upward launch; set X and Z to 0 for purely vertical blast
LOD bounding volume does not enclose the object at expected distances	LOD size or center Vector3 has wrong values	Adjust LOD center and size to enclose the object's visible geometry; test at multiple camera distances
Dictionary format Vector3 not parsed	Keys are lowercase (x, y, z instead of X, Y, Z)	Use uppercase X, Y, Z keys in dictionary format
Legacy Vector3 field not recognized	Field used is not one of the six legacy Vector3 fields	Only LOD_Center, LOD_Size, Explosion_Min_Force, Explosion_Max_Force, and Center_Of_Mass support legacy format

Vector3 parsing in practice: a position wire protocol

The following extended worked example traces a single Vector3 field, Position, through every stage of the author-to-render pipeline. This trace is intended to give modders a complete mental model of what happens between typing 1, 2, 3 in a .dat file and seeing an object appear at the correct world-space location.

Stage 1: Authoring

The modder writes the following line in a map object's .dat file:

Position 1, 2, 3

The field uses the space-separated format with commas. The modder chose this format because it is compact and matches the convention used in the official SDG documentation. The value specifies X=1.0, Y=2.0, Z=3.0 in the Unity coordinate system: 1 unit east of the world origin, 2 units above the ground plane, 3 units north of the world origin.

Stage 2: Parsing at asset load time

The game launches and the asset loader reads the object's .dat file. The parser encounters the Position field. The value 1, 2, 3 contains commas and does not begin with ( or {, so the parser selects the space-separated parse path. The parser reads the three numeric tokens, converts each from its string representation to a float32 value, and constructs a UnityEngine.Vector3 struct with components x=1.0f, y=2.0f, z=3.0f. The constructed Vector3 is assigned to the object's Position property.

If the modder had instead written Position (1, 2, 3), the parser would have taken the parenthesized path and produced the identical Vector3. If the modder had written the dictionary form, the parser would have taken the dictionary path, read X 1, Y 2, Z 3, and produced the identical Vector3. All three paths converge on the same in-memory structure.

Stage 3: Object placement at runtime

During level loading, the game code reads the Position Vector3 from the object asset and constructs a Unity Transform component at that world-space location. The object's mesh is positioned, rotated (using the Rotation Vector3 if present), and scaled (using the Scale Vector3 if present) according to the full transform specification. If the object has a parent with its own transform, the parent's position, rotation, and scale are composed with the child's position to produce the final world-space transform.

Stage 4: Rendering

The positioned object enters the rendering pipeline at its computed world-space location. The camera's view frustum determines whether the object is visible. If visible, the object is drawn at the screen position that corresponds to its world-space location projected through the camera's view and projection matrices. The Vector3 value the modder typed in the .dat file has been transformed through a chain of coordinate conversions -- .dat string to Vector3 struct, local-space position to world-space position, world-space position to screen-space pixel coordinate -- to produce the pixels that appear on the player's display.

The sequence above illustrates the complete path from authoring to display. Each stage is documented in the preceding sections of this article. Modders who understand this chain can diagnose position errors by tracing backward from the observed screen result to the .dat value.

Extended worked examples from shipped game files

Example 7: Recoil pattern analysis from Eaglefire.dat

The shipped Eaglefire.dat contains the following recoil configuration:

Recoil_Min_X 0.5
Recoil_Min_Y 3
Recoil_Max_X 1.5
Recoil_Max_Y 4

Recover_X 0.4
Recover_Y 0.4

Shake_Min_X -0.0025
Shake_Min_Y 0.0025
Shake_Min_Z -0.01
Shake_Max_X 0.0025
Shake_Max_Y -0.0025
Shake_Max_Z -0.02

This recoil configuration reveals the Eaglefire's firing characteristics:

• Horizontal recoil: Between 0.5 and 1.5 units per shot. The minimum is positive (kicks right), but the range includes values that can kick left if the random interpolation produces a negative value. The Eaglefire has modest horizontal drift.
• Vertical recoil: Between 3 and 4 units per shot (always upward). This is the dominant recoil component -- the Eaglefire climbs significantly during sustained fire.
• Recovery: 0.4 units per frame of recovery on both axes. The Eaglefire recovers from recoil at a moderate rate; controlled bursts are more accurate than sustained full-auto fire.
• Camera shake: The shake offset is very small (thousandths of a unit) and primarily on the Z axis. The Eaglefire produces a subtle screen shake rather than a pronounced visual disruption.

Note that these are individual float32 fields with _X/_Y/_Z suffixes, not unified Vector3 fields. Modders writing recoil for a custom gun must use the same individual-field convention.

Example 8: LOD bounding volume from shipped object

The official SDG documentation provides a worked example of legacy LOD_Size fields from a shipped object:

LOD_Size_X 0
LOD_Size_Y -12
LOD_Size_Z -1

The LOD bounding volume has zero extent on the X axis (no width to the bounding box), extends 12 units downward from the center on the Y axis, and extends 1 unit backward on the Z axis. This is a tall, narrow bounding volume positioned below and slightly behind the center point defined by LOD_Center. The shape is appropriate for a tall vertical object like a tree or a building that extends primarily in the downward (negative Y) direction from its pivot.

In unified Vector3 format, the same LOD size would be written as:

LOD_Size 0, -12, -1

Both the legacy and unified representations produce the identical bounding volume. New mods should use the unified format.

Example 9: Center of mass offset for an aircraft

An aircraft vehicle requires a carefully tuned center of mass to maintain stable flight. The center of mass is typically positioned slightly forward and below the aircraft's geometric center to promote nose-down stability during forward flight:

Center_Of_Mass 0, -0.3, 0.5

• X=0: center of mass is laterally centered (no left or right bias)
• Y=-0.3: center of mass is slightly below the pivot, improving roll stability
• Z=0.5: center of mass is slightly forward of the pivot, promoting nose-down pitch during forward flight (a nose-up aircraft would climb uncontrollably)

Modders authoring aircraft vehicles should test the center of mass in single-player across the full flight envelope (takeoff, cruise, maximum speed, stall recovery) and adjust the offset incrementally until stable flight is achieved.

The matrix chain: position, rotation, and scale composition

When a Vector3 Position, Vector3 Rotation, and Vector3 Scale are all specified on the same object, the engine composes them into a single 4×4 transformation matrix using the standard TRS (translation, rotation, scale) composition order:

1. Scale is applied first (multiplying the object's base mesh dimensions)
2. Rotation is applied second (rotating the scaled object around its pivot)
3. Translation is applied third (moving the rotated, scaled object to its world position)

The composition order matters. Scale before rotation means that non-uniform scaling (different X, Y, and Z scale values) can interact with rotation in unintuitive ways. An object scaled to Scale 2, 1, 1 (twice as wide as tall) and rotated Rotation 0, 90, 0 (quarter-turn around the Y axis) will appear twice as deep as tall when viewed from above, because the X-axis stretch has been rotated to align with the Z axis.

Modders who need an object to maintain its visual proportions regardless of rotation should use uniform scale values (X, Y, and Z components are all equal). Modders who intentionally use non-uniform scales should test the object at each expected rotation to confirm that the visual result matches the intention.

The flowchart above shows the TRS composition order applied to every object at load time. Understanding this order is essential for diagnosing spatial behaviour when an object does not appear at the expected position, orientation, or scale.

Vector3 in the context of skeletal animation and attachment hooks

While Vector3 values in .dat files define static spatial properties, the most common Vector3-adjacent feature in mod authoring is the skeletal attachment hook system used by gun prefabs. Attachment hooks (Hook_Sight, Hook_Muzzle, Hook_Grip, Hook_Barrel, Hook_Tactical) are defined as bones in the Unity prefab's skeleton hierarchy, not as Vector3 values in the .dat file. However, modders who need to adjust attachment positioning for a custom prefab must work with the same Vector3 coordinate conventions when placing hook bones in the 3D modelling tool.

In Blender (with the FBX export settings: Forward = -Z, Up = Y), the hook bone's position in Blender is interpreted as a local-space position relative to the weapon's root bone. The same Vector3 conventions apply: +Y is up (a sight hook bone positioned at Y=0.2 is 0.2 units above the weapon's rail), +Z is forward (a muzzle hook bone positioned at Z=1.5 is 1.5 units forward of the weapon's pivot along the barrel direction), and +X is right (a tactical hook bone on the left side of the weapon would have a negative X value).

Modders who place hook bones in Blender should author the bone positions in the Unity coordinate convention (Y-up, left-handed, Z-forward) because the FBX exporter applies the axis remapping automatically. A bone placed at Blender coordinates (0, 0, 1.5) with the correct export settings will appear at Unity local-space coordinates (0, 0, 1.5) -- the exporter handles the coordinate system conversion. The modder's responsibility is to ensure that the export settings are correct (Forward = -Z, Up = Y) and that the resulting hook bone positions produce the correct attachment placement when tested in-game.

Vector3 precision and floating-point considerations

The Vector3 type stores components as float32 (single-precision floating-point) values. Single-precision floats provide approximately 7 significant decimal digits of precision. For typical Unturned™ coordinate values, this is more than adequate, but modders should be aware of the practical limits.

Precision by coordinate magnitude

The precision of a float32 value depends on the magnitude of the value itself. At small magnitudes (near zero), the precision is very fine. At larger magnitudes, the precision coarsens because the available bits are used for the integer portion rather than the fractional portion of the number.

Coordinate magnitude	Approximate precision	Practical effect
0.001	~0.0000001	Sub-millimetre precision; no visible artifacts
1.0	~0.0000001	Micrometre precision; no visible artifacts
100.0	~0.00001	Sub-millimetre precision; no visible artifacts
1,000.0	~0.0001	Tenth-millimetre precision; barely perceptible in extreme close-up
10,000.0	~0.001	Millimetre precision; visible as very slight jitter at distance
100,000.0	~0.01	Centimetre precision; visible jitter and vertex misalignment at all distances

The table shows why the cohort recommendation is to keep map coordinates within approximately 5,000 units of the origin and to position gameplay-critical areas near the map origin. An object at position 100000, 0, 0 (100,000 units from the origin) has centimetre-level precision, which produces visible vertex snapping and jitter during camera movement.

Cumulative precision loss in hierarchical transforms

When an object's world-space position is computed through a chain of parent transforms (parent Position + parent Rotation applied to child Offset), the precision loss accumulates at each level. A child three levels deep in a hierarchy (parent at 10,000 units, child's child at an Offset of 1,000 units, grandchild at an Offset of 100 units) may experience worse precision than the leaf-node Offset magnitude alone suggests. Modders constructing deep transform hierarchies should keep the root object as close to the map origin as possible and minimize the Offset magnitudes at each level.

Precision when converting from the dictionary format

The dictionary format ({ X 1.5 Y 2.5 Z 3.5 }) stores component values as strings that are parsed to float32. The string-to-float conversion is a source of precision loss: a value written as X 1.5000001 may be stored as 1.5 exactly because float32 rounds to the nearest representable value. Modders who need exact component values should be aware that the float32 storage format represents only a subset of decimal numbers exactly; values like 0.1 (which is not exactly representable in binary floating-point) are stored as the closest float32 approximation.

Vector3 comparison: when two Vector3 values are "equal"

The parser does not define an equality comparison for Vector3 values in the .dat file -- each Vector3 is an independent value. However, at runtime, the game code may compare Vector3 values for equality (e.g., checking whether an object's Scale equals the identity 1, 1, 1 to skip the scale matrix multiplication). The equality check uses Unity's Vector3 equality operator, which compares components with a tolerance of approximately 1e-5 (the Mathf.Epsilon threshold).

A Vector3 written as Scale 1, 1, 1 and a Vector3 written as Scale 1.00000001, 1, 1 will compare as equal in engine code because the difference in the X component is below the epsilon threshold. A Vector3 written as Scale 1.001, 1, 1 will compare as not equal because the difference exceeds the epsilon threshold. Modders should not rely on this epsilon tolerance for game logic -- author Vector3 values to the precision required by the visual result, and treat engine-level equality as an implementation detail that may change between game versions.

Euler angle ranges and wrapping behaviour

Rotations specified as Euler angles in degrees (Rotation X Y Z) can exceed the standard 0-to-360-degree range. The engine wraps rotation values internally: a rotation of 370 degrees is equivalent to 10 degrees; a rotation of -10 degrees is equivalent to 350 degrees. However, the wrapping behaviour for Euler angles differs from that of a single scalar angle because the wrapping interacts with the Euler angle composition order (the order in which the engine applies the X, Y, and Z rotations).

The engine applies Euler rotations in the order: Z first (roll), then X (pitch), then Y (yaw). This is Unity's default rotation order. A rotation of Rotation 90, 90, 0 (90-degree pitch, then 90-degree yaw) produces a different orientation than Rotation 0, 90, 90 (90-degree yaw, then 90-degree roll), even though the same three numbers are present. The order matters, and the engine's Z-X-Y application order is fixed and not configurable through .dat fields.

Modders who need a specific three-dimensional orientation should decompose the desired orientation into the component Euler angles using a 3D tool or calculator that uses the Z-X-Y rotation order, then paste the resulting values into the .dat file. Attempting to mentally compose Euler angles without a tool almost always produces the wrong orientation, because the human spatial intuition does not correctly model the Z-X-Y composition order.

Appendix F: External references

Resource	URL	Notes
Smartly Dressed Games modding documentation	https://docs.smartlydressedgames.com/en/stable/	Official field reference. The Vector3 data type is documented in the data types chapter.
Unturned on Steam	https://store.steampowered.com/app/304930/Unturned/	Game changelog.
Color Format Reference	/data-types/color-format-reference	The previous article in this section; covers the colour data type including the dictionary format that shares syntactic patterns with the Vector3 dictionary format.
Structs Type Reference	/data-types/structs-type-reference	The next article in this section; covers the struct type including the dictionary syntax that is a superset of the Vector3 dictionary syntax.
Enumerated Types Reference	/data-types/enumerated-types-reference	The first article in this section; covers the enum value format.
Item Asset Anatomy	/items/item-asset-anatomy	The shared field reference that documents the asset fields where Vector3-typed properties appear.

Appendix G: Vector3 format parsing error reference

The following table documents the parse errors that the parser may produce when encountering a malformed Vector3 value.

Error condition	Parser behaviour	How to detect	How to fix
Fewer than three components	Parse failure; fallback to zero vector or default	Object at wrong position, wrong scale, or wrong offset	Always provide exactly three components
More than three components	Parse failure or components beyond third ignored	Object behaves as if extra components were not specified	Provide exactly three components
Non-numeric component value	Parse failure for that component	Component appears as zero or default	Use only valid float values (digits, decimal point, minus sign, e notation)
Dictionary missing required key (X, Y, or Z)	Parse failure or zero-filled for missing component	One spatial dimension appears as zero unexpectedly	Always provide X, Y, and Z keys in dictionary format
Dictionary brace mismatched	Parse failure; field may consume subsequent lines	Subsequent fields ignored or misparsed	Ensure every { has a matching } on its own line
Parenthesized format missing closing )	Parse failure	Field not parsed; default value used	Ensure opening ( has a matching )
Legacy field used on a non-legacy field	Syntax error; field not recognized	Subsequent .dat fields may also fail to parse	Only use legacy _X/_Y/_Z suffixes on the six documented legacy fields

The parsing errors above are validated against the official SDG documentation and community-observed behaviour.

Cross-references

• Color Format Reference -- the previous article in this section; covers the dictionary format syntax that shares structural patterns with the Vector3 dictionary format.
• Structs Type Reference -- the next article in this section; covers the struct type, which extends the dictionary syntax to arbitrary key-value nesting.
• Enumerated Types Reference -- the first article in this section; covers the enum data type.
• Item Asset Anatomy -- the shared field reference; documents the gun recoil and shake fields that use individual float components rather than unified Vector3.
• Smartly Dressed Games modding documentation -- the official SDG field reference.
• Unturned on Steam -- the Unturned™ Steam store page.

Document history

Version	Date	Author	Notes
1.0	2026-07-26	57 Studios	Initial publication. Complete Vector3 format reference: space-separated, parenthesized, dictionary, and legacy float formats; Unity coordinate system conventions; field coverage table; worked examples; FAQ; diagnostic table.