Hat Asset Reference

Intermediate40-60 minutesWindowsNotepad++Unity Editor

The hat asset is the data definition for every headwear item in Unturned™ - helmets, caps, beanies, berets, hoods, crowns, masks worn on the head slot, and any other item that occupies the Hat slot on the character model. Hats are the most visually prominent single clothing item because they sit at the top of the character model where the human eye naturally lands first. A well-authored hat asset that deforms correctly with the character head, hides or reveals hair appropriately, and carries the correct Hat_Type category is one of the most effective visual investments a modder can make.

This article is the 57 Studios™ canonical reference for the hat asset subtype within the broader clothing system. It covers every .dat field specific to the ItemHatAsset class - the Hair and Beard visibility flags that control character hair rendering under headwear, the Hat_Type enum for cosmetic categorization, the head slot assignment and how it differs from the Mask and Glasses slots, the character skeleton bones that a hat prefab binds to, and the inheritance path from ItemGearAsset through to ItemClothingAsset. The shared item fields common to every clothing type (ID, GUID, Type, Name, Rarity, Useable Clothing, Size_X, Size_Y) are documented in the base Clothing Asset Reference and are not repeated here except where hat-specific configuration departs from the norm.

Documentation source: This article references the official Smartly Dressed Games modding documentation chapters 45 (Hat Assets) and the ItemGearAsset base class. Game-file evidence is drawn from the shipped hats under Bundles/Items/Hats/ in the vanilla Unturned™ asset set, including the Cap_Black, Firefighter_Helmet, Construction_Helmet, Military_Helmet_Forest, Beret_Forest, Rain_Hat, Fedora, Tophat, and Ghillie_Hood families.

Who this article is for

This article is written for Unturned™ mod authors who have completed at least one clothing mod of another type or have read the Clothing Asset Reference and want to focus specifically on the Hat slot. You should already be familiar with the master bundle pipeline, the SkinnedMeshRenderer bone binding workflow, and the .dat authoring format. If you are new to Unturned™ clothing modding, start with Project Folder Structure and GUIDs and How to Install Unity Editor before returning here. The present article assumes you understand the shared clothing fields and focuses entirely on the hat-specific configuration surface.

What you will learn

• The exact inheritance chain of ItemHatAsset and which class each hat .dat field originates from.
• The three hat-specific fields: Hair, Beard, and Hat_Type - how they work, when to use each, and the default behavior when omitted.
• The head slot assignment and how it differs from the Mask and Glasses slots that share the head region.
• The character skeleton bones that a hat prefab binds to, with the exact bone names required for correct deformation.
• Why the Armor field has no effect on hats regardless of the value set in the .dat file.
• Inventory Size_X and Size_Y guidelines by hat type.
• How to configure English.dat hat entries with accurate descriptions that communicate the hair visibility behavior to players.
• The complete diagnostic table for hat-specific authoring errors.

How the hat slot works

The Hat slot is one of seven mutually exclusive clothing slots in Unturned™. When a player equips a hat item, the runtime binds the item's prefab to the character skeleton head bones, applies the Hair and Beard visibility flags, and categorizes the item with the Hat_Type enum for cosmetic filter UIs. The runtime does not apply armor protection for the Hat slot regardless of whether an Armor field is present in the .dat file - this is the single most important behavioral distinction between the Hat slot and the Shirt, Pants, and Vest slots.

As shown in the sequence diagram above, the hat runtime does exactly three things: bind the prefab to the head skeleton, apply the hair visibility flag, and apply the beard visibility flag. Everything else - armor, storage, damage modification - is outside the hat system's scope.

Hat slot vs. Mask slot vs. Glasses slot

The head region of the character model supports three distinct slots that can be equipped simultaneously. Understanding their overlap is critical for authoring items that do not conflict:

Slot	.dat Type value	Primary bones	Can conflict with	Wear simultaneously
Hat	Hat	Head, Neck	Large masks that extend above the head	Yes, with Mask and Glasses
Mask	Mask	Head, Jaw	Hats that cover the lower face, Glasses at nose bridge	Yes, with Hat and Glasses
Glasses	Glasses	Head	Masks at nose bridge	Yes, with Hat and Mask

