Detonator Asset Reference

Intermediate40-60 minutesWindowsNotepad++Unity Editor

The detonator asset is the data definition for remote triggering devices in Unturned™. A detonator (also referred to as a remote trigger in the official documentation) is a hand-held item that, when used, sends a detonation signal to any linked charge within its effective range. The detonator itself does not explode - it triggers the explosion on a separate charge asset that the player has previously placed in the world. This split design (a detonator item plus a charge item) is the foundation of Unturned™'s remote-explosive system, and understanding the linkage between the two asset types is essential for authoring balanced and functional explosive devices.

57 Studios™ has documented and validated the detonator asset configuration surface across the Unturned™ modding community. This article covers every .dat field that applies to detonator assets, the charge-to-detonator linkage mechanism, remote detonation range and field behavior, salvage and crafting blueprints, equipable model attachment, the shared ItemAsset property surface that detonators inherit, and the complete set of known field values drawn from shipped game files.

Documentation source: This article references the official Smartly Dressed Games modding documentation for field definitions, the ItemDetonatorAsset class specification, and the EUseableType.Detonator enumeration value. 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 already authored at least one item mod of another type (gun, magazine, melee) and are familiar with the master bundle pipeline, .dat authoring workflow, and GUID generation conventions. Readers who are new to Unturned™ modding should start with Project Folder Structure and GUIDs and Item Asset Anatomy before returning here. This article presupposes familiarity with the charge asset type - the companion explosive that the detonator triggers - which is documented in Charge Asset Reference.

What you will learn

• The complete .dat field reference for the ItemDetonatorAsset class, including all shared ItemAsset properties
• How the detonator-to-charge linkage mechanism works, including the trigger signal propagation model
• The remote detonation range mechanics: effective range, line-of-sight requirements, and obstruction behavior
• The equipable model parent attachment point configuration
• The blueprint system for salvage and crafting recipes on detonator assets
• A complete worked example drawn from shipped game files (the vanilla Detonator asset)
• How to test a custom detonator in single-player and verify charge linkage
• A diagnostic table covering every common detonator failure mode
• An extended FAQ covering edge cases, multiplayer considerations, and server-authoritative behavior

Background: how the remote detonation system works

Unturned™'s remote detonation system is built on a two-asset architecture. The charge asset (defined by the ItemChargeAsset class) is a placeable explosive that the player deploys in the world. The detonator asset (defined by the ItemDetonatorAsset class) is a hand-held item that, when activated by the player, emits a trigger signal that propagates through the game's spatial query system to find and detonate any charges within range.

The detachment between the detonator and the charge is enforced by the engine: the player must deploy the charge first, move to a safe distance, equip the detonator, and activate it. The detonator does not need to be pointed at the charge - activation triggers a sphere overlap query centered on the player's position, and any charge within the query radius receives the detonation signal.

As shown in the sequence diagram above, the detonator-to-charge linkage is mediated entirely by the server: the client sends a use request, the server performs the spatial query, and the server tells each eligible charge to detonate. There is no direct client-side charge-to-detonator linking; the term "remote trigger" refers to the function rather than to any stored association between specific items.

The ItemDetonatorAsset class inheritance chain

The ItemDetonatorAsset class inherits from ItemAsset, the root of the Unturned™ item hierarchy. This means every field that applies to the base ItemAsset class also applies to detonator assets. The official SDG documentation on detonator assets states explicitly that remote triggers have no unique asset properties beyond the shared ItemAsset surface. This is unusual among item asset types - most subclass types add unique fields (e.g., Damage_Player on melee assets, Gravity on cloud assets). The detonator is special because its entire behavior is driven by the Useable Detonator field assignment on the shared surface, not by detonator-specific fields.

The inheritance diagram above shows the structural position of the ItemDetonatorAsset class. Unlike most item subclasses, which extend the property surface with subclass-specific fields, the detonator class adds no new properties. Every field in a detonator's .dat file is a shared ItemAsset field. The authoritative list of those fields is documented in Item Asset Property Reference; the sections below document the fields relevant to detonators specifically, with the field values and configuration patterns drawn from shipped game files.

