Storage Asset Reference

Intermediate40-60 minutesWindowsUnity EditorBlenderNotepad++

Every looting run in Unturned™ ends at a container. Whether the player is stacking supplies in a wooden crate on their base floor, hauling gear in a military rucksack, or cracking open a padlocked locker owned by another faction, the underlying system is the same: a storage asset that defines a grid, a capacity, and a set of access rules. Understanding that system is the prerequisite for authoring your own containers as part of a 57 Studios™ mod — and for diagnosing why a container you authored is silently refusing to accept items, or why players can open a container that should be locked to the owner.

Storage assets split into two distinct families:

• Placeable containers — crates, lockers, refrigerators, safes. They sit in the world at a fixed position and belong to whoever built or placed them.
• Wearable containers — backpacks, vests, and some specialized packs. They occupy a clothing slot on the player and contribute inventory slots while worn.

Both families share the same underlying inventory-grid logic. The split matters for access control and world placement, but the storage math is identical.

Who this article is for

This article is written for modders who already know how to author a standard item .dat, have a Unity project set up with the Unturned™ modding tools, and are now authoring either a custom placeable container or a wearable storage item. If you have not yet worked through the project folder structure or GUID workflow, complete Project Folder Structure and GUIDs before continuing.

This article covers:

• The full .dat field set for placeable containers and wearable storage.
• Inventory grid math and slot-count calculations.
• Access control — lock states, key mechanics, and ownership semantics.
• Vehicle trunk storage.
• Display containers.
• Safe containers with PIN mechanics.
• Common failure modes and their fixes.
• Balance guidance for competitive and RP server environments.

---

Background: how the storage system works

Unturned's storage system is built around the InteractableStorage script (for placeable containers) and the ItemBagAsset / ItemClothingAsset with storage extension (for wearable containers). Both ultimately surface a two-dimensional grid to the player's inventory UI.

The key insight is that the grid is always rectangular. A container with Width 6 and Height 4 provides 24 slots. The engine enforces this constraint; you cannot produce an L-shaped storage grid or a grid with irregular holes. If the design calls for an unusual shape, you must split storage across two separate containers placed adjacent to each other.

For placeable containers, the grid state is stored server-side (or in the local save file for single-player). For wearable containers, the grid state is stored in the player's clothing slot data and persists with the player's character.

Both families use grid math

The capacity calculation Width × Height applies to placeable containers using the Width and Height fields. Wearable containers use Storage_X and Storage_Y field names but the multiplication is identical. The naming difference is a legacy inconsistency in the Unturned™ .dat format; functionally they are the same parameter.

---

Placeable container .dat fields

Placeable containers are barricade-type objects with storage capacity. Their .dat files share the common item fields and then add the storage-specific fields documented in this section.

Type field value

A placeable storage container's Type field in its .dat is Storage. This is distinct from Clothing (worn containers) and Barricade or Structure (which can reference storage via sub-type). Most custom containers are authored as standalone Storage items.

Core storage fields

Field	Type	Example	Purpose
Type	enum	Storage	Declares this item as a storage container.
Width	uint8	6	Horizontal slot count in the storage grid.
Height	uint8	4	Vertical slot count in the storage grid.
Display	bool	true	When true, the container's exterior shows a preview of its top item. Used by decorative crates and display stands.
Locked	bool	false	When true, the container starts locked. Requires the correct key item to unlock.
Key	uint16	0	The ID of the item that functions as a key for this container. 0 = no key required.
Size_X	uint8	2	The container's footprint width in the player's inventory.
Size_Y	uint8	2	The container's footprint height in the player's inventory.

Grid math

The total slot count of a placeable container is Width × Height. Common configurations:

Configuration	Width	Height	Slots	Typical use
Small crate	4	3	12	Wood or metal crate, small personal storage
Medium crate	6	4	24	Military footlocker, camp chest
Large crate	8	6	48	Industrial locker, server rack
Locker	4	6	24	Tall metal locker
Refrigerator	4	4	16	Food storage
Safe	3	3	9	Small personal safe
Armory rack	10	4	40	Long arms and equipment storage
Vault	10	10	100	High-security storage; large base use only

