Arrest Start Asset Reference

Intermediate40-60 minutesWindowsNotepad++Unity Editor

The arrest start asset, also referred to as a "catcher" item, is the mechanical foundation for every restraint system in Unturned™. An arrest start asset defines an item that a player can apply to another player (or, in specific server configurations, to a captured NPC entity) to restrict the target's movement, weapon access, and inventory interaction. Vanilla examples include the Handcuffs and the Cable Tie. The arrest start asset is the entry point of a two-item restraint system; the matching arrest end asset (the "releaser") removes the restraint and restores the affected player to full mobility.

This article is the 57 Studios™ canonical reference for the arrest start asset subtype. It covers the .dat fields that define a catcher item, the runtime mechanic by which restraints are applied and broken, the pairing mechanism that links a catcher to its corresponding releaser, and the full configuration surface inherited from the ItemAsset parent class. The field set for an arrest start asset is among the smallest in the Unturned™ item system, with only one class-specific field (Strength) beyond the inherited identity, inventory, and blueprint fields. That small surface should not be mistaken for simplicity; the pairing logic between catcher and releaser items, the breaking-free mechanic, and the server-side plugin interactions with the arrest system all require careful attention from the mod author.

Documentation source: This article references the official Smartly Dressed Games modding documentation for field definitions and game behavior. Community-validated notes are marked where the official documentation is silent on a detail. The vanilla game files cited throughout this article were read from the Unturned™ installation at Bundles/Items/Arrest_Starts/.

Who this article is for

This article is written for Unturned™ mod authors who have already completed at least one item mod of another type (melee, throwable, or consumable) and are familiar with the master bundle pipeline and .dat authoring workflow. If you are new to Unturned™ modding, start with Project Folder Structure and GUIDs, Item Asset Anatomy, and Data File Format Reference before returning here. A working understanding of the ItemAsset inherited fields (ID, GUID, Type, Useable, Rarity, Slot, Size_X, Size_Y) is assumed throughout this article.

How the arrest mechanic works

The arrest system involves three distinct phases: application, restraint, and resolution. Each phase is governed by different engine systems and involves different participants.

Phase 1: Application

When a player (the "arrestor") targets another player (the "target") and activates an arrest start item (typically through the context menu or a dedicated server-side interaction key), the engine checks whether the target is eligible for restraint. The eligibility criteria are server-configurable but include, as a minimum, that the target is alive, is not already restrained by a catcher item, and is within the interaction range of the arrestor. If all criteria are met, the slot that the arrest start item occupies is cleared of that item (one unit of the catcher item is consumed), and the target receives the restraint status effect.

The application phase is instant. There is no build-up time, no channeled cast, and no check against the target's consent beyond the server's restraint eligibility rules. A successful application consumes one unit of the catcher item from the arrestor's inventory regardless of whether the target subsequently breaks free.

Phase 2: Restraint

While restrained, the target player experiences a set of documented restrictions. The restricted player cannot sprint, cannot equip weapons from the inventory, cannot interact with the inventory in any meaningful capacity, and moves at a reduced walk speed. The restricted player can still look around, communicate through voice and text chat (subject to server configuration), and attempt to break free. The restricted player can also be moved by other players - a restrained player can be dragged or pushed, which is the mechanic behind player arrest and transport in roleplay server contexts.

Phase 3: Resolution

A restraint is resolved through one of three mechanisms. The first mechanism is the breaking-free action: the restrained player presses the interact key (default E) repeatedly. Each press triggers a lean animation and decrements an internal counter initialized from the arrest start asset's Strength field. When the counter reaches zero, the restraint is removed and the player is free. The second mechanism is the application of a matching arrest end item (a releaser such as the Handcuffs Key) by any player, which removes the restraint instantly without requiring the break-free counter to reach zero. The third mechanism is the restrained player's death, which clears all status effects including active restraints.

As shown in the state diagram above, the restraint cycle has two exit paths that do not require the break-free counter to complete: a releaser item applied by any player, and the restrained player's death. Mod authors designing restraint systems for roleplay servers should account for both non-counter exit paths and should not rely on the Strength field alone as the sole mechanism for restraint resolution.

File and folder structure

A complete arrest start mod requires the following files:

