Skip to content

Arrest End Asset Reference

The arrest end asset, also referred to as a "releaser" item, is the mechanical counterpart to the arrest start asset in Unturned™'s two-item restraint system. Where the arrest start asset defines the catcher - the item that applies a restraint to a target player - the arrest end asset defines the releaser, the item that removes an active restraint and restores the affected player to full mobility. The vanilla releaser is the Handcuffs Key, which unlocks the Handcuffs Lock restraint and returns the restrained player to normal movement, inventory access, and weapon handling.

This article is the 57 Studios™ canonical reference for the arrest end asset subtype. It covers the .dat fields that define a releaser item, the Recover field linkage mechanism that ties each releaser to a specific catcher, the interaction between the releaser and the break-free system, and the full configuration surface inherited from the ItemAsset parent class. Like the arrest start asset, the arrest end asset has a minimal class-specific field set - only one field (Recover) beyond the inherited identity and inventory fields - but the pairing logic requires careful coordination with the corresponding arrest start asset and is a common source of authoring errors in multi-item restraint systems.

Handcuffs Key item as displayed in the Unturned inventory interface

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_Ends/.

Who this article is for

This article is written for Unturned™ mod authors who have already read Arrest Start Asset Reference or are already familiar with the catcher item concept. If you are designing a restraint system from scratch, read the arrest start article first, then return here for the releaser side of the pairing. Familiarity with .dat authoring conventions, the master bundle pipeline, and the ItemAsset inherited fields is assumed. If you need to review those topics, start with Item Asset Anatomy and Data File Format Reference.

How the arrest end mechanic works

The arrest end mechanic is a targeted interaction. When a player holds an arrest end item and activates it on a restrained player (typically through the context menu or a dedicated interaction key), the engine performs a three-step validation sequence.

The first validation step checks whether the target player is currently under an active restraint. If the target is not restrained, the engine produces no effect and the arrest end item is not consumed. The second validation step extracts the catcher item's ID field from the active restraint's configuration data. The third validation step compares that catcher ID against the arrest end item's Recover field value. If the values match, the restraint is removed and the arrest end item is consumed. If the values do not match, the engine produces no effect and the arrest end item is not consumed.

The critical distinction between the arrest end mechanic and the break-free mechanic is that the arrest end item removes the restraint instantly and completely, regardless of the catcher's Strength value. A player who is restrained by a Strength 128 Handcuffs Lock can be freed instantly by a Handcuffs Key without completing a single lean cycle. The break-free counter is bypassed entirely when the releaser is applied.

File and folder structure

A complete arrest end mod requires the following files:

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

The folder structure is identical to the arrest start asset and to most other item types. The folder name and the .dat filename stem should match the Name field to avoid diagnostic confusion.

Complete .dat field reference

Identity and inherited fields

The inherited fields for an arrest end asset follow the same conventions as the arrest start asset and every other item type. The table below documents the specific values that apply to the arrest end subtype.

FieldTypeRequiredExamplePurpose
GUIDuint128 hexYescb4352c6fcb044c2b58e6edfa5644904128-bit globally unique identifier. Generate a fresh GUID for every new arrest end item. Never reuse GUIDs.
IDuint16Yes1196Numeric item ID. Must be unique across all loaded mods. Use IDs in the 50000+ range to avoid collision with vanilla items.
TypeenumYesArrest_EndMust be Arrest_End for releaser items.
UseableenumYesArrest_EndMust be Arrest_End for releaser items.
RarityenumNoUncommonControls the inventory highlight color. Vanilla handcuffs key uses Uncommon.
Size_Xuint8Yes1Width in inventory grid cells. The handcuffs key uses 1.
Size_Yuint8Yes1Height in inventory grid cells. The handcuffs key uses 1.
Size_ZfloatNo0.3Unity world-space z-dimension for the dropped item model.

Class-specific fields

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

FieldTypeRequiredDefaultExamplePurpose
Recoveruint16No01195The numeric ID of the arrest start (catcher) item that this releaser can unlock. Must match the catcher's ID field exactly. A value of 0 means the releaser matches no catcher and is effectively non-functional.

