Color Format Reference

Intermediate10-15 minutesCross-platformNotepad++

The color data type is one of the fundamental scalar types in the Unturned™ .dat file format. Colors define visual properties across the entire asset landscape: the beam of a tactical flashlight on a rifle, the tint of night vision goggles, the hue of a vehicle's paint, the colour of a player spotlight on a helmet, and the atmospheric fog on a map. Every modder who authors items with configurable light sources, tinted optics, or cosmetic colour properties will encounter the colour format in its various representations.

57 Studios™ has documented and validated the full colour 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 colour representations -- hexadecimal, named colour, and dictionary -- along with the alpha channel handling rules, the legacy-parsed colour fields that predate the unified colour type, and the diagnostic table for common colour format errors that appear during asset authoring.

The colour format is deceptively simple. A modder who has only ever seen the hexadecimal representation may not realize that two alternative formats exist and that certain legacy fields accept a fourth representation that splits the components into separate float properties. Understanding the full specification prevents the common frustration of authoring a colour field in one format and finding it silently ignored because the field expects a different representation.

Documentation source: This article references the official Smartly Dressed Games modding documentation for colour 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 colour field for the first time -- in a gun's Laser_Color, a scope's Nightvision_Color, or a map's FogColor -- should read this article in full before authoring the field. Modders who are building item types that include SpotLight_Color or any of the struct-based colour properties should additionally read Structs Type Reference to understand how colours are embedded within nested dictionary configurations.

If you are new to Unturned™ modding, start with Project Folder Structure and GUIDs and Item Asset Anatomy before returning here. The colour 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 colour representations: hexadecimal, named colour, and dictionary
• The syntax rules for each representation, including whitespace handling and capitalization
• Alpha channel specification in hexadecimal format and how the engine interprets the alpha component
• The legacy-parsed colour fields (Laser_Color, Nightvision_Color) and their float-component alternative syntax
• Where colours appear in the Unturned™ asset system and which asset types carry colour fields
• How the parser selects between colour representations at load time
• Worked examples drawn from the official SDG documentation and shipped game files
• Common mistakes that cause colour fields to parse incorrectly or silently fall back to defaults
• How colours interact with the struct system when embedded inside PlayerSpotLightConfig and similar nested configurations

Background: what the colour data type is

The colour data type in Unturned™ is a parser-level type, not an asset-level type. It is not a separate .dat file or an independent asset class. It is a value format that the game's .dat parser recognizes and converts into an in-memory colour structure whenever a field declares that it expects a colour value. The parser performs this conversion at asset load time -- when the game reads the .dat file into memory, encounters a colour-typed field, and constructs the corresponding data object.

The colour type is one of several core data types that the parser supports alongside integers, floats, strings, enums, flags, Vector3, 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 colour type is unique among them in supporting three distinct textual representations for the same underlying data, a design choice that accommodates different authoring preferences and backward compatibility with older asset files.

The parser resolves which representation is in use at the point of reading the field value. If the value begins with a # character, the parser attempts to parse it as a hexadecimal colour. If the value begins with a digit or letter and does not contain #, the parser attempts to match it against the known named colour table. If the value begins with {, the parser attempts to parse it as a dictionary with R, G, and B keys. The resolution is unambiguous because each representation has a distinct leading character or pattern that does not overlap with the others.

This multi-format design means that the same .dat file can mix representations freely -- one field can use hexadecimal, another can use a named colour, and a third can use the dictionary form. The parser does not enforce a single representation across a file or across a project. The modder chooses the representation that is clearest for each individual field.

The flowchart above shows the parser's single-pass resolution of the colour representation. The leading character determines the parse path unambiguously; there is no backtracking and no attempt to re-parse a failed representation in a different format.

The three colour representations

Hexadecimal format

The hexadecimal format is the most common colour representation in Unturned™ .dat files. It encodes the red, green, and blue colour components as a single hexadecimal value, optionally prefixed with the # character and optionally extended with an alpha channel byte.

The canonical syntax for hexadecimal colour is:

#RRGGBB
RRGGBB
#RRGGBBAA
RRGGBBAA

Each pair of characters encodes one colour component as a two-digit hexadecimal value in the range 00 (zero intensity) through FF (maximum intensity). The RR pair encodes the red component, GG encodes green, and BB encodes blue. The optional AA pair encodes the alpha channel (opacity), with 00 representing fully transparent and FF representing fully opaque.

The # prefix is optional. The parser accepts both #0000ff and 0000ff as identical values (pure blue). The cohort recommendation is to always include the # prefix for readability -- it visually distinguishes a hexadecimal colour value from an integer field that happens to contain hexadecimal-looking digits.

The alpha component is optional on all colour fields. When omitted, the parser assumes FF (fully opaque). When included, the alpha component controls the transparency of the rendered element -- a spotlight beam with alpha 80 (50 percent opacity) appears as a dimmer, more translucent beam than one with alpha FF. Not all colour fields respect the alpha component; the specific rendering behaviour depends on the asset type and the field's role in the rendering pipeline. The table of known colour fields later in this article documents which fields support alpha.

Format	Example	Red	Green	Blue	Alpha
Hex without #	0000ff	00	00	FF	FF (implicit)
Hex with #	#00ff00	00	FF	00	FF (implicit)
Hex with alpha, with #	#ff0000ff	FF	00	00	FF (opaque)
Hex with alpha, without #	f5df9380	F5	DF	93	80 (50 percent)

The hexadecimal format is the preferred representation for most colour fields because it is compact, unambiguous, and matches the format used by image editors and web colour pickers. A modder can sample a colour in Photoshop or GIMP, copy the hexadecimal value from the colour picker, and paste it directly into the .dat file.

Named colour format

The named colour format allows a colour field to be specified using a human-readable colour name that the parser resolves against a built-in lookup table. The parser recognizes a set of named colours drawn from standard colour naming conventions.

The canonical syntax for named colour is:

SkyColor skyblue
GroundColor forestgreen

The name is written without quotation marks, without a # prefix, and without any delimiter between the field name and the colour name. Whitespace separates the field name from the colour name, following the standard .dat key-value separator convention.

The named colour table is defined in the engine's parser and is not configurable through .dat files. The official Smartly Dressed Games modding documentation lists the supported named colours, which include the standard web colour set: red, green, blue, white, black, yellow, cyan, magenta, orange, purple, gray, grey, brown, pink, skyblue, forestgreen, and many additional named variants. A complete listing is maintained in the official documentation; this article covers the format rules rather than enumerating the full table.