Grid limits

Unturned™ does not enforce a hard cap on grid size in the .dat, but the inventory UI renders the grid within the screen. Grids wider than 10 slots or taller than 8 slots clip outside the UI bounds on most player screen resolutions. The 57 Studios™ cohort recommendation is to stay within 10×8 for any container intended for public use.

Ownership and access fields

Field	Type	Example	Purpose
Accessible	bool	true	When true, all players can access the container regardless of ownership. Used for public loot containers on maps.
Vulnerable	bool	true	When true, the container can be damaged and destroyed by other players.
Explosion	uint16	0	Effect asset GUID or ID that plays when the container is destroyed.
Salvageable	bool	false	When true, the container drops a partial salvage item when destroyed.
Salvage_Duration_Multiplier	float	1.0	Multiplies the time it takes to salvage this container.

Ownership semantics

A placeable container is owned by the Steam group or player who placed it. Other players cannot open a non-Accessible container unless they have group membership. The group ownership system is handled by the Unturned™ group claim system; the container .dat only controls whether public access is permitted via Accessible.

Locked does not mean indestructible

The Locked flag restricts who can open the container's inventory UI. It does not prevent the container from being destroyed by explosives, firearms, or structural collapse. A container that must survive a raid must have a high Health value and be within a protected structure. Locked is an access gate, not a protection gate.

Durability fields

Field	Type	Example	Purpose
Health	uint16	500	Hit points of the container. Destroyed when Health reaches zero.
Range	float	3.0	Interaction range in meters. Player must be within this range to open the container.
Radius	float	0.0	Used for spherical containers. Leave at 0.0 for most rectangular containers.

Example placeable container .dat — medium wooden crate

A medium wooden crate with 6×4 storage (24 slots):

ID 4001
GUID a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6
Type Storage
Name WoodenCrate_Medium
Rarity Common
Size_X 2
Size_Y 2

Width 6
Height 4
Display true
Locked false
Key 0
Accessible false
Vulnerable true
Health 600
Range 3.0

Example placeable container .dat — base locker

A heavy metal locker with 8×10 storage (80 slots), suitable for long-term base storage:

ID 4002
GUID b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7
Type Storage
Name MetalLocker_Base
Rarity Uncommon
Size_X 2
Size_Y 3

Width 8
Height 10
Display false
Locked false
Key 0
Accessible false
Vulnerable true
Salvageable true
Salvage_Duration_Multiplier 1.0
Health 900
Range 3.0

---

Wearable container .dat fields

Wearable storage items — backpacks, vests, and bag-type clothing — are authored as Clothing items with storage extension fields. The clothing system handles equipping and the equipment slot; the storage fields extend the clothing with an inventory grid that becomes accessible from the player's inventory UI.

Backpacks are clothing

This is the single most common misconception for new Unturned™ modders: backpacks are clothing assets, not storage assets. The Type field in a backpack's .dat is Backpack (a sub-type of Clothing). The storage grid is added through the Storage_X and Storage_Y fields. A backpack cannot be placed in the world; it only functions while worn.

Clothing slot types with storage

Type value	Slot	Storage capable?
Shirt	Shirt slot	No
Pants	Pants slot	No
Hat	Hat slot	No
Backpack	Backpack slot	Yes — primary wearable storage
Vest	Vest slot	Yes — additional vest storage
Mask	Mask slot	No
Glasses	Glasses slot	No

Wearable storage fields

Field	Type	Example	Purpose
Type	enum	Backpack	The clothing type. Backpack or Vest for storage-capable wearables.
Storage_X	uint8	6	Horizontal slot count of the wearable's storage grid.
Storage_Y	uint8	6	Vertical slot count of the wearable's storage grid.
Armor	float	1.0	Damage multiplier when worn. Values less than 1.0 provide damage reduction.
Falling_Damage_Multiplier	float	1.0	Modifies fall damage while wearing.
Proof_Water	bool	false	When true, the player is immune to water damage while wearing.
Proof_Fire	bool	false	When true, the player is immune to fire damage while wearing.
Proof_Radiation	bool	false	When true, the player is immune to radiation damage while wearing.