The Recover field is the single most important field on any arrest end asset. If the value is incorrect or omitted, the releaser cannot unlock any catcher, and the item is a decorative object that consumes inventory space without providing any mechanical benefit.

Blueprint fields

The blueprint block for an arrest end item follows the same conventions as the arrest start asset. The vanilla Handcuffs Key includes only a salvage recipe.

FieldTypeRequiredPurpose
NamestringNoDisplay name for the blueprint category (e.g., Salvage).
CategoryTagGUIDConditionalThe crafting category GUID. Required for craftable items.
InputItemsGUID or GUID arrayConditionalOne or more items consumed by the recipe. this means the item itself is consumed as input.
OutputItemsGUID or GUID arrayConditionalOne or more items produced by the recipe.
EffectGUIDNoThe sound or visual effect played on recipe completion.

The catcher-releaser pairing system

The pairing between a catcher item and a releaser item is the central design concern for any restraint system. The pairing is a one-to-one mapping by numeric ID, enforced at the engine level with no override mechanism.

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

The catcher's ID and the releaser's Recover must share the same numeric value. The pairing is directional - the catcher does not reference the releaser at all. The catcher only defines its own ID, and the releaser selects which catcher it unlocks by setting Recover to the corresponding ID value. This means a catcher item does not know which releaser unlocks it, but a releaser always knows which catcher it unlocks.

As shown in the flowchart above, the pairing is exclusive. A Handcuffs Key cannot unlock a Cable Tie restraint because the values do not match. A modded Cable Tie Key that carries Recover 1197 cannot unlock a Handcuffs Lock restraint. The pairing is deterministic and verifiable by inspecting both .dat files.

The zero-recover edge case

If Recover is set to 0 or omitted from the arrest end .dat, the releaser matches no catcher. This is the default behavior. The engine does not produce an error or warning for a zero-value Recover; the item simply does nothing when activated on any restrained player. This is occasionally useful for placeholder or decorative items that should look like a key but should not function as one. For any functional releaser, set Recover to the catcher's numeric ID.

Multiple releaser items for the same catcher

A single catcher can be unlocked by multiple releaser items, as long as each releaser carries the correct Recover value. This is the pattern for a universal master key across a server. For example, a server administrator could author a "Master Restraint Key" arrest end item with Recover set to 1195 (matching the vanilla Handcuffs Lock) and a separate "Cable Tie Cutter" with Recover set to 1197 (matching the vanilla Cable Tie). Both are distinct .dat files, but they are conceptually part of the same restraint system. A single "Universal Key" with Recover set to all relevant catcher IDs is not possible through the .dat system alone, because Recover accepts a single uint16 value and cannot be an array. Universal unlock behavior requires server-side plugin code.

The diagram shows that the Recover value is the sole arbiter of compatibility. Any releaser with the matching Recover value works with the corresponding catcher, regardless of the releaser's name, rarity, or prefab appearance.

Complete .dat example: Handcuffs Key

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

GUID cb4352c6fcb044c2b58e6edfa5644904
Type Arrest_End
Rarity Uncommon
Useable Arrest_End
ID 1196

Size_X 1
Size_Y 1
Size_Z 0.3

Recover 1195

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 Key
Description Unlock a handcuffed prisoner.

The critical field is Recover 1195, which matches the Handcuffs Lock's ID 1195. Without this field set to the correct value, the Handcuffs Key would be a decorative item with no mechanical function.

Annotated field analysis

LineAnalysis
GUID cb43...4904Unique identifier for the Handcuffs Key asset.
Type Arrest_EndDeclares the item as an arrest end (releaser) type.
Rarity UncommonInventory highlight color. Matches the Handcuffs Lock's rarity tier.
Useable Arrest_EndDeclares the item's use behavior as the arrest end interaction.
ID 1196The item's numeric identifier. Must be unique.
Size_X 1 / Size_Y 1Standard single-grid inventory slot.
Size_Z 0.3World-space collider height for the dropped item model.
Recover 1195The catcher ID this releaser unlocks. Matches the Handcuffs Lock's ID.
BlueprintsSalvage recipe that returns Metal Scrap.