The named colour format is most commonly used in map configuration files where the modder is selecting between broad atmospheric categories (e.g., FogColor gray for a foggy map) rather than requiring a precise hexadecimal hue. For item mods that require colour-accurate asset authoring, the hexadecimal format is the cohort-preferred choice because it eliminates ambiguity about which exact shade a named colour resolves to.

Dictionary format

The dictionary format represents a colour as three or four separate key-value pairs enclosed in curly braces. Each key specifies one component of the colour: R for red, G for green, B for blue, and optionally A for alpha.

The canonical syntax for dictionary colour is:

{
  R 255
  G 0
  B 0
}

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 R, G, B, and optional A keys take uint8 integer values in the range 0 through 255. The values are not expressed as floating-point percentages; 128 is not "fifty percent" but rather the byte value 128 out of 255.

The dictionary format does not support the # prefix. The parser distinguishes the dictionary format from the hexadecimal format by the presence of the opening { brace on the line following the field name. If the value after the field name begins with a digit or letter and no { appears, the parser treats it as a named colour lookup. If the value begins with # or a hex digit, the parser treats it as hexadecimal. If the value begins with {, the parser reads the dictionary components.

The following is a complete worked example of the dictionary colour format as shown in the official SDG documentation:

FogColor
{
  R 255
  G 0
  B 0
}

This sets the fog colour to pure red (maximum red, no green, no blue). The same value could be expressed equivalently as FogColor #ff0000 or FogColor ff0000.

The dictionary format is the least compact of the three representations but offers the clearest readability when colour components need to be individually tuned. A modder iterating on a spotlight colour might author it in dictionary form during development, adjusting individual R, G, and B values across testing sessions, then convert to hexadecimal shorthand for the final published file.

Alpha channel handling

The alpha channel controls the opacity of the rendered colour element. In Unturned™, the alpha channel is supported on a subset of colour-typed fields where transparency has a meaningful rendering effect. The table below documents the known alpha behaviour across colour fields.

Field	Alpha supported?	Behaviour
SpotLight_Color	Yes	Controls spotlight beam opacity. Alpha 80 produces a dimmer, more translucent spotlight beam.
Laser_Color	Yes (legacy format only as float components)	Controls laser beam visibility.
Nightvision_Color	Yes (legacy format only as float components)	Controls night vision tint intensity.
FogColor	No (RGB only)	Alpha is ignored; fog is always fully opaque.
SkyColor	No (RGB only)	Alpha is ignored; sky colour is always fully opaque.
GroundColor	No (RGB only)	Alpha is ignored; ground colour is always fully opaque.

When using the hexadecimal format, alpha is specified as the fourth byte: #RRGGBBAA. A value of #f5df9380 specifies a colour with red F5, green DF, blue 93, and alpha 80 (approximately 50 percent opacity). When the alpha byte is omitted (#RRGGBB or RRGGBB), the parser defaults alpha to FF (fully opaque).

When using the dictionary format, alpha is specified with the optional A key:

SpotLight_Color
{
  R 245
  G 223
  B 147
  A 128
}

The A key follows the same uint8 value convention as R, G, and B: a value in the range 0 through 255, where 0 is fully transparent and 255 is fully opaque. If the A key is omitted from a dictionary colour, the parser defaults alpha to 255.

The named colour format does not support alpha specification. A named colour always resolves to a fully opaque colour value. If a colour field requires alpha control, the hexadecimal or dictionary format must be used.

Legacy-parsed colour fields

Two colour fields in the Unturned™ .dat system predate the unified colour data type and support an alternative legacy representation in addition to the standard three colour formats. These legacy fields are Laser_Color and Nightvision_Color. Both are properties of attachment assets (tactical laser modules and night vision scopes, respectively).

The legacy representation splits the colour into three separate float32 properties, each carrying a normalized floating-point value in the range 0.0 through 1.0:

Laser_Color_R 0.5
Laser_Color_G 1.0
Laser_Color_B 0.0

This is functionally equivalent to a colour with red at 50 percent intensity (approximately byte value 128), green at 100 percent intensity (byte value 255), and blue at 0 percent intensity (byte value 0). In hexadecimal, this would be expressed as #7fff00.

The legacy format exists for backward compatibility with older Unturned™ .dat files that predate the unified colour type. The engine's parser recognizes the _R, _G, and _B suffixed variants of Laser_Color and Nightvision_Color and interprets them using the float component convention. These legacy fields can coexist with the standard colour format -- a .dat file can use either representation for these two fields, but not both representations simultaneously for the same field. If both the unified field (e.g., Laser_Color #ff0000) and the legacy split fields (e.g., Laser_Color_R 0.5) 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 colour field.

Field	Standard representation types	Legacy representation type	Legacy example
Laser_Color	Hex, named, dictionary	Three float32 properties with _R, _G, _B suffixes	Laser_Color_R 0.5
Nightvision_Color	Hex, named, dictionary	Three float32 properties with _R, _G, _B suffixes	Nightvision_Color_G 1.0

The legacy format is a float-based representation in contrast to the uint8 byte-based representation of the dictionary format. The conversion between the two is:

uint8_value = float_value × 255

Example: Laser_Color_R 0.5 corresponds to dictionary R 128 because 0.5 × 255 = 127.5, rounded to 128.

The legacy format is not recommended for new mods. New modders should use the standard hexadecimal format for Laser_Color and Nightvision_Color unless they are maintaining an older mod that already uses the legacy representation and do not wish to migrate the existing files. The standard format is more readable, more compact, and more consistent with every other colour field in the asset system.

The flowchart above documents the decision path for choosing between standard and legacy colour representation. New mods always take the standard path. Legacy mods that already use the split-float representation may continue to do so but should consider migration during the next major mod update.

Where colours appear in the Unturned asset system

Colour-typed fields appear across multiple asset categories in the Unturned™ .dat system. The table below documents the known colour fields, their parent asset types, and the representation formats they accept.

Field	Asset type	Hex	Named	Dict	Legacy	Purpose
SpotLight_Color	Items with SpotLight_Enabled (helmets, headwear)	Yes	Yes	Yes	No	Colour of the player spotlight beam
Laser_Color	Tactical laser attachments	Yes	Yes	Yes	Yes (_R, _G, _B floats)	Colour of the visible laser beam
Nightvision_Color	Night vision scope attachments	Yes	Yes	Yes	Yes (_R, _G, _B floats)	Tint colour of the night vision overlay
FogColor	Map/level .dat	Yes	Yes	Yes	No	Colour of atmospheric fog
SkyColor	Map/level .dat	Yes	Yes	Yes	No	Colour of the skybox
GroundColor	Map/level .dat	Yes	Yes	Yes	No	Colour of the ground plane