Workshop/Content/304930/<modID>/
├── Bundles/
│   └── <BundleName>.unity3d              ← master bundle containing the prefab
└── Items/
    └── MyArrestStartItem/
        ├── MyArrestStartItem.dat          ← arrest start asset 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 multiple arrest start items are loaded concurrently.

Complete .dat field reference

Identity and inherited fields

Every item in Unturned™ requires an identity block. These fields identify the item to the engine and to other mod files that reference it. The table below lists the inherited fields that are required or commonly configured on arrest start assets. The authoritative reference for these shared fields is Item Asset Anatomy; the table below documents the specific values and conventions that apply to the arrest start subtype.

Field	Type	Required	Example	Purpose
GUID	uint128 hex	Yes	a02639d65d79438281af15f22b7632f9	128-bit globally unique identifier. Generate a fresh GUID for every new arrest start item. Never reuse GUIDs.
ID	uint16	Yes	1195	Numeric item ID. Must be unique across all loaded mods. Use IDs in the 50000+ range to avoid collision with vanilla and established community mods.
Type	enum	Yes	Arrest_Start	Must be Arrest_Start for catcher items.
Useable	enum	Yes	Arrest_Start	Must be Arrest_Start for catcher items.
Rarity	enum	No	Uncommon	Controls the inventory highlight color. Vanilla handcuffs use Uncommon; cable ties have no rarity line (defaults to Common).
Size_X	uint8	Yes	1	Width in inventory grid cells. Both handcuffs and cable ties use 1.
Size_Y	uint8	Yes	1	Height in inventory grid cells. Both handcuffs and cable ties use 1.
Size_Z	float	No	0.25	Unity world-space z-dimension for the dropped item model. Not related to inventory grid size.

Class-specific fields

The arrest start asset has exactly one class-specific field beyond the inherited ItemAsset set.

Field	Type	Required	Default	Example	Purpose
Strength	uint16	No	0	128	The number of lean cycles (interact key presses) the restrained player must complete to break free. Higher values mean longer restraint duration. A value of 0 means the restraint can be broken instantly on the first interact press.

Blueprint fields

The blueprint block configures crafting recipes for the item. The following fields are used within the Blueprints array. Blueprint configuration is optional for items that are distributed through loot tables rather than crafted.

Field	Type	Required	Purpose
Name	string	No	Display name for the blueprint category (e.g., Salvage for disassembly recipes).
CategoryTag	GUID	Conditional	The crafting category GUID. Required for craftable items. The value identifies the tab under which the blueprint appears in the crafting menu.
InputItems	GUID or GUID array	Conditional	One or more items consumed by the recipe. A single GUID references one unit; a GUID followed by x N references N units (e.g., "ebb61f2e64f24351a6ab905b5516060b x 2"). When a salvage recipe, the keyword this means the item being salvaged is consumed as the input.
OutputItems	GUID or GUID array	Conditional	One or more items produced by the recipe. The keyword this means the recipe produces the arrest start item itself.
Skill	enum	Conditional	The skill category required for the recipe (Craft, Cooking, etc.).
Skill_Level	uint8	Conditional	The minimum skill level required.
RequiresNearbyCraftingTags	GUID array	No	One or more crafting station tags required to be nearby for the recipe to be available.
Effect	GUID	No	The sound or visual effect played when the recipe is completed.

Arrest start asset classes: handcuffs versus cable tie

The vanilla game ships two arrest start items, each with different Strength values and different crafting availability. The comparison table below documents the differences.

Property	Handcuffs Lock	Cable Tie
ID	1195	1197
Strength	128	64
Rarity	Uncommon	(omitted, defaults to Common)
Craftable	No direct recipe (salvage only)	Yes (wire + tape)
Break-free leans	128	64
Gameplay role	Standard law-enforcement restraint	Improvised field restraint

The Handcuffs Lock requires approximately twice the break-free effort of the Cable Tie, which is consistent with the mechanical advantage of a locking handcuff over a zip-tie-style restraint. The Cable Tie is craftable from common materials (wire and tape), making it a field-expedient restraint that a player can produce without access to a dedicated law-enforcement supply. The Handcuffs Lock is findable only through loot (it has no direct crafting recipe) and is correspondingly rarer and more effective.

When to use each class