The ID assignment pattern

The vanilla Handcuffs Key uses ID 1196, which is the Handcuffs Lock ID 1195 plus one. This is a common vanilla ID assignment convention but is not enforced by the engine. The Recover field is independent of the ID field. A releaser can have any ID in the valid range regardless of the catcher's ID, as long as Recover carries the correct numeric value.

Field rules and parser behavior

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

RuleDetail
Field order independenceThe parser does not enforce ordering for most fields. Recover may appear before or after Size_X with no behavioral difference.
Missing Recover defaultIf Recover is omitted entirely, the default value is 0, meaning the releaser matches no catcher and is non-functional.
Missing UseableIf Useable is omitted, the engine defaults to None, and the item cannot be used as a releaser. The correct value (Arrest_End) is required.
Recover accepts any uint16The field accepts any value in the uint16 range (0 to 65535). The value does not need to correspond to an existing item ID; if it does not, the releaser simply has no effect on any restraint.
GUID uniquenessThe GUID must be unique across all loaded assets. A duplicate GUID with a different ID produces load-time warnings and unpredictable behavior.
Blueprint parsingBlueprint sections are processed as object arrays. A missing opening or closing bracket causes the entire blueprint block to be skipped.
Comment syntaxLines beginning with // are treated as comments and ignored. Inline comments after a value are delimited by //.

Diagnostic table

SymptomMost likely causeResolution
Arrest end item has no effect on any restrained playerRecover field missing, set to 0, or set to the wrong catcher IDConfirm the Recover value matches the catcher item's ID exactly
Arrest end item does nothing when activatedUseable field missing or set to wrong valueSet Useable Arrest_End in the .dat file
Item appears in inventory but cannot be activatedType Arrest_End is missingAdd Type Arrest_End to the .dat file
Arrest end item works on the wrong catcherRecover matches a different catcher's ID than intendedCorrect Recover to the intended catcher's ID
Arrest end item consumed on a non-restrained playerEngine bug or server plugin conflictTest in vanilla single-player; if reproducible, report to SDG support channels
Arrest end item works on one catcher but not anotherRecover is a single value and cannot match multiple catcher IDsAuthor a separate arrest end item for each catcher type
Arrest end item shows wrong display nameEnglish.dat missing or has incorrect Name fieldConfirm English.dat exists in the same folder and contains the correct Name value
Arrest end item has no salvage blueprintBlueprints block omitted entirelyAdd a salvage blueprint so players can recover materials
Recover value is correct but the item still has no effectThe catcher item's ID was changed after the releaser was authoredUpdate the releaser's Recover field to match the new catcher ID
Arrest end item can be used on selfEngine behavior: the releaser activates on the target player, not the userThe user selects a target; the releaser cannot unlock the user's own restraint

Arrest end and break-free interaction

The arrest end item and the break-free mechanic operate on the same restraint state but through independent paths. When a player is restrained, two separate processes can resolve the restraint: the restrained player's own break-free action (governed by the catcher's Strength field) and the external application of a matching releaser by any other player. The two processes are independent and concurrent. If a restrained player has completed 100 of 128 required lean cycles and a second player applies the matching releaser, the restraint is removed and the partial progress toward breaking free is discarded. Conversely, if the restrained player completes all 128 lean cycles before a releaser is applied, the restraint is removed and the releaser item, if subsequently applied to the now-free player, produces no effect and is not consumed.

As shown in the flowchart above, the three resolution paths are independent and any one of them is sufficient to remove the restraint. The arrest end path is the only instantaneous path that does not require the restrained player's participation.

Complete .dat example: modded cable tie cutter

The following example demonstrates a modded arrest end item that unlocks the vanilla Cable Tie (ID 1197). This item does not exist in the vanilla game files; it is presented here as an authoring illustration.

GUID e7f2a1b5c8d34f6e9a0b2c7d5e8f1a3b
ID 50100
Type Arrest_End
Useable Arrest_End
Name CableTieCutter
Rarity Common