The SpotLight_Color field is defined as part of the PlayerSpotLightConfig struct, which is embedded in certain item assets. When a helmet or headwear item includes a toggleable light source (controlled by the SpotLight_Enabled field), the SpotLight_Color field controls the visible colour of the emitted light beam. The default value is #f5df93 (a warm yellowish-white), which is the vanilla flashlight colour. Modders authoring custom helmet lights can override this to produce coloured beams (a red light for a rescue helmet, a blue light for a police helmet, a green light for a military night operations helmet).

The Laser_Color field controls the visible beam of a tactical laser attachment. The default value (when the field is not specified) is red. Modders can author green, blue, or custom-colour lasers by specifying a different colour value.

The Nightvision_Color field controls the colour tint applied to the night vision overlay when a night vision scope is equipped. The default value is green, representing the classic phosphor-green night vision aesthetic. Modders can author alternative tints (white phosphor, amber, blue-tinted) for custom night vision scopes.

The map-level colour fields (FogColor, SkyColor, GroundColor) control the atmospheric rendering properties of a map mod. These fields accept all three standard colour formats and are typically authored using the named colour format for broad atmospheric categories (FogColor gray) or the hexadecimal format for precise tints.

Worked examples from the official documentation and shipped files

Example 1: Hexadecimal colours with and without the # prefix

The official SDG documentation provides the following worked example of hexadecimal colour specification:

SkyColor 0000ff
GroundColor #00ff00

Both fields specify valid hexadecimal colours. SkyColor 0000ff specifies pure blue without the # prefix. GroundColor #00ff00 specifies pure green with the # prefix. The parser accepts both and treats them as identical in function -- the presence or absence of the # does not affect the parsed colour value.

Example 2: Dictionary colour specification

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

FogColor
{
  R 255
  G 0
  B 0
}

This sets the fog colour to pure red. The same colour could be specified equivalently as FogColor #ff0000 or FogColor ff0000. The choice of representation is a matter of authoring preference rather than a functional constraint.

Example 3: Default spotlight colour from the PlayerSpotLightConfig struct

The official SDG documentation specifies the default value for SpotLight_Color as #f5df93, a warm yellowish-white. This default value is used by the vanilla Unturned™ flashlight and by any mod item that includes a PlayerSpotLightConfig struct without explicitly overriding SpotLight_Color. The default value is specified in hexadecimal with the # prefix. This is the canonical representation that the SDG documentation uses for all colour defaults across the asset system.

Example 4: Legacy laser colour representation

A legacy laser colour specified using the float-component format:

Laser_Color_R 0.5
Laser_Color_G 1.0
Laser_Color_B 0.0

This produces a lime-green laser beam at 50 percent red intensity and 100 percent green intensity. The equivalent standard representation would be Laser_Color #80ff00. The legacy format is functionally equivalent but less compact and less portable across tools that expect the unified colour field.

Example 5: Standardized laser colour for a new mod

A new mod that specifies a blue laser using the standard unified colour field:

Laser_Color #0000ff

This is the cohort-recommended representation for new mods. It is compact, unambiguous, and consistent with the format used by every other colour field in the asset system.

Comparison of colour format representations

The table below compares the three standard colour representations across dimensions relevant to mod authoring.

Dimension	Hexadecimal	Named colour	Dictionary
Precision	Full 24-bit (16.7 million colours) plus 8-bit alpha	Limited to engine's named colour table	Full 24-bit (16.7 million colours) plus 8-bit alpha
Compactness	Most compact (7-9 characters)	Compact (variable name length)	Least compact (multiple lines)
Readability	Moderate (requires hex-to-colour mental mapping)	Highest (human-language name)	Highest for per-component tuning (explicit byte values)
Alpha support	Yes (fourth byte)	No	Yes (optional A key)
Tool interop	Best (matches colour picker output in Photoshop, GIMP, web tools)	Poor (resolved name may not match exact intended shade)	Moderate (byte values match colour picker Info panel output)
Cohort recommendation	Preferred for most fields	Acceptable for broad atmospheric categories	Acceptable for iterative per-component tuning

The cohort recommendation for new modders is to use the hexadecimal format for all colour fields in item mods. The hexadecimal format is the most compact, the most interoperable with colour picker tools, and the most consistent with the official SDG documentation. Named colours are acceptable for map-level atmospheric fields where exact colour precision is not required. The dictionary format is useful during development when a modder is iterating on individual colour components and wants to see the byte values explicitly.

Frequently asked questions

Does the parser require the # prefix for hexadecimal colours?

No. The # prefix is optional. SkyColor 0000ff and SkyColor #0000ff are functionally identical values. The parser recognizes the hexadecimal pattern by the presence of exactly six or eight hexadecimal characters, with or without the # prefix. The cohort recommendation is to include the # prefix for readability -- it visually distinguishes a hexadecimal colour from an integer field that happens to contain hexadecimal-looking digits.

What happens if I specify a hexadecimal value that is shorter than six characters?