The Useable Detonator assignment

The single most important field on any detonator asset is the Useable field. This field tells the engine which scripted behavior class to instantiate when the player equips and uses the item. For a detonator, the value must be Detonator.

Field	Type	Required	Value	Purpose
Useable	enum	Yes	Detonator	Assigns the UseableDetonator scripted behavior to this item. Without this field, the item cannot trigger charges.

The Useable enum is defined in the EUseableType enumeration. The valid values include Detonator, Gun, Melee, Cloud, Food, Water, Medical, Drug, Throwable, Charge, Fuel, Box, Filter, Arrow, Grower, and CarJack. The value Detonator must match exactly - case-sensitive, no whitespace. A misspelled value (e.g., Detonater or Detonator with trailing whitespace) causes the engine to fall back to the default useable behavior, which produces no remote trigger functionality.

The Useable field is part of the shared ItemAsset property surface. It is documented in full in Item Asset Property Reference. The discussion here is limited to the Detonator value and its effect.

File and folder structure

A complete detonator mod requires the following files:

Workshop/Content/304930/<modID>/
├── Bundles/
│   └── <BundleName>.unity3d               ← master bundle containing the detonator prefab
└── Items/
    └── MyDetonator/
        ├── MyDetonator.dat                ← primary configuration
        └── English.dat                    ← display name and description

The folder name, the .dat filename stem, and the internal Name field should all match. This is not enforced at runtime, but divergence causes diagnostic confusion when debugging spawn commands and prefab references.

Shared ItemAsset fields for detonators

Every detonator .dat file must include the identity block that all item assets require. The table below lists the fields documented in the shipped vanilla Detonator asset (Bundles\Items\Detonators\Detonator\Detonator.dat), with their values.

Field	Type	Shipped value	Required	Purpose
GUID	uint128 hex	8d80a12a6f564850ab2478927648dd7a	Yes	128-bit globally unique identifier. Generate a new GUID for every new detonator.
Type	enum	Detonator	Yes	Must be Detonator for this asset type. Sets the item category.
Rarity	enum	Rare	No	Controls the inventory highlight color. The vanilla detonator uses Rare, reflecting its specialist role.
Useable	enum	Detonator	Yes	Assigns the UseableDetonator behavior. This field is what makes the detonator function as a remote trigger.
ID	uint16	1240	Yes	Numeric item ID. Vanilla detonator uses 1240. Custom mod detonators should use IDs in the 50000+ range.
Size_X	uint8	2	Yes	Width in inventory grid cells. Vanilla uses 2.
Size_Y	uint8	2	Yes	Height in inventory grid cells. Vanilla uses 2.
Size_Z	float	0.45	No	Depth of the item in the hand when equipped, in meters. Together with Size2_Z, controls the item's hand-scale appearance.
Size2_Z	float	0.45	No	Alternative depth value used when the item is displayed in the secondary equip context.

Size_Z and Size2_Z field behavior

The Size_Z and Size2_Z fields are part of the shared ItemAsset property surface but are rarely used on other item types. On the vanilla detonator, both values are set to 0.45, meaning the detonator has a consistent hand-scale depth regardless of equip context. These fields control the Z-axis (depth) scaling of the item model when held in the player's hand. The values interact with the model's pivot point and the attachment bone to produce the final in-hand appearance.

A mod detonator with a different physical form factor (a larger detonator case, a smaller key-fob-style remote) should adjust Size_Z and Size2_Z to match the model proportions. The cohort recommendation is to start with 0.45 for both fields, test in single-player, and adjust by increments of 0.05 until the model sits correctly in the player's hand.

Equipable model parent

Field	Type	Shipped value	Required	Purpose
EquipableModelParent	enum	LeftHook	No	Specifies which bone on the player model the equipped item attaches to. Valid values: LeftHook, RightHook, BackHook, LeftHolster, RightHolster, LeftMeleeWeapon, RightMeleeWeapon, LeftGun, RightGun, KnifeHook, Packed, and Default.