Grid math for wearable containers

Configuration	Storage_X	Storage_Y	Slots	Typical use
Small backpack	4	4	16	Daypack, civilian carry
Medium backpack	5	6	30	Military assault pack
Large backpack	6	8	48	Military ruck, expedition pack
Small vest	3	3	9	Light tactical vest
Medium vest	4	4	16	Plate carrier with pouches
Large vest	5	5	25	Heavy tactical vest
Specialist pack	5	8	40	Medic, engineer, or role-specific carry

Example wearable container .dat — military assault backpack

A military assault backpack with 5×6 (30 slots):

ID 4010
GUID b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7
Type Backpack
Name MilAssaultPack
Rarity Rare
Size_X 2
Size_Y 2

Storage_X 5
Storage_Y 6
Armor 1.0
Falling_Damage_Multiplier 1.0
Proof_Water false
Proof_Fire false
Proof_Radiation false

English.dat for wearables

Include the display name and tooltip in English.dat alongside the .dat file. Players read the tooltip before deciding whether to pick up a backpack. Document the slot count in the description so players know what they are getting before equipping.

---

Placeable vs wearable: choosing the right type

Decision criterion	Use placeable container	Use wearable container
Item sits in the world	Yes	No
Item is worn by the player	No	Yes
Access control by group membership	Yes	N/A (worn)
Can be locked with a key	Yes	No
Can be destroyed by enemies	Yes	No (worn items are not destructible in vanilla)
Inventory footprint while not in use	Takes no player inventory space	Takes clothing slot
Grid is accessible from player inventory	No — open interaction required	Yes — always accessible while worn

Most container mods are one or the other. If your design requires a container the player carries but cannot wear (a portable crate), use a placeable container with a Size_X and Size_Y footprint appropriate for an in-inventory item. The player carries it in their main inventory or drops it at the base.

---

Vehicle trunk storage

Vehicle trunks are a third storage variant. They are not authored through a separate storage asset .dat; they are authored through the vehicle asset .dat using the Trunk_X and Trunk_Y fields. This section is included for reference because trunk storage uses the same grid math.

Field	Type	Example	Purpose
Trunk_X	uint8	4	Horizontal slot count of the vehicle trunk.
Trunk_Y	uint8	4	Vertical slot count of the vehicle trunk.
Locked	bool	false	When true, the trunk is locked when the vehicle is locked by its owner.

Vehicle trunks use the same Width × Height grid math. A Trunk_X 4, Trunk_Y 4 vehicle has a 16-slot trunk.

Trunk access and vehicle ownership

Vehicle trunk access is controlled by vehicle ownership. If the vehicle is locked, only the owner and group members can access the trunk. The storage asset system's Accessible field does not apply to vehicle trunks; vehicle access control is handled entirely through vehicle ownership flags. Adding Accessible false to a vehicle .dat does not restrict trunk access; it controls who can enter the vehicle.

---

Locking and key mechanics

Placeable containers support a key-lock system. When Locked true is set, the container cannot be opened without the correct key item. The key item is identified by the Key field, which takes the ID of the item that functions as the key.

Authoring a locked container with a custom key

1. Author the key item as a standard item with Type Key in its .dat.
2. Note the key item's ID.
3. In the container .dat, set Locked true and Key <key item ID>.
4. In the English.dat for the container, document that a specific key is required.
5. Author an English.dat for the key item that names it clearly.

Key item type is mandatory

The key item must have Type Key in its .dat. A regular item with a matching ID but an incorrect type will not unlock the container. This is a silent failure — the container does nothing when the wrong item type is used, and no error message is surfaced to the player or the server log.

Lock state interaction matrix