The parser expects exactly six characters for an RGB value or exactly eight characters for an RGBA value. A value that is shorter (e.g., #fff for white in CSS shorthand) is not recognized by the Unturned™ parser and will either fail to parse or fall back to the default colour for that field. Always use the full six-character (#RRGGBB) or eight-character (#RRGGBBAA) form.

Can I mix representations across colour fields in the same file?

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

What happens if a named colour is not recognized by the parser?

If the named colour is not in the engine's lookup table, the parser treats the value as unrecognized. The behaviour depends on the specific game version and the field: some versions fall back to the field's default colour value (e.g., #f5df93 for SpotLight_Color), while others may produce a parse warning in the log. The cohort recommendation is to verify named colours against the official SDG documentation's table of recognized colour names before relying on them in a published mod.

Does the alpha channel work on all colour fields?

No. The alpha channel is supported on fields where transparency has a meaningful rendering effect -- primarily SpotLight_Color, Laser_Color, and Nightvision_Color. Map-level colour fields (FogColor, SkyColor, GroundColor) ignore the alpha channel; they are always rendered fully opaque. Specifying an alpha value on a field that does not support it is harmless (the parser accepts it but the renderer ignores it) but unnecessary and potentially confusing to future readers of the .dat file.

Can I use uppercase hexadecimal letters in my colour values?

Yes. The parser accepts both uppercase (A through F) and lowercase (a through f) hexadecimal letters. #FF0000 and #ff0000 are functionally identical. The cohort recommendation is to use lowercase for consistency with the colour picker output of most image editing tools, which default to lowercase hexadecimal display.

How do I specify a colour that is exactly 50 percent transparent?

In hexadecimal format, specify an alpha byte of 80 (128 in decimal, which is approximately 50 percent of the 0-255 range): #ff000080 for a semitransparent red. In dictionary format, use A 128:

SpotLight_Color
{
  R 255
  G 0
  B 0
  A 128
}

The named colour format does not support alpha and cannot specify a semitransparent colour.

What is the difference between the dictionary R/G/B uint8 values and the legacy laser float values?

The dictionary format uses uint8 values in the range 0 through 255 for R, G, B, and A. The legacy Laser_Color_R (and Nightvision_Color_R) format uses float32 values in the range 0.0 through 1.0. The two are related by the conversion uint8_value = float_value × 255 rounded to the nearest integer. The dictionary format is a byte-level specification; the legacy float format is a normalized-level specification. The dictionary format is used in modern .dat files; the legacy float format exists only for backward compatibility with the two specific colour fields that predate the unified colour type.

Do I need to quote colour values?

No. Colour values are never quoted in .dat files. The parser expects unquoted hexadecimal strings (#ff0000), unquoted named colours (skyblue), and unquoted integer values (255) within the dictionary format. Quotation marks surrounding a colour value will cause the parser to fail to recognize it as a valid colour.

Can I use spaces inside a hexadecimal colour value?

No. The hexadecimal colour value is a single unbroken string of characters. #ff 00 00 (with spaces between the component pairs) is not a valid colour value and will not parse correctly. The hexadecimal representation relies on the exact six-character or eight-character pattern; any whitespace embedded within the hex string breaks the pattern recognition.

How do I find the exact colour used by a vanilla Unturned item?

Locate the vanilla item's .dat file in the game's Bundles/Items/ directory and inspect the colour fields directly. For items where the colour is specified as part of a struct (e.g., PlayerSpotLightConfig within a helmet's .dat), the colour value may be embedded at a deeper nesting level. The Structs Type Reference article documents how to locate nested colour values within struct-based configurations.

Can I specify a colour in HSL or HSV format?

No. The Unturned™ colour parser does not support HSL (hue, saturation, lightness) or HSV (hue, saturation, value) colour specification. Colours must be specified in one of the three recognized formats: hexadecimal RGB/RGBA, named colour, or dictionary with R/G/B/A byte values. A modder who prefers to design colours in HSL space should use an external colour picker that displays the equivalent hexadecimal or RGB byte values and copy those into the .dat file.

What happens if I specify alpha on a field that does not support it?

The parser accepts the value. The renderer ignores the alpha component for fields where transparency has no visual meaning. Specifying FogColor #80808080 (gray with 50 percent alpha) on a map will produce a fully opaque gray fog identical to FogColor #808080. The alpha byte is parsed and stored internally but is not used by the rendering pipeline for that field. This behaviour is harmless but the extraneous alpha byte may confuse a future reader of the file; the cohort recommendation is to omit alpha on fields that do not support it.

How do I test colour output without rebuilding the Unity bundle?

Colour fields do not require a Unity bundle rebuild. The .dat file is re-read each time the game launches. To test a colour change: edit the .dat file, save it, and launch Unturned™ in single-player. Spawn the item with the changed colour field. If the item is already in the player's inventory from a previous session, the existing instance may carry the old colour value (because items already in the world are not re-parsed from the .dat file). To force the game to read the updated .dat value, spawn a fresh instance of the item using the @give console command or start a new single-player session.

Can colour fields be used in server-only mods (no client bundle)?

Yes. Colour fields are server-authoritative data stored in the .dat file, which is read by both the server and the client. A server-only mod that adds a SpotLight_Color field to an existing item will cause the server to send the modified spotlight colour to connected clients. The clients do not need a custom bundle to render a different spotlight colour -- the colour value is transmitted as part of the item's network-synced state. This is one of the few modding operations that can be performed server-side without requiring client-side asset downloads.

How do game updates affect colour field compatibility?

Unturned™ game updates rarely change the colour data type itself, because the colour format is a foundational parser type that has been stable across many game versions. However, game updates may add new colour-typed fields to existing asset types or change the default colour value for a field. A mod that relies on a specific default colour value may behave differently after an update if the game's default changes. The cohort recommendation is to always specify colour fields explicitly in mod .dat files rather than relying on game defaults, so that the mod's colour values are self-contained and immune to default-value changes in subsequent game updates.

What is the difference between the legacy Laser_Color float values and the dictionary uint8 values in terms of precision?

The legacy Laser_Color_R/_G/_B float format supports full float32 precision (approximately 7 significant decimal digits) for each component. The dictionary format's R/G/B values are uint8 (0-255), which limits each component to 256 discrete intensity levels. In practice, both formats provide more precision than the human eye can distinguish -- the 256 levels of the uint8 format correspond to the standard 8-bit-per-channel colour depth of consumer displays. The difference only matters if the modder is programmatically generating colour values with sub-integer precision; for hand-authored colours, both formats are equivalently precise perceived by human eyes.

Is there a performance difference between the three colour representations?

No. All three representations are converted to the same in-memory colour structure at asset load time. The load-time parsing cost differs trivially between representations -- the dictionary format requires marginally more parser work because it must read multiple lines and key-value pairs rather than a single hex string -- but this cost is incurred once at asset load time and is negligible compared to the cost of loading the asset's Unity bundle and textures. The modder should choose the representation that is clearest for authoring and maintenance, not the one with the theoretically fastest parse time.

Best practices

• Use the hexadecimal format with the # prefix for all colour fields in item mods. It is the most compact, the most interoperable with colour picker tools, and the format the official SDG documentation uses for default values.
• Include alpha only on fields where transparency has a meaningful rendering effect. Specifying alpha on FogColor or SkyColor is harmless but misleading.
• During development, use the dictionary format for colour fields that need per-component tuning. Convert to hexadecimal shorthand for the final published file.
• Verify named colours against the official SDG documentation before relying on them. A misspelled or unrecognized named colour falls back to the default, which may not be visually apparent until the mod is tested in-game.
• When authoring Laser_Color or Nightvision_Color for a new mod, use the standard unified colour field rather than the legacy _R, _G, _B split properties. The standard format is more consistent with every other colour field and is more readable.
• Always test colour fields in single-player before publishing. Colours that parse correctly at the syntax level may look different in the rendered game environment than they do in an external colour picker due to lighting, post-processing, and the rendering pipeline.
• Document the intended colour in a comment alongside the colour field if the chosen colour has a specific in-game rationale (e.g., // Blue light for police roleplay faction identifier).
• When migrating a legacy .dat file that uses split Laser_Color_R/_G/_B properties, convert all three to the single unified field during the same migration pass. A file that is partially migrated (some fields unified, others still split) is harder to debug than a file that is completely in one format.
• Maintain a personal palette reference file for mod series that share a common colour scheme across multiple items. The palette file records faction colours in hex, dictionary, and named colour form and serves as the single source of truth during iterative development.
• Test colour-dependent mods under colour blindness simulation before publication if the colour conveys gameplay information. Add non-colour cues (intensity difference, beam pattern, audio cue, or text label in the inventory tooltip) for redundancy.
• When specifying bright or saturated colours for light sources, reduce the SpotLight_Intensity value to compensate. A intensely red spotlight at full intensity can flood the screen with colour, obscuring the player's view of the environment. A lower intensity produces a visible colour tint without overwhelming the rendered scene.
• When authoring tactical laser colours, test the beam visibility against both light and dark surfaces. Additive blending makes lasers invisible against bright surfaces and vivid against dark surfaces. A laser colour that looks good against a dark wall may be invisible against a daytime sky, which is a gameplay consideration for PvP mods where laser visibility signals position.
• For mods intended for use on RP servers (such as Horizon Life RP), document the in-universe significance of colour choices in the mod's Workshop description. A police faction helmet with a blue spotlight carries different connotations across different RP server configurations, and providing the design rationale in the description helps server owners decide whether the mod fits their server's faction colour conventions.
• When authoring multiple colour-dependent items in a single mod pack, maintain consistency across the pack. If a faction's helmet uses SpotLight_Color #0044ff, that faction's weapon laser attachments, vehicle lights, and base lighting should use the same hex value to establish a recognizable faction colour identity that players learn to associate with the faction across gameplay sessions.

Advanced considerations

Colour precision and gamut limitations

The colour format supports 8 bits per channel (24-bit RGB or 32-bit RGBA), which provides 16.7 million distinct colours. This is the standard colour depth of consumer display hardware and is sufficient for every colour field in the Unturned™ asset system. The engine does not support high-dynamic-range (HDR) colour values, 10-bit colour depth, or floating-point colour components outside the legacy Laser_Color and Nightvision_Color fields. A modder who designs assets in a wide-gamut colour space (Adobe RGB, DCI-P3) should convert to sRGB before extracting hexadecimal values for .dat fields; colours authored in a wide-gamut space and pasted directly as sRGB hex values will appear desaturated in the game.

Colour interaction with post-processing

Colour fields in the .dat file specify the raw colour of the rendered element before post-processing. The game's post-processing stack (tone mapping, colour grading, bloom, ambient occlusion) modifies the final pixel colour that reaches the screen. A spotlight beam authored as #ff0000 (pure red) may appear as a slightly desaturated or bloom-softened red in the final rendered frame, particularly at night with bloom enabled. Modders who require precise colour matching between a reference image and the in-game appearance should test the colour in the target lighting conditions (daytime, nighttime, interior, exterior) and adjust the .dat value to compensate for post-processing effects.

Colour authoring for accessibility

Colour fields that convey gameplay information -- a red laser versus a green laser indicating enemy versus friendly, a blue spotlight versus a white spotlight indicating faction affiliation -- should be designed with colour vision deficiency (CVD) considerations. The three most common forms of CVD affect the perception of red-green distinctions, blue-yellow distinctions, and overall colour saturation. A mod that uses colour as the sole discriminator between gameplay states should additionally provide a non-colour cue (intensity difference, beam pattern difference, audio cue) to ensure that players with CVD can interpret the information. The colour fields themselves are fully configurable; the accessibility accommodation lives in the broader design of the mod rather than in the .dat file.

Batch colour replacement across multiple assets

Mod projects that use a consistent colour palette across multiple items (a faction pack where all helmets, uniforms, and weapon attachments share a common faction colour) benefit from documenting the palette in a separate project-level reference file. The palette file records the faction colours in all three representations (hexadecimal, named colour, and dictionary byte values) and serves as the single source of truth that every item's .dat references. When the palette changes, the modder updates the palette file and then updates each affected .dat field individually -- the engine does not support a shared colour reference (a variable or macro) that multiple .dat files can import. The palette file is a project management aid, not an engine feature.

Colour fields in server-side plugins

Server-side plugin code (C# OpenMod or RocketMod plugins) can read and write colour fields from asset objects at runtime through the Unturned Dedicated Server API. The API exposes colour values as Unity Color structs with floating-point components (r, g, b, a in the range 0.0f through 1.0f). A plugin that dynamically adjusts a spotlight colour based on player state (e.g., a helmet light that shifts from white to red as the player takes damage) reads the asset's SpotLight_Color, constructs a new Color struct, and writes it back through the appropriate API method. The API-level component values use the normalized float convention (0.0f through 1.0f), not the uint8 convention (0 through 255), which is a common source of off-by-scale errors in colour-aware plugin code.

Appendix A: Colour format quick reference card

Format	Syntax	Example	Alpha	Use case
Hex without #	RRGGBB or RRGGBBAA	0000ff	Optional fourth byte	Compact, tool-friendly
Hex with #	#RRGGBB or #RRGGBBAA	#00ff00	Optional fourth byte	Preferred, readable
Named colour	name	skyblue	Not supported	Broad atmospheric categories
Dictionary	{ R uint8 G uint8 B uint8 A uint8 }	{ R 255 G 0 B 0 }	Optional A key	Per-component tuning
Legacy float	_R float32 _G float32 _B float32	Laser_Color_R 0.5	Not supported	Laser_Color, Nightvision_Color only

Appendix B: Colour component reference table

Component	Hex range	Dictionary uint8 range	Legacy float range	Description
Red (R)	00 - FF	0 - 255	0.0 - 1.0	Red colour channel intensity
Green (G)	00 - FF	0 - 255	0.0 - 1.0	Green colour channel intensity
Blue (B)	00 - FF	0 - 255	0.0 - 1.0	Blue colour channel intensity
Alpha (A)	00 - FF	0 - 255	,	Opacity: 00/0 = transparent, FF/255 = opaque

Appendix C: Common colour values used in Unturned modding

Colour name	Hex (RGB)	Hex (RGBA opaque)	Dictionary	Typical use
White	ffffff	#ffffff	R 255 G 255 B 255	Default flashlight spotlight
Warm white	f5df93	#f5df93	R 245 G 223 B 147	Vanilla SpotLight_Color default
Red	ff0000	#ff0000	R 255 G 0 B 0	Default laser beam colour
Green (night vision)	00ff00	#00ff00	R 0 G 255 B 0	Default night vision tint
Blue	0000ff	#0000ff	R 0 G 0 B 255	Police/faction light variant
Black	000000	#000000	R 0 G 0 B 0	"Off" state for light fields
Gray	808080	#808080	R 128 G 128 B 128	Fog/atmosphere neutral tint
Amber	ffbf00	#ffbf00	R 255 G 191 B 0	Alternative night vision tint
Dim red (50 percent alpha)	ff000080	#ff000080	R 255 G 0 B 0 A 128	Subdued laser or spotlight

Appendix D: Colour format authoring checklist

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

• [ ] All colour fields use a recognized format: hexadecimal (with or without #), named colour, dictionary, or legacy float (for Laser_Color/Nightvision_Color only)
• [ ] Hexadecimal values are exactly six characters (RGB) or eight characters (RGBA)
• [ ] Named colours are verified against the official SDG documentation list
• [ ] Alpha is specified only on fields that support it (SpotLight_Color, Laser_Color, Nightvision_Color)
• [ ] New mods use the standard unified colour field for Laser_Color and Nightvision_Color, not the legacy _R/_G/_B split format
• [ ] Colours tested in the target lighting conditions (day, night, interior) and adjusted for post-processing effects
• [ ] If colours convey gameplay information, a non-colour cue (intensity, pattern, audio) provides redundancy for CVD accessibility
• [ ] Dictionary format colour components follow the uint8 (0-255) convention, not the float32 (0.0-1.0) convention used by the legacy format

Appendix E: Diagnostic table for colour format errors

Symptom	Most likely cause	Resolution
Colour field produces default colour (not the one specified in .dat)	Unrecognized named colour or hex value too short	Verify named colour against SDG docs; use full 6- or 8-character hex
Colour field produces white or near-white when a specific colour was intended	Float values used in dictionary format instead of uint8 values	Use uint8 values (0-255) in dictionary format; convert floats by multiplying by 255
Alpha has no visible effect on spotlight/Laser/Nightvision colour	Field does not support alpha, or alpha byte is FF (fully opaque)	Confirm field supports alpha; set alpha to a value below FF for visible transparency effect
Laser colour specified in standard format ignored	Legacy _R/_G/_B properties also present and take precedence (version-dependent)	Remove legacy split properties; use only the unified Laser_Color field
Colour renders differently in-game than in colour picker	Post-processing modifies final pixel colour; lighting conditions affect perceived colour	Test in target conditions; adjust .dat value to compensate for post-processing
Named colour resolves to unexpected shade	Engine's named colour table does not match the modder's expectation	Switch to hexadecimal format for precise colour control
Dictionary colour not parsed (parser treats value as named colour lookup)	Opening brace { not on the line immediately following the field name	Ensure { appears on the line after the field name, on its own line or at the start of the value line

Colour format parsing in practice: a tracer wire protocol

The following extended worked example traces a single colour field, SpotLight_Color, 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 #ff0000 in a .dat file and seeing a red spotlight beam in the game world.

Stage 1: Authoring

The modder writes the following line in TacticalHelmet.dat:

SpotLight_Color #ff0000

The field is an embedded struct field of the PlayerSpotLightConfig type. The modder chose the hexadecimal representation with the # prefix. The value specifies pure red with no green, no blue, and implicit full opacity (alpha defaults to FF).

Stage 2: Parsing at asset load time

The game launches and the asset loader reads TacticalHelmet.dat. The parser encounters the SpotLight_Color field. The leading character is #, which triggers the hexadecimal colour parse path. The parser reads the six characters ff0000, validates that they are valid hexadecimal digits, and constructs an in-memory UnityEngine.Color struct with components r=1.0f, g=0.0f, b=0.0f, a=1.0f. The parsed Color is assigned to the SpotLight_Color property of the hat item's PlayerSpotLightConfig struct instance.

If the modder had instead written SpotLight_Color red, the parser would have taken the named colour path, looked up red in the named colour table, and constructed the identical Color(1.0f, 0.0f, 0.0f, 1.0f). If the modder had written the dictionary form, the parser would have taken the dictionary path and read R 255, G 0, B 0 as uint8 values before converting to the normalized float components. All three paths converge on the same Color struct.

Stage 3: Runtime activation

During gameplay, the player equips the helmet and presses the light toggle key. The game code reads the PlayerSpotLightConfig from the item asset, checks that SpotLight_Enabled is true, and activates the spotlight. The spotlight's rendering component reads SpotLight_Color (the parsed Color from stage 2) and applies it as the beam colour. The beam is rendered with the specified colour multiplied by the spotlight's intensity (SpotLight_Intensity 1.3), producing a slightly brightened red beam.

Stage 4: Post-processing

The red spotlight beam passes through the game's post-processing stack. Tone mapping adjusts the beam's HDR intensity to the display's SDR range. Bloom adds a soft glow around the beam. Colour grading applies any map-level colour corrections. The final pixel colours on screen are the result of the raw #ff0000 colour modulated through intensity, distance attenuation, tone mapping, bloom, and colour grading. The colour the modder sees on screen is not the raw #ff0000 from the .dat file; it is that colour processed through the full rendering pipeline.

The sequence above illustrates the complete path from authoring to display. Each stage is documented in detail in this article. The key insight for modders is that the colour seen on screen differs from the raw .dat value due to intensity modulation and post-processing -- testing in-game is the only way to verify that the intended colour appearance is achieved.

Extended worked examples from shipped game files

Example 6: Light colour toggle on a helmet with a coloured spotlight

A helmet with a blue spotlight for a police faction mod. The spotlight colour is specified in hexadecimal with the # prefix. The intensity is reduced from the vanilla default of 1.3 to 0.8 to produce a dimmer blue beam that does not overwhelm the screen at night.

SpotLight_Enabled true
SpotLight_Range 40
SpotLight_Angle 60
SpotLight_Intensity 0.8
SpotLight_Color #0044ff

The narrow angle of 60 degrees produces a more focused beam than the vanilla 90-degree flashlight. The reduced range of 40 meters means the police light is effective at closer distances, appropriate for indoor and urban encounters rather than open-field illumination.

Example 7: Night vision scope with white-phosphor tint

Vanilla Unturned™ uses green-phosphor night vision (the classic green-tinted overlay). A custom night vision scope with a white-phosphor (greyscale) tint for a more modern military aesthetic:

Nightvision_Color #aaaaaa

The gray value #aaaaaa produces a desaturated, near-greyscale overlay. This is perceptually easier on the eyes during extended night operations and provides better contrast discrimination than the green-phosphor default, at the cost of reduced "night vision feel" for players who prefer the classic aesthetic.

Example 8: Red tactical laser for an enemy-faction weapons pack

A faction weapons pack where all laser attachments use red beams to visually distinguish enemy weapons from friendly weapons (which use green lasers). The laser colour is specified using the unified colour field:

Laser_Color #ff0000

This is a new-mod example using the standard unified field format. The red laser is immediately distinguishable from the green laser default, providing visual faction identification at a glance without requiring the player to inspect inventory icons or item names.

Colour in the game world: lighting model interaction

The colour fields documented in this article specify the raw emission colour of light sources (spotlights, lasers) and the raw tint colour of overlays (night vision). These colours interact with the game's lighting model to produce the final rendered result. Understanding this interaction is essential for modders who need precise colour reproduction.

Spotlight colour and the Unity lighting model

Spotlights in Unturned™ use Unity's real-time spotlight rendering with a cookie texture for the beam falloff pattern. The spotlight colour (SpotLight_Color) is multiplied by the spotlight intensity (SpotLight_Intensity), the distance attenuation (determined by SpotLight_Range), and the cookie texture's alpha channel at each pixel. The result is then added to the scene's accumulated lighting buffer and processed through the deferred rendering pipeline.

The practical consequence for colour authoring is that a spotlight colour of #ffffff (pure white) at intensity 1.3 and range 64 produces a beam that appears slightly warm on screen due to the default spotlight cookie texture, which has a subtle warm tint baked into its falloff pattern. A modder aiming for a truly neutral white beam may need to counter-tint the colour value slightly toward blue to compensate for the cookie's warm tint, or author a custom cookie texture with a neutral falloff.

Laser colour and the additive blending model

Laser beams in Unturned™ are rendered using additive blending -- the laser colour is added to the existing pixel values rather than mixed with them. This means a laser beam that passes across a bright surface becomes nearly invisible (adding RGB values to an already-near-white pixel saturates to white), while a laser beam against a dark surface appears at its full saturated colour. A red laser (#ff0000) against a dark wall appears as a vivid red line; the same laser against a bright daytime sky is virtually invisible. Modders designing laser colours should test the beam visibility in the full range of expected lighting conditions (day, night, interior, exterior) and consider adjusting the laser intensity (which is controlled by the attachment prefab, not the .dat file) if consistent visibility is required.

Colour conversion reference: hex to uint8 to float

Modders working across the three colour representation systems frequently need to convert between hexadecimal, uint8 byte values, and normalized float values. The following extended reference table provides the conversion relationships and worked examples.

Conversion formulas

From	To	Formula	Example
Hex pair	uint8	Convert.ToInt32(hex, 16)	FF → 255
uint8	Normalized float	uint8 / 255.0	128 → 0.502
Normalized float	uint8	round(float * 255)	0.5 → 128 (or 127)
uint8	Hex pair	uint8.ToString("X2")	255 → "FF"
Hex RRGGBB	Dictionary R,G,B	Extract pairs, convert each to uint8	#ff8000 → R 255 G 128 B 0
Dictionary R,G,B	Hex RRGGBB	Convert each uint8 to hex pair, concatenate	R 255 G 128 B 0 → #ff8000

Common conversion table

Colour description	Hex	uint8 (R,G,B)	Normalized float (R,G,B)
Pure red	#ff0000	R 255 G 0 B 0	1.0, 0.0, 0.0
Pure green	#00ff00	R 0 G 255 B 0	0.0, 1.0, 0.0
Pure blue	#0000ff	R 0 G 0 B 255	0.0, 0.0, 1.0
White	#ffffff	R 255 G 255 B 255	1.0, 1.0, 1.0
Black	#000000	R 0 G 0 B 0	0.0, 0.0, 0.0
50% gray	#808080	R 128 G 128 B 128	0.502, 0.502, 0.502
Warm white (default spotlight)	#f5df93	R 245 G 223 B 147	0.961, 0.875, 0.576
50% transparent red	#ff000080	R 255 G 0 B 0 A 128	1.0, 0.0, 0.0, 0.502
Deep orange	#ff8000	R 255 G 128 B 0	1.0, 0.502, 0.0
Lime green	#80ff00	R 128 G 255 B 0	0.502, 1.0, 0.0
Cyan	#00ffff	R 0 G 255 B 255	0.0, 1.0, 1.0
Magenta	#ff00ff	R 255 G 0 B 255	1.0, 0.0, 1.0
Yellow	#ffff00	R 255 G 255 B 0	1.0, 1.0, 0.0
Navy blue	#000080	R 0 G 0 B 128	0.0, 0.0, 0.502
Maroon	#800000	R 128 G 0 B 0	0.502, 0.0, 0.0

The conversion table covers the most commonly needed colour values in Unturned™ modding. Modders who work extensively with colour fields may benefit from maintaining a personal conversion reference for their mod's palette colours in all three representations.

Colour gamut and display consistency

The colour values authored in .dat files specify colours in the sRGB colour space. The Unturned™ rendering engine operates in the sRGB colour space for all colour-typed fields, including light sources and overlays. Modders who author colour values on a display calibrated to a different colour space (wide-gamut DCI-P3, Adobe RGB, or an uncalibrated consumer display) may see colours in-game that differ from the colours they see in their image editing software.

Practical display calibration considerations

The cohort recommendation for colour-critical mod authoring (spotlight beams that must match a specific faction colour, night vision tints that must be perceptually distinguishable) is:

1. Author the initial colour value in an image editor with sRGB colour management enabled.
2. Sample the sRGB hexadecimal value from the colour picker.
3. Paste the hexadecimal value into the .dat file.
4. Test the colour in single-player on the target display (the display the modder expects the majority of players to use).
5. If the in-game colour differs from the intended appearance, adjust the .dat value to compensate -- the .dat value is the ground truth, and the display appearance is what must match the intention.

This workflow acknowledges that display calibration varies across the player base and that the modder cannot control every player's display settings. The modder controls the .dat value, and the .dat value should be tuned so that the in-game appearance on a typical consumer display matches the modder's intention.

Colour blindness simulation for accessibility testing

Mods that use colour fields to convey gameplay information (red laser vs. green laser for enemy/friendly) should be tested under colour blindness simulation before publication. Tools such as the Colour Blindness Simulator in Photoshop (View → Proof Setup → Colour Blindness) or the browser-based Coblis simulator can preview how colour-encoded information appears to players with protanopia, deuteranopia, or tritanopia. If the colour distinction is lost under simulation, the mod should add a non-colour cue (intensity difference, beam pattern difference, audio cue, or text label in the inventory tooltip) to ensure that all players can interpret the gameplay information.

Appendix F: External references

Resource	URL	Notes
Smartly Dressed Games modding documentation	https://docs.smartlydressedgames.com/en/stable/	Official field reference. The colour data type is documented in the data types chapter.
Unturned on Steam	https://store.steampowered.com/app/304930/Unturned/	Game changelog.
Structs Type Reference	/data-types/structs-type-reference	The companion article that documents the struct type; covers how SpotLight_Color is embedded within PlayerSpotLightConfig.
Vector3 Type Reference	/data-types/vector3-type-reference	The next article in this section; covers the three-dimensional vector data type.
Enumerated Types Reference	/data-types/enumerated-types-reference	The previous article in this section; covers the enum data type.
Item Asset Anatomy	/items/item-asset-anatomy	The shared field reference that documents the asset fields where colour-typed properties appear.

Appendix G: Colour format parsing error reference

The following table documents the parse errors that the parser may produce when encountering a malformed colour value. The parser's error reporting varies by game version; some versions silently fall back to defaults, while others write a warning to the game's log file.

Error condition	Parser behaviour	How to detect	How to fix
Hex value shorter than 6 characters	Parse failure; fallback to default	Colour appears as default (not the intended value)	Always use exactly 6 (RGB) or 8 (RGBA) hex characters
Hex value longer than 8 characters	Parse failure or truncation	Colour may appear unexpected	Trim to exactly 6 or 8 characters
Invalid hex character (e.g., #FF00GG)	Parse failure; fallback to default	Colour appears as default	Use only valid hex digits: 0-9, A-F, a-f
Named colour not in engine table	Parse failure; fallback to default	Colour appears as default	Verify name against official SDG docs or switch to hex format
Dictionary missing required key (R, G, or B)	Parse failure or zero-filled for missing component	One colour channel appears as zero (black channel) when non-zero was intended	Always provide R, G, and B keys in dictionary format
Dictionary key has non-numeric value	Parse failure for that component	One colour channel appears as default or zero	Use only integer values (0-255) for dictionary component keys
Dictionary brace mismatched (missing closing })	Parse failure; field may consume subsequent lines	Subsequent fields ignored or misparsed	Ensure every { has a matching } on its own line
Legacy float value outside 0.0-1.0 range	Clamped to 0.0-1.0 or parse failure	Colour component appears at maximum or minimum unexpectedly	Keep legacy float values within the 0.0-1.0 range

The parsing errors above are validated against the official SDG documentation and community-observed behaviour. Modders experiencing unexpected colour field behaviour should consult this table before investigating deeper engine-level causes.

Appendix H: Colour field category reference

The following table organizes all known colour fields in the Unturned™ asset system by their functional category, providing a quick lookup for modders who know what they want to colour but not which field name controls it.

Functional category	Field name	Asset types	Default value
Player light source	SpotLight_Color	Hats, headwear items with spotlight config	#f5df93 (warm white)
Tactical laser	Laser_Color	Tactical laser attachments	Red (engine default)
Night vision overlay	Nightvision_Color	Night vision scope attachments	Green (engine default)
Atmospheric fog	FogColor	Map/level assets	Varies by map
Skybox	SkyColor	Map/level assets	Varies by map
Ground plane	GroundColor	Map/level assets	Varies by map

Each field in this table is documented in full detail in the relevant field reference section earlier in this article. The category reference is provided as a convenience for modders who need to quickly identify the correct field name for a given functional purpose.

Appendix I: Colour format version compatibility

Appendix I: Colour format version compatibility

The colour data type has been stable across Unturned™ Release 3.x. The three standard representations (hexadecimal, named colour, dictionary) have been supported since the colour type was introduced. The legacy Laser_Color and Nightvision_Color float-component format predates the unified colour type and is retained for backward compatibility. Modders authoring new content for any current Unturned™ version (Release 3.x and later) can rely on all three standard colour representations being available.

The only version-dependent behaviour is the specific set of recognized named colours in the engine's lookup table. The named colour table has expanded slightly across game versions as new colour names were added. Modders who rely on a named colour that was added in a recent game version should verify that the named colour is recognized by the minimum game version they intend to support. When in doubt, the hexadecimal format is version-agnostic and safe for all target game versions.

Game updates may add new colour-typed fields to existing asset types. A .dat file that specifies a colour for a field that did not previously support colour will behave differently after the game update that added support for the field -- the previously ignored field will now be recognized and applied. This is a minor consideration for modders maintaining mods across multiple game versions but rarely causes practical issues because game updates that add colour support to existing fields are announced in the game's changelog.

Future-proofing colour field authoring

The cohort recommendation for future-proofing colour field authoring is to always use the hexadecimal format with the # prefix. This format is the most compact, the most widely supported across all game versions, and the format used by the official SDG documentation for all default colour values. If future Unturned™ versions extend the colour type with additional formats (e.g., HSL support, HDR colour values), existing hexadecimal fields will continue to parse correctly because the legacy # prefix will still be recognized as the standard hexadecimal representation. Modders who prefer the named colour or dictionary format may continue to use them but should be aware that these formats are less universally recognized by external tools and less likely to be carried forward unchanged in future parser versions.

Mod publishing and colour versioning

When a mod that includes colour fields is published to the Steam Workshop, the Workshop item's changelog should note any changes to colour values between mod versions. A player who has customized their local copy of the mod's .dat file to change a colour (e.g., a server owner who wants a different spotlight colour for their faction helmets) will have their local changes overwritten on each Workshop update. Documenting colour changes in the Workshop changelog gives server owners advance notice of which colours will be reset and allows them to re-apply their customizations after the update.

The Workshop update system overwrites the entire mod folder on each update, including the .dat files. There is no field-level merge -- the entire file is replaced. Server owners who maintain custom colour configurations should keep a separate copy of their customized .dat files outside the Workshop content folder and re-copy them after each Workshop update. This workflow is not specific to colour fields; it applies to any .dat field that a server owner may customize. The general recommendation is documented in Steam Workshop Submission, which covers the update lifecycle and server-owner customization considerations in full detail.

Cross-references

• Enumerated Types Reference -- the previous article in this section; covers the enum value format used in .dat files.
• Vector3 Type Reference -- the next article in this section; covers the three-dimensional vector format.
• Structs Type Reference -- the companion data type article; documents how colours are embedded within nested struct configurations like PlayerSpotLightConfig.
• Item Asset Anatomy -- the shared field reference; documents the asset fields where colour-typed properties appear.
• 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 colour format reference: hexadecimal, named, dictionary, and legacy float formats; alpha channel handling; field coverage table; worked examples; FAQ; diagnostic table.