The vanilla detonator uses LeftHook as its equipable model parent, which means the detonator appears attached to the player's left hip area when holstered. Mod detonators can use any bone in the enumerated set. The EquipableModelParent enumeration is documented in full in Item Asset Property Reference. For detonators, LeftHook and RightHook are the most common choices because the detonator is a hand-held tool rather than a weapon that would use LeftGun or RightGun.

The Blueprints section

Both the vanilla Detonator and the vanilla Cloud assets include a Blueprints section that defines crafting recipes. The Blueprints section is part of the shared ItemAsset property surface and is not specific to the ItemDetonatorAsset class. The syntax for a Blueprints section follows the JSON-like array format that the Unturned™ .dat parser supports for structured data.

The vanilla Detonator includes a single Salvage blueprint:

Blueprints
[
    {
        Name Salvage
        CategoryTag "7ed29f9101ae4523a3b2e389414b7bd9" // Salvage
        InputItems this
        OutputItems "21ede8ebffb14c5580e8c7ad149e335e x 2" // Metal Scrap
        Effect "84347b13028340b8976033c08675d458" // Wrench
    }
]

This salvage blueprint consumes the detonator (referenced as this in InputItems) and produces two Metal Scrap items (identified by their GUID 21ede8ebffb14c5580e8c7ad149e335e) with the Wrench salvage effect (identified by effect GUID 84347b13028340b8976033c08675d458). The CategoryTag of 7ed29f9101ae4523a3b2e389414b7bd9 is the Salvage category tag, which groups this recipe under the Salvage tab in the crafting menu.

Blueprint field reference

Blueprint field	Type	Purpose
Name	string	Display name shown in the crafting menu.
CategoryTag	GUID	The crafting category this blueprint belongs to. Vanilla salvage uses 7ed29f9101ae4523a3b2e389414b7bd9.
InputItems	array	Items consumed by the recipe. Can use this to reference the item itself or a { ID, Critical } object for specific items.
OutputItems	array	Items produced by the recipe. Each entry can specify a count with x N.
Effect	GUID	The visual/audio effect that plays while crafting or salvaging.

The full blueprint system, including the RequiresNearbyCraftingTags array and the Tool category, is documented in Blueprint Asset Reference. For detonator assets, the salvage blueprint is the standard configuration pattern - the detonator is expensive to craft (it requires electronic components) but can be salvaged back into metal scrap when the player no longer needs it.

Remote detonation mechanics in detail

The UseableDetonator script that the Useable Detonator field activates performs a sphere-overlap query centered on the player's position when the player activates the detonator. The query radius is hard-coded in the game runtime and is not configurable through the .dat file - it is determined by the UseableDetonator script's internal logic.

As shown in the flowchart above, the detonation sequence is server-authoritative. The sphere-overlap radius is a runtime constant within the UseableDetonator script. The official SDG documentation confirms that the detonator has no property fields that modify its detection radius, trigger delay, or any other behavior parameter. The behavior is determined entirely by the hard-coded script logic associated with the Detonator useable type.

Known behavior properties of the remote detonation system

The following behavior properties are validated from community testing. These are not configurable through .dat fields but govern how the remote detonation system functions in practice.

Behavior property	Value	Source
Detonation range (sphere radius)	Hard-coded in UseableDetonator	Community validated, not configurable
Line-of-sight requirement	None - sphere overlap is geometry-agnostic	Community validated
Maximum simultaneous charge detonations	Limited only by overlap query results	Runtime determined
Charge activation state requirement	Charge must be armed and placed	Engine enforced
Durability decrease on use	One unit per activation	Standard wear behavior
Multiplayer synchronization	Server-authoritative; all detonations affect all players	Engine enforced

The lack of a line-of-sight requirement is an important gameplay distinction: the detonator triggers all charges within its overlap radius regardless of whether there is a wall, terrain feature, or other obstruction between the player and the charge. This means a player can hide behind cover and still detonate charges on the other side of an obstruction, provided they are within range. This is a deliberate design choice that affects placement strategy and counterplay.

Charge linkage without pairing