Size_X 1
Size_Y 1

Recover 1197

Blueprints
[
	{
		Name Salvage
		CategoryTag "7ed29f9101ae4523a3b2e389414b7bd9" // Salvage
		InputItems this
		OutputItems "ebb61f2e64f24351a6ab905b5516060b" // Wire
		Effect "84347b13028340b8976033c08675d458" // Wrench
	}
]

Companion English.dat:

Name Cable Tie Cutter
Description Cuts through cable tie restraints. Does not unlock handcuffs.

Note that the Recover value (1197) matches the vanilla Cable Tie's ID, and the English.dat description explicitly documents which catcher the releaser unlocks. This is the cohort-recommended practice for mods with multiple restraint types.

Arrest end assets in roleplay server contexts

On roleplay servers, the arrest end asset is typically a restricted item. Law-enforcement factions carry the keys that unlock the restraints they apply. Players who are restrained by a law-enforcement officer cannot unlock their own restraints without assistance (the break-free mechanic still works, but a high Strength value makes it slow). The design pattern on roleplay servers is for law-enforcement factions to carry the matching releaser items and for civilian players to have limited or no access to them.

The 57 Studios™ cohort recommendation for roleplay servers is to distribute releaser items through faction-specific loadouts, admin shops, or quest rewards, and to avoid placing them in general loot tables. A roleplay server where any player can find a handcuffs key in a kitchen cabinet undermines the law-enforcement gameplay loop.

Server-side enforcement considerations

The .dat file alone cannot restrict who can use a releaser item. Any player who holds a releaser in their inventory can activate it on any restrained player. Server-side enforcement of key ownership (e.g., "only police faction members can use handcuffs keys") requires plugin-level code. The .dat file defines the item's mechanical properties; the server's plugin system defines the access control.

Best practices

  • Set Recover to the exact ID of the catcher item that the releaser is intended to unlock. Verify the value by reading the catcher's .dat file directly.
  • Generate a fresh GUID for every arrest end asset. Never reuse GUIDs from other items or from other mods.
  • Choose IDs in the 50000+ range to avoid collision with the vanilla Handcuffs Key (ID 1196) and established community mods.
  • Pair every arrest end asset with exactly one catcher asset. One releaser per catcher is the minimum viable design; multi-catcher releaser systems require one .dat file per catcher.
  • Author the English.dat description to document which catcher the releaser unlocks. Players should not need to inspect .dat files to understand which key works on which restraint.
  • Include a salvage blueprint so players can recover materials from found releaser items.
  • Set Rarity to match the catcher item's rarity tier. A rare handcuffs item should be paired with a rare key item.
  • Test the releaser against its corresponding catcher in single-player before publishing. Verify that the releaser unlocks the restraint and that the releaser is consumed on use.
  • Test the releaser against non-matching catchers to confirm the exclusivity works as intended.

Frequently asked questions

What is the maximum value for Recover?

The Recover field is a uint16, meaning its maximum value is 65535. The field accepts any value in that range, though values that do not correspond to any loaded catcher item's ID simply produce a releaser that has no effect on any restraint. The vanilla releaser uses Recover 1195 to match the Handcuffs Lock's ID 1195.

Can a single arrest end item unlock multiple catcher types?

No. The Recover field accepts a single uint16 value, not an array. One releaser item unlocks exactly one catcher type. If a mod requires a universal releaser that can unlock multiple catcher types (handcuffs, cable ties, rope bindings), the mod author must either author a separate .dat file for each catcher-releaser pairing or implement the universal unlock behavior through server-side plugin code.

What happens if Recover is set to the catcher's ID but the catcher item is not loaded?

The releaser is still a valid item. It spawns in the inventory, has the correct name and appearance, and can be activated on a restrained player. However, because no catcher item with the matching ID is loaded, the releaser never finds a restraint to unlock. The item is functionally decorative. This scenario occurs when a mod pack ships the releaser but accidentally omits the catcher, or when the catcher's ID was changed after the releaser was authored.

Does the arrest end item have any effect if used on a non-restrained player?