Locked	Accessible	Result
false	true	Container is universally accessible by any player without any key.
false	false	Container is accessible only to the owner or group members.
true	true	Container requires the correct key. Any player who has the key can open it.
true	false	Container requires the correct key. Only the owner or group members with the key can open it.

The Accessible flag and Locked flag are fully independent. Accessible true on a locked container allows any player to use the key — it does not bypass the lock requirement. Accessible false on an unlocked container means only the owner or group can open it even though no key is needed.

---

Storage grid visualization

The following diagram shows the slot numbering layout for a 6×4 storage grid (24 slots):

Col:  0    1    2    3    4    5
Row 0: [00] [01] [02] [03] [04] [05]
Row 1: [06] [07] [08] [09] [10] [11]
Row 2: [12] [13] [14] [15] [16] [17]
Row 3: [18] [19] [20] [21] [22] [23]

Items that occupy more than one slot (e.g., a rifle with Size_X 4, Size_Y 1) consume a contiguous horizontal run of four slots. The engine handles placement automatically; you do not manually assign items to numbered slots in the .dat.

The player's inventory UI renders the grid left-to-right, top-to-bottom, matching the numbering above. Items are placed starting from the first available slot in reading order.

Footprint planning example

A "field medic backpack" is expected to hold:

Item	Size_X	Size_Y	Slots consumed
4× Bandage	1	1	4
Splint	1	2	2
Blood bag	2	2	4
Medical kit	2	3	6
Defibrillator	2	3	6
Total			22

The largest single item is 2×3 (needs at least 2 columns). A Storage_X 5, Storage_Y 5 grid (25 slots) fits all items with 3 slots of margin. A Storage_X 4, Storage_Y 6 grid (24 slots) also works and produces a taller, narrower UI panel.

Match Storage_X to the widest expected item

If a container is designed to hold rifles (typically Size_X 4), Storage_X must be at least 4. A container with Storage_X 3 cannot hold any 4-wide item regardless of total slot count.

---

Display containers

The Display true flag on a container causes the exterior of the container model to show a preview of the most recently deposited item. This is used by decorative crates, weapon display racks, and item showcase mounts.

Field	Configuration	Effect
Display false	Default	No item preview on exterior
Display true	With Width 1, Height 1	Single-item display stand
Display true	With larger grid	Preview of top item; other items not shown

Display containers show only the most recent item

If a display container has a grid larger than 1×1, players can deposit multiple items. Only the most recently deposited item is shown as a three-dimensional model on the container's exterior. The remaining items are in the grid but not visually displayed. Author display containers as 1×1 to avoid player confusion about what is inside.

---

How-to: author a custom wooden crate

Step-by-step summary:

1. Model the crate exterior in Blender. Add a lid if it is meant to animate on open — see the animations article for lid-open animation authoring.
2. UV-unwrap and texture at 2048×2048 albedo.
3. Export FBX and import to Unity.
4. Add InteractableStorage script to the prefab root.
5. Add a BoxCollider to the prefab, sized to the visual bounds.
6. Assign the asset bundle name and build the master bundle.
7. Author the .dat with Type Storage, Width, and Height.
8. Author English.dat with the display name and description (include slot count in the description).
9. Copy to the mod folder, test in single-player.

---

Common pitfalls and their fixes