The cohort recommendation for mod authors is to maintain the same distinction in custom arrest start items. A high-quality, law-enforcement-grade restraint (locking handcuffs, dedicated restraint system) should use a Strength value in the 100-150 range and should be uncraftable or difficult to craft. An improvised field restraint (cable ties, rope, tape bindings) should use a Strength value in the 40-80 range and should be craftable from common materials. The mechanical difference between the two classes creates a meaningful gameplay choice: the player who invests in crafting or finding high-quality restraints is rewarded with longer-lasting captures.

The flowchart above shows the two-tier design pattern. The Strength field is the single lever that controls restraint duration; all other design decisions (crafting availability, rarity, material cost) should be balanced around the intended Strength tier.

Complete .dat example: Handcuffs Lock

The full Handcuffs_Lock.dat from the vanilla game files, annotated with field-level commentary:

GUID a02639d65d79438281af15f22b7632f9
ID 1195
Type Arrest_Start
Useable Arrest_Start
Rarity Uncommon

Size_X 1
Size_Y 1
Size_Z 0.25

Strength 128

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

InventoryAudio Sounds/Inventory/Keys.asset

The companion English.dat:

Name Handcuffs
Description Lock up a surrendering prisoner.

The InventoryAudio line on the Handcuffs Lock references a custom inventory sound. This line is optional and is present in the vanilla game files as a polish detail. Mod authors may omit the InventoryAudio line and inherit the default inventory sound for the item type.

Complete .dat example: Cable Tie

The full Cable_Tie.dat from the vanilla game files:

GUID 9d5d6f62c95f4aa6af2d89711064cd3c
Type Arrest_Start
Useable Arrest_Start
ID 1197

Size_X 1
Size_Y 1
Size_Z 0.25

Strength 64

Blueprints
[
	{
		CategoryTag "ad1804b6945145f3b308738b0b8ea447" // Tools
		InputItems
		[
			"ebb61f2e64f24351a6ab905b5516060b x 2" // Wire
			"8c25cf28c76a4634855f404c8972c0ae" // Tape
		]
		OutputItems this
		Effect "84347b13028340b8976033c08675d458" // Wrench
	}
	{
		Name Salvage
		CategoryTag "7ed29f9101ae4523a3b2e389414b7bd9" // Salvage
		InputItems this
		OutputItems "ebb61f2e64f24351a6ab905b5516060b" // Wire
		Effect "84347b13028340b8976033c08675d458" // Wrench
	}
]

InventoryAudio Sounds/Inventory/Keys.asset

The companion English.dat:

Name Cable Tie
Description Lock up a surrendering prisoner.

Note that the Cable Tie uses the same English.dat description as the Handcuffs Lock in the vanilla game files. Mod authors who ship multiple restraint types should distinguish the descriptions to communicate the mechanical difference to players.

The catcher-releaser pairing system

The arrest start asset is half of a two-item pairing. The other half is the arrest end asset (the releaser). The two items are linked through the arrest end asset's Recover field, which carries the numeric ID of the arrest start item that it can unlock.

Arrest start item (catcher)     Arrest end item (releaser)
ID 1195                ←──→    Recover 1195
(Handcuffs Lock)                (Handcuffs Key)

The pairing logic operates as follows. When any player activates an arrest end item on a restrained player, the engine checks whether the releaser's Recover field value matches the catcher's ID field value of the active restraint. If the values match, the restraint is removed. If the values do not match, the releaser has no effect on that restraint.

This means a single releaser item can be paired with exactly one catcher item type. A Handcuffs Key cannot unlock a Cable Tie restraint because the Cable Tie has ID 1197 and the Handcuffs Key has Recover 1195. The pairing is exclusive. If a mod author wants a universal releaser that can unlock multiple catcher types, they must either author a separate arrest end asset for each catcher type, where each arrest end asset carries the corresponding Recover value, or implement a custom unlock system through server-side plugin code.

As shown in the flowchart above, the catcher-releaser pairing is strictly a one-to-one mapping by numeric ID. The Recover field on the arrest end asset and the ID field on the arrest start asset must match exactly for the releaser to function. Mod authors who are designing a restraint system with multiple catcher items (handcuffs, cable ties, rope, chain) should plan the releaser item set to match, and should document which releaser unlocks which catcher in the mod's workshop description or in-game manual.

Field rules and parser behavior

The following rules govern how the parser interprets the fields of an arrest start .dat file.