No. The engine checks whether the target player is under an active restraint before checking the Recover value. If the target is not restrained, the engine returns a "no valid target" state, the releaser is not consumed, and no effect is produced. The arrest end item is safe to use on any player; it does nothing unless the target is restrained by a matching catcher.

Can an arrest end item be used by the restrained player on themselves?

The activation model for arrest end items requires the user to select a target. A restrained player can activate an arrest end item from their own inventory on themselves if the server's interaction system permits self-targeting. In the standard context-menu interaction, the restrained player selects themselves as the target and, if the releaser's Recover matches the active restraint's catcher ID, the restraint is removed. This is the self-release mechanic and is intentional.

How does the arrest end item interact with the break-free partial progress?

The arrest end item clears the restraint state entirely, discarding any partial break-free progress. If a restrained player has completed 64 of 128 required lean cycles and a matching releaser is applied, the restraint is removed and the counter is reset. The partial progress toward breaking free is not preserved and cannot be resumed if the player is subsequently re-restrained.

Is there a cooldown or animation associated with activating an arrest end item?

The arrest end item activation uses the standard Unturned™ player interaction system. There is no class-specific cooldown or animation for the arrest end activation. The activation is instant, subject only to the interaction range check and the validation sequence described in this article. The vanilla game does not play a specific "unlocking" animation when a releaser is used; the restraint state change is the only feedback.

Can an arrest end item be configured as a tool that is not consumed on use?

No. The engine consumes one unit of the arrest end item on every successful unlock. There is no field in the .dat file to override the consumption behavior for arrest end items. If a mod scenario requires an unlock tool that is reusable, the item must be implemented through server-side plugin code rather than through the .dat configuration.

The cohort recommendation is to use IDs in the 50000+ range. The vanilla arrest end asset (Handcuffs Key) uses ID 1196. Modded items should avoid the 0-20000 range where vanilla items and established community mods reside. A common convention is to reserve a block of IDs (e.g., 50000-50099) for restraint system items, alternating between catcher and releaser IDs.

Can a releaser item have the same ID as its paired catcher item?

No. Every item in Unturned™ must have a unique ID value. The catcher and releaser are separate items with separate .dat files and must have different IDs. The pairing is established through the Recover field on the releaser and the ID field on the catcher, which are different fields on different files; they carry the same numeric value but on different items.

Does the arrest end item need a 3D prefab in the master bundle?

Yes. The arrest end item is a full item asset and requires a prefab in the master bundle for the in-game model - the model shown when the item is held in the inventory or dropped on the ground. An empty master bundle or missing prefab causes the item to be invisible when dropped, though it can still be carried in the inventory and used as a releaser. Always provide a prefab, even if it is a simple placeholder mesh during early development.

Can an arrest end item be crafted?

Yes. Adding a crafting blueprint to the Blueprints block makes the arrest end item craftable. The vanilla Handcuffs Key includes only a salvage recipe (disassembling the key to recover materials), but a modded arrest end item can have a full crafting recipe that produces the item from base materials. Set the CategoryTag, Skill, Skill_Level, and InputItems fields appropriately for the crafting system.

How do I make a key that unlocks multiple different restraint types?

The .dat system does not support multi-value Recover. To approximate a master key, the server administrator must implement a server-side plugin that intercepts the arrest end activation and checks against a list of catcher IDs. The .dat file on the client side cannot natively express "unlock any catcher." If a multi-type master key is required for a mod, the practical approach is to make the .dat file a placeholder item that triggers the plugin behavior, rather than trying to express the multi-unlock logic through the Recover field.

What happens if I set Recover to a value that matches no existing item?

The arrest end item is still a valid item and can be held, dropped, and activated. When activated on a restrained player, the engine compares Recover against the active restraint's catcher ID. Because no catcher has an ID matching the Recover value, the validation fails and the releaser has no effect. The item is not consumed. This is a common configuration for placeholder items during mod development; the item exists in the player's inventory but has no function until the corresponding catcher is added to the mod.

Appendix A: Arrest end asset .dat field quick reference