Symptom	Root cause	Fix
Container shows no storage grid on interact	Type field wrong or missing	Confirm Type Storage for placeable, Type Backpack or Vest for wearable
Grid appears but has zero slots	Width and Height both missing or zero	Set both fields to non-zero values
Backpack worn but no storage accessible	Using Storage_X and Storage_Y on a non-storage clothing type	Confirm Type Backpack or Type Vest, not Shirt or Pants
Container accessible by enemies	Accessible true unintentionally set	Set Accessible false for owner-only containers
Lock does not respond to key item	Key item Type not set to Key	Confirm the key item .dat has Type Key
Container destroyed immediately	Health set too low	Set Health to an appropriate value (300–1000 for most containers)
Player cannot open from normal interaction range	Range too low	Increase Range to at least 2.5
Container shows display item preview permanently	Display true on container without exterior preview mesh	Only enable Display true on containers with a visible exterior preview mesh in the prefab
Wearable gives too many slots and breaks balance	Storage_X or Storage_Y too large	Keep wearable grids within balance ranges; see balance reference below
Vehicle trunk inaccessible when vehicle is unlocked	Trunk fields missing from vehicle .dat	Add Trunk_X and Trunk_Y to the vehicle .dat
Items disappear from container on server restart	Server save not configured	Confirm the server has world-state saving enabled
Container falls through the ground on placement	Prefab missing base collider	Add a BoxCollider to the prefab sized to the container base
Large items do not fit in the container	Grid too narrow for item Size_X	Increase Width or Storage_X to at least the widest item's size
Container description blank in tooltip	English.dat missing or Description empty	Author English.dat with both Name and Description
ID collision with another mod	ID below 50000 collides with vanilla or existing mod	Reassign ID to 50000+ range and update all cross-references

---

Storage item balance reference

The table below documents the storage capacity of selected vanilla Unturned™ containers and wearables for comparison when authoring custom storage items.

Item (vanilla reference)	Type	Grid	Slots
Wooden Crate	Placeable	6×4	24
Metal Crate	Placeable	7×5	35
Large Locker	Placeable	4×6	24
Civilian Backpack	Wearable	4×5	20
Military Backpack	Wearable	5×7	35
Alice Pack	Wearable	6×8	48
Duster Vest	Wearable	3×3	9
Plate Carrier	Wearable	4×4	16

Balance guidance

The 57 Studios™ cohort recommendation for new storage mods is to match capacity to the visual size of the container. A small box that provides 48 slots creates balance problems on servers where storage space is a competitive resource. Match the slot count to what the container would realistically hold, then adjust based on server feedback after publishing.

RP server coordination

Storage mods that offer significantly more capacity than vanilla equivalents can disrupt RP server economy. Coordinate with the server operator before publishing high-capacity containers intended for a specific server. Document the container's intended role and capacity in the Steam Workshop description so server operators can make informed decisions before subscribing.

---

Frequently asked questions

What is the maximum grid size I can author?

The engine does not enforce a hard maximum, but the inventory UI clips at approximately 10 columns wide and 8 rows tall on standard 1080p resolution. The 57 Studios™ cohort recommendation is a maximum of Width 10 and Height 8 for any container intended for public mod use. Larger grids require UI scrolling, which is functional but reduces usability.

Can I make a container that holds only specific item types?

Vanilla Unturned™ storage containers accept any item that fits within the grid dimensions. Type-restricted containers (e.g., ammo-only) require custom scripting through the modding API's extension points. This is outside the scope of standard .dat authoring. If you need a type-restricted container, the approach is a server-side plugin rather than a .dat field.

Why does my backpack not appear in the clothing slot?

Confirm the Type field is Backpack or Vest. A clothing item with Type Shirt appears in the shirt slot, not the backpack slot. The storage fields Storage_X and Storage_Y are ignored for non-backpack, non-vest clothing types — they produce no error and no storage.

Can the same item function as both a placeable container and a wearable?

No. The Type field determines whether an item is Storage (placeable) or Backpack or Vest (wearable). An item cannot simultaneously occupy both categories. If the design requires a container that can be placed and also carried, author two separate items — one Storage and one Backpack — with identical visual appearance and separate GUIDs.

Why does my locked container open without the key?

The most likely cause is that the key item's Type field is not set to Key. An item must have Type Key for the engine to recognize it as a key during the lock-check. The second possible cause is that Accessible true is set, which allows any player to use the key regardless of ownership status.

How do I make a container that anyone can loot?

Set Accessible true in the container .dat. This allows any player regardless of group membership to open the container. Map-side loot containers in vanilla Unturned™ maps use Accessible true.

What happens to items inside a container when it is destroyed?

When a container is destroyed (health reaches zero), the items inside are dropped at the container's location as loose item pickups. The items are not destroyed with the container. This behavior is controlled by the Unturned™ server runtime and is not configurable in the .dat.