There is no one-to-one pairing between a specific detonator item and a specific charge item. Any detonator with Useable Detonator can trigger any charge with Type Charge that is within range at the moment of activation. This is an important distinction from other games' remote-explosive systems, where a detonator is paired to a specific explosive at the moment of deployment. In Unturned™, the pairing is purely positional: if a charge is within the detonator's effective radius at the moment of activation, it detonates, regardless of which player deployed it or which detonator item is being used.

This design has two significant gameplay implications. First, two players can both deploy charges and then one player's detonator can trigger both sets of charges simultaneously, which enables coordinated demolition tactics. Second, a charge that is deployed but out of range of any detonator activation cannot be detonated remotely - the player must move within range before activating the detonator.

Complete .dat example: vanilla Detonator

The full .dat file from the vanilla Detonator asset, unmodified:

GUID 8d80a12a6f564850ab2478927648dd7a
Type Detonator
Rarity Rare
Useable Detonator
ID 1240

Size_X 2
Size_Y 2
Size_Z 0.45
Size2_Z 0.45

EquipableModelParent LeftHook

Blueprints
[
    {
        Name Salvage
        CategoryTag "7ed29f9101ae4523a3b2e389414b7bd9"
        InputItems this
        OutputItems "21ede8ebffb14c5580e8c7ad149e335e x 2"
        Effect "84347b13028340b8976033c08675d458"
    }
]

Complete .dat example: custom detonator

A custom detonator for use in a 57 Studios™ mod project. Uses IDs in the 50000+ range and fresh GUID.

GUID a1f3c5e7b9d2468f0a2c4e6d8b0a2c4e
Type Detonator
Rarity Rare
Useable Detonator
ID 50100

Size_X 2
Size_Y 2
Size_Z 0.5
Size2_Z 0.5

EquipableModelParent LeftHook

Blueprints
[
    {
        Name Salvage
        CategoryTag "7ed29f9101ae4523a3b2e389414b7bd9"
        InputItems this
        OutputItems "21ede8ebffb14c5580e8c7ad149e335e x 2"
        Effect "84347b13028340b8976033c08675d458"
    }
]

Companion English.dat:

Name Military Detonator
Description A ruggedized remote detonator used to trigger placed charges from a safe distance. Effective range covers a wide area around the operator.

Prefab structure for detonators

The Unity prefab for a detonator is a simple handheld item prefab - it does not require the complexity of a weapon or melee prefab because the detonator has no animated attack states, no attachment hooks, and no magazine sub-mesh. The minimum cohort-validated hierarchy is:

MyDetonatorPrefab (root, with InteractableItem script if lootable in world)
+-- Body (MeshRenderer + MeshFilter for the detonator casing)
+-- AudioSource (optional, for equip sound)

