Asset Pointer Type Reference

Intermediate10-15 minutesCross-platformNotepad++

When one Unturned™ asset needs to refer to another , a gun referencing its default magazine, a barricade referencing the item that deploys it, a quest referencing the NPC who gives it , it does so using an asset pointer. An asset pointer is a GUID-based reference that identifies the target asset by its 128-bit globally unique identifier. The asset pointer is the fundamental cross-reference mechanism in the Unturned™ asset system and appears across every file format the game reads at load time: .dat files, .asset files, and JSON configuration files.

57 Studios™ has documented and validated the full asset pointer specification across the Unturned™ modding community. This article covers the three format-specific syntaxes for asset pointers , the .dat file format, the two .asset file formats (legacy explicit and modern inline), and the JSON format , and documents the pointer resolution behavior, the difference between an asset pointer and a plain GUID string, where asset pointers are used in shipped game files, and the common mistakes that prevent a pointer from resolving at load time.

Documentation source: This article references the official Smartly Dressed Games modding documentation for the asset pointer specification and resolution behavior. 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 are working with asset-type files (.asset, .dat) that reference other assets, and for mod authors who need to understand how the game resolves cross-references between item definitions. The article assumes familiarity with GUID generation and the concept of globally unique identifiers, as documented in Project Folder Structure and GUIDs. If you are new to the Unturned™ asset system, start with Item Asset Anatomy before returning here.

What you'll learn

• The definition of an asset pointer and how it differs from a plain GUID string
• The three format-specific syntaxes for asset pointers: .dat, .asset (legacy and modern), and JSON
• How asset pointers are resolved at load time and what happens when a pointer cannot be resolved
• Where asset pointers are used in shipped Unturned™ files (item references, effect references, spawn table entries, quest and dialogue node references)
• The two .asset file pointer formats , the legacy explicit style and the modern inline style , and when to use each
• Worked examples drawn from shipped game files
• Common pointer-resolution failures and their diagnostic signatures

Background: GUID-based cross-referencing

Every asset in Unturned™ is identified by a GUID , a 128-bit hexadecimal value that is globally unique within the game's loaded asset table. When one asset needs to refer to another, it does not use the target asset's numeric ID or its internal Name string. It uses the target asset's GUID. This is a design decision with a clear rationale: GUIDs are guaranteed unique across all loaded mods, while numeric IDs can collide and string names can be duplicated. A reference by GUID is an unambiguous pointer to exactly one asset.

An asset pointer is the syntactic wrapper around a GUID that signals to the parser that the field value is a cross-reference rather than a raw GUID string. The wrapper syntax depends on the file format in which the pointer appears. The parser reads the wrapper, extracts the GUID, and initiates the resolution process to locate the target asset in the loaded asset table.

The flowchart above shows the resolution chain for every asset pointer, regardless of file format. The parser extracts the GUID from the pointer syntax, queries the asset table, and either resolves the reference or triggers the asset type's fallback behavior for unresolved pointers. The fallback behavior varies by asset type: an unresolved magazine reference on a gun results in the gun having no default magazine and being unfireable; an unresolved quest-giver NPC reference results in the quest being unavailable; an unresolved barricade reference results in the barricade not appearing in the crafting menu.

Asset pointer syntax by file format

In .dat files

The .dat file format is the simplest asset pointer syntax. A .dat file field is a pair of whitespace-separated strings: the field name and the field value. The parser treats every .dat file as a sequence of string pairs, with no quoting or wrapping conventions. An asset pointer in a .dat file is therefore a field value that is the target asset's GUID as a raw hex string, without quotes, without brackets, and without any wrapper syntax.

MyAssetPtr a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d

The example above defines the field MyAssetPtr with the value a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d , the target asset's 32-character lowercase hex GUID. The field name (MyAssetPtr) identifies the field as a pointer type to the parser; the GUID value provides the target. The parser recognizes pointer fields by their position in the asset type's field schema, not by any syntactic marker on the value itself.

GUID case sensitivity in .dat files

Unturned™ .dat file GUIDs are case-insensitive at the parser level , the hex digits A through F are treated identically to a through f. However, the GUID values in shipped vanilla .dat files are uniformly lowercase. The cohort recommendation is to use lowercase GUIDs in all .dat files to maintain consistency with the vanilla convention.