Rule	Detail
Field order independence	The parser does not enforce ordering for most fields. Strength may appear before or after Size_X with no behavioral difference.
Missing Strength default	If Strength is omitted entirely, the default value is 0, meaning the restraint can be broken instantly on the first interact key press.
Missing Useable	If Useable is omitted, the engine defaults to None, and the item cannot be used as a catcher. The correct value (Arrest_Start) is required.
GUID formatting	The 32-digit hexadecimal GUID is stored as a continuous string with no hyphens. Hyphenated GUIDs cause a parse warning but may still function in recent Unturned versions.
Size_Z is optional	The Size_Z field controls the world-space collider size for the dropped item. If omitted, the engine uses a default.
Blueprint parsing	Blueprint sections are processed as object arrays. A missing opening or closing bracket causes the entire blueprint block to be skipped, but the rest of the file is parsed normally.
Comment syntax	Lines beginning with // are treated as comments and ignored. Inline comments after a value are delimited by //. Both forms are used in the vanilla game files for documentation purposes.
InventoryAudio line	The InventoryAudio line is optional and accepts an asset path to a sound asset. If the path is invalid or the asset is missing, the engine logs a warning and falls back to the default inventory sound.

Diagnostic table

Symptom	Most likely cause	Resolution
Arrest start item cannot be used on another player	Useable field missing or set to wrong value	Set Useable Arrest_Start in the .dat file
Item appears in inventory but has no effect when activated	Type Arrest_Start is missing	Add Type Arrest_Start to the .dat file
Restrained player breaks free instantly	Strength is 0 or omitted	Set Strength to the desired number of lean cycles (e.g., 128 for standard handcuffs)
Restrained player cannot break free at any interact key press	Strength is set too high for the intended use case	Reduce Strength (e.g., 64 for improvised restraints, 128 for law-enforcement grade)
Arrest end item has no effect on a restrained player	Recover field on the arrest end item does not match the catcher's ID	Confirm the Recover value on the arrest end .dat equals the ID value on the arrest start .dat
Arrest start item shows wrong display name	English.dat missing or has incorrect Name field	Confirm English.dat exists in the same folder and contains the correct Name value
Arrest start item not craftable despite having a Blueprints block	Skill or Skill_Level requirement not met by the player	Check the crafting skill requirements against the player's current skill levels
Arrest start item shows default inventory sound instead of custom audio	InventoryAudio path is invalid or the sound asset GUID is incorrect	Verify the sound asset GUID and path in the InventoryAudio line
Catcher item does not consume on use	Item is a server-side admin spawn or has been spawned with @give in creative mode	Confirm the item was legitimately acquired and that the server enforces consumption on use
Restrained player can still access weapons	Server plugin or game mode overrides the standard restraint restrictions	Check server plugin configuration; some roleplay servers intentionally allow partial inventory access while restrained

Best practices

• Generate a fresh GUID for every arrest start asset. Never reuse GUIDs from other items or from other mods.
• Choose IDs in the 50000+ range to avoid collision with vanilla items (handcuffs ID 1195, cable tie ID 1197) and established community mods.
• Set Strength proportional to the item's intended quality tier. Low-strength restraints (40-80) are appropriate for improvised items; high-strength restraints (100-150) are appropriate for dedicated law-enforcement gear.
• Pair every arrest start asset with a matching arrest end asset that carries the catcher's ID in its Recover field. An unreleasable restraint is a bug that will frustrate players.
• Author distinct English.dat descriptions for each restraint type so players can distinguish them in the inventory interface.
• Test the catcher-releaser pairing in single-player before publishing. The pair must work together as a complete system.
• Document the break-free Strength value in the mod's workshop description so players know how long the restraint lasts.
• Include a salvage blueprint for the item so players can recover materials from found restraints.
• Set Rarity to reflect the item's availability in the loot economy. A rare, high-strength restraint should be marked Rare or Epic.

Frequently asked questions

What is the maximum value for Strength?

The Strength field is a uint16, meaning its maximum value is 65535. In practical terms, a Strength value above approximately 500 produces a restraint that takes several minutes of continuous interact-key pressing to break free, which is longer than most gameplay scenarios require. The vanilla handcuffs use Strength 128, which takes approximately 10-15 seconds of sustained key pressing for a player to break free. Values above 1000 should be reserved for admin items or quest-required restraints that are not intended to be breakable through the interact mechanic.