Can I author a container with a zero-slot grid?

Setting Width 0 and Height 0 produces a container with zero slots. The storage UI opens but shows an empty grid. This is not a practical configuration; do not author zero-slot containers for public use.

How do I set the display name and description for my container?

Author an English.dat file in the same folder as the container's main .dat. Set the Name field to the in-game display name and Description to the tooltip text. Include the slot count in the description so players know the capacity before picking up the item.

Why does my container fall through the ground when placed?

The prefab is missing a collider on the base of the container. Add a BoxCollider or Capsule Collider to the prefab root in Unity, sized to the container's physical dimensions. Rebuild the master bundle after adding the collider.

Can I change the grid size of a container at runtime?

Runtime modification of the storage grid requires the Unturned™ plugin API (RocketMod or OpenMod) and is outside the scope of standard .dat authoring. The .dat grid is fixed at load time.

How are container items saved on a dedicated server?

Container item state is saved to the server's save directory in the Level folder. Items are stored per-container by the container's position and GUID. On server restart, items are restored from the save file. If the container is destroyed before the server saves, items inside may be lost.

Can two different storage mods use the same ID?

No. IDs are global within the Unturned™ item system. Two items with the same ID will conflict; only one will load correctly. Use IDs in the 50000+ range for community mods and check the Smartly Dressed Games modding documentation for reserved ID ranges. Always generate a fresh GUID for every new item — GUIDs are the long-term stable identifier.

---

Appendix A: complete placeable storage .dat field reference

Field	Type	Required	Default	Purpose
ID	uint16	Yes	—	Unique item ID
GUID	uint128	Yes	—	Globally unique identifier
Type	enum	Yes	—	Must be Storage
Name	string	Yes	—	Internal name
Rarity	enum	No	Common	Item rarity
Size_X	uint8	Yes	—	Inventory footprint width
Size_Y	uint8	Yes	—	Inventory footprint height
Width	uint8	Yes	—	Storage grid width (columns)
Height	uint8	Yes	—	Storage grid height (rows)
Display	bool	No	false	Show top item on container exterior
Locked	bool	No	false	Container starts locked
Key	uint16	No	0	Key item ID (0 = no key)
Accessible	bool	No	false	Allow access by all players
Vulnerable	bool	No	true	Container can be damaged
Health	uint16	No	500	Container hit points
Range	float	No	3.0	Interaction range in meters
Salvageable	bool	No	false	Drops salvage on destroy
Salvage_Duration_Multiplier	float	No	1.0	Salvage time multiplier
Explosion	uint16	No	0	Effect on destruction

---

Appendix B: complete wearable storage .dat field reference

Field	Type	Required	Default	Purpose
ID	uint16	Yes	—	Unique item ID
GUID	uint128	Yes	—	Globally unique identifier
Type	enum	Yes	—	Backpack or Vest
Name	string	Yes	—	Internal name
Rarity	enum	No	Common	Item rarity
Size_X	uint8	Yes	—	Inventory footprint width
Size_Y	uint8	Yes	—	Inventory footprint height
Storage_X	uint8	Yes	—	Storage grid width
Storage_Y	uint8	Yes	—	Storage grid height
Armor	float	No	1.0	Damage multiplier while worn
Falling_Damage_Multiplier	float	No	1.0	Fall damage multiplier
Proof_Water	bool	No	false	Water damage immunity
Proof_Fire	bool	No	false	Fire damage immunity
Proof_Radiation	bool	No	false	Radiation damage immunity

---

Appendix C: vehicle trunk field reference

Field	Type	Required	Default	Purpose
Trunk_X	uint8	No	0	Trunk grid width (0 = no trunk)
Trunk_Y	uint8	No	0	Trunk grid height
Locked	bool	No	false	Trunk locked when vehicle is locked

Vehicle trunk fields are authored in the vehicle .dat, not in a separate storage item .dat. The capacity math is identical: Trunk_X × Trunk_Y = total trunk slots.

---