The absence of syntactic wrapping on .dat file asset pointers means that a plain GUID string and an asset pointer are visually identical in a .dat file. The distinction is semantic: the field name tells the parser that the value should be treated as a pointer and resolved against the asset table. A GUID value in a non-pointer field (e.g., the GUID field itself, which defines the asset's own identity) is not resolved and is not treated as a reference.

In .asset files

The .asset file format supports two pointer syntaxes. The modern inline style is the recommended format for new content; the legacy explicit style is retained for backward compatibility with existing vanilla assets and older mods.

Modern inline style

The modern inline style wraps the GUID in a quoted string on the same line as the field name:

"MyAssetPtr" "a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d"

The field name is quoted, the GUID value is quoted, and both appear on the same line. The parser recognizes the pair as an asset pointer and resolves the GUID against the asset table. This is the format used in the majority of newer vanilla .asset files and is the recommended format for all new mod content.

Legacy explicit style

The legacy explicit style wraps the GUID in a nested block with a named sub-field:

"MyAssetPtr"
{
    "GUID" "a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d"
}

The field name appears alone on the first line, followed by a brace-delimited block containing a "GUID" sub-field. The parser recognizes the block structure and the "GUID" sub-field name as an asset pointer and resolves the GUID value against the asset table. This format is the older of the two .asset pointer styles and appears in legacy vanilla assets that have not been updated to the modern inline style.

Both formats produce identical resolution behavior. The choice between them is a style decision; the modern inline style is more compact and is the format that the official SDG documentation uses in examples. The legacy explicit style is more verbose but can be clearer in .asset files with many pointer fields because the block structure visually separates each pointer.

Which format to use in new mod content

For new mod .asset files, use the modern inline style ("MyAssetPtr" "GUID_HERE"). The legacy explicit style is supported but produces larger files with no functional advantage. The cohort convention is to follow the official SDG examples, which uniformly use the inline style.

In JSON files

Unturned™ uses JSON for certain configuration files, primarily in the server-side plugin ecosystem (OpenMod, RocketMod) and in newer game systems that have been migrated from the .dat/.asset format. An asset pointer in a JSON file uses a named object with a GUID field:

"MyAssetPtr": { "GUID": "a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d" }

The field value is a JSON object with a single key GUID whose value is the target asset's GUID as a string. The JSON parser recognizes the GUID key and the string value as an asset pointer and resolves the GUID against the asset table.

The JSON format is functionally identical to the .asset legacy explicit style, expressed in JSON syntax rather than the Unturned™ custom .asset format. The GUID field name is the same across both formats; the enclosing braces and quoting conventions differ.

Pointer resolution behavior

When the game loads at startup, it builds an asset table , an in-memory dictionary mapping every loaded GUID to its corresponding asset object. The table is built from every .dat and .asset file that the game enumerates in the local Bundles/ folder and the Workshop folder. Each asset's GUID field serves as the key.

When a pointer is encountered during parsing, the parser performs the following resolution sequence:

1. Extract the GUID string from the pointer value.
2. Query the asset table for the GUID.
3. If the GUID is found: the pointer resolves, and the source asset receives a reference to the target asset. The target asset's fields are now accessible to the source asset's runtime logic.
4. If the GUID is not found: the pointer remains unresolved. The source asset's runtime logic receives a null reference. The behavior of a null reference varies by asset type and context , some asset types treat it as a soft error (the feature that depends on the reference simply does not work), while others treat it as a hard error (the asset fails to load).

The sequence diagram above shows the resolution path for every asset pointer, regardless of file format. The critical detail is that resolution is a load-time operation , it happens once, when the file is first parsed, and the result (a valid reference or a null) is stored with the source asset for the lifetime of the game session. If a mod is added, removed, or updated while the game is running, existing asset pointers are not re-resolved; a game restart is required.

Unresolved pointer fallback behavior

The behavior when a pointer fails to resolve depends on the asset type that holds the pointer and the specific pointer field:

Asset type	Pointer field	Fallback behavior
Gun	Default magazine reference	Gun loads but has no magazine; cannot fire
Gun	Sight/Grip/Tactical/Barrel attachment references	Slot left empty; gun functions without the attachment
Item	Master bundle pointer	Item loads with no visible model; placeholder cube or invisible
Barricade	Item reference	Barricade cannot be placed; missing from crafting menu
Quest	NPC giver reference	Quest cannot be started; missing from quest log
Dialogue	Next dialogue reference	Dialogue chain breaks; conversation ends abruptly
Vendor	Item listing reference	Item not available for purchase
Spawn table	Asset entry	Entry skipped; no corresponding item spawns
Effect	Prefab reference	Effect does not render; no visible or audible feedback
Airdrop	Barricade reference	Airdrop deploys but the care package model is missing

Unresolved pointers in published mods

An unresolved asset pointer in a published mod produces a silent failure , the game does not log a warning or display an error to the player. The dependent feature simply does not work, and the player receives no indication of the cause. This absence of error feedback is the reason unresolved pointers are among the hardest bugs to diagnose in published mods. The cohort recommendation is to verify every pointer in the mod by loading the complete mod (all dependent assets) in single-player and testing every feature that references another asset before publishing to the Workshop.

How asset pointers differ from plain GUID strings

A plain GUID string is a raw 32-character hex value that appears in a non-pointer context , notably, the asset's own GUID field, which defines the asset's identity rather than referencing another asset. An asset pointer is a GUID string that appears in a field that the parser's schema recognizes as a cross-reference field. The GUID string is the same; the field context determines whether the parser attempts resolution.

The practical distinction matters for file authoring:

Context	Example	Treated as pointer?
Asset's own identity	GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d	No , this is the asset's own GUID
Gun's default magazine	Magazine a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d	Yes , resolved against magazine assets
Barricade's item reference	Item a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d	Yes , resolved against item assets
Quest's NPC giver	NPC a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d	Yes , resolved against NPC character assets

The same 32-character hex string can appear as the asset's own identity in one file and as a pointer to that asset in another file. The syntax wrapping (or lack thereof, in .dat files) does not change the underlying value.

Where asset pointers are used

Asset pointers are the universal cross-reference mechanism in Unturned™. They appear in every asset type that depends on another asset. The table below documents the most common pointer fields by asset category, drawn from shipped vanilla files and the official SDG documentation.

Asset category	Example pointer field	Points to	File format
Guns	Magazine	Magazine asset	.dat
Guns	Sight, Grip, Tactical, Barrel	Attachment assets	.dat
Guns	Magazine_Caliber_N	Magazine asset for a specific caliber slot	.dat
Barricades	Item	Item asset that deploys the barricade	.dat
Structures	Item	Item asset that places the structure	.dat
Quests	NPC	NPC character asset (quest giver)	.dat
Dialogue	Responses_N.Guid	Next dialogue message asset	.dat
Dialogue	Conditions_N.NPC_GUID	NPC character asset for condition check	.dat
Vendors	Items_N.Guid	Item asset available for purchase	.dat
Spawn tables	Assets_N.Guid	Asset to spawn	.asset
Airdrops	Landed_Barricade.GUID	Barricade asset for the landed state	.asset
Airdrops	Carepackage_Prefab	Master bundle pointer (not asset pointer)	.asset
Effects	Various GUID references	Effect assets, prefab assets	.asset
Foliage	Various GUID references	Foliage asset definitions	.asset

The table above reinforces an important pattern: .dat files use unwrapped GUIDs for pointer fields; .asset files use quoted inline or block-style GUID wrappers. The pointer field name is the only signal in a .dat file that the value is a cross-reference rather than a literal string.

Worked examples

Example 1: gun-to-magazine pointer in a .dat file

A gun .dat file referencing its default magazine by GUID:

Magazine d5e6f708192a4b3c5d6e7f8a9b0c1d2e

The field Magazine is the pointer field. The value d5e6f708192a4b3c5d6e7f8a9b0c1d2e is the target magazine's GUID. At load time, the parser queries the asset table for a magazine-type asset with this GUID and, if found, assigns it as the gun's default magazine.

Example 2: barricade-to-item pointer in a .dat file

A barricade .dat file referencing the item that deploys it:

Item fe71781c60314468b22c6b0642a51cd9

The field Item is the pointer field. The value is the deploying item's GUID. Without this pointer, the player cannot deploy the barricade , the game has no item-to-barricade mapping.

Example 3: asset pointer in a .asset file (modern inline style)

From a shipped airdrop .asset file:

"Landed_Barricade"
{
    "GUID" "fe71781c60314468b22c6b0642a51cd9"
}

The field Landed_Barricade contains a GUID sub-field referencing a barricade asset. This is the legacy explicit style. The same pointer could be written in the modern inline style as:

"Landed_Barricade" "fe71781c60314468b22c6b0642a51cd9"

Example 4: asset pointer in a JSON file

A server configuration JSON file referencing an item by GUID:

{
    "StarterItem": { "GUID": "a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d" }
}

The JSON object "StarterItem" contains a GUID field. The server-side plugin that reads this configuration resolves the GUID against the loaded asset table to determine which item to grant new players.

Example 5: quest NPC pointer in a .dat file

A quest .dat file referencing the NPC who gives the quest:

NPC b3c4d5e6f7084a9b1c2d3e4f5a6b7c8d

The player must speak to the NPC whose GUID matches this field value for the quest to become available. If the pointer is unresolved, the quest is inaccessible.

Frequently asked questions

What happens if two assets have the same GUID?

The game's asset table enforces GUID uniqueness at load time. If two assets share a GUID, the asset that loads second overwrites the asset that loaded first in the table. All pointers that previously resolved to the first asset are silently redirected to the second asset. This is the mechanism by which mods override vanilla assets , a mod asset with the same GUID as a vanilla asset replaces it. For mod-unique assets, this behavior is a hard bug: duplicate GUIDs across different items in the same mod produce unpredictable behavior and are difficult to diagnose. Always generate fresh GUIDs for every new asset.

Can a pointer reference an asset that is in a different mod?

Yes. The game builds the asset table from all loaded mods, not from individual mod folders. A pointer in Mod A can reference an asset in Mod B as long as both mods are loaded. This is how dependency chains work in the modding ecosystem , a gun mod that uses a shared attachment library mod, or a map mod that references items from an item pack mod. The dependent mod should document its dependency in its Workshop description and, ideally, in a mod dependency manifest.

How do I know which fields are pointer fields?

Pointer fields are identified by context within the asset type's field schema. The official SDG documentation lists which fields are pointer fields for each asset type. In practice, any field whose value is a 32-character hex string and whose purpose is to reference another asset is a pointer field. The field name (Magazine, Item, NPC, GUID inside a nested block) is the primary classifier. When in doubt, consult the asset-type-specific reference articles in the items section of this knowledge base.

Can a pointer reference an asset that does not exist yet?

The game resolves pointers at load time. An asset that is referenced by a pointer must be present in the loaded asset table when the resolution query runs. If the target asset is in the same mod, it loads before the pointer is resolved because the game enumerates all files before beginning resolution. A pointer to an asset in a different mod that is not loaded at the time of resolution will remain unresolved and produce the null-reference fallback behavior for that pointer's asset type.

Is there a limit to how many pointers a single asset can have?

No. There is no hard limit on the number of asset pointer fields an asset can contain. Practical limits are determined by the asset type's field schema , a gun can reference a finite number of attachment types, a spawn table can list a finite number of entries, a quest condition can reference a finite number of NPCs. The game does not impose a ceiling on these counts beyond the field schema's design.

Can a pointer reference an asset of the wrong type?

The parser resolves pointers by GUID lookup only , it does not validate that the resolved asset's Type field matches the expected target type. A pointer field named Magazine on a gun asset that resolves to a barricade asset (because the GUID matches a barricade asset) will produce a type mismatch at runtime. The gun's magazine logic will attempt to read magazine-specific fields from the barricade asset and will either receive default/zero values or encounter a runtime error. The cohort recommendation is to maintain a naming convention for GUID prefixes or a documented GUID index in the mod project to prevent type-mismatched pointer resolution.

How do I know if a pointer failed to resolve?

There is no in-game error message or log entry for an unresolved pointer. The diagnostic method is functional testing: if a feature that depends on a pointer works (a gun fires, a barricade places, a quest is available), the pointer resolved. If the feature silently does not work, an unresolved pointer is a likely cause. Test every cross-reference in single-player by exercising the dependent feature.

Can I use an asset pointer in a mod's English.dat file?

No. English.dat is a localization file, not an asset definition file. It does not contain asset pointers and does not participate in the pointer resolution system. Localization files contain only display text; the Name and Description fields are string literals rendered as UI text, not as asset references.

Can a pointer reference loop back to the source asset?

A circular reference , Asset A points to Asset B, which points back to Asset A , is technically valid at the parser level because the parser resolves pointers one at a time and does not detect cycles. The practical question is whether the runtime logic that uses the pointer handles the cycle. Most asset types' runtime logic does not anticipate circular references, and the behavior is undefined. The cohort recommendation is to avoid circular pointer chains in mod asset definitions. Design pointer relationships as directed acyclic graphs.

Can an asset pointer reference an archived or superseded memory?

This question is not applicable to the Unturned™ engine. The game does not have a concept of archived or superseded assets , every asset in the loaded asset table is live and resolvable. If an asset is removed from the loaded set (by unsubscribing from the mod that contains it), any pointer that previously resolved to it becomes unresolved. There is no archival or fallback-reference mechanism.

How do I know which format a specific .asset file expects?

The official SDG documentation specifies whether a given pointer field expects the inline, explicit, or JSON format. In practice, the .asset parser accepts all three formats for pointer fields , the format is a presentation choice, not a functional constraint. The parser recognizes the field structure (quoted inline value, brace-delimited block with GUID sub-field, or brace-delimited block with MasterBundle/AssetPath) and dispatches to the appropriate resolver. An .asset file can mix formats within the same file; there is no file-level format declaration.

What is the difference between an asset pointer and a master bundle pointer?

An asset pointer references another Unturned™ asset (an item, an NPC, a quest, a barricade, etc.) by its GUID. A master bundle pointer references a Unity prefab, material, audio clip, or other asset inside a Unity master bundle by its file path within the bundle. Asset pointers resolve against the game's asset table; master bundle pointers resolve against the Unity asset bundle at load time. The two pointer types serve different referencing domains and use different syntax. Master bundle pointers are documented in Master Bundle Pointer Type Reference.

How are GUIDs formatted in asset pointers?

GUIDs in asset pointers are 32 hexadecimal characters without hyphens, matching the format of the GUID as it appears in the target asset's GUID field. Hyphenated GUIDs (the UUID v4 canonical format) are not recognized by the parser and produce unresolved pointers. When generating a GUID for use in asset pointers, strip the hyphens before writing the value. The PowerShell GUID generation command [guid]::NewGuid().ToString("N") produces a hyphen-free 32-character hex string directly.

Best practices

• Generate a fresh GUID for every new asset using a collision-resistant method (UUID v4 generator, PowerShell [guid]::NewGuid().ToString("N")).
• Strip hyphens from GUIDs before writing them into .dat, .asset, or JSON files. The parser does not recognize hyphenated GUIDs.
• Use lowercase GUIDs in .dat files to match the vanilla convention. The parser is case-insensitive, but consistency with shipped files reduces confusion.
• Use the modern inline pointer style in .asset files for new mod content. The legacy explicit style is valid but verbose.
• Verify every pointer by loading the complete mod in single-player and testing the dependent feature before publishing.
• Maintain a documented GUID index for the mod project. A simple table mapping GUIDs to asset names and types prevents type-mismatched pointer resolution.
• Test pointer resolution with all dependent mods loaded. A pointer that resolves when the mod is tested in isolation may fail when the dependent mod is not present.
• Use asset pointers to reference assets within the same mod and across mods. The mechanism is the same; the only requirement is that both assets are loaded at resolution time.
• Document mod dependencies that involve cross-mod asset pointers in the Workshop description and the mod readme.
• When copying a .dat file as a template for a new asset, replace every GUID pointer field with the appropriate new target GUID. A template's GUIDs left in place produce resolved pointers to the wrong assets.

Advanced considerations

Pointer resolution and mod load order

The order in which the game enumerates mod folders determines the order in which assets are loaded into the asset table. If Mod A loads before Mod B and Mod A's pointer targets an asset in Mod B, the resolution may fail because the target asset has not yet been loaded when the pointer is resolved. The game does not perform a second resolution pass for initially unresolved pointers , the resolution is a one-pass operation at load time.

The load order is determined by the file system's enumeration order of the Bundles/ and Workshop folders. On Windows, this is typically alphabetical by folder name. Modders who need to guarantee that a dependency mod loads before a dependent mod can use alphabetical folder naming (e.g., _DependencyMod loads before DependentMod on most file systems). However, this is a fragile workaround; the recommended approach is to bundle all referenced assets within the dependent mod's own bundle so that load order is irrelevant.

Pointer resolution and dedicated server environments

On Unturned™ dedicated servers, mods are loaded server-side and the asset table is built from the server's loaded mod set. Client-side mods (mods loaded only by the client, such as UI mods) are not in the server's asset table. A pointer in a server-side asset that targets a client-side-only asset will not resolve. Conversely, a pointer in a client-side .dat or .asset file that targets a server-side asset will resolve only if both the server and the client have loaded the target asset.

For Workshop-published mods, this distinction is typically irrelevant because Workshop mods are loaded by both the server and each client. For private server mods distributed outside the Workshop, the distinction matters: the mod containing the pointer and the mod containing the target must both be loaded by the same game instance (server, client, or both) for the pointer to resolve.

Bulk pointer validation for large mods

For mods with many interconnected assets (map mods, quest-heavy NPC mods, large item packs), manually verifying every pointer by spawning every item is impractical. The cohort-recommended bulk-validation method is to write a small PowerShell or Python script that:

1. Enumerates every .dat and .asset file in the mod project.
2. Extracts every GUID that appears in a pointer field.
3. Extracts every GUID that appears as an asset's own GUID field (the identity GUID).
4. Reports any pointer GUID that does not appear in the set of identity GUIDs.

This is a syntactic validation only , it confirms that every GUID used in a pointer field exists as an identity GUID somewhere in the project. It does not confirm that the target GUID belongs to the correct asset type. Type validation requires the asset-type-specific reference articles and cannot be automated without a typed schema of every field in every asset type.

Asset pointers in the Unturned level editor

The Unturned™ level editor (the in-game map editor) uses asset pointers to reference the barricades, structures, items, NPCs, and effects placed on a map. When a map author places an object on a map, the editor records the placed object's GUID as an asset pointer in the map's data file. When the map is loaded by a player, the game resolves these pointers to instantiate the placed objects.

Map-level asset pointers follow the same resolution rules as any other asset pointer. If the map references an asset from a mod that the player has not loaded, the placed object does not appear. This is the most common cause of "missing objects" in Workshop maps , the map author placed objects from a mod that the subscribing player does not have installed. Map authors should document all required mods in the map's Workshop description.

Pointer resolution at scale

When a mod contains hundreds of assets that reference each other through asset pointers, the resolution process runs once per pointer at load time. The game does not optimize the resolution order , each pointer is resolved independently in the order the parser encounters it. For a mod with 500 items and 2000 pointer fields among them, the resolution process is typically completed in under one second on modern hardware and is not a performance concern.

The practical constraint is not resolution speed but resolution correctness: 2000 pointers mean 2000 opportunities for a typo in a GUID to produce an unresolved reference. The GUID index file recommended in Appendix D becomes essential for mods of this scale. A single mistyped hex digit in one GUID among 2000 pointer fields can take hours to locate by manual inspection of the in-game behavior alone.

Pointer forward-compatibility

The Unturned™ asset pointer system is backward-compatible across game versions. Asset pointer syntax has been stable since the asset pointer was introduced and has not changed across major Unturned™ updates. The GUID resolution mechanism is a core engine service and is unlikely to change in future versions. Mods that author asset pointers according to the syntaxes documented in this article will continue to work across future Unturned™ updates, subject to the usual caveats about asset-type field changes documented in the official SDG changelog.

Diagnostic table

Symptom	Most likely cause	Resolution
Gun has no magazine and cannot fire	Magazine pointer unresolved , target magazine missing or GUID mismatch	Verify the magazine GUID in the gun's .dat matches the magazine's GUID field exactly
Barricade cannot be placed	Item pointer unresolved , deploying item missing	Verify the item GUID in the barricade's .dat matches the item's GUID field
Quest not available in quest log	NPC pointer unresolved , quest-giver NPC not loaded	Verify the NPC GUID matches an NPC character asset that is loaded
NPC dialogue chain breaks mid-conversation	Responses_N.Guid pointer unresolved , next dialogue message missing	Check each dialogue message's response GUIDs against the dialogue asset files
Vendor does not sell expected items	Items_N.Guid pointer unresolved , target item missing	Verify each vendor listing GUID matches a loaded item asset
Spawn table entry produces no items	Assets_N.Guid pointer unresolved , target asset missing	Verify each spawn table entry GUID matches a loaded asset
Effect does not play	Effect reference pointer unresolved , target effect asset missing	Verify the effect reference GUID matches a loaded effect asset
Hyphenated GUID in pointer field	GUID not recognized by parser	Strip hyphens; use 32-character hex string
Case mismatch in GUID	Not a genuine error (parser is case-insensitive)	Use lowercase GUIDs for consistency with vanilla convention
Pointer resolves to wrong asset type	GUID collision with unrelated asset	Generate fresh GUIDs; maintain a project GUID index
Mod loads but all pointers are unresolved	Dependent mod not loaded	Load all dependent mods; restart game to re-resolve pointers

Appendix A: Asset pointer syntax quick-reference card

File format	Syntax	Example
.dat	FieldName GUID_STRING	Magazine a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d
.asset (modern inline)	"FieldName" "GUID_STRING"	"Magazine" "a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d"
.asset (legacy explicit)	"FieldName" { "GUID" "GUID_STRING" }	"Magazine" { "GUID" "a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d" }
JSON	"FieldName": { "GUID": "GUID_STRING" }	"Magazine": { "GUID": "a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d" }

Appendix B: External references

• Smartly Dressed Games modding documentation , the authoritative source for the asset pointer specification and resolution behavior.
• Unturned on Steam , game page and community hub.
• Master Bundle Pointer Type Reference , the next article in this section; covers the master bundle pointer type used to reference Unity assets.
• Project Folder Structure and GUIDs , GUID generation and the ID/GUID distinction in detail.
• Item Asset Anatomy , the shared field reference that documents the GUID field itself.
• Master Bundle Export , the Unity bundling workflow; master bundle pointers are the referencing mechanism for bundle contents.

Cross-references

• Rich Text Formatting Reference , the previous article in this section.
• Master Bundle Pointer Type Reference , the next article in this section; covers master bundle pointers.
• Item Asset Anatomy , the shared field reference for all item types.
• Project Folder Structure and GUIDs , GUID generation workflow.
• Master Bundle Export , Unity bundling pipeline.
• Smartly Dressed Games modding documentation , official field reference.
• Unturned on Steam , game page and community.

Appendix C: Pointer field discovery in shipped files

Identifying which fields in a given asset type's .dat or .asset file are pointer fields is a recurring task for modders inspecting shipped vanilla files or reverse-engineering existing mods. Pointer fields are not syntactically marked in the file format itself , the parser determines the field's type from the asset schema, not from the file content. The following heuristics help identify pointer fields when reading an unfamiliar asset file.

Heuristic 1: the value is a 32-character hex string

In .dat files, a field whose value is a 32-character hexadecimal string (0-9, a-f) with no hyphens, no quotes, and no whitespace is likely a pointer field or the asset's own GUID field. If the field name is GUID, the value is the asset's own identity. If the field name is anything else (Magazine, Item, NPC, Spawn, etc.), the value is almost certainly an asset pointer.

Heuristic 2: the field name suggests a reference

Fields with names that imply ownership or dependency , Magazine, Item, NPC, Vehicle, Spawn, Attachment, Effect, Quest, Dialogue , are typically pointer fields. Fields with names that imply a property of the asset itself , Damage, Range, Speed, Size_X, Rarity , are typically value fields, not pointers. The field name is the strongest single signal of whether a field is a pointer.

Heuristic 3: the .asset file contains a GUID sub-field

In .asset files, any field that contains a GUID sub-field or a MasterBundle/AssetPath sub-field pair is a pointer. The sub-field name tells the parser which pointer type it is handling: GUID signals an asset pointer; MasterBundle and AssetPath signal a master bundle pointer.

Heuristic 4: cross-reference against known asset types

If you have the target GUID, search the Bundles/ folder for a .dat file containing that GUID in its GUID field. The Type field in the found file tells you what kind of asset the pointer references. This cross-reference confirms that the field is indeed a pointer and identifies the target asset's type.

Heuristic 5: the official SDG documentation lists pointer fields

The Smartly Dressed Games modding documentation documents every field for every asset type, including which fields are pointer fields. When the official documentation is available for an asset type, it is the authoritative source for pointer field identification.

Appendix D: GUID collision avoidance strategies

Asset pointers depend on GUID uniqueness for correct resolution. A GUID collision , two assets with the same GUID , causes the second-loading asset to overwrite the first in the asset table, redirecting every pointer that previously resolved to the first asset. The following strategies prevent GUID collisions in mod projects.

Strategy 1: UUID v4 generation

Generate GUIDs using a UUID v4 generator, which produces 128-bit random values with a collision probability so low as to be negligible for any practical mod-development scale. The PowerShell command [guid]::NewGuid().ToString("N") produces a UUID v4 and strips the hyphens in a single operation.

Strategy 2: namespace GUIDs for mod series

For a mod series with many assets, prefix each GUID with a fixed segment derived from the mod's project namespace and vary only the remaining hex digits. This is not enforced by the engine but serves as a human-readable signal that two GUIDs belong to the same mod series, which aids debugging when inspecting pointer chains in a text editor.

Strategy 3: GUID index file

Maintain a plain-text index file in the mod project that maps every GUID to its asset name, type, and file path. The index is a manual authoring aid, not consumed by the game. When authoring a new pointer, the modder consults the index to confirm that the target GUID is correct. When copying a .dat file as a template for a new asset, the index reminds the modder to replace the GUID in every pointer field.

Strategy 4: avoid GUID reuse from template files

The single most common source of GUID collisions in mod projects is copying a .dat file as a template and forgetting to replace the GUID in pointer fields. The template's GUID field is replaced (giving the new asset its own identity), but the pointer fields that still carry the template's original GUIDs now reference the wrong assets. When copying a template, replace every GUID in the file , not just the GUID field , with the correct new value.

Appendix E: Cross-mod pointer dependency patterns

When one mod's assets reference assets from another mod via asset pointers, a cross-mod dependency exists. The dependent mod (the mod that contains the pointers) requires the dependency mod (the mod that contains the target assets) to be loaded for the pointers to resolve. Four dependency patterns recur across the Unturned™ Workshop ecosystem.

Pattern 1: item pack dependency

A weapon mod references attachment assets from a shared attachment pack mod. The weapon mod's .dat files contain asset pointers to the attachment pack's attachment GUIDs. If the attachment pack is not loaded, the weapon's attachment slots are empty. The weapon mod's Workshop description should state the dependency and link to the attachment pack.

Pattern 2: map-to-item dependency

A custom map mod spawns items from an item pack mod through spawn table entries that reference the item pack's item GUIDs. If the item pack is not loaded, the spawn entries are silently skipped and the items do not appear. The map mod's submission should list the item pack as a required dependency.

Pattern 3: NPC-to-dialogue dependency

An NPC character asset references dialogue message assets through pointer fields. The NPC must have every dialogue message in its chain loaded for conversations to progress correctly. An unresolved dialogue pointer causes the conversation to end abruptly at the broken link.

Pattern 4: quest-chain dependency

A quest chain uses pointer fields to reference the previous and next quests in the chain, the NPC giver, and any item rewards. A broken pointer anywhere in the chain makes the affected quest unavailable. Quest chains with complex branching should be tested by exercising every branch path in single-player before publishing.

Cross-mod dependency versioning

If the dependency mod is updated and the update changes the GUID of any asset that the dependent mod points to, every pointer to that asset in the dependent mod becomes unresolved. The dependent mod must be updated to carry the new GUID. This is the primary maintenance burden of cross-mod pointer dependencies and the reason many mod authors prefer to bundle all referenced assets within a single mod's master bundle rather than maintaining cross-mod dependency chains.

Document history

Version	Date	Author	Notes
1.0	2026-07-26	57 Studios	Initial publication. Complete asset pointer specification, per-format syntax reference, resolution behavior, worked examples, diagnostic table, pointer discovery heuristics, collision avoidance, cross-mod dependency patterns.