Bag Asset Reference

Intermediate40-60 minutesWindowsNotepad++Unity Editor

The bag asset is not a standalone item type. It is the abstract base class - ItemBagAsset in the Unturned™ runtime - from which backpack assets derive their storage grid capability. A standalone bag asset cannot be placed, equipped, or interacted with in the game world. It exists solely as a code-level inheritance node that provides the Width and Height fields that define a rectangular storage grid. Every backpack item you have ever used in Unturned™ - from a cloth daypack to the Alicepack military cargo backpack - inherits its storage dimensions from ItemBagAsset.

This article is the 57 Studios™ reference for the bag asset as a system component. It covers the ItemBagAsset class, its two fields (Width and Height), its position in the class inheritance chain, how its grid dimensions propagate through to the ItemBackpackAsset subclass, how the bag-level grid math differs from the clothing-level Storage_X/Storage_Y fields used by vest items, and the practical implications of the bag being an abstract base class for mod authors. The article also covers the relationship between the bag base class and the ItemClothingAsset class from which it inherits, and the distinction between the bag asset system and the placeable container storage system that uses Width and Height on a different code path.

Documentation source: This article references the official Smartly Dressed Games modding documentation for the ItemBagAsset class definition and the parent ItemClothingAsset class. Game-file evidence is drawn from the 50+ shipped backpack items under Bundles/Items/Backpacks/ in the vanilla Unturned™ asset set.

Who this article is for

This article is written for Unturned™ mod authors who want to understand the class hierarchy that underpins wearable storage items. It is not an authoring tutorial - you cannot author a standalone bag item because the ItemBagAsset class is not usable on its own. This article is a reference for understanding where the backpack's Width and Height fields come from, how the grid math works at the base-class level, and how the inheritance chain connects the abstract bag concept to the concrete backpack items you author. If you are looking for the practical authoring guide for backpack items, read Backpack Asset Reference instead.

What you will learn

• The exact position of ItemBagAsset in the Unturned™ class inheritance chain.
• The two fields that ItemBagAsset contributes: Width and Height, both uint8 with a default value of 0.
• Why the bag class exists as an abstract base rather than being collapsed into ItemBackpackAsset.
• How the Width/Height field pair is distinct from the Storage_X/Storage_Y pair used by vest items.
• The grid capacity math and the interaction between bag-level grid dimensions and inventory UI rendering.
• How the bag base class relates to the placeable container storage system that shares the same field names.
• The practical implications of the bag being an abstract base class for mod authors diagnosing backpack configuration issues.
• The field inheritance resolution order: how ItemBagAsset fields override parent defaults and how ItemBackpackAsset inherits them.

Inheritance chain

The full inheritance chain from the root item class to the concrete backpack type is:

ItemAsset
  └── ItemClothingAsset   (slot assignment, Armor, wearable behavior, Useable Clothing)
      └── ItemBagAsset    (Width, Height - abstract base, not usable on its own)
          └── ItemBackpackAsset (no unique fields - concrete type, usable as Backpack item)

Each layer in the chain contributes specific functionality to the final backpack item. Understanding which fields come from which layer is essential for diagnosing configuration issues.

The flowchart above traces the full inheritance chain. Note that ItemBagAsset introduces exactly two fields: Width and Height. The Armor field is introduced at the ItemClothingAsset level and is inherited by ItemBagAsset, but the SDG documentation explicitly states that Armor has no effect on backpacks because "backpacks do not cover any body part(s) when worn." The Storage_X and Storage_Y fields are also introduced at the ItemClothingAsset level but are used by the Vest slot, not by the Bag or Backpack classes. The Bag class provides its own storage fields (Width and Height) that are distinct from the clothing-level Storage_X and Storage_Y.

Why the bag class exists as a separate node

The ItemBagAsset class exists as a separate node in the inheritance chain because it represents a generic "rectangular container" concept that could theoretically be used by item types other than backpacks. The class defines a width and height for a two-dimensional grid. The ItemBackpackAsset subclass then specializes this generic container concept into a wearable item that occupies the Backpack slot. The separation of concerns - grid dimensions in the base class, wearable behavior in the subclass - is a standard object-oriented design pattern that allows the grid logic to be tested and validated independently of the clothing system.

In practice, the Unturned™ modding community has not produced any non-backpack item types that inherit from ItemBagAsset. The base class exists primarily as an architectural node and as a reference point for code-level documentation. The only concrete type that uses ItemBagAsset in the shipped game is ItemBackpackAsset.