Mod folder structure for a storage mod

A storage mod with two containers (a field crate and a wall locker) uses the following folder structure. This matches the cohort-validated layout from the Project Folder Structure and GUIDs article.

MyStorageMod/
├── Bundles/
│   ├── Items/
│   │   ├── FieldCrate/
│   │   │   ├── Item.dat          ← the .dat for the field crate
│   │   │   ├── English.dat       ← localization
│   │   │   └── (FBX source — not shipped in bundle)
│   │   └── WallLocker/
│   │       ├── Item.dat          ← the .dat for the wall locker
│   │       ├── English.dat
│   │       └── (FBX source — not shipped in bundle)
│   └── myStorageMod.unity3d      ← the exported master bundle
└── Workshop.dat                  ← Steam Workshop metadata

Each container item has its own subfolder under Items/. The master bundle contains both prefabs. The Workshop.dat declares the mod's Steam Workshop ID and mod name. Do not ship the FBX source files — only the .unity3d bundle and the .dat files are required by the game.

---

Prefab structure for placeable containers

Placeable storage containers require a Unity prefab with a specific structure. The Unturned™ barricade system expects the following layout:

MyStoragePrefab (root)
├── Model (MeshRenderer + MeshFilter for container exterior)
├── Trigger (BoxCollider, Is Trigger = true, sized to container bounds)
└── AudioSource (Spatial Blend 1.0, Play On Awake false, Loop false)

The InteractableStorage script is wired by the Unturned™ runtime when the bundle is loaded. The modder's responsibility is to provide the visual geometry, a correctly-sized trigger collider, and an AudioSource for interaction sounds. The trigger collider defines the hit volume for player interaction — size it to closely match the visual bounds of the container model.

Collider sizing matters for placement

An undersized trigger collider makes the container difficult to interact with from normal approach angles. An oversized trigger collider causes placement conflicts where the container reports a collision even though its visual model would fit in the space. The cohort recommendation is to match the trigger collider to the visual model's axis-aligned bounding box with a 5–10% margin on each axis.

---

Best practices summary

The following practices reduce the most common authoring errors in storage mods:

• Use IDs in the 50000+ range for all custom storage items to avoid collision with vanilla and popular community mods.
• Generate a fresh GUID for every new item. Never reuse GUIDs across items, even if the items are copies of each other with different IDs.
• Set Accessible false by default for any container intended for group or personal use. Change to Accessible true only for loot containers placed on maps.
• Set Vulnerable true for any container intended to be used in PvP environments. Indestructible containers are generally considered unfair in competitive contexts.
• Include slot count in the English.dat description. Players make equip decisions based on capacity; the tooltip is the primary discovery surface.
• Test the container in single-player before testing on a dedicated server. Single-player surfaces prefab and .dat errors without the added complexity of server networking.
• Confirm that Width (or Storage_X for wearables) is at least as wide as the widest item the container is expected to hold. A container that cannot hold its intended contents reads as a bug to players.
• Keep wearable grids within the vanilla balance range unless the server operator has specifically requested a high-capacity item. Oversize wearables disrupt server economy faster than oversize placeable containers.

---

Cross-references

• Clothing Asset Reference — the previous article; covers the full clothing asset system including worn armor and appearance.
• Throwable Asset — the next article; grenade and throwable item configuration.
• Project Folder Structure and GUIDs — folder layout and GUID workflow required before authoring any asset.
• Master Bundle Export — how to package the prefab and .dat for in-game use.
• Gun Mod Tutorial — reference article for the cohort's .dat authoring conventions and bundle workflow.
• Smartly Dressed Games Modding Documentation — official Unturned™ modding reference.
• Unturned on Steam — official Steam listing.

---

Document history

Version	Date	Author	Notes
1.0	2025-05-18	57 Studios	Initial publication. Full placeable and wearable storage field reference with grid math, locking semantics, and authoring pitfalls.
1.1	2025-05-18	57 Studios	Expanded with display containers, lock state matrix, footprint planning example, and balance guidance.