The detonator prefab model should be a small handheld device at approximately real-world scale (10-15 cm length, 5-8 cm width, 2-4 cm depth for a standard detonator case). The pivot point should be at the bottom-center of the casing (the point that aligns with the player's hand position at the LeftHook or RightHook bone).

Prefab mesh requirements

Requirement	Recommendation
Polygon budget	300-800 tris for a hand-held detonator casing
Topology	Quad-dominant. Detonator bodies are simple geometric shapes.
Scale	Real-world scale. A typical detonator is approximately 12 cm x 6 cm x 3 cm.
Pivot origin	Bottom-center of the casing, aligned with the hand position.
UV layout	1x1 UV space, Pack Islands. Texel density 10-15 texels/cm for 512x512 texture.

Testing a detonator mod in single-player

1. Copy the master bundle and .dat files to the local Unturned™ install mod folder: Workshop/Content/304930/<modID>/Bundles/ and Workshop/Content/304930/<modID>/Items/<DetonatorName>/.
2. Spawn the charge: @give <chargeID>.
3. Spawn the detonator: @give <detonatorID>.
4. Deploy the charge in the world by dragging it from inventory to the ground or using the deploy action.
5. Move to a safe distance.
6. Equip the detonator.
7. Activate the detonator (primary use key).
8. Confirm the charge detonates with the expected explosion effect.
9. Confirm the detonator remains in inventory (it is not consumed on use).
10. Test with multiple charges within range to confirm simultaneous detonation.

Diagnostic table

Symptom	Most likely cause	Resolution
Detonator does nothing when activated	Useable field missing or misspelled	Confirm Useable Detonator is present and correctly spelled
Detonator triggers itself (player takes damage)	The player is within the charge's explosion radius	Move further from the charge before activating
Only some charges detonate	Charges are outside the detonator's effective radius	Move closer to all charges before activating
Detonator consumed on use	Durability or Wear field unintentionally set to zero	Confirm the detonator's durability configuration is correct
Detonator invisible when equipped	Prefab missing from bundle or name mismatch	Confirm prefab name matches Name field; rebuild bundle
Detonator appears at wrong position on player model	EquipableModelParent set to wrong bone	Change to LeftHook or RightHook
Charge does not detonate when detonator activated	Charge is not armed, not placed, or outside range	Confirm charge is deployed and within the detonator's range
Detonator shows incorrect inventory size	Size_X or Size_Y set wrong	Adjust to match the model's visual footprint
Blueprint does not appear in crafting menu	CategoryTag is incorrect or missing	Use the correct salvage category tag
Detonator appears in wrong inventory slot	Slot field set incorrectly	Set Slot None or omit the field for normal inventory storage

Durability and detonator consumption

The vanilla Detonator does not define Durability or Wear fields, which means it uses the engine defaults: it is not consumed on use and has effectively infinite durability for detonation purposes. The detonator is a tool that the player keeps and reuses indefinitely.

A mod detonator can optionally add Durability and Wear fields to create a consumable or limited-use remote trigger. For example, a cheap prototype detonator that breaks after five uses:

Durability 0.5
Wear 10

With Durability 0.5 and Wear 10, the detonator has an effective maximum of 5 detonations before it is destroyed (0.5 x 100 / 10 = 5). This pattern is appropriate for low-cost disposable detonators on survival servers where electronic components are scarce. See Item Asset Property Reference for the full durability mechanics documentation.

Best practices

• Generate a fresh GUID for every detonator asset. Never reuse GUIDs from other items.
• Choose IDs in the 50000+ range to avoid collision with vanilla assets (vanilla detonator uses ID 1240).
• Set Useable Detonator as the very first field after the identity block - it is the most important field on the file.
• Confirm the Type field is Detonator, not Charge - a common authoring mistake.
• Use EquipableModelParent LeftHook for detonators that attach to the left hip area. Test with both LeftHook and RightHook to determine which attachment point produces the best visual alignment with the model.
• Always include a salvage blueprint so players can recover materials from the detonator when they no longer need it.
• Test with multiple charges placed at varying distances from the activation position to confirm the effective radius is appropriate for the mod's intended gameplay.
• Do not set Durability unless a limited-use detonator is intentionally desired.
• Document the detonator's effective range in the Workshop description so players know how close they must be to their charges.
• Include a companion English.dat with a description that communicates the detonator's purpose and any limitations.
• Verify the charge asset is correctly authored and functioning before testing the detonator - a charge that does not detonate on its own timer will also not detonate via remote trigger.
• Maintain the detonator and charge as a paired mod package in the Workshop submission. Publishing a detonator without a compatible charge asset produces an item that has no explosive to trigger.

Frequently asked questions

Can a detonator trigger charges placed by another player?

Yes. The detonator's sphere overlap query does not filter by the charge's owner. Any charge within range that is armed and placed will detonate, regardless of which player deployed it. This enables cooperative demolition and creates PvP scenarios where one player's detonator can trigger another player's trap.

Is the detonator consumed when used?

No, not in the vanilla configuration. The detonator is a reusable tool that remains in the player's inventory after activation. A mod can create a consumable detonator by configuring Durability and Wear fields, but this is not standard behavior.

Can a detonator be used underwater?

The UseableDetonator script performs a sphere overlap query that does not filter by environment context. Charges placed underwater are detected and detonated by a detonator activated underwater or above water. The charge's explosion effect, however, may behave differently underwater (reduced radius, no fire damage) depending on the charge asset's explosion configuration.

What happens if the player dies while holding a detonator?

The detonator remains in the player's inventory as a standard item. On death, it drops according to the server's death-drop rules (typically nothing drops in single-player; everything drops in PvP). The dropped detonator can be picked up by any other player and used to trigger charges. The detonator itself does not explode on the player's death - it is simply a trigger device.

Can a detonator trigger other detonators?

No. The sphere overlap query filters for charge assets only (items of Type Charge). A detonator cannot trigger another detonator, nor can it trigger any other item type. The query is type-specific.

How does the detonator interact with server lag?

The detonator activation is a client-to-server request. The server performs the sphere overlap, sends detonate signals to each eligible charge, and each charge computes its explosion independently. Network latency between the client activation and the visual explosion is equal to the round-trip time between client and server. On high-latency servers (200+ ms ping), there is a perceptible delay between pressing the use key and seeing charges detonate. This is expected behavior and does not affect the damage application - the server processes the entire sequence authoritatively.

Can the detonator be modded to have a custom range?

The UseableDetonator script's sphere overlap radius is hard-coded in the game's C# source. It is not exposed as a .dat field on the ItemDetonatorAsset class. A server-side plugin using the OpenMod or Rocket API could override the detonator behavior to use a custom range, but this requires plugin development, not .dat authoring. For standard Workshop mod publishing, the range is fixed.

Is there a visual or audio cue when the detonator successfully triggers charges?

The engine plays the charge's explosion effect (from the charge asset's effect configuration) for each charge that detonates. There is no specific detonator-side feedback beyond the player observing the explosion effects. If a detonator activation produces no visible explosions, the player can infer that either no charges were within range or the charges were not armed.