ItemBagAsset field reference

The ItemBagAsset class introduces two fields. Both are inherited unmodified by ItemBackpackAsset.

Field	Type	Default	Inherited by	Purpose
Width	uint8	0	ItemBackpackAsset	Number of columns in the storage grid. A value of 0 means no horizontal storage. The field is defined at the bag level to represent the horizontal dimension of a generic rectangular container.
Height	uint8	0	ItemBackpackAsset	Number of rows in the storage grid. A value of 0 means no vertical storage. The field is defined at the bag level to represent the vertical dimension of a generic rectangular container.

Field type and valid range

Both Width and Height are typed as uint8, meaning they accept integer values from 0 to 255 inclusive. The practical range is constrained by the inventory UI rendering limits: values above 10 for Width or above 8 for Height produce grids that clip outside the bounds of the standard inventory panel on most player screen resolutions. The 57 Studios cohort recommendation is to stay within the 0-to-10 range for both fields on any backpack item intended for public use.

Default value behavior

The default value for both Width and Height is 0. When both fields are 0 (or when both fields are absent from the .dat file), the item inheriting from ItemBagAsset provides zero storage grid slots. This is the correct configuration for cosmetic-only backpacks (capes, shields, wings, novelty items) that occupy the Backpack slot without expanding inventory capacity. The default of 0 ensures that an item author who does not explicitly set Width and Height produces a wearable backpack item that provides no storage, rather than producing an arbitrarily sized grid.

Field inheritance resolution

When the engine reads a backpack .dat file, it resolves fields through the following priority order:

1. The concrete .dat file (the backpack's Asset.dat) - explicit field values here override everything below.
2. The ItemBackpackAsset class defaults (no unique fields - passes through to parent).
3. The ItemBagAsset class defaults (Width: 0, Height: 0).
4. The ItemClothingAsset class defaults (slot assignment, Armor, wearable behavior).
5. The ItemAsset class defaults (common item properties).

If a backpack .dat file does not include Width or Height, the engine falls through the inheritance chain to the ItemBagAsset defaults of 0. The backpack will provide zero storage slots. This is the standard failure mode for a first-time backpack modder who omits the storage fields.

The sequence above shows how field resolution works for a backpack that explicitly sets Width and Height but omits the Armor field. The explicit Width and Height values are used directly; the Armor field falls through to the ItemClothingAsset default of 1.0.

Grid capacity math at the bag level

The grid capacity formula is identical at every level of the inheritance chain: Width × Height = total slot count. The bag-level Width and Height fields define the grid dimensions. No additional calculation, scaling, or offset is applied at the ItemBackpackAsset level.

Role of default zero values in grid math

When Width is 0 and Height is 0 (the defaults inherited from ItemBagAsset), the grid capacity calculation produces 0 × 0 = 0 slots. When one dimension is non-zero and the other is zero - for example, Width 8 and Height 0 - the capacity is still 8 × 0 = 0 slots. Both dimensions must be set to non-zero values for the backpack to provide usable storage. This is a common authoring mistake: setting Width but forgetting Height, or vice versa, produces a backpack that equips correctly but provides zero storage slots.

Grid area comparison by dimension pair

The following table shows the grid capacity for each dimension pair, independent of whether the fields are set at the bag level or at the backpack level. The math is identical regardless of where the values originate.

Width	Height	Total slots	Notes
0	0	0	Default - no storage
4	4	16	Small backpack, equivalent to a civilian knapsack
5	4	20	Small tactical pack
5	6	30	Medium military pack
5	7	35	Tall-narrow expedition pack
6	5	30	Medium cargo pack (Leather Pack configuration)
7	4	28	Wide civilian pack (Daypack, Dufflebag configuration)
8	5	40	Tactical pack (Pack_Spec_Ops configuration)
8	7	56	Large cargo pack (Alicepack configuration)
10	8	80	Cohort-recommended maximum for UI visibility
10	10	100	UI clipping on most screen resolutions
255	255	65,025	Theoretical maximum, not practically usable

The grid capacity is a simple area calculation. The same math applies to placeable containers that use the Width and Height fields on a different code path (the InteractableStorage system rather than the ItemBagAsset system). The field names are the same, the data type is the same, and the grid math is identical, but the runtime code path that reads these fields is different for placeable containers versus wearable backpacks.

How bag differs from backpack

The distinction between bag and backpack is the single most frequently misunderstood concept in the wearable storage system. The two terms are often used interchangeably in community documentation, but they refer to different levels of the class hierarchy with different behaviors.

Aspect	ItemBagAsset	ItemBackpackAsset
Class role	Abstract base class	Concrete usable type
Can be authored as standalone item	No - not usable on its own	Yes - this is the item type you author
Provides Width and Height fields	Yes - defines them	Yes - inherits them
Provides wearable behavior	No - inherits from ItemClothingAsset	Yes - inherits from ItemBagAsset + ItemClothingAsset
Slot assignment	None (base class)	Backpack slot (via Type: Backpack)
Can have blueprints	No blueprint system at this level	Yes - Salvage, Repair, Craft blueprints
Inventory audio defaults	Not applicable	Varies by Width/Height values
Appears in loot tables	Never	Yes, when configured in spawn tables
Has a prefab requirement	No	Yes - requires prefab in master bundle
Has an English.dat requirement	No	Yes - requires Name and Description
Can be equipped by the player	No	Yes
Can store items	No (no grid without dimensions)	Yes, when Width and Height are set

The most important distinction for mod authors is that you never author an ItemBagAsset directly. You author an ItemBackpackAsset (a backpack item) that inherits from ItemBagAsset. The bag class is the source of the storage grid fields; the backpack class is the wearable item that uses them.

Relationship between Width/Height and Storage_X/Storage_Y

Unturned™ has two distinct field pairs for defining wearable storage grids. They serve different slots and cannot be used interchangeably.

Field pair	Defined in	Used by	Item type
Width, Height	ItemBagAsset	Backpack items	Type Backpack
Storage_X, Storage_Y	ItemClothingAsset	Vest items	Type Vest

The two field pairs have identical semantics (horizontal count and vertical count of inventory slots) and identical data types (uint8). They differ only in which class defines them and which slot they apply to. A backpack reads Width and Height from the bag level of its inheritance; a vest reads Storage_X and Storage_Y from the clothing level of its inheritance.

Why two field pairs exist

The existence of two separate field pairs for the same concept is a legacy design choice in the Unturned™ codebase. The ItemBagAsset class was introduced to provide a generic rectangular container concept, while the Storage_X/Storage_Y fields on ItemClothingAsset were added to the clothing system specifically for vest items. The two systems evolved independently and were never unified. Mod authors must use the correct field pair for the slot they are authoring: Width/Height for backpacks, Storage_X/Storage_Y for vests.

Practical implications of ItemBagAsset being abstract

The fact that ItemBagAsset is an abstract base class has several practical implications for mod authors who are diagnosing configuration issues or designing wearable storage items.

You cannot search for "bag" items in game files

Because ItemBagAsset is never instantiated directly, there is no Bundles/Items/Bags/ folder in the vanilla Unturned™ asset set. All wearable storage items are Type Backpack items under Bundles/Items/Backpacks/. If a workshop mod or community resource refers to a "bag item," it is almost certainly a backpack item using the Type Backpack field value. The term "bag" in community documentation is an informal shorthand for any wearable container, not a reference to the ItemBagAsset class.

The Width and Height fields are the only bag-level fields you can set

When authoring a backpack .dat file, the only fields that originate from ItemBagAsset are Width and Height. Every other field in a backpack .dat comes from ItemClothingAsset (the wearable behavior, slot assignment, Armor) or from ItemAsset (the identity fields, inventory footprint, Pro flag). If you are troubleshooting a backpack configuration, the bag-level fields are the simplest part of the file: two values, one purpose, no edge cases.

Field name collisions between bag system and storage system

The Width and Height field names are shared between the ItemBagAsset wearable storage system and the placeable container storage system (crates, lockers, safes). The same field names appear on two entirely separate code paths:

• In wearable backpacks: Width and Height are read by the ItemBagAsset code path that creates a wearable storage grid.
• In placeable containers: Width and Height are read by the InteractableStorage code path that creates a world-interactable storage grid.

The field names are the same, but the context determines which code path reads them. A Type Backpack item routes Width and Height through the wearable path. A Type Storage item routes Width and Height through the placeable path. The grid math is identical; the runtime behavior (equip vs. place-in-world) is different.

Grid-only backpacks are possible through field omission

A backpack that omits Width and Height is technically a "grid-only" item: it occupies the Backpack slot, renders a prefab on the character skeleton, but provides zero storage slots. This is the correct configuration for cosmetic-only backpacks (capes, shields, wings). The bag-level default of 0 for both fields ensures that omitting the storage fields does not produce a random grid size. The artifact of this design is that the default bag is an empty container, which is the correct default for items that inherit container capability but do not intend to use it.

How the inheritance chain affects English.dat requirements

The English.dat localization file is not part of the ItemBagAsset or ItemBackpackAsset class hierarchy. It is a separate file that the engine reads alongside the primary .dat file. The bag inheritance chain has no effect on localization behavior. Every backpack item requires an English.dat file regardless of its position in the inheritance chain. The English.dat format is the same standard key-value format used by all item types:

Name Backpack Display Name
Description Description text shown in the inventory tooltip.

The localization system does not interact with the class hierarchy. The Name field in English.dat is the player-facing display name; the Name field in the primary .dat file is the internal name used for console commands and cross-reference. They are separate fields on separate files.

Blueprint system cross-reference

The blueprint system (Blueprints block in the .dat) is not defined at any level of the ItemBagAsset inheritance chain. Blueprints are a property of the item asset system as a whole and are attached to any item that declares them. Backpack items inherit blueprint capability from the ItemAsset base class, not from ItemBagAsset. The blueprint block is authored in the concrete backpack's .dat file. The bag class has no blueprint-related fields.

For the blueprint patterns used on backpack items (Salvage, Repair, and Dye color variants), see the Backpack Asset Reference article, which documents the blueprint blocks observed in the shipped game files.

Diagnostic table: bag-level inheritance issues

Symptom	Most likely cause	Resolution
Backpack equips but provides zero storage slots	Width or Height missing from .dat (defaults to 0 from ItemBagAsset)	Add Width and Height with positive values in the backpack .dat
Backpack equips but provides only a single-column grid	Width set but Height omitted (defaults to 0, producing 0 total slots)	Add both Width and Height
Backpack equips but provides only a single-row grid	Height set but Width omitted (defaults to 0, producing 0 total slots)	Add both Width and Height
Backpack provides exactly the wrong number of slots	Width or Height value is one digit off (e.g., 6 instead of 7)	Re-check the field values against the intended grid math
Backpack grid is too wide for the UI	Width exceeds 10	Reduce Width to 10 or lower
Backpack grid is too tall for the UI	Height exceeds 8	Reduce Height to 8 or lower
Backpack provides storage when it should be cosmetic-only	Width and Height are set to non-zero values on a cosmetic item	Remove Width and Height lines to fall back to default 0
Armor field on backpack has no effect	Armor is inherited from ItemClothingAsset but documented to have no effect on backpacks	Remove the Armor field; backpacks cannot provide armor regardless of the field value
Backpack is invisible when equipped but provides storage	Prefab is missing, but the bag-level fields are read correctly	The storage fields (Width/Height) are independent of the visual prefab - fix the prefab issue separately
Storage_X and Storage_Y fields on a backpack have no effect	Backpacks read Width/Height from ItemBagAsset, not Storage_X/Storage_Y from ItemClothingAsset	Replace Storage_X and Storage_Y with Width and Height

Worked example: tracing bag-level field inheritance through a concrete backpack

The following worked example traces how the bag-level Width and Height fields propagate through the inheritance chain for a concrete backpack configuration based on the Alicepack (vanilla ID 253).

Alicepack .dat fields (bag-relevant subset)

Type Backpack
Useable Clothing
Width 8
Height 7

Field resolution trace

Step 1: The engine reads Type Backpack. This instructs the asset loader to use ItemBackpackAsset as the runtime type, which inherits the storage grid from ItemBagAsset.

Step 2: The engine reads Useable Clothing. This is a field from ItemClothingAsset that enables wearable behavior. Backpacks inherit this field from the clothing layer, not from the bag layer.

Step 3: The engine reads Width 8. The field Width is defined in ItemBagAsset (uint8, default 0). The concrete .dat provides an explicit value of 8, which overrides the ItemBagAsset default. The value propagates to the runtime grid dimension without modification.

Step 4: The engine reads Height 7. The field Height is defined in ItemBagAsset (uint8, default 0). The concrete .dat provides an explicit value of 7, which overrides the ItemBagAsset default. The value propagates to the runtime grid dimension without modification.

Step 5: The runtime computes grid capacity: Width 8 × Height 7 = 56 total slots. No additional calculation, scaling, or offset is applied. The grid is created with 56 cells when the player equips the backpack.

What would happen if the bag-level defaults were different

If the ItemBagAsset defaults for Width and Height were non-zero (for example, Width: 4, Height: 4), then every cosmetic-only backpack that omitted Width and Height would erroneously provide a 16-slot storage grid. The designers of the Unturned™ asset system chose zero defaults specifically to avoid this outcome. A cosmetic cape that inherits from ItemBagAsset should provide zero storage unless the author explicitly enables storage by setting Width and Height. The zero defaults implement this design intent correctly.

Reference: all shipped backpacks by bag-level configuration

The following table lists every shipped backpack item in the vanilla Unturned™ asset set that uses non-zero Width and Height values (i.e., items that actually use the bag-level grid fields). This table documents the effective bag-level configuration for every functional backpack in the game.

Item	ID	Width	Height	Slots	Bag class used?
Daypack (white)	205	7	4	28	Yes (via ItemBackpackAsset)
Daypack (red)	9	7	4	28	Yes
Daypack (blue)	201	7	4	28	Yes
Daypack (green)	202	7	4	28	Yes
Daypack (orange)	203	7	4	28	Yes
Daypack (purple)	204	7	4	28	Yes
Daypack (yellow)	206	7	4	28	Yes
Daypack (black)	200	7	4	28	Yes
Travelpack (white)	251	5	7	35	Yes
Travelpack (red)	250	5	7	35	Yes
Travelpack (blue)	246	5	7	35	Yes
Travelpack (green)	247	5	7	35	Yes
Travelpack (orange)	248	5	7	35	Yes
Travelpack (purple)	249	5	7	35	Yes
Travelpack (yellow)	252	5	7	35	Yes
Travelpack (black)	245	5	7	35	Yes
Dufflebag (white)	1188	7	4	28	Yes
Dufflebag (red)	1187	7	4	28	Yes
Dufflebag (blue)	1183	7	4	28	Yes
Dufflebag (green)	1184	7	4	28	Yes
Dufflebag (orange)	1185	7	4	28	Yes
Dufflebag (purple)	1186	7	4	28	Yes
Dufflebag (yellow)	1189	7	4	28	Yes
Dufflebag (black)	1182	7	4	28	Yes
Alicepack	253	8	7	56	Yes
Alicepack (Arctic)	1511	8	7	56	Yes
Leather Pack	1014	6	5	30	Yes
Pack_Spec_Ops	1170	8	5	40	Yes
Diving Tank	1178	2	4	8	Yes

Every other backpack in the shipped set (capes, shields, wings, quivers, tails, shields, instrument cases, novelty items) uses the default Width: 0, Height: 0 from the ItemBagAsset base class because those items omit Width and Height from their .dat files. They inherit bag-level grid capability but do not exercise it.

Frequently asked questions

Can I author an ItemBagAsset directly as a standalone item?

No. The ItemBagAsset class is an abstract base class that is not usable on its own. The SDG documentation explicitly states this: "This class is a base class that other classes are derived from. It is unusable on its own." There is no Type Bag or Type BagAsset enum value that would allow you to instantiate a bag as a standalone item. If you attempt to author an item with Type Bag or omit the Type field, the engine will either fail to load the item or silently ignore it.

Does the bag class affect placeable container storage?

No. Placeable containers (crates, lockers, safes) use Width and Height fields on a different code path (InteractableStorage), not through the ItemBagAsset class hierarchy. The field names are the same and the grid math is identical, but the runtime code path is entirely separate. A placeable container does not inherit from ItemBagAsset; it reads Width and Height from its own Storage asset type's field parser.

Why are there no bag items in the game files if ItemBagAsset exists?

Because ItemBagAsset is never instantiated directly. The only concrete type that inherits from ItemBagAsset is ItemBackpackAsset, and backpack items are stored in the Bundles/Items/Backpacks/ folder. The bag class exists only in the compiled game code and the SDG documentation. There are no "bag" folders, no "bag" prefabs, and no "bag" .dat files in the shipped asset set.

Do I need to understand ItemBagAsset to author a backpack?

Not for routine authoring. You can author a functional backpack by following the worked example in the Backpack Asset Reference without knowing that the Width and Height fields come from ItemBagAsset. You need to understand the bag class only when you are diagnosing inheritance-related bugs (an Armor field that has no effect on a backpack, or a missing Width field that defaults to zero) or when you are reading the official SDG documentation and encountering the ItemBagAsset class reference.

Could a future Unturned update add a usable bag type that is not a backpack?

Technically yes. The ItemBagAsset class provides the grid infrastructure for any future item type that needs a rectangular container. The engine code path for bag-level grid creation is generic enough to support new item types. However, no such item type has been added in any Unturned™ update to date, and the SDG documentation does not hint at any planned bag-type items. The bag class remains an architectural placeholder with no concrete usage beyond backpacks.

How do I set bag-level fields if I cannot author a standalone bag?

You set bag-level fields by including them in the backpack's .dat file. When the engine reads a backpack .dat, it resolves the Width and Height fields by checking the concrete file first (your Asset.dat) and falling back to the ItemBagAsset defaults if the fields are absent. Setting Width and Height in your backpack .dat is the same as setting bag-level field values - the runtime value is the same regardless of which layer of the inheritance chain defines the default.

Does the ItemBagAsset class have any methods or behaviors beyond the two fields?

Not from the mod author's perspective. At the code level, ItemBagAsset may have internal methods that the engine uses for grid creation and inventory slot management, but these are not exposed through the .dat file system. The only interface between the mod author and the ItemBagAsset class is the Width and Height fields. Everything else happens automatically in the engine runtime.

What happens if I set Width to 0 but Height to a positive value?

The grid capacity calculation 0 x positive = 0 applies. The backpack will equip correctly and the prefab will be visible, but the storage grid will have zero usable slots. Both Width and Height must be set to positive values for functional storage. This is one of the most common field-configuration errors in first-time backpack authoring, and it is directly traceable to the bag-level default of zero for both dimensions.

Does the bag class use uint8 or uint16 for its storage fields?

The ItemBagAsset class defines both Width and Height as uint8 values. This limits each dimension to a maximum of 255. The uint8 type is sufficient for the practical range because inventory UI constraints (grid width above 10 clips off-screen) make the uint8 ceiling irrelevant for any playable scenario. The choice of uint8 over uint16 is an engine-level optimization: backpack grid dimensions do not need a 65,535 maximum because the functional cap is 10 or fewer on each axis.

Can I use bag-level Width and Height fields on a non-backpack clothing item?

No. The Width and Height fields are defined in ItemBagAsset, which is a class that sits between ItemClothingAsset and ItemBackpackAsset in the inheritance chain. Clothing items that inherit directly from ItemClothingAsset (hats, shirts, pants, masks, vests, glasses) do not inherit from ItemBagAsset and cannot use bag-level fields. If you attempt to add Width and Height to a hat's .dat file, the engine will silently ignore them because the ItemHatAsset class does not inherit from ItemBagAsset.

What is the relationship between ItemBagAsset and the placeable container Width/Height?

The relationship is entirely coincidental. Both the wearable bag system and the placeable container system use Width and Height as field names with uint8 type and identical grid-math semantics. The two systems read these field names from the same .dat format but route them through different code paths based on the Type field value. A Type Backpack item routes Width and Height through the ItemBagAsset wearable grid system. A Type Storage item routes Width and Height through the InteractableStorage placeable grid system. The field-name collision is a product of independent development timelines and is not architecturally meaningful.

Why does the SDG documentation call this a "bag" asset when no bag items exist in the game?

The SDG documentation uses "bag asset" as the chapter title for the ItemBagAsset class documentation. The term "Bag Assets" describes the class name (ItemBagAsset), not a category of usable in-game items. The documentation naming convention follows the C# class name, which itself reflects the original design intention that ItemBagAsset would be a generic base for any bag-type container. The "bag" name has persisted through the Unturned codebase despite the class never having been used for anything other than backpacks.

Troubleshooting bag-level field issues

The following expanded diagnostic table covers the full range of bag-level field inheritance issues that mod authors may encounter when authoring backpack items. Each entry traces the symptom to its root cause in the ItemBagAsset inheritance layer.

Symptom	Likely origin in ItemBagAsset	Root cause	Resolution path
Backpack provides no storage	Bag-level defaults (Width=0, Height=0)	Width and Height fields omitted from .dat	Add explicit Width and Height values to the backpack .dat
Backpack provides storage on slot other than Backpack	Not a bag-level issue	Type field set incorrectly	Change Type to Backpack
Backpack has Armor field that does nothing	ItemClothingAsset Armor inherited through ItemBagAsset	Armor documented to have no effect on backpacks	Remove Armor field from backpack .dat
Grid capacity is wrong by exactly one factor	Bag-level field value typo	Width or Height off by a digit	Recheck both values and recalculate Width x Height
Backpack provides 0 slots despite Width and Height being set	Bag-level field resolution order	One of the two fields is spelled wrong or not recognized	Confirm field names match exactly: Width and Height (capitalized)
Backpack shows correct storage but wrong audio	Bag-level InventoryAudio default	Engine selects audio based on Width/Height dimension range	Set explicit InventoryAudio field override if needed
Mod works in single-player but fails on server	Not a bag-level issue	Mod sync issue, not field inheritance	Check mod packaging and server workshop sync

Bag-level field visual reference: the inventory grid anatomy

The diagram below shows how the bag-level Width and Height fields translate to the inventory grid that a player sees when wearing a backpack. The grid is rectangular, with the width dimension running horizontally (columns) and the height dimension running vertically (rows).

Inventory grid created from ItemBagAsset Width and Height fields:

  Width = 7 columns
  +---+---+---+---+---+---+---+
  |   |   |   |   |   |   |   |  ^
  +---+---+---+---+---+---+---+  |
  |   |   |   |   |   |   |   |  Height = 4 rows
  +---+---+---+---+---+---+---+  |
  |   |   |   |   |   |   |   |  |
  +---+---+---+---+---+---+---+  v
  |   |   |   |   |   |   |   |
  +---+---+---+---+---+---+---+

  Total slots: 7 x 4 = 28

  The bag-level fields define the grid dimensions.
  The backpack subclass decides where and when this grid is shown.
  The grid math is identical for every Width and Height pair.

Engine code path differentiation: bag vs. storage

The flowchart below illustrates how the Unturned runtime determines whether Width and Height fields are read through the ItemBagAsset (wearable) code path or the InteractableStorage (placeable) code path. The decision point is the Type field value in the .dat file.

The branching logic above is implemented in the Unturned asset loader, not in the .dat file. The same field names produce different runtime behavior depending on the Type field value. The bag-level fields are meaningful only when the type resolves to Backpack, because only ItemBackpackAsset inherits from ItemBagAsset.

Backpack grid vs. bag-level grid: clarifying the terminology

The phrase "backpack grid" in community documentation sometimes refers to the storage grid that a backpack provides and sometimes to the container concept represented by ItemBagAsset. The two meanings are related but distinct:

Term	What it refers to	Where the fields are defined	Scope
Bag-level grid	The abstract rectangular container concept	ItemBagAsset (Width, Height)	Generic container dimensions
Backpack grid	The concrete wearable storage grid	ItemBackpackAsset (inherits from ItemBagAsset)	Specific to Backpack slot
Placeable container grid	The world-interactable storage grid	InteractableStorage (separate code path)	Specific to placed objects

Understanding the distinction helps mod authors identify which documentation is relevant when reading community resources. A tutorial that says "set the bag grid to 7x4" is giving the same instruction as a tutorial that says "set Width 7 and Height 4 in the backpack .dat file." The terminology is inconsistent across resources because the underlying code architecture uses a base-class pattern that community documentation does not always acknowledge.

Appendix A: ItemBagAsset .dat field quick reference

Field	Type	Range	Default	Defined in	Purpose
Width	uint8	0-255 (practical: 0-10)	0	ItemBagAsset	Horizontal grid slot count for the wearable storage grid. Inherited unmodified by ItemBackpackAsset.
Height	uint8	0-255 (practical: 0-8)	0	ItemBagAsset	Vertical grid slot count for the wearable storage grid. Inherited unmodified by ItemBackpackAsset.

No other fields are defined in ItemBagAsset. All other fields on a backpack .dat originate from ItemClothingAsset or ItemAsset.

Appendix B: Inheritance field source table

The following table maps every field that can appear on a backpack .dat to its originating class in the inheritance chain. Fields that originate from ItemBagAsset are highlighted as bag-level fields.

Field	Source class	Notes
ID	ItemAsset	Identity - required
GUID	ItemAsset	Identity - required
Type	ItemClothingAsset	Slot assignment
Name	ItemAsset	Internal name
Rarity	ItemAsset	Optional - highlights color
Useable	ItemClothingAsset	Must be Clothing
Size_X	ItemAsset	Inventory footprint when not equipped
Size_Y	ItemAsset	Inventory footprint when not equipped
Size_Z	ItemAsset	Visual depth scaling
Width	ItemBagAsset	Storage grid horizontal count - bag-level field
Height	ItemBagAsset	Storage grid vertical count - bag-level field
Armor	ItemClothingAsset	No effect on backpacks (SDG documentation)
Pro	ItemAsset	PRO/Gold item gating
Bypass_ID_Limit	ItemAsset	Bypass ID limit for high IDs
Proof_Water	ItemClothingAsset	Water damage immunity
Proof_Fire	ItemClothingAsset	Fire damage immunity
Proof_Radiation	ItemClothingAsset	Radiation damage immunity
Ignore_NPOT	ItemAsset	Non-power-of-two texture warning suppression
Blueprints	ItemAsset (generic)	Crafting, salvage, and repair definitions

The table above makes clear that ItemBagAsset contributes the smallest number of fields of any class in the backpack inheritance chain. Two fields out of approximately eighteen possible fields come from the bag level. The bag class is small, focused, and architecturally simple.

Appendix C: External references

• Smartly Dressed Games modding documentation - Item assets - the official class hierarchy reference. The ItemBagAsset class is documented in the Bag Assets chapter.
• Backpack Asset Reference - the companion article that covers the concrete ItemBackpackAsset type and the complete backpack authoring workflow.
• Storage Asset Reference - covers the placeable container storage system that shares the Width and Height field names on a different code path.
• Clothing Asset Reference - the clothing-level field reference that covers the wearable system that ItemBagAsset inherits from.
• Item Asset Anatomy - the universal field reference for all item types.
• Unturned on Steam - the Unturned™ store page and community hub.

Best practices

• Understand that Width and Height are bag-level fields inherited from ItemBagAsset, not clothing-level fields. This distinction matters when reading SDG documentation or troubleshooting field resolution issues.
• Set both Width and Height to non-zero values on functional backpacks. Omitting one of the two fields produces a zero-slot grid because the bag default is 0 for both dimensions.
• Use the default zero values for cosmetic-only backpacks. Omitting Width and Height is the correct configuration for items that occupy the Backpack slot without providing storage.
• Do not confuse bag-level Width/Height with clothing-level Storage_X/Storage_Y. The field pairs serve different slots and are not interchangeable.
• Remember that the bag class is abstract - you never author a standalone bag item. All wearable storage items are backpack items using Type Backpack.
• When reading community documentation that says "bag," mentally translate to "backpack." The community uses "bag" as a colloquial term for any wearable container, not as a reference to ItemBagAsset.
• If you are designing a new wearable container type that is not a backpack, consider whether it should inherit from ItemBagAsset or use a different base class. The inheritance decision determines which storage fields the item supports.

Cross-references

• Backpack Asset Reference - the previous article; covers the concrete backpack type that inherits from ItemBagAsset.
• Box Asset Reference - the next article in this section.
• Storage Asset Reference - covers the placeable container system with the shared Width and Height field names.
• Clothing Asset Reference - the parent class documentation for the wearable slot system.
• Item Asset Anatomy - the universal shared field reference for every item type.
• Smartly Dressed Games modding documentation - the official field reference.
• Unturned on Steam - game page and community.

Document history

Version	Date	Author	Notes
1.0	2026-07-26	57 Studios	Initial publication. ItemBagAsset base class reference, inheritance chain documentation, field reference, grid math, diagnostic tables, distinction from backpack type.

Authoring checklist

• [ ] Confirm you are authoring a backpack item (Type Backpack), not attempting to author a standalone bag item.
• [ ] Confirm Width and Height are both set to positive values on functional backpacks.
• [ ] Confirm Width and Height are both absent (or set to 0) on cosmetic-only backpacks.
• [ ] Confirm you are using Width/Height for backpacks, not Storage_X/Storage_Y (which is for vests).
• [ ] Confirm the total grid capacity Width × Height matches the intended design.
• [ ] Confirm Width does not exceed 10 (UI visibility limit).
• [ ] Confirm Height does not exceed 8 (UI visibility limit).
• [ ] Verify the backpack does not include Armor (backpacks cannot provide armor; the field would be silently ignored).