Can an arrest start item have multiple Strength values?

No. The Strength field accepts a single uint16 value. There is no per-target or per-context variation mechanism within the arrest start .dat file. If a mod scenario requires different restraint durations against different target types (players versus NPCs, for example), that variation must be implemented through server-side plugin code rather than through the .dat configuration.

What happens if Useable is set to a value other than Arrest_Start?

If Useable is set to a value that the engine does not recognize as a catcher type, the item spawns in the inventory and can be carried and dropped but cannot be activated on another player. The item is effectively decorative. The engine does not produce a hard error for this configuration; the item simply does nothing when the player attempts to use it. Always set Useable Arrest_Start on catcher item .dat files.

Can the same item be both an arrest start and something else?

No. The Type and Useable fields define a single function for the item. An item cannot be simultaneously an Arrest_Start and a Melee or Gun weapon. If a mod scenario requires a multi-function restraint (a weapon that also applies a restraint on hit, for example), the effect must be implemented through server-side plugin code that applies the restraint status separately from the damage logic.

Does the Strength value affect anything beyond the break-free lean count?

No. The Strength field's sole function is to set the number of lean cycles required to break free. It does not affect the movement speed of the restrained player, the range at which the catcher can be applied, the duration of the lean animation, or any other property of the restraint. All of those properties are controlled by the engine's internal restraint configuration and are not configurable through the .dat file.

How does the arrest system interact with the Bleeder logic?

The arrest system and the Bleeder status are independent systems. A player can be both restrained and bleeding simultaneously. The bleeding status continues to deplete the player's health while restrained, and the player cannot apply bandages or medical items to stop the bleeding because the inventory is locked. This interaction makes restraint-plus-bleeding a dangerous combination in PvP scenarios. Mod authors who design mods around the arrest system should be aware that a restrained and bleeding player is on a timer toward incapacitation unless a teammate or captor applies medical aid.

Can NPCs be restrained by an arrest start item?

The vanilla engine does not support NPC restraint through the standard arrest start system. The Useable Arrest_Start logic is hard-coded for player targets only. NPC restraint requires server-side plugin code and is not available through .dat configuration alone.

Does the catch radius (interaction range) for applying an arrest start item differ from other items?

The interaction range for applying an arrest start item is governed by the same interaction range setting that applies to all player-to-player interactions in Unturned™. There is no per-item range override field on the arrest start asset. The interaction range is configured server-side. A mod author who wants an arrest start item with a longer or shorter application range must adjust the server's interaction range setting, which affects all interactions globally.

What is the interaction between arrest start items and safezones?

The restraint behavior inside safezones (player-built or server-defined areas where PvP is disabled) is determined by the server's safezone plugin configuration, not by the arrest start .dat file. On a typical roleplay server, restraints can be applied inside safezones only if the target player is a willing participant (the "arrest RP" consent convention). The engine itself does not enforce safezone restrictions on restraint application; that enforcement is plugin-level.

Can an arrest start item be used on a player who is already restrained?

No. The engine prevents a new restraint from being applied to a player who is already under an active restraint. The item can still be activated but produces no effect and is not consumed. This prevents restraint stacking (two handcuffs on the same player producing a combined break-free requirement of 256 leans, for example). If a mod scenario requires cumulative restraint strength, that behavior must be implemented through server-side plugin code.

Is the arrest system available in single-player mode?

Yes. The arrest system functions in single-player mode and can be tested locally. The @give console command can spawn both the catcher and releaser items for testing purposes. Local testing of the catcher-releaser pairing is straightforward and is the recommended workflow before publishing.

Can a player break free while moving?

Yes. The restrained player can move (at reduced speed) and press the interact key simultaneously. The break-free counter is independent of the movement system. A determined player can break free while walking away from the arrestor, which is a consideration for roleplay servers where the captor must guard the restrained player actively.

What is the impact of significant Strength values on server performance?

The arrest system imposes negligible server-side performance cost regardless of the Strength value. The break-free counter is a simple decrement operation on an integer value. A Strength value of 65535 does not meaningfully differ from a Strength value of 128 in terms of server load. The performance characteristic is linear and trivial at both extremes.

How do I make an unlockable restraint that only a specific key can open?