FieldTypeRequiredDefaultNotes
GUIDuint128Yes,32 hex digits, no hyphens
IDuint16Yes,50000+ range for mods
TypeenumYes,Must be Arrest_End
UseableenumYes,Must be Arrest_End
NamestringYes,Internal name
RarityenumNoCommonCommon, Uncommon, Rare, Epic, Legendary
SlotenumNoNoneArrest end items use None
Size_Xuint8Yes,Inventory grid width
Size_Yuint8Yes,Inventory grid height
Size_ZfloatNoEngine defaultWorld-space collider height
Recoveruint16No0Target catcher item ID
InventoryAudioasset pathNoDefaultCustom inventory sound

Appendix B: Vanilla catcher-releaser pairings reference

Catcher (Arrest Start)Catcher IDReleaser (Arrest End)Releaser IDRecover
Handcuffs Lock1195Handcuffs Key11961195
Cable Tie1197- (no vanilla releaser)--

Note that the vanilla Cable Tie does not have a dedicated releaser item. This means the only way to remove a Cable Tie restraint in the vanilla game is through the break-free mechanic (64 lean cycles) or through death. Mod authors who add cable-tie-style restraints should consider authoring a matching releaser item so that players have a non-break-free removal option.

Appendix C: Arrest end asset template

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

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

Size_X <1>
Size_Y <1>

Recover <catcher-id>

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. Mention which restraint type this unlocks.>

Appendix D: External references

Advanced considerations

Arrest end items with conditional unlock logic

The .dat system does not support conditional unlock logic - there is no field for "unlocks only if the user is a member of the police faction" or "unlocks only during daylight hours." All conditional unlock behavior must be implemented server-side through plugin code. The .dat file defines the mechanical property (which catcher ID the releaser unlocks); the server plugin defines the access control (who can use the releaser and under what circumstances).

The Recover field as a cross-mod compatibility surface

The Recover field creates a natural cross-mod compatibility surface. If two different mod authors each publish a handcuffs item with ID 50001, and a third mod author publishes a releaser with Recover 50001, the releaser works with both catcher items (whichever one is loaded last). This can be either a feature (universal key compatibility across mod packs) or a bug (unintended cross-mod releaser behavior). The cohort recommendation for mod authors who want cross-mod compatibility is to document the catcher ID prominently in the mod description and to coordinate with other mod authors in the same ecosystem.

Arrest end items in admin and debug contexts

Arrest end items with Recover 0 (the default) are non-functional by design. Server administrators who need a debug tool that removes any restraint from any player cannot use the standard arrest end system because the Recover field is a single-value match. The recommended approach for an admin unlock tool is to implement it through the server's command system (@unlock or similar), not through a releaser item.

Authoring a releaser for a modded catcher

The authoring sequence for a complete catcher-releaser pair is: author the catcher item first, note its assigned ID value, then author the releaser item with Recover set to that ID value. Publishing the catcher without the releaser, or the releaser without the catcher, produces an incomplete restraint system that either cannot be removed (releaser missing) or cannot be applied (catcher missing). The two items form a conceptual unit and should be authored, tested, and published together.

Authoring checklist

Before publishing an arrest end 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_End is present
  • [ ] Useable Arrest_End is present
  • [ ] Recover is set to the exact ID of the corresponding catcher item
  • [ ] The corresponding catcher item exists and is loaded into the same game instance
  • [ ] English.dat is authored with Name and Description fields
  • [ ] The English.dat description documents which catcher this releaser unlocks
  • [ ] The master bundle contains the item prefab at the correct name
  • [ ] Blueprint recipes are configured (at minimum a salvage recipe)
  • [ ] Tested in single-player: catcher applies restraint, releaser unlocks it
  • [ ] Tested with a non-matching catcher to confirm exclusivity
  • [ ] Rarity matches the catcher item's rarity tier
  • [ ] Workshop description documents the catcher-releaser pairing relationship

Document history

VersionDateAuthorNotes
1.02026-07-2657 StudiosInitial publication. Complete arrest end asset field reference, catcher-releaser pairing documentation, vanilla example files, FAQ, diagnostic tables, appendices.

Cross-references