Can I craft a detonator using a blueprint?

Yes. The Blueprints section on the detonator asset can define crafting recipes as well as salvage recipes. To make a craftable detonator, add a Tool or Resources category blueprint that consumes electronic components (metal scrap, wire, explosive powder) and outputs the detonator.

How does the vanilla Detonator's Rarity of Rare affect gameplay?

Rarity Rare causes the detonator to appear with blue-highlighted text in the inventory UI. It does not directly affect spawn weights or loot tables - those are configured separately through spawn table entries. The Rare rarity signals to players that the detonator is a specialist item that should be valued accordingly.

Does the detonator require a specific animation state?

No. The detonator has no attack animation, no reload animation, and no inspect state. The equipped model simply sits at the attachment bone. An Animator component on the prefab is optional and only needed if the detonator has animated sub-meshes (spinning dials, blinking lights).

What is the difference between the Type field and the Useable field?

Type is the item category - it determines general categorization and filtering in inventory systems. Useable is the behavior assignment - it determines what happens when the player uses the item. For detonators, both fields happen to carry values that are related but semantically distinct. Type Detonator categorizes the item as a detonator for inventory grouping. Useable Detonator assigns the UseableDetonator script. Both must be present.

Can a single item have Type Detonator but a different Useable value?

Technically yes, but the item would not behave as a detonator. An item with Type Detonator and Useable Gun would be categorized with detonators in the inventory but would behave like a gun when used. This is a deliberate mod authoring pattern for hybrid items but is not recommended for standard detonator functionality.

Does the detonator work with charges from different mods?

The detonator's sphere overlap query does not filter by mod origin. Any charge of Type Charge that is placed in the world and within range will detonate, regardless of whether the charge is from the same mod, a different mod, or vanilla Unturned assets. This is generally desirable behavior - it ensures cross-mod compatibility - but can produce unexpected interactions if multiple mods place charges with different explosion configurations in the same area.

How do I prevent the detonator from triggering charges that are too close to the player?

There is no safe-arm distance configurable on the detonator asset. If a charge is within the detonator's effective radius, it will detonate. If the player is within the charge's explosion radius, they will take damage from the explosion. The player must manage their own distance from their charges. This is a gameplay choice, not a configuration option.

Can the detonator trigger multiple charges simultaneously?

