HMG Weapon Reference
The HMG -- full asset name HMG_Fighter_Jet -- is a heavy machine gun defined in Unturned's asset files. It carries item ID 1471, the GUID d3270ede04e54eadba9d2e4befc9cfab, rarity Epic, and occupies the Primary equipment slot. Its in-game description reads: Heavy machine gun chambered in HMG ammunition.
This article is a data reference for modders. It catalogues every field the asset file exposes, explains what each field controls, and shows where the weapon appears -- or does not appear -- in the game's loot tables. It does not provide play advice, ammo economy tips, or damage maths beyond the values the file literally contains.
Why this reference exists
When a modder opens an Unturned weapon asset file, they see a list of field names and numeric values. The file does not explain what Caliber 37 means or why Firerate is 7 instead of 700. This reference answers those questions field by field, using the HMG's actual extracted values as the data set.
The raw asset file -- typically a .dat file stored inside a .unity3d bundle archive -- is a flat key-value document. Fields are listed one per line with no grouping or documentation. A modder reading the file cold sees numbers, enums, and flag names with no indication of which fields control damage, which control rendering, and which control behaviour. This reference supplies the missing documentation.
Asset extraction tools pull these values from the game's bundle files by deserialising the Unity asset format. The extracted values are the same ones the game reads at runtime. When this reference states that Firerate is 7, that is the literal value stored in the asset file on disk. There is no conversion, no inferred meaning, and no derived stat -- just the field as the game sees it.
The HMG is a good asset to study because it combines three systems that appear across many weapon types: the ballistics block (present in every firearm), the damage-multiplier block (present in every weapon with per-zone damage), and the turret-flag system (present in every emplaced and vehicle-mounted weapon). Understanding how the HMG's fields work gives you the mental model for reading any Unturned weapon asset.
Each weapon type in Unturned shares a common field structure. All firearms have Range, Firerate, Action, Caliber, Muzzle, Magazine, Ammo_Min, and Ammo_Max in their ballistics block. All weapons that deal damage to living targets have the three damage blocks (Player_Damage, Zombie_Damage, Animal_Damage) and their corresponding multiplier fields. All weapons that can accept attachments have hook flags. The HMG is a representative example of this structure: it has the full ballistics block, the full damage block across all three target classes, and a flag list that shows how flags combine to define weapon role. Learning to read the HMG's fields teaches you to read any weapon's fields.
The extraction methodology used to produce the data in this reference is deterministic. Asset values are read directly from the deserialised .dat file. No values are estimated, averaged, or derived. The computed damage columns in the per-hit-zone tables are the only exception: they are the product of the base damage and the multiplier, labelled explicitly as "computed" to distinguish them from the raw extracted fields. Every other number in this reference is a literal asset value.
Asset identity
Every item in Unturned is identified by three values that appear together in the asset file: the asset name, the item ID, and the GUID. The asset name is the internal identifier the game engine uses to load the file from the Bundles directory. The item ID is a numeric key used by commands, save files, and the item-spawning system. The GUID is a 32-character hex string that uniquely identifies the item across all assets in the game -- it is the primary key modding tools use to reference an asset.
For the HMG these identifiers are:
| Attribute | Value |
|---|---|
| Asset name | HMG_Fighter_Jet |
| Item ID | 1471 |
| GUID | d3270ede04e54eadba9d2e4befc9cfab |
| Rarity | Epic |
| Slot | Primary |
The GUID is generated by the Unity editor when the asset is first created and is stored in the asset's .meta file. Unturned uses the GUID as the authoritative reference key. When a save file records that a player has an item, it stores the GUID, not the item ID. If two different items share the same GUID -- which can happen if a modder copies an asset file without generating a new GUID -- the game resolves the conflict by picking the first asset it loads, and the second asset becomes invisible to the save system. Always generate a fresh GUID for custom assets.
The item ID 1471 falls within the range Unturned reserves for official content. Custom items should use IDs in the range allocated by the modding system -- typically a high range that the base game does not occupy. If a modded item uses ID 1471, it will collide with the HMG. The game resolves ID collisions at load time by the order bundles are loaded, and the result is unpredictable. Always check the official item ID list before assigning an ID to a custom item.
The Rarity field controls which colour the item's name displays in the inventory UI. Epic items appear in purple. The game uses the rarity string to look up a colour entry in the UI theme; changing this field to Rare would display the name in blue, changing it to Legendary would display it in gold. The rarity value also affects the item's sort order in the inventory: higher-rarity items appear before lower-rarity items when the inventory is sorted by quality. Rarity does not affect damage, durability, or any mechanical property -- it is purely a UI and sorting cue.
The Slot field determines which equipment slot the weapon occupies. Primary means it competes with rifles, shotguns, and other large weapons, not with secondary sidearms. The slot system is a hard constraint: a player can carry one Primary weapon and one Secondary weapon at a time. If a player picks up the HMG while already holding a Primary weapon, the existing weapon is dropped or swapped, depending on server settings. The swap behaviour is controlled by the server's Item_Drop_On_Equip configuration: when enabled, the currently equipped Primary weapon is dropped to the ground; when disabled, the pick-up is blocked and the player cannot acquire the new weapon until they manually unequip their current one.
The asset name HMG_Fighter_Jet reveals an important clue about the weapon's intended context. The Fighter_Jet suffix tells you the weapon was designed as part of a fighter-jet vehicle asset. This is why the weapon carries the Turret flag and has no recoil fields -- it was never meant to be held by a player character. When you encounter an asset name with a vehicle suffix, expect the stats to be tuned for vehicle-mounted use, even if the weapon can technically be spawned as a standalone item.
The vehicle suffix convention is widespread in Unturned's asset naming. Vehicle-mounted weapons use the vehicle's asset name as a suffix to establish the parent-child relationship in the bundle hierarchy. The game's bundle loading system resolves this relationship: when it loads the Fighter_Jet vehicle asset, it searches for all weapon assets whose name contains Fighter_Jet, finds HMG_Fighter_Jet, and binds the weapon to the vehicle's turret mount point. If you rename the weapon asset, the vehicle can no longer find it, and the turret slot will be empty when the vehicle spawns.
The naming convention HMG_Fighter_Jet follows a pattern of [WeaponType]_[VehicleName]. The HMG prefix identifies the weapon class, and the Fighter_Jet suffix identifies the parent vehicle. This pattern is searchable: to find all vehicle-mounted weapons, a modder can search for asset names containing any known vehicle name. To find all weapons on a specific vehicle, search for that vehicle's name as a suffix. The naming convention is not enforced by the engine -- it is a convention followed by the asset creators -- but modders who follow it will have an easier time maintaining vehicle-weapon relationships.
Understanding the asset hierarchy is essential for vehicle modding. The chain is: vehicle asset defines mount points (a list of transform indices), each mount point references a turret weapon by asset name suffix convention, and each turret weapon defines its own ballistics, damage, and flags. A modder who creates a new vehicle must either reuse existing turret weapons (by matching the suffix convention) or create new weapon assets with the correct suffix and mount-point transform indices.
How asset files reference each other
Before diving into the individual fields, it helps to understand the relationship graph that connects weapon assets to other asset types. When the game loads the HMG, it follows a chain of references:
- The weapon asset file (
HMG_Fighter_Jet.dat) is loaded from the game's bundle. - The
Magazinefield (1395) tells the game to load the magazine item asset. The magazine asset defines its own capacity, calibre, and model. - The
Caliberfield (37) tells the game which ammo type the magazine accepts. When the player reloads, the game searches the inventory for ammo items whose calibre matches 37. - The
Muzzlefield (4) tells the renderer which transform index on the weapon model to use as the bullet-spawn point. - The flag list tells the game which behavioural systems to activate: the
Autoflag engages full-auto firing logic, theTurretflag engages the turret-camera system, and theInvulnerableflag tells the damage system to skip this entity.
When you edit one value, trace its reference chain to understand what else might break. If you change Magazine from 1395 to a different item ID, that item must exist and must have a matching calibre. If you change Caliber from 37 to a different value, ammo items must exist at that calibre or the weapon becomes un-reloadable. This reference-chain thinking is the single most important skill for weapon modding.
The game's bundle system loads assets from .unity3d archive files in the Bundles directory. When the game starts, it enumerates all bundles, reads their manifest files to build an in-memory asset registry, and resolves cross-references by GUID lookup. If a reference points to a GUID that does not exist in any loaded bundle, the reference resolves to null. For weapon assets, a null magazine reference means the weapon cannot be reloaded -- the reload key does nothing, and no magazine model is rendered. A null calibre reference means the weapon can fire but cannot accept any ammunition, which effectively makes it a single-magazine weapon with no way to refill.
Modded bundles are loaded after vanilla bundles by default. This load order means a modded asset can override a vanilla asset by using the same GUID. The game keeps the last-loaded asset and discards earlier ones with the same GUID. This is how weapon stat override mods work: they bundle a copy of the vanilla .dat file with modified values but the same GUID, and because the modded bundle loads last, the modified values take effect. When debugging a weapon mod, check that your bundle loads after any other mod that might be overriding the same GUID.
The reference chain also extends to effects and audio. When the HMG fires, the game looks up the firing sound by action type and calibre, not by a direct sound-file reference in the weapon asset. The sound pipeline is: the weapon's Action type (Trigger) selects the sound category, and the Caliber (37) selects the specific sound within that category. If you change the weapon's Action to Rocket, the game will search for rocket-firing sounds at calibre 37, and if none exist, the weapon will fire silently. This indirect reference system is common in Unturned: many asset fields are lookup keys into other systems, not direct paths to resources.
The raw .dat file for a weapon looks like a flat list of key-value pairs, one per line. A typical excerpt might read: Range 500, Firerate 7, Action Trigger, Caliber 37. There is no nesting, no comments, and no type annotation -- every value is either a number, an enum string, or a flag name. Flags appear as bare strings in a designated flags block. When you open the file in a text editor, the fields appear in whatever order the asset was last serialised in, which is not necessarily a logical order. This is why a reference like this one is necessary: the raw file cannot be navigated by context, only by knowing which field names carry which meanings.
When a reference in the chain breaks, the game handles it gracefully but silently. A missing magazine asset does not crash the game; it simply means the weapon spawns with no magazine model and cannot reload. A missing calibre match does not crash the game; it means the reload key does nothing. The weapon still fires its initial ammunition, but once the magazine runs dry, the weapon becomes dead weight in the player's inventory. These failures produce no on-screen error message -- the only clue is that expected behaviour does not happen. When debugging a weapon that behaves strangely, check every field that contains a reference-type value (item ID, calibre number, transform index) against the target asset to ensure it exists in the loaded bundles.
For modders working with bundle extraction tools, the reference chain dictates the extraction order. You must extract the weapon asset first, note the Magazine and Caliber values, then find and extract the corresponding magazine item and ammunition items. If you extract the weapon in isolation without its referenced assets, the extracted data is incomplete -- you have the pointer but not what it points to. A complete weapon reference (like this article) requires extracting every node in the reference graph.
Ballistics fields
The ballistics block controls how the weapon fires, what ammunition it draws from, and how the projectile behaves after leaving the barrel. Each field is a single numeric or enum value in the asset file.
| Field | Value |
|---|---|
| Range | 500 |
| Firerate | 7 |
| Action | Trigger |
| Caliber | 37 |
| Muzzle | 4 |
| Magazine | 1395 |
| Ammo_Min | 40 |
| Ammo_Max | 50 |
Range (500) determines the maximum distance a bullet travels before the game despawns it. The unit is game metres. A value of 500 means the projectile persists for 500 metres of in-game distance before the engine removes it from the world. For hitscan weapons (which the HMG is, because its Action is Trigger), the range check happens instantly: the engine draws a line from the muzzle to the first collision point, and if the distance to that point exceeds 500, the hit is discarded. This means that a target standing at 501 metres from the muzzle will not register a hit even if the crosshair is perfectly on it.
The range check is performed on both the client and the server. The client uses range to decide whether to render hit effects and play hit sounds; the server uses range to validate incoming damage events. If a client reports a hit at 510 metres when the weapon's Range is 500, the server rejects the damage packet and no damage is applied. This dual validation is part of Unturned's anti-cheat architecture: the server independently verifies every damage event against the weapon's stat block.
Modders adjusting this field should expect that higher values increase the distance over which the game must test for hits. In multiplayer, where the server performs hit validation for every shot fired by every player, a very high Range on a full-auto weapon can add measurable CPU load. For turret weapons that are expected to control sightlines, 500 is a generous value that covers most engagement distances.
Firerate (7) is the internal tick count between shots. This is a raw engine value -- it is not a rounds-per-minute figure and it does not convert cleanly to wall-clock time. The game engine runs at a fixed tick rate, and Firerate is the number of ticks the weapon waits between firing consecutive rounds in an automatic sequence. A lower number means a shorter wait and therefore faster fire. A value of 7 is low, meaning the HMG has a fast cyclic rate.
When editing Firerate, do not try to target a specific real-world rounds-per-minute value. Compare the number against other weapons with the same Action type to gauge relative speed. If you want the HMG to fire faster, decrease the value (e.g., from 7 to 5). If you want it to fire slower, increase the value (e.g., from 7 to 12). The relationship is inverse: lower tick count equals faster fire.
The Firerate value interacts directly with the Auto flag. When Auto is present, the game enters a firing loop: fire one round, wait Firerate ticks, fire another round, repeat. If Auto is absent and the weapon is set to Semi, the Firerate still controls the minimum delay between consecutive manual trigger pulls -- the game will not let you fire faster than one round per Firerate ticks even if you click the fire key faster. This means Firerate is always a rate limiter, regardless of fire mode.
Action (Trigger) is an enum that determines the projectile type and firing mechanic. Trigger is the standard hitscan action used by most firearms. In hitscan, the game does not spawn a physical projectile that travels through the world. Instead, on the frame the weapon fires, the engine draws an instantaneous line from the muzzle position in the direction of the crosshair. The first object that line intersects receives the damage. There is no travel time, no bullet drop, and no visible projectile (unless a tracer effect is configured separately).
The other common action types are Rocket (spawns a physical projectile that travels through the world and can explode on impact) and Rail (a high-velocity projectile, often with piercing or multi-hit behaviour). If you change the HMG's Action from Trigger to one of these types, you must also adjust Caliber, Magazine, and likely the weapon model's muzzle placement, because each action type loads its projectile data from a different pipeline.
The Action type also controls which hit-effect system the game uses. Trigger weapons use the bullet-impact effect pool (sparks, dust puffs, blood splatters based on surface type). Rocket weapons use the explosion-effect pool. If you change the Action type without updating the effect references, the weapon will fire but produce no visual impact feedback, which is confusing for players and a common modding oversight.
Caliber (37) is the ammunition-calibre identifier. Every ammo box or magazine item in the game carries its own Caliber number. The weapon can only reload from items whose Caliber matches exactly. The HMG's calibre of 37 links it to a specific ammo type. To find out which ammo items the HMG accepts, search the item database for every ammo asset with Caliber 37. The game does a simple integer comparison -- there is no range or category matching, just exact equality.
When the player presses the reload key, the game iterates through the inventory from the first slot to the last, comparing each ammo item's calibre against the weapon's calibre. The first match it finds is consumed. If the player carries two ammo types that both match calibre 37, the one in the earlier inventory slot is used first. This deterministic behaviour means players can control which ammo variant is consumed by arranging their inventory order.
Changing the calibre is the primary way to control which ammo a weapon uses. If you create a custom ammo type with Caliber 99, and you set the HMG's Caliber to 99, the weapon will only reload from your custom ammo. This is how modders create weapon-specific ammunition that cannot be used in other firearms.
A hidden dependency of the Caliber field is the hit-sound lookup. When a bullet hits a target, the game uses the calibre to determine which impact sound to play. Calibre 37 maps to a specific set of impact audio assets. If you change the calibre to a value that does not have impact sounds defined, hits will be silent -- the damage still applies, but the audio feedback is missing. When creating custom calibres, define the full set of audio references (fire sound, impact sound, reload sound, equip sound) or the weapon will have gaps in its audio profile.
Muzzle (4) is the transform index along the weapon model's bone hierarchy. When the weapon fires, the game looks up the transform at this index and uses its world-space position and rotation as the origin point for the bullet ray. Enabling hitmarkers or tracers draws visual effects from this same position. If the weapon model has fewer than 5 transforms (indices 0 through 4), the engine falls back to index 0, which is typically the model's root bone.
For modellers importing custom weapons, the muzzle transform must be placed precisely at the barrel exit. If the transform is inside the barrel geometry, the bullet ray will start from inside the weapon model and may fail the initial collision test (the ray immediately hits the weapon's own geometry). If the transform is offset from the visual barrel, muzzle flash and tracers will appear to emit from thin air next to the weapon. Test with a visible tracer effect to verify muzzle placement.
The Muzzle index is also used by the recoil system. When recoil fields are present, the game applies the camera kick after spawning the bullet at the muzzle transform. If the muzzle transform is at index 0 and the model has a complex bone hierarchy, the kick direction may not match the visual barrel direction. For turret weapons like the HMG (which have no recoil), this interaction is irrelevant, but it becomes important if you convert the weapon to handheld and add recoil.
Magazine (1395) is the item ID of the magazine or feeding device attached to the weapon. The game's reload system uses this value to look up the magazine item asset, determine its capacity, render its model, and spawn it as a separate item when the weapon is dropped or disassembled. The value 1395 is not the magazine capacity -- it is a pointer to another asset file. To find the actual magazine capacity, open the item asset with ID 1395 and read its capacity field.
If you change the magazine, the new magazine item must exist as a separate asset. The magazine asset must carry a Caliber field; if that calibre does not match the weapon's Caliber, the reload will fail. This is a common mistake: a modder changes the weapon's Caliber but forgets to update the magazine's Caliber to match, and the weapon becomes un-reloadable.
The magazine capacity and the Ammo_Min / Ammo_Max fields serve different purposes. The magazine capacity (defined in the magazine asset at ID 1395) sets the ceiling: after a reload, the weapon can hold at most this many rounds. Ammo_Min and Ammo_Max set the initial spawn amount, which must be less than or equal to the magazine capacity. If you set Ammo_Max to a value higher than the magazine capacity, the game clamps the spawn amount to the magazine capacity at runtime. This clamping is silent -- no error is logged -- so a modder who sees their weapon spawning with fewer rounds than expected should check the magazine asset's capacity field.
When a player drops the HMG, the game spawns two items: the weapon item (with its current round count serialised into the item data) and the magazine item (if the magazine is detachable -- determined by a field in the magazine asset). If the magazine is marked as non-detachable, the magazine model stays attached to the weapon and is not spawned separately. This split-spawn behaviour is part of the game's item economy: a player who kills an HMG operator and loots the body will find a weapon and potentially a separate magazine item, each with its own inventory footprint.
Ammo_Min (40) and Ammo_Max (50) set the random range for the number of rounds the weapon carries when it first spawns. The game picks a uniform random integer between the inclusive Min and Max. A freshly spawned HMG will carry between 40 and 50 rounds in its magazine. These fields do not cap the total magazine capacity -- the magazine item's own capacity field defines the maximum number of rounds the weapon can hold after a reload. Ammo_Min and Ammo_Max only set the initial spawn state.
The gap between Min and Max controls how much variance players see. With Min 40 and Max 50, the spawn round count varies by up to 10 rounds. A modder who wants less variance can narrow the range (e.g., Min 45, Max 50). A modder who wants zero variance sets Min equal to Max (e.g., Min 50, Max 50), in which case every spawn produces exactly 50 rounds.
The spawn-round count is written into the item's serialised state when it is created. When the game saves, the current round count (including rounds spent) is persisted. When the save is loaded, the weapon restores its exact round count from the save data -- it does not re-roll Ammo_Min to Ammo_Max. This means the spawn-randomisation fields only matter the first time the item enters the world. After that, the item's round count is determined by gameplay: how many rounds were fired and how many reloads occurred.
Field interaction: Magazine + Caliber + Ammo_Min/Max. These three fields form a dependency triangle. The Magazine field points to an item that defines the maximum capacity. The Caliber field must match the magazine's calibre. Ammo_Min and Ammo_Max must not exceed the magazine's capacity. If any leg of this triangle is broken -- the magazine is missing, the calibre mismatches, the spawn range exceeds capacity -- the weapon's reload and spawn behaviour degrades. The game does not display warnings for these mismatches, so testing after every edit is the only way to catch them. A modder who changes the calibre should immediately test a reload. A modder who changes the magazine should immediately spawn the weapon and verify the round count. A modder who changes Ammo_Min/Ammo_Max should spawn the weapon multiple times and confirm the round count falls within the expected range and does not exceed the magazine capacity.
Field interaction: Firerate + Auto + Range. These three fields combine to define the weapon's suppression capability. Auto enables sustained fire, Firerate of 7 sets a fast cyclic rate, and Range of 500 means every bullet in the stream is threat-checked across half a kilometre. Changing any one of these three alters the weapon's effectiveness as an area-denial tool. Increasing Range to 600 extends the danger zone. Increasing Firerate (decreasing the value to, say, 5) puts more bullets in the air per unit of time. Removing Auto strips the weapon of sustained fire entirely, reducing it to single shots that can be timed and dodged. The three fields are tuned as a set; edits to one should be accompanied by consideration of the other two.
Field interaction: Action + Muzzle + Spread_Aim. For hitscan weapons, the bullet trace originates at the Muzzle transform and travels along a vector that is the crosshair direction plus the Spread_Aim random offset. If the Muzzle transform is misconfigured (wrong index, inside the geometry, or missing), the trace starts from the wrong origin. The Spread_Aim of 0.05 still widens the cone from that wrong origin, so inaccuracy stacks with misalignment. If the Action is changed to a projectile-based type (Rocket, Rail), the projectile still spawns at the Muzzle transform but Spread_Aim may or may not apply depending on how the projectile type handles spread. Always test the projectile spawn position and spread cone after changing any of these three fields.
Player damage fields
The player damage block defines how much damage the HMG deals to other players and how that damage scales when the bullet strikes different body regions. Each region has a multiplier that is applied to the base damage value.
| Field | Value |
|---|---|
| Player_Damage | 35 |
| Player_Leg_Multiplier | 0.6 |
| Player_Arm_Multiplier | 0.6 |
| Player_Spine_Multiplier | 0.8 |
| Player_Skull_Multiplier | 1.1 |
Player_Damage (35) is the base damage value applied before any multiplier. If the bullet strikes a body region that has no multiplier override, this is the raw damage dealt -- subject to armour and other damage-reduction layers the server applies. The value 35 is the damage for a single bullet. Because the HMG is a full-auto weapon (Auto flag present) with a low Firerate of 7, multiple bullets can land in quick succession, and the total damage delivered over a burst is the sum of each bullet's individual damage.
The four multiplier fields scale the base damage when the hit lands on that specific hitbox. The game determines which hitbox was struck by examining the bone name of the collision point on the target's skeleton. If the bone name maps to the skull group, the Player_Skull_Multiplier is applied. If it maps to the spine group, Player_Spine_Multiplier is used. Bones that do not belong to any multiplier group receive the un-multiplied base damage.
A multiplier of 1.0 means the hit zone receives exactly the base damage. A multiplier below 1.0 (like 0.6 for arms and legs) reduces the damage. A multiplier above 1.0 (like 1.1 for the skull) increases it. The multipliers are multiplicative, not additive: the game computes base * multiplier, not base + multiplier.
The bone-name mapping that the game uses to apply multipliers is defined elsewhere in the game's configuration, not in the weapon asset. The weapon only specifies the multiplier values; the bone-group definitions (which bone names belong to Skull, Spine, Arm, Leg) are part of the character rigging system. If a modded player character uses non-standard bone names, the multiplier system cannot map hits to the correct group and all hits receive the base damage of 35. This is the same issue that affects zombie and animal damage, described in those sections.
Player damage per hit zone (computed, use verbatim)
| Hit zone | Multiplier | Damage (base 35) |
|---|---|---|
| Skull | 1.1 | 38.5 |
| Spine | 0.8 | 28 |
| Arm | 0.6 | 21 |
| Leg | 0.6 | 21 |
This table shows the product of the base damage and each multiplier -- the damage delivered to an unarmoured player before any server-side modifiers (armour absorption, damage resistance buffs, etc.). The arm and leg share the same multiplier (0.6) and therefore produce the same effective damage of 21. The spine is the intermediate zone: at 28 damage, it sits between the limb hits and the skull hit of 38.5.
The damage pipeline runs in a specific order on the server. First, the hit zone is determined from the bone name. Second, the per-zone multiplier is applied to the base damage. Third, armour absorption is applied -- each equipped armour piece (helmet, vest, etc.) has an absorption value that reduces incoming damage by a percentage. Fourth, any active buffs or debuffs (medkit heal-over-time, bleeding, infection) modify the result. Fifth, the final damage value is subtracted from the target's health. Each step is independent and sequential; an error in one step does not affect the others.
The armour absorption step is the most significant damage modifier from a balance perspective. A player wearing a military-grade vest might absorb 40 per cent of incoming torso damage. The 28 damage from a spine hit would be reduced to approximately 16.8. The 38.5 damage from a skull hit would be reduced by the helmet's absorption value -- if the helmet absorbs 30 per cent, the skull hit deals approximately 27. This armour layering means the raw computed damage in the table above is only an upper bound; actual in-game damage is almost always lower when the target wears armour.
The game stores the multiplier and the base as separate fields. When you edit the asset, you change the multiplier field (e.g., Player_Skull_Multiplier), not the computed damage column. The computed column is shown here as a reference for what the game will calculate at runtime. If you want the skull hit to deal 50 damage, do not try to set a computed value -- instead, choose the multiplier that produces 50 when multiplied by the base, and test that the result matches your intent.
The game processes damage per bullet. If a burst of three bullets all hit the torso (spine multiplier), each bullet independently applies the 0.8 multiplier to the base 35, and the target receives three hits of 28 damage. There is no accumulated burst bonus or multi-hit penalty -- each bullet resolves independently.
Network replication of damage events works as follows. The client that fired the shot sends a damage event to the server: "fired weapon GUID X from position Y in direction Z at timestamp T." The server validates that the shooter owns weapon X, was at position Y at timestamp T (within reasonable bounds), and that direction Z intersects a target within the weapon's Range. The server then computes the damage using the weapon's stat block (the same values shown in this reference), applies armour and buffs on the target, subtracts the result from the target's health, and broadcasts the damage result to all clients in range. This means the server is the authority on damage values -- clients cannot modify the base damage or multipliers to cheat.
Friendly-fire interaction depends on the server's Enable_Friendly_Fire configuration. When friendly fire is enabled, the damage pipeline runs unchanged against friendly targets -- the same multipliers, the same armour absorption, the same final damage. When friendly fire is disabled, the server still receives the damage event but sets the damage to zero before applying it to the target's health. The hit effects (blood, impact audio) still play, but the health bar does not move. This is an important distinction for server owners debugging damage logs: a zero-damage event in the log may indicate friendly-fire suppression, not a bug in the weapon's damage values.
Comparison: player vs zombie vs animal base damage
Before diving into the zombie and animal sections individually, it is useful to compare the three damage bases side by side. The HMG carries three independent base damage values: Player_Damage at 35, Zombie_Damage at 50, and Animal_Damage at 50. The player base is 30 per cent lower than the NPC bases. This is a deliberate tuning choice: the designer wanted the weapon to be effective in PvE without being equally lethal in PvP.
The decoupling of player and NPC damage bases is a core Unturned weapon design pattern. It allows a weapon to serve two roles simultaneously: in PvE, it is a horde-clearing tool (high base damage, fast fire rate); in PvP, it is a suppression weapon (moderate damage per bullet, compensated by volume of fire). If all three bases were tied to a single value, the designer would have to compromise -- strong enough for zombies means too strong for players, or balanced for players means weak against zombies. The three-base system avoids this compromise entirely.
The limb multipliers tell a different story for each target class. Player limb multipliers (0.6 arms, 0.6 legs, 0.8 spine, 1.1 skull) are the most forgiving -- non-headshot hits still deal a reasonable fraction of the base. Zombie limb multipliers (0.3 arms, 0.3 legs, 0.6 spine, 1.1 skull) are the most punishing -- non-headshot hits are heavily penalised. Animal limb multipliers (0.6 legs, 0.8 spine, 1.1 skull, no arm multiplier) sit between the two. This three-way differentiation is visible across many Unturned weapons and reflects the different design goals for each target class: player combat rewards accuracy, zombie combat demands headshots, and animal combat is forgiving because animals are harder to hit.
When tuning damage across all three target classes, a modder should consider the ratio between base damage and limb multipliers together. Raising the zombie base to 60 while keeping zombie limb multipliers at 0.3, 0.6, and 1.1 creates a weapon that is devastating on headshots (60 * 1.1 = 66) but still weak on body shots (60 * 0.3 = 18 for limbs). Lowering the zombie base to 40 while raising limb multipliers to 0.8 and 1.0 creates a weapon that is more consistent across hit zones but less dramatic on headshots. The ratio defines the weapon's damage personality -- how much the player is rewarded for precision versus forgiven for inaccuracy.
The three computed damage tables, placed side by side, reveal the full shape of the HMG's damage profile:
| Hit zone | Player (base 35) | Zombie (base 50) | Animal (base 50) |
|---|---|---|---|
| Skull | 38.5 | 55 | 55 |
| Spine | 28 | 30 | 40 |
| Arm | 21 | 15 | -- |
| Leg | 21 | 15 | 30 |
The skull column is uniform across all three target classes: 38.5 for players, 55 for zombies, 55 for animals. The 1.1 skull multiplier is the only value shared across all three multiplier tables. The designer kept the headshot bonus constant while varying everything else. This suggests the headshot was treated as the "ideal" hit and tuned once, with the limb and spine multipliers adjusted per target class to produce the desired body-shot penalty.
The spine column is the most varied: 28 for players, 30 for zombies, 40 for animals. For players, the spine deals about 73 per cent of the skull damage (28 / 38.5). For zombies, the spine deals about 55 per cent of the skull damage (30 / 55). For animals, the spine deals about 73 per cent (40 / 55 -- matching the player ratio). This reveals a clear intent: against zombies, the designer wanted body shots to be significantly less effective than headshots, creating a strong incentive to aim for the head. Against players and animals, body shots remain a viable but suboptimal alternative.
The arm column exposes the biggest gap: 21 for players, 15 for zombies. Against a player, shooting an arm deals more than half the damage of a headshot. Against a zombie, shooting an arm deals barely a quarter. This is the most extreme manifestation of the PvE headshot-enforcement design: the penalty for hitting a zombie's arm is severe enough that players who aim for centre mass against zombies will burn through ammunition at an unsustainable rate.
When a modder adjusts the player damage multipliers, they are changing the PvP balance -- how long firefights last, how lethal ambushes are, and how much body armour matters. When they adjust the zombie multipliers, they are changing the PvE difficulty -- how many rounds it takes to clear a horde, how important headshots are, and whether the weapon can stagger zombies. When they adjust the animal multipliers, they are changing the hunting and survival balance -- how many rounds it takes to bring down a bear, and whether the weapon is a viable hunting tool. Each adjustment affects a different game loop, and the modder should be deliberate about which loop they are targeting.
The decoupled damage system also has an important implication for modded servers that mix PvP and PvE. A server that wants players to fight each other and fight zombies with the same weapon does not need to change the weapon's stats -- the three base values already handle the split. The player base of 35 keeps PvP measured; the zombie base of 50 keeps PvE satisfying. If a server owner wants PvP to be more lethal, they adjust Player_Damage and possibly the player limb multipliers upward, without touching the zombie or animal values. If they want PvE to be harder, they adjust Zombie_Damage and Animal_Damage downward, without changing how players damage each other. The independence of the three bases makes the HMG -- and every weapon that follows this pattern -- a flexible tool for server-side balance tuning.
Zombie damage fields
Zombie damage uses the same multiplier system as player damage, but with a different base value and different limb multipliers. This decoupling allows a weapon to behave distinctly against NPCs without affecting player-versus-player balance.
| Field | Value |
|---|---|
| Zombie_Damage | 50 |
| Zombie_Leg_Multiplier | 0.3 |
| Zombie_Arm_Multiplier | 0.3 |
| Zombie_Spine_Multiplier | 0.6 |
| Zombie_Skull_Multiplier | 1.1 |
Zombie_Damage (50) is higher than the player base damage of 35. A weapon that deals 50 base damage against zombies and 35 against players is intentionally weighted toward PvE. This is a common tuning technique: the designer wanted the HMG to feel powerful when mowing down hordes but did not want that same power level applied to other players. By decoupling the two bases, the designer can adjust one without touching the other.
The limb multipliers for zombies -- 0.3 for legs and arms, 0.6 for the spine -- are noticeably lower than the player limb multipliers of 0.6 and 0.8. This means a non-headshot hit against a zombie is penalised more severely than the same hit against a player. The designer's intent is visible in the data: the weapon heavily rewards headshots against zombies (1.1 multiplier on a 50 base = 55 damage) while punishing body shots (0.6 spine multiplier on 50 base = 30 damage).
This tuning pattern -- high base, low limb multipliers, normal skull multiplier -- is a common design signature for weapons meant to be used in sustained fire against hordes. The low limb multipliers mean a player who sprays into a crowd without aiming will deal minimal damage. The high base means a player who maintains head-level aim will eliminate zombies efficiently. The weapon teaches good aim through its damage profile: the penalty for missing the head is severe.
Zombie damage per hit zone (computed, use verbatim)
| Hit zone | Multiplier | Damage (base 50) |
|---|---|---|
| Skull | 1.1 | 55 |
| Spine | 0.6 | 30 |
| Arm | 0.3 | 15 |
| Leg | 0.3 | 15 |
The damage spread is substantial: a skull hit at 55 versus an arm hit at 15 is a difference of 40 damage points per bullet. For modders, the implication is that changing the zombie limb multipliers has a large effect on how the weapon feels in PvE. Raising the arm and leg multipliers from 0.3 to 0.5 would increase limb damage from 15 to 25, which nearly doubles the effectiveness of body shots against zombies without changing headshot damage at all.
When editing zombie damage, always test against actual zombie NPCs. The per-zone multipliers depend on the zombie skeleton's bone names matching the groups the game expects. If a custom zombie model uses different bone names, some or all multiplier lookups will fail and the base damage will be applied uniformly. This is a common source of bugs when modders add custom NPCs and find that headshots do not deal extra damage -- the skull bone is not named in a way the multiplier system recognises.
Different zombie types in Unturned use different skeleton rigs. The standard civilian zombie, the military zombie, the firefighter zombie, and the sprinter zombie each have unique models with potentially different bone hierarchies. The game's multiplier system maps each zombie type's bones to the four hit-zone groups (skull, spine, arm, leg) using a shared bone-name lookup table. If a zombie type's skull bone is named differently (e.g., head instead of skull), the game cannot match it to the skull multiplier group, and all hits to that bone receive the base damage. When creating custom zombie NPCs, verify the bone naming against the vanilla zombie rig or provide a bone-name mapping override in the NPC configuration.
Zombie health pools are defined in each zombie type's NPC asset, not in the weapon. Vanilla Unturned zombies typically have health values between 100 and 200, but this varies by type and difficulty. When a modder adjusts zombie damage on a weapon, the effective number of hits required to eliminate a zombie changes, but the exact count depends on the zombie's health value. The weapon asset does not know the zombie's health -- it only delivers damage, and the zombie's own asset determines how much damage it can absorb before being destroyed.
The zombie AI system responds to damage events through a separate feedback pipeline. When a zombie takes damage from the HMG, the game checks the damage amount and the hit zone. High-damage hits (like the 55 from a skull hit) often trigger stagger animations, briefly interrupting the zombie's movement. Low-damage hits (like the 15 from a limb hit) may not stagger the zombie, allowing it to continue advancing. The stagger threshold is defined in the zombie's NPC asset, not in the weapon. A weapon with high per-hit damage is more likely to trigger staggers, creating a crowd-control effect that is separate from the raw damage output.
Zombie types and damage interaction. Unturned ships several zombie variants: civilian, military, firefighter, construction worker, and sprinter, among others. Each variant has a different health pool, skeleton rig, and behaviour profile. The civilian zombie -- the most common type -- has a relatively low health pool and a standard humanoid skeleton, meaning the HMG's multiplier system works predictably: skull hits deal 55, spine hits deal 30, limb hits deal 15. The military zombie has a higher health pool and may wear visual armour pieces, but the armour is cosmetic only -- zombie armour does not apply absorption like player armour does. The damage formula is the same regardless of zombie model: base times multiplier, no armour subtraction.
The sprinter zombie is the most important variant for HMG tuning because its high movement speed makes headshots harder to land. Against a sprinter, a player may only have time for a few rounds before the zombie closes the distance. If those rounds hit the limbs or spine (dealing 15 or 30), the sprinter will survive and attack. If those rounds hit the skull (dealing 55), the sprinter may be eliminated or staggered before it reaches the player. The HMG's fast fire rate (Firerate 7) helps compensate for the small target window by putting more rounds in the air, but the low limb multipliers mean the player must still aim for the head to be effective.
Fuel-type zombies (firefighter, hazmat) and special zombies (mega zombie, boss variants) may have different health pools and may be immune to certain types of stagger. The HMG's damage profile does not change based on zombie type -- the same base and multipliers are applied. The difference in effectiveness comes from the zombie's own stats: a zombie with 200 health requires roughly four skull hits at 55 damage each, while a zombie with 100 health requires two. A modder adding custom zombies should test against the HMG to ensure the weapon's damage profile produces the desired difficulty.
Animal damage fields
The animal damage block governs damage against wildlife: deer, wolves, bears, and any other creature with an animal hitbox classification. It follows the same multiplier pattern as the other two target classes but omits the arm multiplier, because animal skeletons do not define an arm hitbox group.
| Field | Value |
|---|---|
| Animal_Damage | 50 |
| Animal_Leg_Multiplier | 0.6 |
| Animal_Spine_Multiplier | 0.8 |
| Animal_Skull_Multiplier | 1.1 |
Animal_Damage (50) matches the zombie base damage, not the player base. The animal leg multiplier (0.6) and spine multiplier (0.8), however, match the player table rather than the zombie table. This means the weapon's damage profile against animals is a hybrid: it uses the higher base value but the more forgiving limb multipliers. Against a wolf, a leg hit deals 30 damage (50 * 0.6), whereas against a zombie with the same base of 50, a leg hit would deal only 15 damage (50 * 0.3).
This hybrid tuning is intentional. Animals in Unturned are generally faster and more evasive than zombies, with smaller hitboxes that make headshots harder. By keeping the limb multipliers at the more forgiving player-level values, the designer ensures that hitting an animal anywhere is still reasonably effective, even if the player cannot land the perfect headshot.
The absence of an arm multiplier is worth understanding in detail. Animal rigs in Unturned use a quadruped skeleton -- four legs, a spine, and a skull. There is no bone group corresponding to arms because the animal walks on all four limbs; the front legs and rear legs both use the Leg bone group. The multiplier system only defines multipliers for bone groups that exist on the target; it does not check for the presence of all four groups. If a bullet strikes an animal bone that maps to the leg group, the Animal_Leg_Multiplier of 0.6 is applied regardless of whether it is a front leg or a rear leg. This means front and rear leg hits deal identical damage.
Animal damage per hit zone (computed, use verbatim)
| Hit zone | Multiplier | Damage (base 50) |
|---|---|---|
| Skull | 1.1 | 55 |
| Spine | 0.8 | 40 |
| Leg | 0.6 | 30 |
Only three zones appear because there is no Animal_Arm_Multiplier field. The game's animal hit-detection system distinguishes skull, spine, and leg bones. If a bullet strikes a bone that maps to none of these three groups, the game applies the un-multiplied base damage of 50. This fallback is important for modders adding custom animal NPCs: if your custom animal model uses bone names the multiplier system does not recognise, all hits will receive the full 50 base damage, effectively making the multipliers irrelevant for that creature.
When tuning animal damage, keep in mind that animal NPCs have their own health values defined in their NPC asset files. The damage numbers in the weapon asset are only one half of the equation; the other half is the animal's health pool. A modder who wants animals to be tougher can either lower the weapon's animal damage or raise the animal's health. Changing the weapon affects every weapon that hits that animal; changing the animal affects every weapon that hits it. Choose the edit point that matches your design intent.
Animal health values in Unturned's vanilla assets range from low (chicken, deer) to high (bear). The weapon's damage profile must be evaluated against the specific animals on the map. A wolf with 80 health will absorb two skull hits (55 * 2 = 110) or three leg hits (30 * 3 = 90). A bear with 200 health requires four skull hits (55 * 4 = 220) or seven leg hits (30 * 7 = 210). The differences compound: the ammo consumption, time exposed while firing, and noise generated all increase when facing higher-health animals. Server owners balancing animal spawns should consider the weapons available on the map and tune animal health accordingly.
The animal AI damage response is simpler than the zombie response. Animals do not stagger on hit; they either flee (deer) or continue advancing (wolves, bears). The damage amount does not change the animal's behaviour state -- only the fact of being hit triggers a response, not the magnitude of the hit. This means a weapon with high per-hit damage has no crowd-control advantage against animals, unlike against zombies where high damage can trigger staggers.
Handling and recoil
The handling fields control how the weapon moves the camera and where the bullet lands relative to the crosshair. The HMG has a very small spread value and no recoil fields in its asset data.
| Field | Value |
|---|---|
| Spread_Aim | 0.05 |
Spread_Aim (0.05) is the angular deviation applied to the bullet spawn direction when the player is aiming down sights. The game takes the crosshair direction, generates a random angular offset within a cone defined by the Spread value, and fires the bullet along the resulting vector. A value of 0.0 would mean the bullet travels exactly to the crosshair centre with no deviation. A value of 0.05 introduces a small random offset, meaning the impact point will dance slightly within a narrow cone around the crosshair.
The unit for Spread is not degrees in the geometric sense -- it is an internal angular unit that the game's aiming system uses. A modder should compare spread values across weapons rather than trying to convert to real-world MOA or degrees. A value of 0.05 is tight by Unturned standards; designated marksman rifles and sniper rifles often carry values between 0.001 and 0.01, while automatic rifles may carry 0.05 to 0.15.
The spread calculation runs independently on the client and the server. The client uses the spread value to render the visual bullet trajectory (tracers, hit sparks) for immediate feedback. The server uses the same spread value to compute the authoritative hit location during damage validation. If the server's random spread offset places the hit within a different hit zone than the client predicted, the server's result is authoritative and the client's visual feedback is discarded. This is why players occasionally see a hit marker (client predicted a hit) but no damage registers (server determined a miss) -- the client and server generated different random spreads from the same seed.
The HMG has only the Spread_Aim field and no hipfire spread field (Spread_Hip). When a weapon does not define Spread_Hip, the game typically applies a default hipfire spread that is wider than the aim spread, or it uses the Spread_Aim value for both states. The absence from the extracted data means the hipfire spread behaviour is not modifiable through the asset's explicit fields -- it is governed by the game's default spread system.
Absence of recoil fields. The HMG's extracted data contains no Recoil_Min_X, Recoil_Max_X, Recoil_Min_Y, Recoil_Max_Y, Shake_Min_X, Shake_Max_X, Shake_Min_Y, or Shake_Max_Y fields. When these fields are absent, the game does not apply any camera kick or screen shake when the weapon fires. The shooter's view remains perfectly static from the first shot to the last.
This absence is not an omission or a bug -- it is the correct configuration for a turret-class weapon. Emplaced and vehicle-mounted turrets in Unturned use a fixed-camera system where the player's viewpoint is decoupled from the weapon. Recoil, which moves the player's camera, is meaningless for a turret because there is no player camera to move. The omission of recoil fields is intentional and should be preserved when editing the HMG for its intended turret role.
The turret camera system deserves a deeper technical explanation. When a player enters a turret seat on a vehicle, the game switches the player's camera from the character controller to the turret gimbal controller. The gimbal controller reads input from the mouse or thumbstick and rotates the turret's yaw and pitch independently of the player character's facing direction. The turret's barrel transform rotates to match the gimbal angles, and the bullet spawns from the barrel transform's forward direction. Recoil -- which offsets the camera by a random amount per shot -- cannot be applied in this camera mode because there is no camera to offset. The gimbal directly controls the turret's rotation; there is no intermediate camera layer that recoil could perturb.
If you convert the HMG to a handheld weapon (by removing the Turret flag), you must add recoil fields. A handheld weapon with zero recoil provides no visual feedback and feels disconnected from the firing action. Start with modest values: Recoil_Min_X -2, Recoil_Max_X 2, Recoil_Min_Y 4, Recoil_Max_Y 6, then adjust based on testing. The recoil values from similar full-auto weapons are a good reference point.
When adding recoil to a formerly turret-class weapon, you must also consider how the recoil interacts with the Auto flag and the Firerate value. Each shot in an automatic burst applies the recoil offset to the camera. With Firerate of 7 (a fast cyclic rate), the recoil accumulates rapidly. The Recoil_Min and Recoil_Max values define a random range for each shot's kick; over a sustained burst, the camera will drift upward (positive Y recoil) and jitter left and right (random X recoil). Test with full-magazine dumps to verify that the accumulated recoil does not push the camera into an unplayable state.
How spread and recoil differ. Spread and recoil are often conflated but they are separate systems. Spread (controlled by Spread_Aim and optionally Spread_Hip) affects where the bullet goes relative to the crosshair. It is a randomness factor applied to the projectile trajectory before the shot is fired. Recoil (controlled by the Recoil_Min/Max_X/Y fields) affects where the camera points after the shot is fired. It is a cumulative displacement applied to the player's viewpoint. A weapon with zero spread and high recoil will fire exactly where the crosshair was pointing but will move the crosshair after each shot -- the first shot is perfectly accurate but the second shot is not, because the crosshair moved between shots. A weapon with high spread and zero recoil will fire in a random cone around the crosshair but the crosshair will not move -- each shot is inaccurate from a stationary aim point. The HMG has zero recoil and a small spread of 0.05, meaning each shot is quite accurate from a stationary aim point. For a turret, this is ideal: the gimbal stays on target, and the bullet lands within a tight cone.
The spread system uses a random-number generator seeded by the server's tick counter. This means the spread offset is deterministic for a given tick: if the weapon fires on tick N, the spread offset is the same every time the weapon fires on tick N (for that server session). This determinism is why the client and server can independently compute the same spread offset without explicitly synchronising random seeds for each shot: they use the same tick counter, the same weapon asset, and the same random-number algorithm. The spread is repeatable but not predictable by the player, because the player does not know the server's tick counter at the moment of firing.
Why other spread fields are absent. In addition to missing recoil fields, the HMG's extracted data has no Spread_Hip, no Spread_Aim_Movement, and no Spread_Crouch field. Weapons that are designed for handheld use often define a full matrix of spread values that vary by player state: standing vs. crouching, stationary vs. moving, hip-firing vs. aiming down sights. A turret weapon does not benefit from this state matrix because the turret operator is always stationary (seated) and always "aiming" (the gimbal replaces the ADS system). The spread value that matters is the single Spread_Aim of 0.05, which applies to every shot regardless of the operator's state. When converting the HMG to handheld, a modder should add the missing spread fields to give the weapon appropriate accuracy variation by movement and stance.
Flags
Flags are boolean or tag-like properties that modify weapon behaviour. Each flag enables or disables a specific system in the game engine. The HMG asset registers three flags:
| Flag | Effect |
|---|---|
Auto | Weapon fires continuously while the fire button is held |
Invulnerable | Weapon cannot be destroyed by damage |
Turret | Weapon behaves as an emplaced or vehicle-mounted turret |
Auto enables full-automatic fire. When the player presses and holds the fire key, the weapon enters a firing loop: it fires a round, waits Firerate ticks, fires another round, waits again, and continues until the fire key is released or the magazine runs dry. If the Auto flag were absent and no other fire-mode flag (Semi, Burst) were present, the weapon would fire once per key press regardless of how long the key is held.
The Auto flag works in combination with the Firerate value. The Firerate field controls the delay between shots in the automatic sequence; the Auto flag controls whether the sequence repeats. Both must be present and correctly configured for automatic fire to work as expected.
The firing loop at the engine level works as follows. On the tick when the fire key is first detected as pressed, the game checks ammunition (is the magazine count greater than zero?), checks the fire-mode flag (is Auto present?), spawns the bullet at the muzzle transform, decrements the magazine count by one, and schedules the next fire event for Firerate ticks in the future. On the scheduled tick, the game repeats the check: is the fire key still held? Is ammunition still available? If both are true, it fires again and schedules another event. If the fire key has been released, the loop ends. If the magazine reaches zero, the loop ends and the game initiates a reload if the player has matching ammo in their inventory.
This per-tick scheduling means the fire rate is tied to the game's tick rate. On a server with a stable tick rate, the Firerate value produces a consistent delay between shots. On a server with an unstable tick rate (due to high player count, heavy mod load, or underpowered hardware), the actual delay between shots may vary because the scheduled fire events are processed when the tick runs, not at a precise wall-clock interval. This is one reason why weapons with very low Firerate values (very fast fire) can feel inconsistent on busy servers -- the server cannot schedule events fast enough to keep up with the weapon's intended rate.
Invulnerable prevents the weapon entity from taking any damage. In normal Unturned gameplay, placed objects (barricades, structures, deployables) have health bars and can be destroyed by gunfire, explosives, or melee. The Invulnerable flag tells the damage system to skip this entity entirely -- damage events targeting the HMG are discarded before any health calculation occurs.
This flag is important for a turret that is part of a vehicle or structure. If the turret could be destroyed independently of its parent vehicle, the vehicle would be rendered useless while still appearing intact. The Invulnerable flag ensures the turret lasts as long as its parent vehicle, with the vehicle's own health system governing when the combined entity is destroyed.
The damage-event priority queue on the server processes damage events in the order they arrive. When a damage event targets the HMG, the server checks the entity's flag set before computing any damage. If Invulnerable is present, the event is discarded immediately -- before armour checks, before health subtraction, before death-state transitions. The event is not logged as a hit; it is silently consumed. This means server logs will show zero incoming damage events for the HMG turret entity, even if enemies are actively shooting at it.
The Invulnerable flag applies only to the turret entity itself. It does not protect the operator sitting in the turret seat. A player manning the HMG can still be shot and killed. The flag also does not protect the parent vehicle -- if the vehicle's health reaches zero, the vehicle is destroyed, and the turret entity is cleaned up as part of the vehicle destruction sequence regardless of its Invulnerable flag. The flag prevents direct destruction of the turret; it does not prevent the turret from being removed when its parent is destroyed.
For server owners, the Invulnerable flag has balance implications. A placed HMG cannot be countered by shooting it -- enemies cannot destroy the turret to neutralise the threat. The only counterplay is to kill the operator or destroy the vehicle the turret is mounted on. If your server's PvP meta relies on the ability to destroy placed weapons, you may want to remove this flag, but test first: the turret model may not have a destruction animation, and removing the flag could lead to visual glitches when the turret reaches zero health.
Turret tells the game that this asset is a turret rather than a handheld firearm. When the Turret flag is present, the game routes the weapon through an entirely different set of systems:
Aiming: The player's camera does not control the turret directly. Instead, the turret responds to gimbaled input -- the camera looks around normally while the turret's gun barrel tracks independently. This is the system that allows a vehicle driver to look one way while the turret gunner aims another.
Input: The fire key is interpreted by the turret system, not the standard weapon system. Turrets may have separate key bindings depending on the vehicle configuration.
Attachment handling: The turret's position and rotation are managed by the vehicle or structure it is mounted on, not by the player's hand-bone transforms. Removing the
Turretflag without updating the model and attachment points will result in the weapon floating at the world origin or snapping to the player's hand in a misaligned orientation.Mounting: The game's turret-mount system expects a mounting point on the parent vehicle or structure. The turret asset references this mount point through the vehicle's configuration. If you spawn a turret-class item as loose inventory and the player equips it without a mount point, the behaviour is undefined and may result in the weapon being unusable or the game crashing.
The turret gimbal system is seat-indexed. Each vehicle defines a list of seats, and each seat can be flagged as a turret seat. When a player enters a seat flagged as a turret, the game looks up the turret weapon asset bound to that seat index (by the suffix convention described in the Asset identity section), instantiates the turret entity at the seat's mount transform, and switches the player's input to the gimbal controller. The gimbal controller reads the player's look input (mouse delta or controller stick) and rotates the turret's yaw and pitch within limits defined by the vehicle asset. Some turret seats have unrestricted yaw (full 360-degree rotation); others have limited arcs. The HMG's turret limits are defined in the Fighter_Jet vehicle asset, not in the weapon asset.
When the Turret flag is present, the game also skips several systems that only make sense for handheld weapons. It skips the aim-down-sights system (there is no iron sight or scope to look through). It skips the sprint-interrupt system (the player cannot sprint while in a turret seat). It skips the weapon-bob animation system (the turret model does not sway with player movement). It skips the recoil system entirely, even if recoil fields are present in the asset -- the gimbal controller does not have a camera to perturb. Understanding what the Turret flag disables is as important as understanding what it enables, because adding turret-incompatible fields (like recoil) will appear to work in the asset editor but produce no in-game effect.
The flags list contains no attachment-hook flags (Hook_Sight, Hook_Grip, Hook_Tactical). This means the HMG cannot accept attachments -- there are no hook points for the attachment system to slot items into. A modder who wants to add a sight or grip must add the relevant hook flag AND ensure the weapon model has the corresponding attachment transform with the correct index.
Attachment hooks work through a transform-index system similar to the Muzzle field. Hook_Sight expects a transform at a specific index on the weapon model where the sight attachment will be parented. Hook_Grip expects a transform at a different index. When a player attaches an optic to the weapon, the game instantiates the optic model as a child of the sight-hook transform, positioning and rotating it relative to the weapon. If the transform index is wrong or missing, the optic will appear at the model's root (typically at the weapon's centre of mass) or fail to appear entirely. When adding hook flags to a weapon that previously lacked them, verify the transform indices against the model's bone hierarchy in a 3D editor.
Flag interaction depth
The three flags on the HMG -- Auto, Invulnerable, and Turret -- do not operate in isolation. They combine to produce specific behaviours that emerge from the interaction of their respective systems.
The Auto + Turret combination means the weapon fires continuously from a stabilised platform. In a handheld weapon, Auto fire causes the recoil system to push the camera upward, and the player must actively compensate by pulling the mouse down. In a turret, Auto fire has no recoil cost -- the gimbal stays perfectly on target while the barrel spits rounds. This makes the turret version of an automatic weapon significantly more accurate than the handheld version of the same weapon would be, even with identical Firerate and Spread_Aim values. The accuracy advantage comes entirely from the flag interaction, not from any stat difference.
The Turret + Invulnerable combination makes the weapon a permanent fixture of the battlefield. A turret that cannot be destroyed becomes a terrain feature that shapes player movement. Vehicles can be destroyed, and when they are, the turret disappears with them -- but while the vehicle lives, the turret is an immovable object. This combination is common in base-defence scenarios: a vehicle placed as a static emplacement with an invulnerable turret creates a hard point that attackers must flank or suppress, not destroy.
The Auto + Invulnerable + Turret triple combination is what gives the HMG its area-denial role. A high-fire-rate weapon on a stabilised, indestructible mount can suppress a sightline indefinitely as long as ammunition holds. The ammo economy becomes the only limiting factor: the weapon will never break, never jam, never deviate from its aim point, but it will eventually run dry. Server owners designing encounters around the HMG should tune the ammo availability to control how long the turret can sustain fire. A turret with Ammo_Max 50 and no nearby ammo crates is a short-term threat. A turret with a resupply crate of Caliber 37 ammo boxes nearby is a persistent area-denial tool.
Flags are mutually exclusive within the fire-mode category. Auto, Semi, and Burst are fire-mode flags, and the game uses the first one it encounters in the flag list. If you add Semi before Auto in the list, the weapon fires semi-automatically regardless of what other flags are present. If you add both without understanding the order-dependency, the weapon will behave unpredictably. Always use exactly one fire-mode flag per weapon, and place it first in the flag list if you care about deterministic behaviour.
Consequences of removing individual flags. Each flag removal has a specific, predictable effect that cascades through the weapon's behaviour:
Removing
Autowithout addingSemi: The weapon fires once per trigger pull. TheFirerateof 7 still limits the minimum delay between manual shots, so rapid clicking produces fire slower than the automatic rate. The weapon retains all other turret behaviour -- it is still gimbal-aimed, still invulnerable, still recoil-free -- but requires a separate click for every round fired. This makes the weapon tedious to use but does not break any system.Removing
Invulnerable: The turret entity gains a health bar and can be destroyed by enemy fire. The turret uses the default barricade health calculation unless a health value is specified elsewhere in the asset. If the turret is destroyed, the operator is ejected from the turret seat (if the vehicle handles turret-destruction cleanup correctly). If the vehicle does not handle turret destruction, the operator may become stuck in a destroyed turret -- a known edge case that requires testing before deployment.Removing
Turret: This is the most disruptive single-flag removal. The weapon ceases to use the gimbal controller and reverts to the handheld weapon pipeline. The weapon model snaps to the player's hand-bone transform, which was never configured for this weapon. The aim-down-sights system activates but has no sight model to render. The sprint system begins checking whether the weapon should interrupt sprint, which may produce incorrect behaviour because the weapon was never tagged for sprint-compatible use. This flag removal requires adding multiple supporting fields (recoil, spread-hip, hand-bone indices) to produce a functional handheld weapon.
Flag interaction with server settings. The Invulnerable flag interacts with server settings that control entity damage. If a server plugin or configuration disables damage to all barricades (for creative-mode or build-protection purposes), the Invulnerable flag becomes redundant -- the entity is protected by the server setting regardless of the flag. Conversely, if a server configuration amplifies damage to barricades (for hardcore or raid-focused servers), removing the Invulnerable flag makes the turret fragile and potentially unusable. The server's damage multiplier applies to whatever health the turret entity has after the flag is removed, so a 2x damage multiplier means the turret is destroyed twice as fast by enemy fire.
Flag compatibility across game versions. Unturned receives regular updates that occasionally change how flags are parsed and applied. A flag that works in one version may be ignored or reinterpreted in a later version. The three flags on the HMG -- Auto, Invulnerable, Turret -- are among the oldest and most stable flags in the game and are unlikely to change behaviour across versions. However, if you add newer flags (introduced in recent updates) to the HMG's flag list, verify that your target game version supports them. Flags introduced after the version you are targeting will be silently ignored, and the weapon will work but without the expected behaviour.
Loot table presence
This weapon does not appear in any extracted loot table. It is obtained another way (NPC reward, crafting, or admin-only).
This is an important finding. When a weapon has zero loot-table entries across all official maps, it cannot be found by looting containers, killing enemies, or searching world spawns in normal gameplay. The absence from loot tables means the item is gated behind a non-loot system.
There are three common gating mechanisms for items that do not appear in loot tables:
NPC quest reward: An NPC dialogue tree awards the item upon quest completion. The quest system tracks quest state per player and awards the item once. The item ID (
1471) would appear in the NPC's reward configuration, not in any loot table.Crafting recipe: A blueprint asset references the item as an output. The player gathers the required input items, stands near the required crafting station (if any), and crafts the weapon. The weapon's item ID appears in the blueprint's output list.
Admin only: The item exists in the game files but has no legitimate acquisition path. It can only be spawned via the
/give 1471command, which requires admin permissions. This is common for developer test items, event-exclusive items, and items that are part of an unreleased feature.
Without additional data from the NPC or blueprint systems, it is not possible to determine which of these three mechanisms applies to the HMG. The loot-table data is clear in what it tells us: the weapon is not obtainable through looting. A modder who wants the HMG to appear as loot must add entries to the relevant spawn tables manually.
Adding the HMG to loot tables. Each map's loot configuration lists named spawn tables. Find the table that corresponds to the container or enemy type you want to populate, and add a row with the HMG's item ID (1471) and a weight value. The weight determines the item's share of the table's total.
For example, if a spawn table currently has 10 items each with weight 10, the total weight is 100. Adding the HMG with weight 10 increases the total to 110 and gives it a 10/110 = roughly 9.1% chance per roll. Adding it with weight 2 gives it a 2/102 = roughly 2% chance. Choose the weight based on how rare you want the item to be relative to the table's other contents.
Be aware that spawning a turret-class weapon as loose loot may produce unexpected behaviour. The player who picks it up cannot equip it in the conventional sense -- they can place it as a turret, but they cannot hold it and aim down sights. Test the spawn-and-equip flow before deploying the loot-table change to a live server.
Loot table structure. Unturned's loot system is a tree of named tables. At the root, each map defines a master list of spawn-table references. Each spawn table contains a list of item entries, where each entry has an item ID and a weight. Some spawn tables reference other spawn tables through a "sub-table" mechanism: instead of listing items directly, a table entry points to another table by name, and the game recursively resolves the reference before rolling. This means a single item can appear in many different containers without duplicating the entry -- the entry lives in one table, and every container that references that table inherits the entry automatically.
When adding the HMG to a loot table, you can either add the entry directly to a container-specific table (e.g., the military-crate table) or create a new sub-table for rare turret weapons and reference it from the container tables you want to populate. The sub-table approach is cleaner for server-wide changes: you add the HMG once, in one place, and it appears everywhere the sub-table is referenced. The direct-entry approach is simpler for one-off additions: you add the entry to exactly the container you want, and no others are affected.
Loot table weight tuning. The weight system is proportional, not percentage-based. This has important implications for editing. If a spawn table currently has a total weight of 100 and you add the HMG with weight 10, the HMG has a 10/110 = 9.1 per cent chance per roll. If you later add five other items to the same table, each with weight 10, the total weight becomes 160 and the HMG's chance drops to 10/160 = 6.25 per cent -- without you ever editing the HMG's weight. This drift is a common source of balance degradation in long-running servers. An item added early with a carefully chosen weight becomes increasingly rare as other items are added to the same table. To maintain a target probability, recalculate the weight whenever items are added or removed from the table.
The inverse is also true: if items are removed from the table, the HMG's probability increases without any edit to its weight. A server owner who removes several common items from a spawn table to make loot more interesting may accidentally make rare items much more common. After any batch edit to a spawn table, verify the new probability of each rare item and adjust weights to restore the intended distribution.
Sub-table inheritance and overlapping references. A spawn table can be referenced by multiple parent tables. If the HMG is placed in a sub-table called rare_turrets, and three different container types (military crate, airdrop crate, boss loot chest) all reference rare_turrets, the HMG is now available from three container types with the same probability per roll. If you want the HMG to be rarer in one container than another, you cannot achieve this through the sub-table alone -- all containers referencing rare_turrets get the same weights. You would need to create two separate sub-tables (rare_turrets_common and rare_turrets_rare) with different weights for the HMG, and have different container types reference different sub-tables. Planning the table hierarchy before adding entries avoids having to restructure the entire loot system later.
Quest reward implementation. If the HMG is a quest reward, the quest system configuration lives in an NPC dialogue asset, not in a loot table. The dialogue asset defines conversation nodes, each with conditions and actions. A reward action specifies an item ID to give the player, a quantity, and whether the reward is repeatable. The NPC dialogue editor in Unturned's development tools provides a visual node graph for configuring quest chains, conditions (player level, items in inventory, quest flags), and rewards. To add the HMG as a quest reward, find the dialogue node that represents quest completion and add a reward action with item ID 1471 and quantity 1.
Crafting recipe implementation. If the HMG is craftable, the recipe lives in a blueprint asset. A blueprint defines input items (each with an item ID and quantity), an output item (item ID and quantity), a required skill level, and an optional required crafting station (e.g., a workbench). Creating a crafting recipe for the HMG requires creating a new blueprint asset -- or modifying an existing one -- with 1471 as the output item ID. The input items should be rare enough to match the weapon's value; common inputs for high-tier weapons include military-grade components, scrap metal, and electronic parts.
Server owners and modders have a fourth option beyond loot tables, quests, and crafting: direct plugin injection. Server plugins running on frameworks like RocketMod or OpenMod can listen for events (player spawn, container open, enemy killed) and inject items into the player's inventory or the container's loot list. A plugin rule like "give every player the HMG on first spawn" or "add the HMG to airdrop crates with a 5 per cent chance" is independent of the game's loot tables and does not require modifying the map's asset files. This is the recommended approach for server owners who want to distribute the HMG without bundling a modified map.
Loot respawn mechanics. When a container's loot is taken by a player, the game starts a respawn timer. The duration of this timer is set per-container or per-spawn-table in the map configuration. When the timer expires, the game rolls the spawn table again and populates the container with new items. The HMG, if added to a spawn table, will be eligible for each respawn roll. If a container has a five-minute respawn timer and the HMG has a 2 per cent weight in that table, a player who loots the container every five minutes for several hours has a cumulative chance of eventually finding the HMG. The expected number of rolls to see the HMG at least once depends on the weight percentage: at 2 per cent per roll, the expected number of rolls is roughly 50, which at five minutes per respawn means roughly four hours of looting the same container. This is why high-tier items are often given low weights -- the rarity is enforced by statistical probability rather than a hard cap.
Why the HMG has no loot-table entries. The absence from loot tables is not an oversight. Vehicle-mounted weapons in Unturned are typically acquired by acquiring the vehicle, not by finding the weapon as a standalone item. The Fighter_Jet vehicle spawns at predetermined locations on certain maps, and the HMG comes with it. The weapon was never meant to circulate in the player economy as an equippable item. This is the most common reason for a weapon to have zero loot-table entries: it is part of a vehicle spawn, and the vehicle is the acquisition method. The item still has an ID, a GUID, and a complete stat block because the game engine treats it as an item -- but the distribution system treats it as a vehicle component.
The Fighter_Jet vehicle itself has its own spawn rules, defined in the map's vehicle-spawn configuration. Vehicle spawns are separate from item loot tables. A map may define a set of vehicle spawn points, each with a list of vehicles that can appear there, each with a weight. The Fighter_Jet appears at vehicle spawn points assigned to military airfields or similar locations, with a weight that determines how often it spawns relative to other aircraft. When the Fighter_Jet spawns, the HMG spawns with it -- bound to the turret mount point, loaded with 40 to 50 rounds of ammunition. From the player's perspective, the acquisition chain is: find an airfield, find a spawned Fighter_Jet, get in the gunner seat, and the HMG is ready. The weapon never enters the player's inventory as a standalone item.
This acquisition model has implications for server balance. If a server owner disables vehicle spawns (for performance or gameplay reasons), the HMG becomes unobtainable through normal gameplay. If a server owner increases the Fighter_Jet spawn rate, the HMG becomes more common indirectly, because every spawned Fighter_Jet carries one. If a server owner modifies the Fighter_Jet's health or spawn location, they are indirectly modifying the HMG's availability and durability. Server owners who want to control the HMG's distribution must think in terms of the vehicle spawn system, not the loot system.
This pattern -- vehicle-component weapons with full stats but no loot-table entries -- repeats across many Unturned weapons. Examples include the tank cannon, the helicopter minigun, and various naval turrets. Each is a fully defined weapon that can be spawned with /give and studied in isolation, but each is intended to be encountered as part of a vehicle. When you find a weapon with full stats but no loot presence, check whether the weapon's asset name contains a vehicle suffix. If it does, the weapon is almost certainly a vehicle component, and the vehicle's spawn configuration is the distribution mechanism.
How the loot-table extraction was verified. The statement "this weapon does not appear in any extracted loot table" is the result of a systematic extraction pipeline, not a casual observation. The pipeline works as follows: every bundled map's loot configuration is deserialised, producing a list of named spawn tables. Each spawn table's entries are enumerated, recording the item ID and weight of every entry. Sub-tables are recursively resolved to ensure no indirect references are missed. The resulting flat list of item IDs is deduplicated and compared against the HMG's item ID (1471). No match was found in any official map's loot tables as of the extraction date. This methodology is repeatable: re-running the extraction on updated map bundles will produce a current result, and any future appearance of the HMG in a loot table will be detected by the same pipeline.
Canned Beans
There are no Canned Beans associated with the HMG's loot tables in the extracted data. This is expected for a turret-class weapon. Beans typically appear in civilian-loot tables, food-crate tables, and grocery-store spawns -- not in military emplaced-weapon drops. The absence is documented here rather than silently omitted.
The Canned Beans lore thread on this wiki tracks every verified bean sighting across all loot tables. A weapon that has no loot-table entries cannot, by definition, share a table with beans. If the HMG is later found to appear in a loot table that also contains beans, this section will be updated to reflect that relationship.
For the broader context of beans in Unturned lore, see Canned Beans Lore.
The tracking methodology for beans is straightforward: every loot table extraction run logs the full list of items each table contains, including item IDs, weights, and any sub-table references. A cross-reference between the item IDs and the known Canned Beans item IDs produces a matrix of bean appearances. The HMG (item ID 1471) does not appear in any table, so the bean cross-reference yields no results. The methodology is documented here so future extractions can verify or update this finding using the same pipeline.
Practical use for server owners and modders
Server owners who want the HMG to be available to players should assess how it reaches them. Without loot-table entries, the item must be distributed through a plugin, a server shop, a kit, or admin commands.
If you run a PvP server, the Invulnerable flag is a significant balance consideration. A placed HMG turret cannot be destroyed by enemy fire. The only way to neutralise it is to kill the operator. In a base-defence scenario, an indestructible turret creates a hard point that attackers must work around rather than destroy. Decide whether this fits your server's design philosophy before making the HMG widely available.
The combination of Auto fire, Firerate 7, and zero recoil means the HMG will output consistent, accurate fire as long as ammunition remains. The Spread_Aim of 0.05 means the fire stays on target even at the weapon's full Range of 500. In practice, this makes the HMG an area-denial tool: a placed turret with a good sightline can suppress a wide zone with minimal accuracy loss.
The ammo economy is an important factor. With Ammo_Min 40 and Ammo_Max 50, the weapon starts with 40 to 50 rounds and must be reloaded with ammo items that match Caliber 37. Server owners who provide the weapon through a shop should also make the matching ammo available, or players will have a one-magazine weapon with no way to refill it.
For server-shop or kit integration, the item ID 1471 is the key. A /kit plugin entry for the HMG would reference 1471 as the item to grant, optionally with a quantity and a specific ammo count. A shop plugin entry would list 1471 with a currency cost and optionally a permission node that restricts who can purchase it. Both approaches bypass the loot-table absence entirely, making the weapon available without modifying the map's spawn configuration.
Server performance is a relevant consideration for the HMG. A full-auto hitscan weapon with Firerate 7 fires rapidly, and each shot triggers a hit-scan trace on the server. On a busy server with multiple HMG turrets firing simultaneously, the cumulative trace load can contribute to server tick-rate degradation. The hit-scan cost per shot is relatively low (a single raycast against the physics world), but it scales linearly with the number of shots per second. If your server runs into tick-rate issues, consider reducing the number of active turrets or increasing the Firerate value (slower fire = fewer traces per second) rather than lowering the player count.
Modders editing the HMG asset should focus on the fields described in this reference. Each edit should be made in isolation and tested before combining with other changes. The key edits a modder is likely to make are:
Convert to handheld: This is the most complex single edit because it touches multiple systems. Remove the
Turretflag. AddHook_Sight,Hook_Grip, andHook_Tacticalflags if the weapon should accept attachments. Add recoil fields:Recoil_Min_X,Recoil_Max_X,Recoil_Min_Y,Recoil_Max_Yso the weapon provides visual feedback. IncreaseSpread_Aimfrom 0.05 to a higher value if you want less pinpoint accuracy in handheld mode. Test by equipping the weapon on a player character and verifying that the model positions correctly, the fire animation plays, and the recoil feels appropriate.Change calibre and magazine: Modify the
Caliberfield to match a different ammunition type. You must also update theMagazinefield to an item ID whose calibre matches the new value. If the new magazine has a different capacity, updateAmmo_MinandAmmo_Maxto match the desired spawn-round range. Verify that the ammo items for the new calibre exist in the game's item database and are obtainable.Adjust the damage profile: The three independent damage bases (
Player_Damage,Zombie_Damage,Animal_Damage) can be tuned separately. To make the weapon stronger in PvE without changing PvP balance, raiseZombie_DamageandAnimal_Damagewhile leavingPlayer_Damageunchanged. To flatten the damage curve against zombies (making body shots less punishing), raise the zombie limb multipliers (Zombie_Leg_Multiplier,Zombie_Arm_Multiplier,Zombie_Spine_Multiplier) toward 1.0.Add loot-table entries: Find the spawn-table configuration for the map you are editing. Add an entry with the weapon's item ID (
1471) and a weight value. A weight of 5 in a table with total weight 200 yields a 2.5% chance per roll. If adding to a table that already has many items, use a proportionally larger weight to achieve the desired rarity.Remove invulnerability: Delete the
Invulnerableflag to make the turret destructible. The turret will then have a health pool and can be damaged by enemy fire. Test the destruction behaviour: does the turret model disappear cleanly? Does the parent vehicle handle the turret's destruction correctly? If the turret has no destruction animation, the model may snap out of existence, which is visually jarring.Change the fire mode: Remove the
Autoflag and addSemito make the weapon fire one round per trigger pull. AddBurstand a burst-count field to make it fire a fixed number of rounds per trigger pull. Each fire mode flag is mutually exclusive -- the first mode flag the game encounters determines the behaviour, and adding multiple mode flags produces undefined results.
When editing the asset, always keep a backup of the original values. The HMG's stat profile -- high base damage against zombies and animals, low limb multipliers for zombies, Auto fire with Firerate 7, zero recoil, pinpoint Spread_Aim of 0.05, Invulnerable damage immunity, and Turret camera handling -- is a specific, interlocking combination that fits the emplaced-turret role. Any single-field edit can cascade into balance surprises, so test each change in isolation before combining edits.
Testing methodology. Each change to a weapon asset should be tested in a controlled environment before deployment. Use a single-player creative-mode world for initial testing -- spawn the weapon with /give 1471, equip it, and fire it against static targets at known distances. Verify that the model renders correctly, the firing sound plays, the hit effects appear on targets, and the damage numbers match the computed values in this reference. For turret-specific changes, spawn the parent vehicle and test the turret from the gunner seat. For loot-table changes, set up a local server with the modified map and verify that the HMG appears in the intended containers at the intended rate over a statistically meaningful number of rolls (at least 100 container opens to validate a low-percentage spawn rate).
The testing workflow for the HMG should cover four distinct scenarios because the weapon has three flags that change its operating context. Test the weapon as a turret on its parent vehicle first -- this is the baseline, the configuration the weapon was designed for. Fire at stationary targets, moving targets, and targets at the edge of the 500-metre Range. Verify that the gimbal controller responds to input smoothly, that the firing sound plays without gaps or stutter, and that the hit effects render on the target surface. Test at multiple distances: point-blank, 250 metres (half range), 500 metres (maximum range), and just beyond 500 metres (should produce no hit).
Test the weapon as a standalone spawned item to verify that the /give command works and that the item appears in the inventory with the correct name, rarity colour, and description text. If the weapon is configured to be equipable as handheld (with the Turret flag removed and relevant handheld fields added), test the equip animation, the aim-down-sights view, the recoil pattern in sustained fire, and the reload cycle. If the weapon is still turret-class when spawned standalone, verify that the player cannot equip it conventionally and that placing it produces a functional turret entity at the placement point.
Test the weapon in a multiplayer environment with at least two clients. One client fires the weapon while the other client observes from different angles. Verify that the firing animation and muzzle flash are visible to the observer, that hit effects appear on the target from the observer's perspective, and that the damage reported on the target's client matches the damage computed on the server (use a server-side damage log or health-display plugin to verify). Multiplayer testing exposes discrepancies between client prediction and server authority that are invisible in single-player tests.
Test the weapon in a high-load scenario. Spawn multiple turrets in close proximity and fire them simultaneously. If the server tick rate drops, the Firerate of 7 may be too aggressive for your server's hardware. Consider increasing Firerate (slower fire) or reducing the number of concurrent turrets. If the server's physics engine struggles with multiple simultaneous hit-scan traces, consider lowering Range to reduce the trace distance. Performance testing is the step most often skipped, and it is the step that exposes issues that only appear on a populated server.
Common bugs and their causes:
- Weapon fires but no hit effects appear: The
Muzzletransform index may not match the weapon model's bone hierarchy. Verify with a tracer effect. - Weapon cannot reload after calibre change: The
Magazineasset's calibre does not match the weapon's new calibre. Open the magazine asset and update its calibre field. - Weapon snaps to hand at a strange angle after removing
Turret: The weapon model's hand-bone attachment point is not configured for handheld use. Add hand-bone transform data or revert to turret mode. - Weapon deals uniform damage to all zombie hit zones: The custom zombie model uses non-standard bone names. Verify bone names against the vanilla zombie rig or add a bone-name mapping in the NPC configuration.
- Headshots deal no extra damage to custom animals: Same bone-name issue. Verify that the skull bone in the custom animal model is named in a way the multiplier system recognises.
- Loot table change has no effect: The loot table file may not be in the correct map bundle, or the server may be using a cached version of the table. Clear the server's asset cache and restart.
- Weapon spawns with zero rounds despite
Ammo_Min> 0: The magazine asset referenced by theMagazinefield may have a capacity of zero or may be missing entirely. Verify the magazine asset exists and has a positive capacity. - Turret does not appear on vehicle after asset rename: The vehicle resolves turrets by asset name suffix. If you renamed the weapon from
HMG_Fighter_Jetto something else, the vehicle can no longer find it. Either revert the name or update the vehicle asset's turret references. - Reload completes but magazine count does not increase: The ammo item consumed during reload has a calibre that matches the weapon's calibre but provides zero rounds. Check the ammo item's "rounds per box" field.
- Sound cuts out during sustained fire: The firing sound asset may have a maximum polyphony limit, or the audio system may be culling duplicate sounds. Try reducing
Firerate(increasing the wait value) to lower the sound-trigger frequency, or check the audio asset's configuration for instance limits.
Version control for asset edits. Unturned does not provide built-in version control for asset files. Modders should maintain their own backup system. Before editing any .dat file, copy it to a backup directory with a descriptive filename (e.g., HMG_Fighter_Jet_v1_original.dat). After each successful edit, save a new version (e.g., HMG_Fighter_Jet_v2_handheld.dat). This allows you to revert to any previous state and to diff the files to understand what changed between versions. The backup directory should be outside the game's bundle directory to prevent the game from loading backup files as live assets.
The backup discipline is particularly important for the HMG because it has interlocking fields. An edit that changes Caliber also requires a matching change to Magazine, which requires a matching change to ammo availability. If you discover three edits later that the weapon no longer reloads, you need to trace back to which edit introduced the mismatch. With versioned backups, you can binary-search the version history: load v2, test reload -- if it works, load v4, test reload -- if it fails, the bug was introduced between v2 and v4. Without versioned backups, you are guessing about which edit broke the reference chain.
For modding teams, version control goes beyond local backups. A Git repository containing the .dat files, the bundle project files, and a changelog allows multiple modders to collaborate on the same weapon without overwriting each other's work. Each edit is a commit with a message describing what changed and why. The Git diff shows exactly which lines in the .dat file were modified, which is useful for code review and for understanding the edit history when revisiting a weapon months after the last change. The .dat file format is plain text, so it diffs cleanly in any version-control system.
Deployment checklist. Before deploying a modified HMG asset to a live server, verify each item on this list:
- The weapon loads without errors in a single-player test world.
- All field values are intentional -- no accidental changes to unrelated fields.
- The weapon's GUID is unique if this is a new custom asset, or matches the vanilla GUID if this is an override.
- The magazine asset exists, has a matching calibre, and has a capacity that aligns with
Ammo_MinandAmmo_Max. - Ammo items exist for the weapon's calibre and are obtainable through loot or shop.
- If the weapon is lootable, the loot-table change is in the correct map bundle and the weight is appropriate for the desired rarity.
- If the weapon is a shop or kit item, the shop/kit plugin configuration references the correct item ID.
- The
Invulnerableflag decision is intentional and documented for server moderation staff. - Recoil values, if added, have been tested with sustained full-auto fire and do not produce unplayable camera behaviour.
- A backup of the original asset file exists and can be restored if the deployment must be rolled back.
When the asset is the first of its kind, deploy it to a test server with a small group of trusted players before rolling it to the main server. Observe how the weapon performs in actual multiplayer conditions -- things that work perfectly in single-player creative mode often expose edge cases when multiple players, network latency, and server load are introduced.