A hat that covers the full head (a balaclava-style hood, a knight's helmet with faceplate) will visually overlap with a mask worn underneath. The engine does not prevent simultaneous equip; the visual result depends on the prefab z-ordering and blend shapes. The cohort recommendation is to design hat meshes that sit above the mask region (above the jaw line) and mask meshes that sit below the hat region (below the hat brim or helmet base) to avoid z-fighting between the two slots.

Why Armor does not work on hats

The ItemHatAsset class inherits from ItemGearAsset, which inherits from ItemClothingAsset. The Armor field is defined on ItemClothingAsset and is inherited by all clothing subtypes. However, the Unturned™ runtime explicitly does not apply armor reduction for the Hat slot. The Armor field on a hat .dat is parsed without error at load time, stored in memory, and silently ignored when the engine calculates damage reduction. There is no override flag, no hidden mechanic, and no mod configuration that enables hat armor. This is an engine-level constraint: hats do not cover a body region that participates in the damage-reduction calculation. Several vanilla hats (the Firefighter Helmet at ID 241 with Armor 0.9, the Cap_Blue at ID 426 with Armor 0.95, the Fedora_Mafia at ID 1385 with Armor 0.95) carry Armor values in their .dat files, and those values have no gameplay effect. The cohort recommendation is to omit the Armor field from hat .dat files entirely to avoid implying protection that does not exist.

Hat .dat field reference

Identity and shared fields

Hat items require the same shared identity fields as every other item type. These are documented in full in Item Asset Anatomy and Clothing Asset Reference.

Field	Type	Example	Notes
ID	uint16	42001	Unique item ID. Use 42000+ range per 57 Studios™ allocation or 50000+ for open community range.
GUID	uint128 hex	a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6	128-bit globally unique identifier. Generate fresh per item.
Type	enum	Hat	Must be Hat for hat slot items.
Name	string	MyMilitaryHelmet	Internal name. Used in console commands and cross-reference.
Rarity	enum	Uncommon	Common, Uncommon, Rare, Epic, Legendary, Mythical.
Useable	enum	Clothing	Must be Clothing for all wearable items.
Size_X	uint8	2	Inventory grid width un-equipped.
Size_Y	uint8	2	Inventory grid height un-equipped.
Size_Z	float	0.45	Visual depth scaling for the item icon.

Hat-specific fields

The ItemHatAsset class introduces exactly three slot-specific fields beyond the shared clothing identity block. All three are optional.

Field	Type	Default if absent	Purpose
Hair	flag	Hair hidden	When present, the character's hair remains visible while the hat is equipped. When absent, hair is hidden.
Beard	flag	Beard hidden	When present, the character's beard remains visible while the hat is equipped. When absent, beard is hidden.
Hat_Type	enum	No category	Cosmetic classification for filtering. Valid values: Hat, Helmet, Hood. No gameplay effect.

Hair and Beard flag behavior

The Hair and Beard flag semantics are simple toggle-based visibility controls. They are the only mechanism by which a hat item affects character appearance beyond the prefab mesh.

.dat configuration	Hair behavior	Beard behavior
Neither Hair nor Beard present	Hidden	Hidden
Hair present alone	Visible	Hidden
Beard present alone	Hidden	Visible
Both Hair and Beard present	Visible	Visible

The flags are independent. A hat with Hair but without Beard is a valid configuration - the character's hair shows (e.g., a baseball cap with a ponytail hole) but the beard is hidden (the cap does not logically interfere with the beard, but the designer wants a clean jaw line).

Hat_Type enum values

The Hat_Type field categorizes the hat for cosmetic filter UIs in the game inventory. It has no gameplay effect.

Value	Description	When to use
Hat	Standard hat. Default category for non-helmet, non-hood headwear.	Caps, beanies, berets, fedoras, tophats, cowboy hats, wizard hats, crowns.
Helmet	Protective helmet category. Use for any headwear that visually resembles armor.	Military helmets, construction helmets, knight helmets, riot helmets, space helmets, motorcycle helmets.
Hood	Hood category. Use for any headwear that is soft fabric covering the head.	Ghillie hoods, balaclavas, hoodies worn on the head, monk robes, mask-hybrid headwear.

The Hat_Type value is cosmetic-only. A Hat_Type Helmet hat provides no more armor protection than a Hat_Type Hat hat. The distinction exists for inventory sort/filter purposes and for workshop skin categorization. Players sorting their inventory by category will see hats grouped under their Hat_Type value.

Field behavior summary table

Field	Type	Required	Default	Engine validates?
Hair	flag	No	Hair hidden	Yes - flag presence checked at runtime
Beard	flag	No	Beard hidden	Yes - flag presence checked at runtime
Hat_Type	enum	No	No category	Yes - parsed at load time; invalid values silently default to no category

File and folder structure

A complete hat mod requires the following files organized in the standard item folder layout:

Workshop/Content/304930/<modID>/
├── Bundles/
│   └── <BundleName>.unity3d              ← master bundle containing the hat prefab
└── Items/
    └── MyHat/
        ├── MyHat.dat                      ← primary configuration (fields documented here)
        └── English.dat                    ← display name and description

The folder name, the .dat filename stem, and the internal Name field should all match. This is not enforced at runtime but divergence causes diagnostic confusion, particularly when using console commands that reference the item Name.

Hat inventory footprint guidelines

The Size_X and Size_Y fields define how much inventory grid space the hat occupies when held un-equipped. The cohort-recommended footprint by hat type:

Hat type	Size_X	Size_Y	Rationale
Glasses-sized small headwear (headband, small flower, small crown)	1	1	Minimal bulk, comparable to glasses
Cap, beanie, beret, fedora, small hat	2	1	Small, fits in a pocket row
Standard helmet, hood, baseball cap	2	2	Medium footprint
Large helmet, full-head hood, knight helmet	2	3	Bulky, takes significant inventory space
Very large headwear, wide-brim hat, crown with protrusions	3	3	Maximal footprint for exceptional items

The footprint should reflect the hat's physical bulk in the real-world sense. A beret should not occupy the same inventory space as a full knight helmet. Consistent footprint sizing across a clothing catalog makes inventory management intuitive for players.

Character skeleton binding for hats

A hat prefab binds to the Character_Head and Character_Neck bones of the Unturned™ character skeleton. The SkinnedMeshRenderer on the hat prefab must reference these bones by their exact names.

Required prefab components

Component	Required	Purpose
SkinnedMeshRenderer	Yes	The mesh that deforms with the character head. A MeshRenderer produces a static hat that does not follow head movement.
Mesh	Yes	The hat geometry authored in Blender.
Material	Yes	The shader and textures applied to the hat mesh.
Bone references	Yes	Bone transforms referencing Character_Head and optionally Character_Neck by exact name.

SkinnedMeshRenderer is mandatory

Hats must use a SkinnedMeshRenderer, never a MeshRenderer. A MeshRenderer renders the hat at a fixed world position; the hat will float in place when the character turns their head. This is the most common structural error in first-time hat mods. Confirm the renderer type before building the master bundle.

Bone binding for hats

The character skeleton bones that a hat prefab binds to:

Bone name	Region	Required for hat
Character_Head	Head	Yes - primary binding bone. The hat mesh must weight to this bone in Blender.
Character_Neck	Neck	Recommended - secondary binding. Weighting the hat base to the neck bone prevents gaps when the character looks up or down.

The hat mesh should be weighted predominantly to Character_Head (approximately 80-100% weight) with optional partial weighting to Character_Neck (0-20%) for hat meshes that extend below the jaw line. The weight distribution controls how the hat follows the character's head rotation - a hat weighted only to Character_Head tracks the head perfectly but may show a gap at the neck seam when the character looks up.

Hat prefab hierarchy

The minimum structure for a hat prefab:

MyHatPrefab (root)
├── Body (SkinnedMeshRenderer - hat mesh)
└── Material (assigned to the SkinnedMeshRenderer)

No Animator is needed unless the hat has animated components (a blinking light, a moving visor). Hats do not have action animations; they deform with the character skeleton automatically through the SkinnedMeshRenderer bone references.

Mesh authoring considerations for hats

The hat mesh must be modeled to fit the Unturned™ character head. The cohort-recommended workflow:

1. Import the character head reference FBX into Blender as a background object.
2. Model the hat mesh approximately 1-3mm outside the character head surface in edit mode.
3. Parent the hat mesh to the character armature using Armature Deform with Automatic Weights, then inspect and correct weight paint.
4. Confirm the hat does not intersect the character head - intersecting faces produce z-fighting artifacts.
5. Apply scale and rotation (Ctrl+A in Blender) before FBX export.
6. Export FBX with the correct axis settings (Y-up, -Z forward) for Unity import.
7. In Unity, assign the SkinnedMeshRenderer bone references to Character_Head and optionally Character_Neck.
8. Create the prefab, assign the material, set the AssetBundle name, and build the master bundle.

Complete .dat example: tactical helmet (no hair, helmet type)

ID 42001
GUID a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6
Type Hat
Name MyTacticalHelmet
Rarity Uncommon
Size_X 2
Size_Y 2
Size_Z 0.45
Useable Clothing

Hat_Type Helmet

Companion English.dat:

Name Tactical Helmet
Description Full-coverage ballistic helmet. Hair and beard are concealed when worn.

Complete .dat example: baseball cap (hair visible, hat type)

ID 42002
GUID b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7
Type Hat
Name MyBaseballCap
Rarity Common
Size_X 2
Size_Y 1
Size_Z 0.3
Useable Clothing

Hair
Beard
Hat_Type Hat

Companion English.dat:

Name Baseball Cap
Description Classic baseball cap. Hair remains visible while worn. Lightweight and comfortable.

Complete .dat example: ghillie hood (full head coverage, no hair)

ID 42003
GUID c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8
Type Hat
Name MyGhillieHood
Rarity Rare
Size_X 2
Size_Y 2
Size_Z 0.5
Useable Clothing

Hat_Type Hood

Companion English.dat:

Name Ghillie Hood
Description Full-head ghillie hood for camouflage. Hair and beard are completely concealed by the mesh overlay.

English.dat localization considerations for hats

The English.dat file for a hat item should communicate the hair and beard visibility behavior to the player so that expectations are set before equipping. The cohort recommendation is to include a brief phrase in the description indicating whether hair is visible or hidden:

.dat configuration	Recommended description phrasing	Example full description
Hair present + Beard present	"Hair and beard are visible when worn." or "Hair remains visible."	"Lightweight baseball cap. Hair and beard remain visible when worn."
Hair present, Beard absent	"Hair is visible; beard is concealed."	"Visor cap with hair opening. Hair is visible; beard is concealed by the neck cover."
Both absent (default)	"Hair and beard are concealed when worn." or omit if obvious	"Full-coverage tactical helmet. Hair and beard are concealed when worn."

Accurate descriptions prevent player confusion when equipping a hat and seeing their character's hair behave unexpectedly.

Hat authoring checklist

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

• [ ] Type Hat is set correctly - not Mask or Glasses.
• [ ] Hair flag is present on hats that should show hair, absent on full-coverage headwear.
• [ ] Beard flag is present on hats that should show the beard, absent otherwise.
• [ ] Hat_Type is set to the appropriate category (Hat, Helmet, or Hood).
• [ ] The prefab uses a SkinnedMeshRenderer, not a MeshRenderer.
• [ ] Bone references match Character_Head and Character_Neck exactly - case-sensitive.
• [ ] The hat mesh does not intersect the character head surface (no z-fighting).
• [ ] Scale has been applied in Blender before FBX export.
• [ ] The material is assigned in Unity, not pink in the prefab.
• [ ] The master bundle is built and copied to the mod's Bundles/ folder.
• [ ] English.dat is authored with name and description that communicate hair visibility.
• [ ] Armor field is omitted - it has no effect on hats and implying protection is misleading.
• [ ] Tested in single-player: hat visible when equipped, deforms with head movement, hair/beard visibility matches flag configuration.

Hat asset in the clothing inheritance chain

The ItemHatAsset class occupies a specific position in the Unturned™ clothing inheritance hierarchy. Understanding this chain is essential for reading the official SDG documentation and for diagnosing field resolution issues.

ItemAsset (base item properties: ID, GUID, Name, Rarity, Size_X, Size_Y)
  └── ItemClothingAsset (clothing properties: Useable Clothing, slot behavior)
      └── ItemGearAsset (eye/gear-location properties - base for head-region items)
          └── ItemHatAsset (Hair, Beard, Hat_Type fields - concrete: Type Hat)

The hat class inherits from ItemGearAsset, not from ItemBagAsset. This is the architectural reason hats cannot have Width and Height storage fields - those fields are defined in ItemBagAsset, which is a sibling branch under ItemClothingAsset, not an ancestor of ItemHatAsset. The ItemGearAsset class is the common base for head-region items (hats, masks, glasses) and does not introduce any unique .dat fields beyond what ItemClothingAsset provides. The Hair, Beard, and Hat_Type fields are specific to ItemHatAsset.

The flowchart above shows the complete clothing inheritance hierarchy. Hats share the ItemGearAsset branch with masks and glasses. Shirts and pants share the ItemBagAsset branch with backpacks - this is why shirts and pants can have Width and Height storage fields but hats cannot.

Hat balance considerations

Hats are purely cosmetic items in the Unturned™ balance system. They provide no armor, no storage, and no damage modification. Their entire gameplay contribution is visual. The balance levers for hats are:

Lever	How it affects gameplay	Notes
Rarity	Controls inventory highlight color and perceived loot value	Higher rarity = more visually distinguished hat
Inventory footprint	Controls how much inventory space the hat consumes	Larger hats cost more inventory to carry un-equipped
Workshop skin vs. full mod	Full mod adds new item; workshop skin replaces existing item texture	Full mod is visible in loot tables; workshop skin requires ownership
Hat_Type category	Controls inventory sort/filter grouping	No gameplay effect; purely organizational

Because hats provide no functional gameplay benefit, they are ideal candidates for cosmetic-only items in RP server stores, faction uniform components, and vanity items. The cohort recommendation is to treat hats as the lowest-priority slot for balance tuning - focus balance attention on shirts, pants, and vests instead.

Diagnostic table

Symptom	Most likely cause	Resolution
Hat is invisible when equipped	Prefab missing or GUID mismatch in master bundle	Confirm the prefab exists in the bundle at the correct name; check GUID match
Hat floats in place when character turns head	MeshRenderer used instead of SkinnedMeshRenderer	Replace MeshRenderer with SkinnedMeshRenderer, re-bind bones, rebuild bundle
Hat deforms incorrectly	Bone name misspelled in Unity	Verify Character_Head and Character_Neck spelling exactly - case-sensitive
Hair clips through hat mesh	Hair flag present on a full-coverage hat	Remove the Hair flag from the .dat file
Beard clips through hat neck area	Beard flag present on a full-coverage hat	Remove the Beard flag from the .dat file
Hair hidden when it should be visible	Hair flag absent from .dat	Add the Hair flag
Beard hidden when it should be visible	Beard flag absent from .dat	Add the Beard flag
Pink material on hat	Material not assigned in Unity	Assign material, rebuild bundle
Hat equips to wrong slot	Type field value incorrect	Set Type Hat
Hat provides no armor despite having an Armor field	Engine does not apply armor to Hat slot	Remove the Armor field - it is misleading and has no effect
Hat item cannot be picked up	Useable Clothing missing	Add Useable Clothing
Hat mesh z-fights with character face	Mesh modeled inside character head surface	Refit mesh to sit 1-3mm outside head surface in Blender
Hat appears on Mask slot in some UI views	Confusion between Type Hat and Type Mask	Set Type Hat explicitly; confirm no other .dat uses the same ID
Character head disappears when hat equipped	Bone weight bleeding into face region bone weights	Re-weight the mesh in Blender; limit influence to Character_Head and Character_Neck only

Frequently asked questions

Can a hat have the same visual coverage as a full mask?

A hat mesh can be authored to cover the full head including the face area. However, the Hat slot and the Mask slot are independent - a player can equip both simultaneously. If the hat mesh covers the face, it will visually overlap with any mask the player is also wearing. The cohort recommendation is to design hat meshes that sit above the jaw line and to use the Mask slot for face coverage. If you need a single item that covers the full head without a separate mask, use the Hat slot and accept the simultaneous-mask overlap as a visual edge case.

Why do some vanilla hats have Armor values if Armor does not work on hats?

Several vanilla hat items carry Armor values in their .dat files, including the Firefighter Helmet (Armor 0.9), the Cap_Black (Armor 0.95), and the Fedora_Mafia (Armor 0.95). These values are vestigial - they are parsed by the engine at load time, stored in memory, and silently ignored during damage calculation. The most likely explanation is that these hat items were authored against an older version of the runtime or copied from a shirt or pants template that included an Armor field. The engine accepts the field without error but never reads it for the Hat slot. The cohort recommendation for mod authors is to omit Armor from hat .dat files to avoid implying protection that does not exist.

Does the Hair flag affect helmet-style hats that fully enclose the head?

Yes. If a full-head-covering hat (a knight helmet, a space helmet, a ballistic helmet with full face shield) has the Hair flag present, the character's hair will render inside the helmet mesh, clipping through it visibly. Always omit the Hair flag on hats whose mesh fully encloses the head. Use the Hair flag only for hats that logically allow hair to show through - baseball caps, beanies, visors, crowns.

Can I have only beard visible without hair?

Yes. Set the Beard flag without the Hair flag. The character's beard will be visible but hair will be hidden. This is useful for headwear that covers the top of the head (a helmet with a chin strap opening, an open-face helmet) where the beard should be visible but the hair is logically covered.

Does Hat_Type affect workshop skin compatibility?

Hat_Type does not directly affect workshop skin functionality. Workshop skins replace textures on existing items and do not read the Hat_Type field. However, the Hat_Type value is used by inventory sort/filter UIs, so setting it to the correct category helps workshop skin users find the base item. The Hat_Type field is secondary to the Type field for workshop skin targeting.

Can I add custom properties to a hat .dat file?

The Unturned™ .dat parser silently ignores unrecognized fields. You can add custom key-value pairs to a hat .dat for organizational or comment purposes, and the engine will not error. However, custom fields have no gameplay effect and are not accessible through any in-game or server-side API in the vanilla runtime. They exist only in the file for human readers.

How many hats can a player wear simultaneously?

One. The Hat slot is mutually exclusive - equipping a new hat replaces the currently worn hat. There is no way to stack hats in the vanilla Unturned™ runtime. If your mod design requires multiple head items, consider using the Mask and Glasses slots for additional head-region items.

Can a hat have an animation?

Yes, if the prefab includes an Animator component with animation states, the hat can have a looping animation (a blinking light, a rotating fan, a waving flag). The animation must be authored in Unity and packaged in the master bundle alongside the skinned mesh. The .dat file does not need any special field to enable animation - the Animator runs automatically when the prefab is instantiated. Note that hat animations are visual only; they do not interact with the game mechanics (damage, inventory, etc.).

What happens if I set Hat_Type to an invalid value?

The engine parses the Hat_Type field at load time. If the value does not match any recognized enum constant (Hat, Helmet, Hood), the engine silently falls back to no category. The hat will load without error, equip correctly, and function normally in all respects. The invalid Hat_Type will simply not appear in any category filter. There is no crash, no log error, and no performance impact from an invalid Hat_Type value.

Does a hat affect zombie character models?

Hats worn by player characters are separate from zombie headgear. Zombies can spawn with hat items from their loot table configuration, but the zombie hat rendering uses the same SkinnedMeshRenderer bone binding system - the same prefab works for both player and zombie characters. The Hair and Beard flags do not apply to zombies (zombies do not have hair/beard visibility logic), but the hat mesh renders on the zombie head skeleton if the zombie spawns with the hat equipped.

Can I make a hat that is invisible (transparent material)?

A hat with a fully transparent material renders on the character head but is visually invisible. The item still occupies the Hat slot and still applies the Hair and Beard flags. This is a niche use case - typically for server-authority items that need to occupy the hat slot for some mechanic without visual presence. The cohort recommendation is to use a very low opacity material (0.05-0.1) rather than full transparency, and to set the Size_X and Size_Y to minimum (1x1) for such items.

Best practices

• Omit the Hair flag on full-coverage hats (helmets, full hoods, knight helms). Include it only on hats that logically allow hair to show through.
• Omit the Beard flag on hats whose mesh covers the jaw area. Include it on open-face hats and caps where the beard is naturally visible.
• Set Hat_Type to the correct category. It costs nothing to set and helps players sort their inventory.
• Always verify the SkinnedMeshRenderer type in Unity before building the master bundle. A MeshRenderer hat is effectively broken.
• Keep the hat mesh 1-3mm outside the character head surface in Blender to prevent z-fighting.
• Apply scale in Blender before FBX export. Non-unit scale produces incorrect in-game positioning.
• Author the English.dat description to communicate hair and beard visibility - this sets accurate player expectations.
• Test hats in-game with both hair and beard enabled in the character creator to confirm flag behavior matches the visual design.
• Test hats simultaneously with a Mask item and a Glasses item to confirm no z-fighting between the three head-region items.

Advanced considerations

Hats in RP server context

In RP servers such as Horizon Life RP, hats serve faction-identity purposes and are often the most visible item slot for faction affiliation. A police officer's cap, a military beret, and a civilian beanie immediately communicate faction and role. The cohort recommendation for RP server hat authoring is to use the Hat_Type field consistently - faction police and military headwear use Helmet, faction civilian headwear uses Hat. This enables server UI filters to categorize items correctly.

Workshop skins for hats

Workshop skins for hats follow the same rules as workshop skins for any other clothing slot - they replace the texture of an existing vanilla hat item without creating a new item ID. Workshop skins for hats are authored as texture file sets submitted through the Steam Workshop tools and do not require Unity prefab authoring. See the Clothing Asset Reference workshop skin section for the full workflow.

Hat prefab texture map requirements

Texture	Resolution	Notes
Albedo	1024x1024	Base color, surface detail, markings
Normal Map	1024x1024	Surface detail without geometry cost
Metallic/Roughness	1024x1024	PBR material parameters (metalness, smoothness)
Emission (optional)	512x512	Glowing elements - illuminated visor, light attachments

The hat texture resolution recommendations match the standard clothing texture requirement. Hats are small meshes relative to the character body, so a 1024x1024 albedo provides ample texel density for a hat texture.

Appendix A: Complete hat field quick reference

Field	Type	Required	Default	Notes
ID	uint16	Yes	-	Unique item ID
GUID	uint128 hex	Yes	-	128-bit globally unique identifier
Type	enum	Yes	-	Must be Hat
Name	string	Yes	-	Internal name
Rarity	enum	No	Common	Rarity tier
Useable	enum	Yes	-	Must be Clothing
Size_X	uint8	Yes	-	Inventory width
Size_Y	uint8	Yes	-	Inventory height
Size_Z	float	No	Engine default	Visual scaling
Hair	flag	No	Hair hidden	Controls hair visibility
Beard	flag	No	Beard hidden	Controls beard visibility
Hat_Type	enum	No	No category	Cosmetic category: Hat, Helmet, Hood
Armor	float	No	1.0	Silently ignored on hats - omit this field

Appendix B: Inheritance field source table

Field	Source class	Notes
ID	ItemAsset	Identity
GUID	ItemAsset	Identity
Type	ItemClothingAsset	Slot assignment
Name	ItemAsset	Internal name
Rarity	ItemAsset	Highlights color
Useable	ItemClothingAsset	Must be Clothing
Size_X	ItemAsset	Inventory footprint
Size_Y	ItemAsset	Inventory footprint
Size_Z	ItemAsset	Visual scaling
Hair	ItemHatAsset	Hat-specific field
Beard	ItemHatAsset	Hat-specific field
Hat_Type	ItemHatAsset	Hat-specific field
Armor	ItemClothingAsset	Silently ignored on hats
Pro	ItemAsset	PRO/Gold gating
Bypass_ID_Limit	ItemAsset	Bypass ID limit
Proof_Water	ItemClothingAsset	Water immunity
Proof_Fire	ItemClothingAsset	Fire immunity
Proof_Radiation	ItemClothingAsset	Radiation immunity

Appendix C: Hat inventory dimension reference by vanilla hat type

Vanilla hat example	Size_X	Size_Y	Hat_Type category
Cap_Black	2	1	Hat
Beret_Forest	2	1	Hat
Fedora	2	1	Hat
Tophat	2	2	Hat
Firefighter_Helmet	2	2	Helmet
Military_Helmet_Forest	2	2	Helmet
Construction_Helmet	2	2	Helmet
Ghillie_Hood	2	2	Hood
Rain_Hat	2	2	Hat
Crown	2	2	Hat
Bowler	2	1	Hat
Ushanka	2	2	Hat
Sombrero	3	2	Hat
Pumpkin	3	3	Hat

Appendix D: Shipped hats with Armor field (for reference - Armor has no effect)

The following vanilla hats carry an Armor field in their .dat file despite the engine not applying armor protection to the Hat slot. These items are documented here as evidence of the vestigial-Armor pattern.

Hat	ID	Armor value	Notes
Cap_Black	426	0.95	Cosmetic cap, no logical armor
Cap_Blue	427	0.95	Cosmetic cap, no logical armor
Cap_Green	429	0.95	Cosmetic cap, no logical armor
Cap_Orange	430	0.95	Cosmetic cap, no logical armor
Cap_Purple	431	0.95	Cosmetic cap, no logical armor
Cap_Red	432	0.95	Cosmetic cap, no logical armor
Cap_White	433	0.95	Cosmetic cap, no logical armor
Cap_Yellow	434	0.95	Cosmetic cap, no logical armor
Fedora_Mafia	1385	0.95	Cosmetic hat
Firefighter_Helmet	241	0.9	Protective helmet - Armor still has no effect
Rain_Hat	1996	0.95	Sou'wester rain hat

None of these Armor values are applied to damage reduction when the hat is equipped. The field is vestigial.

Cross-references

• Bag Asset Reference - the previous article in this section; covers the ItemBagAsset base class that shirts and pants inherit from.
• Shirt Asset Reference - the next article; covers the Shirt slot which shares the clothing system but inherits from BagAsset (not GearAsset).
• Clothing Asset Reference - the base clothing reference covering all seven slots, shared fields, prefab requirements, and the full clothing pipeline.
• Project Folder Structure and GUIDs - item folder layout and GUID authoring.
• Item Asset Anatomy - the universal shared field reference for every item type.
• How to Export an FBX - the FBX export workflow for clothing meshes.
• How to Install Unity Editor - Unity install prerequisite.
• Master Bundle Export - the Unity bundling workflow used to package hat prefabs.
• Steam Workshop Submission - publishing workflow for both full mods and workshop skins.
• Smartly Dressed Games Modding Documentation - the authoritative asset field reference.
• Unturned on Steam - the base game page; install and version history.

Document history

Version	Date	Author	Notes
1.0	2026-07-26	57 Studios	Initial publication. Complete hat asset field reference, Hair/Beard flag behavior, Hat_Type enum, character skeleton binding, inheritance chain documentation, diagnostic tables, worked examples.