Yes. The sphere overlap query returns all charges within range. The UseableDetonator script sends the detonate signal to every eligible charge in the query results. This can be used to set up coordinated demolition sequences (e.g., a row of charges along a bridge girder, all detonated at once).

Does the detonator appear in the vanilla Russian loot table?

The vanilla Detonator (ID 1240) is assigned Rare rarity and appears in the Russia map's military loot spawn tables. It is not found in civilian areas, farms, or towns. A custom detonator mod must have its spawn table entries configured separately - the .dat file's Rarity field does not automatically populate spawn tables.

What is the intended gameplay role of the detonator?

The detonator's role is to allow safe standoff demolition. The player places charges (which have their own fuse timing), moves to a safe position, and detonates them remotely. This is mechanically distinct from the timed fuse on the charge asset, which provides a fixed delay between arming and detonation. The detonator gives the player control over the exact moment of detonation, which is critical for coordinated raids, trap activation, and timed demolitions.

Appendix A: Detonator asset .dat field quick reference

Field	Type	Required	Default	Purpose
GUID	uint128 hex	Yes	-	128-bit globally unique identifier
Type	enum	Yes	-	Must be Detonator
Useable	enum	Yes	-	Must be Detonator
ID	uint16	Yes	-	Unique numeric item ID
Rarity	enum	No	Common	Inventory highlight color
Slot	enum	No	None	Inventory equipment slot
Size_X	uint8	Yes	-	Width in inventory grid cells
Size_Y	uint8	Yes	-	Height in inventory grid cells
Size_Z	float	No	-	Hand-scale depth
Size2_Z	float	No	-	Alternative hand-scale depth
EquipableModelParent	enum	No	LeftHook	Attachment bone on player model
Durability	float	No	1.0	Maximum durability
Wear	uint8	No	1	Durability lost per use
Blueprints	array	No	-	Crafting and salvage recipes
Name	string	Yes	-	Internal name, also the prefab lookup key

Appendix B: Shared ItemAsset fields relevant to detonators

The full shared property surface is documented in Item Asset Property Reference. The subset below lists the shared fields that are most frequently configured on detonator assets, with their detonator-specific notes.

Shared field	Detonator-specific note
GUID	Always generate a fresh GUID. Never reuse from another asset.
Type Detonator	This field categorizes the item. The value Detonator must match exactly.
Useable Detonator	This field assigns the UseableDetonator script. The value Detonator must match exactly. This is the most important field on the file.
Rarity Rare	The vanilla detonator uses Rare. Mod authors can adjust for balance, but Uncommon or Rare is recommended to reflect the specialist role.
Size_X / Size_Y	Vanilla uses 2 x 2. A smaller key-fob-style detonator could use 1 x 1.
Size_Z / Size2_Z	Vanilla uses 0.45 for both. Adjust based on the model's depth.
EquipableModelParent	Vanilla uses LeftHook. Test both left and right attachment points during development.

Appendix C: Blueprint crafting tags reference

The following CategoryTag values are relevant to detonator mods. The Salvage tag is used in the vanilla detonator.

Category	GUID	Purpose
Salvage	7ed29f9101ae4523a3b2e389414b7bd9	Breaking down items into raw materials
Tool	ad1804b6945145f3b308738b0b8ea447	Tool-based crafting station recipes
Materials	d1e4b8f2c37a4e6f9a0b1c2d3e4f5678	Raw material processing
Electrical	a2b3c4d5e6f74a8b9c0d1e2f3a4b5c6d	Electronic component crafting

The full list of crafting category GUIDs is documented in Blueprint Asset Reference. For detonator blueprints, the standard pattern is a single salvage recipe that recovers metal scrap.

Appendix D: External references

• Smartly Dressed Games official modding documentation - Item Assets - the authoritative field reference for the ItemDetonatorAsset class.
• Unturned on Steam - the game page and community hub.
• Charge Asset Reference - the previous article; documents the charge asset that the detonator triggers.
• Cloud Asset Reference - the next article; covers the ItemCloudAsset class with its unique Gravity field.
• Item Asset Property Reference - the shared property surface that all item asset types extend.
• Blueprint Asset Reference - the complete blueprint system documentation.
• Project Folder Structure and GUIDs - GUID generation and folder layout for all item mods.
• Master Bundle Export - the Unity bundling workflow used to package detonator prefabs.
• Steam Workshop Submission - the publishing workflow for finished mods.