This is the standard catcher-releaser pairing pattern. Author an arrest start asset with a custom ID and Strength. Author one arrest end asset with Recover set to that catcher's ID. Do not distribute the arrest end asset through regular loot tables; distribute it only through admin commands, quest rewards, or locked containers. The key is still a valid item that any player can hold, but its scarcity in the loot economy creates the "only X can open" effect.

Can I reuse the same prefab across multiple arrest start items?

Yes. Multiple arrest start items can share the same prefab in the master bundle by setting the Model or Item field in each .dat file to the shared prefab name. This is useful for restraint types that are visually identical but have different Strength values or different catcher-releaser pairings. Players and observers cannot distinguish the restraint type visually; only the break-free behavior differs.

What is the difference between the ID field and the Strength field in the interaction with arrest end items?

The ID field identifies the catcher item for the purpose of the catcher-releaser pairing. The Strength field controls the break-free duration. These fields serve independent functions and are not interchangeable. The arrest end asset's Recover field matches against the catcher's ID, not against the Strength value. Two catcher items with different Strength values but the same ID are the same catcher item; two catcher items with the same Strength values but different ID values are different catcher items with independent releaser requirements.

Appendix A: Arrest start asset .dat field quick reference

Field	Type	Required	Default	Notes
GUID	uint128	Yes	,	32 hex digits, no hyphens
ID	uint16	Yes	,	50000+ range for mods
Type	enum	Yes	,	Must be Arrest_Start
Useable	enum	Yes	,	Must be Arrest_Start
Name	string	Yes	,	Internal name
Rarity	enum	No	Common	Common, Uncommon, Rare, Epic, Legendary
Slot	enum	No	None	Arrest start items use None
Size_X	uint8	Yes	,	Inventory grid width
Size_Y	uint8	Yes	,	Inventory grid height
Size_Z	float	No	Engine default	World-space collider height
Strength	uint16	No	0	Break-free lean cycles
InventoryAudio	asset path	No	Default	Custom inventory sound

Appendix B: Vanilla arrest asset values reference

Asset	ID	Type	Strength	Rarity	Craftable?
Handcuffs Lock	1195	Arrest_Start	128	Uncommon	Salvage only
Cable Tie	1197	Arrest_Start	64	Common	Yes (wire + tape)
Handcuffs Key	1196	Arrest_End	- (Recover 1195)	Uncommon	Salvage only

Appendix C: Arrest system compatibility matrix

System	Arrest start compatibility	Notes
Single-player local	Full	Testable with @give
Vanilla dedicated server	Full	No plugin required
Roleplay server (plugin-based)	Full	Plugin may override default restraint behavior
PvP server	Full	Restraint mechanics apply to all players
PvE server	Full	Same mechanics but applied less frequently in practice
Workshop mod	Full	Standard item packaging and distribution
Map script (NPC)	Requires plugin	Vanilla engine does not support NPC restraint

Appendix D: Arrest start asset template

Copy this template for a new arrest start item. Replace the bracketed values with the intended configuration.

GUID <32-hex-digit-guid>
ID <50000+>
Type Arrest_Start
Useable Arrest_Start
Name <InternalName>
Rarity <Common|Uncommon|Rare|Epic|Legendary>

Size_X <1>
Size_Y <1>

Strength <64-150>

Blueprints
[
	{
		Name Salvage
		CategoryTag "<salvage-category-guid>"
		InputItems this
		OutputItems "<output-item-guid>"
		Effect "<effect-guid>"
	}
]

Companion English.dat:

Name <Display Name>
Description <Tooltip description text.>

Appendix E: External references

• Smartly Dressed Games official modding documentation - Item assets - the authoritative field reference for all item types including arrest start.
• Unturned on Steam - the Unturned™ store page and community hub.
• Arrest End Asset Reference - the companion article that documents the releaser side of the catcher-releaser pairing.
• Item Asset Anatomy - the shared field reference; documents the ID, GUID, Rarity, Slot, and Size fields used on all item types.
• Blueprint Asset Reference - the full blueprint system reference for crafting recipes.
• Project Folder Structure and GUIDs - folder layout and GUID generation workflow.
• Data File Format Reference - the .dat syntax reference covering comment syntax, array literals, and object blocks.
• Master Bundle Export - the Unity bundling workflow used to package item prefabs.
• Steam Workshop Submission - the publishing workflow for finished mods.

Advanced considerations

Arrest start items in roleplay server design

On roleplay servers such as the 57 Studios™ Horizon Life RP server, the arrest system is one of the foundational mechanics of the law-enforcement gameplay loop. Police factions carry handcuffs as standard equipment. Players who commit criminal infractions are restrained, transported to a jail facility, processed, and released. The Strength field on the arrest start asset controls how long the restrained player must wait before breaking free if no guard is present to prevent the break-free action. Mod authors designing for roleplay servers should set Strength high enough that the break-free action takes long enough for a guard to respond but low enough that an unattended restrained player can eventually escape. The 57 Studios™ cohort recommendation for roleplay police restraints is Strength 100-150.

Arrest start items and the building decay system

The arrest system does not interact with the building decay system. A restrained player is still subject to all standard game rules for hunger, thirst, temperature, and passive health regeneration. If a restrained player is left unattended for an extended period and cannot break free (due to a very high Strength value), the player may die from hunger or thirst, which releases the restraint through the death resolution path. Mod authors should not rely on the arrest system as a permanent containment mechanism; death is always an exit path.

Arrest start items with custom audio

The vanilla arrest start items (Handcuffs Lock and Cable Tie) both reference Sounds/Inventory/Keys.asset for the InventoryAudio line. This sound plays when the item is picked up or moved in the inventory interface. Mod authors who want a distinct audio experience for a custom restraint can author a custom sound asset and reference it in the InventoryAudio line. The custom sound asset must be packaged in a content bundle and the asset path must resolve to the correct Unity asset.

Arrest start items in competitive gameplay

Arrest start items are disabled or restricted on most competitive PvP servers because the restraint mechanic removes player agency for an extended duration, which is incompatible with the fast-respawn gameplay loop of competitive modes. Mod authors designing arrest start items for competitive contexts should document the restraint duration prominently in the mod description and should consider limiting the Strength value to under 50 to minimize the duration of enforced inactivity.

Multiple catcher items sharing the same ID

If two different .dat files share the same ID value but have different GUID values, the engine loads both but uses only one (the last-loaded GUID wins for ID-based lookups). The catcher-releaser pairing system uses the ID field, not the GUID field, for matching. This means if two arrest start items share the same ID, an arrest end item with Recover set to that ID can unlock either catcher item (whichever was loaded last). This is almost never the intended behavior. Always assign unique IDs to each catcher item type.

Authoring checklist

Before publishing an arrest start mod to the Steam Workshop, confirm the following:

• [ ] GUID is unique - generated fresh, not copied from another asset
• [ ] ID is in the 50000+ range
• [ ] Type Arrest_Start is present
• [ ] Useable Arrest_Start is present
• [ ] Strength is set to a non-zero value unless instant-break-free is intentional
• [ ] A matching arrest end asset exists with Recover set to this catcher's ID
• [ ] English.dat is authored with Name and Description fields
• [ ] The master bundle contains the item prefab at the correct name
• [ ] Blueprint recipes are configured (at minimum a salvage recipe)
• [ ] Tested in single-player: item applies restraint, break-free counter works, releaser item unlocks
• [ ] Rarity is set to reflect the item's loot economy tier
• [ ] Workshop description documents the restraint strength (number of leans required to break free)
• [ ] IDs do not collide with vanilla IDs (1195 Handcuffs, 1197 Cable Tie)

Document history

Version	Date	Author	Notes
1.0	2026-07-26	57 Studios	Initial publication. Complete arrest start asset field reference, catcher-releaser pairing documentation, vanilla example files, FAQ, diagnostic tables, appendices.

Cross-references

• Caliber ID Registry - the previous article in this section.
• Arrest End Asset Reference - the next article; documents the releaser side of the catcher-releaser pairing.
• Item Asset Anatomy - shared field reference for all item types.
• Blueprint Asset Reference - full blueprint system documentation.
• Project Folder Structure and GUIDs - GUID authoring workflow.
• Data File Format Reference - .dat file format syntax.
• Master Bundle Export - Unity bundling pipeline.
• Throwable Asset - the throwable item type; uses the same inherited ItemAsset field set.
• Melee Asset - melee weapon item type; reference for the ItemAsset field conventions.
• Smartly Dressed Games modding documentation - official field reference.
• Unturned on Steam - game page and community.