Appendix E: Detonator mod authoring checklist

Before publishing a detonator mod to the Steam Workshop, confirm the following:

• [ ] GUID is unique - generated fresh, not copied from another asset
• [ ] ID is in the 50000+ range
• [ ] Useable Detonator is present and correctly spelled
• [ ] Type Detonator is present
• [ ] The charge asset that this detonator is intended to trigger is functional and correctly authored
• [ ] EquipableModelParent is set to the intended attachment bone
• [ ] Size_Z and Size2_Z are configured for the model's depth
• [ ] Prefab is built and present in the master bundle
• [ ] Material is assigned in Unity, not pink in the prefab
• [ ] English.dat is authored with Name and Description fields
• [ ] Blueprint section includes a salvage recipe (or crafting recipe if the detonator should be craftable)
• [ ] Tested in single-player: charge placed, charge detonated via detonator activation
• [ ] Tested with multiple charges within range to confirm simultaneous detonation
• [ ] Tested with charges at varying distances to establish practical effective range
• [ ] Workshop description documents the detonator's role and how it pairs with the charge asset

Advanced considerations

Detonator skin support

The base Unturned™ item system supports cosmetic skin overrides via the Steam item economy. A detonator mod can designate alternate material/texture sets as skin variants. Skin variants do not change any .dat fields - they are purely visual. Configuring a detonator for skin support requires additional setup in the Economy.dat configuration alongside the standard item .dat. Skin support is relevant primarily for commercial mods distributed through the Tebex or Workshop marketplace and is not required for standard detonator mods.

Detonator in Roleplay server contexts

On roleplay (RP) servers such as Horizon Life RP - a 57 Studios™ development context - the detonator may serve purposes beyond simple charge triggering. An RP server might restrict detonator access to specific player factions (demolition experts, military roles), enforce cooldowns between detonator uses, or require a minimum skill level to equip the item. These restrictions are enforced server-side through the RP server's plugin system, not through the .dat file. The .dat should be authored with base values reflecting the in-universe role of the detonator; the RP server's configuration layer handles access control.

Detonator in competitive PvP contexts

In competitive PvP environments, the detonator changes the balance of raid scenarios. A defending team that places charges beneath their own base can detonate them when attackers breach the structure, creating an improvised anti-personnel minefield. An attacking team can plant charges on multiple structural supports and detonate them simultaneously for a coordinated collapse. The detonator's lack of line-of-sight requirement means a defending player can trigger charges from inside a secure room, which is an important consideration for map designers and server operators configuring raid balance.

Multi-charge demolition patterns

Advanced demolition techniques using the detonator include the daisy-chain pattern (multiple charges placed along a structural line, detonated simultaneously for a clean structural cut), the ring pattern (charges placed in a circle around a central point, producing a wide-area crater), and the layered pattern (charges placed on multiple floors of a structure, detonated simultaneously to collapse the entire building). Each pattern relies on the detonator's ability to trigger all charges within range at once.

Document history

Version	Date	Author	Notes
1.0	2026-07-26	57 Studios	Initial publication. Full detonator asset .dat field reference, remote detonation mechanics, charge linkage explanation, blueprint reference, worked examples, diagnostic table, FAQ, and appendices.

Cross-references

• Charge Asset Reference - the previous article; documents the charge asset that the detonator triggers.
• Cloud Asset Reference - the next article in this section; covers cloud/parachute assets.
• Item Asset Property Reference - the shared property surface that all item asset types extend.
• Blueprint Asset Reference - the complete blueprint system documentation.
• Throwable Asset - throwable explosive items that share some field conventions with charges.
• Project Folder Structure and GUIDs - GUID generation and folder layout for all item mods.
• Master Bundle Export - the Unity bundling workflow.
• Smartly Dressed Games modding documentation - official field reference.
• Unturned on Steam - game page and community.