Eaglefire Weapon Reference
The Eaglefire is an Unturned firearm defined by the asset Eaglefire with item ID 4 and GUID b03d581a5c1a490f995f8deba57b0f17. It is a Rare primary-slot assault rifle chambered in Military ammunition. This reference documents every field a modder reads and edits when working with the Eaglefire in the Unturned editor or in a raw .dat file. It covers the ballistics table, the three damage tables, the handling parameters, the enum flags that control behaviour, and the loot tables the weapon appears in across all official and curated maps.
If you searched for "Eaglefire damage", "Eaglefire spawn", "Eaglefire stats", "Eaglefire GUID", or "Eaglefire item ID", this page is the canonical data reference for what the game files actually contain. It does not tell you how to play; it tells you what the asset declares and how a modder interprets those declarations.
This article is written for three audiences. For modders creating custom weapon variants: every field, flag, and enum value is explained so you know exactly what to change and what the change does inside the engine. For server owners tuning balance: the damage tables and spawn-table data provide the quantitative baseline you need to make informed adjustments. For plugin developers: the GUID, item ID, and flag-bitmask details give you the identifiers and patterns to reference the Eaglefire programmatically. Each section builds on the previous ones, and the article is structured so that you can jump directly to the section relevant to your task -- ballistics for fire-rate tuning, damage tables for balance adjustments, flags for behaviour changes, and spawn tables for loot distribution.
Asset identity
Every gun in Unturned is a .dat asset file. The fields below are read directly from the asset. The key identifiers are:
| Property | Value |
|---|---|
| Asset name | Eaglefire |
| Item ID | 4 |
| GUID | b03d581a5c1a490f995f8deba57b0f17 |
| Rarity tier | Rare |
| Slot | Primary |
The asset name is what you type in the editor spawn menu and what appears in spawn-table entries. The item ID is the integer the engine uses internally; it is the value stored in save files and sent over the network. The GUID is a 32-character hex string that uniquely identifies the asset across every map, mod, and server. If you write a plugin that references the Eaglefire by GUID, you use b03d581a5c1a490f995f8deba57b0f17. The rarity tier controls the colour of the item name in the inventory UI and is one of the factors the loot system uses when deciding which spawn table to roll. The slot determines which inventory row the item occupies.
The in-game description string is: American assault rifle chambered in Military ammunition. This string is read from the asset's Description field and displayed in the inventory tooltip.
Understanding the .dat asset format
A .dat asset in Unturned is a plain-text file using a hierarchical key-value format with bracket-delimited blocks. These files live in the Bundles/Sources/... directory tree inside the Unturned installation directory. Item assets reside in Bundles/Sources/Items/ and spawn tables reside in Bundles/Sources/Spawns/. Each .dat file is loaded by the engine at startup; the game reads every asset in the configured source directories, parses them into in-memory ItemAsset objects, and builds lookup tables keyed on both the item ID and the GUID. The engine maintains an index of every loaded asset so that lookups by ID or GUID are constant-time operations during gameplay.
A modder opens a .dat file by navigating to the asset in the Unturned editor and clicking the "Open File" button, which launches the file in the system text editor. Alternatively, a modder can browse to the source directory in Windows Explorer and open the file directly in Notepad, Notepad++, or VS Code. The file is fully human-readable: field names like Range, Player_Damage, and Hook_Barrel are written in plain English with a numeric or enum value on the same line. Editing a .dat file is a matter of changing a number and saving; the engine picks up the change on the next map load or server restart. There is no compilation step, no binary asset-pack step, and no texture-rebake step required for a .dat file change to take effect. A modder can iterate on weapon balance by editing the .dat file, saving, and reloading the map, all within seconds.
The .dat file format uses curly braces {} to delimit blocks and square brackets [] to delimit sub-blocks. The top-level structure of an item asset typically begins with metadata fields (name, ID, GUID, rarity, slot) at the root level, followed by block sections for each category of data. The ballistics fields live in one block, the three damage blocks each live in their own block, the handling fields live in another block, and the flags, blueprints, and other data each have their own blocks. The parser reads these blocks sequentially and maps each field name to its value. If a field appears outside its expected block, the parser may ignore it or map it incorrectly. A modder editing a .dat file should pay attention to the bracket structure: fields must be placed inside the correct block, and blocks must be properly closed with their matching bracket character. A missing closing brace can cause the parser to merge two adjacent blocks, reading fields from the second block as if they belonged to the first, which produces unpredictable behaviour. The Unturned editor provides a "Validate Asset" function that checks for bracket mismatches and other structural errors, and running this validation after editing the file catches the most common bracket-related issues before the weapon is loaded in-game.
When working on a workshop mod, the directory structure matters. A workshop mod intended for distribution through the Steam Workshop must organise its assets into a specific folder hierarchy. The mod's root folder -- typically named after the mod's display title -- contains subdirectories such as Sources/Items/ for .dat files, Sources/Spawns/ for custom spawn tables, and other directories for models, textures, and audio. The .dat file for a custom Eaglefire variant lives inside Sources/Items/ within that mod folder. When the mod is loaded by a client subscribed through Steam Workshop, the engine parses every .dat file in the mod's Sources/Items/ directory and registers the assets alongside the vanilla assets. If a mod includes a custom spawn table that places the variant in the world, that spawn table file goes in the mod's Sources/Spawns/ directory and must be referenced by the mod's map configuration. A modder who is not yet ready to publish to the Workshop can test locally by placing the mod folder in the Unturned Workshop/Content/ directory and enabling the mod in the game's mods menu.
The Unturned editor's asset-source list determines which directories the engine scans for .dat files. By default, the editor includes the vanilla source directories. A modder adding a custom source directory navigates to the editor's asset-source settings and adds the path to their workshop mod folder. Once added, the editor's item browser displays the custom assets alongside the vanilla ones, and the modder can spawn, inspect, and test the variant directly within the editor environment. If the custom source directory is not registered, the engine does not parse the .dat file and the asset does not appear in the editor's item list. This is a common cause of "the asset doesn't show up" when a modder is setting up a new workshop project for the first time.
When writing a plugin that references the Eaglefire, a developer uses the GUID b03d581a5c1a490f995f8deba57b0f17 to locate the asset at runtime. In RocketMod, this involves calling SDG.Unturned.Assets.find(EAssetType.ITEM, guid) which returns the ItemAsset object. In OpenMod, the pattern goes through the abstraction layer: IUnturnedItemAssetDirectory.FindByGuidAsync(guid). Once the modder holds a reference to the ItemAsset, every field described in this article -- Player_Damage, Firerate, Range, the multiplier fields, and the hook flags -- is a property on that object that can be read and, in many cases, overridden programmatically.
The item ID 4 is how the engine identifies the Eaglefire internally. This integer appears in save files (in the .json save data for a player's inventory) and is transmitted over the network when a player equips, fires, or drops the weapon. Spawn tables reference items by ID as well: a spawn table entry for the Eaglefire contains the integer 4 in its ID field, paired with a Weight field that determines how often the engine selects that entry. The engine uses item IDs, not GUIDs, for spawn table lookups and inventory serialisation. GUIDs are used for cross-reference lookups -- plugin code, asset-dependency resolution, master-asset linking, and the flag-block reference described later in this article.
The rarity tier Rare affects the in-game UI in two concrete ways. First, the item name in the inventory grid and tooltip is rendered in a colour that corresponds to the rarity tier: Rare items display in light blue text. A Common item displays in grey, an Uncommon in green, an Epic in purple, and a Legendary in orange -- but the Eaglefire is Rare, so its label is rendered in light blue. Second, the loot system uses rarity when a spawn table has a Min_Rarity or Max_Rarity constraint. A table constrained to Uncommon and Rare items would include the Eaglefire (Rare) but would exclude an Epic or Legendary weapon. If a table has no rarity filter, rarity does not gate the entry at all, and the weight alone determines its selection probability. The rarity tier is displayed in the item tooltip alongside the item name, so a player can see at a glance that the Eaglefire is a Rare-tier weapon without opening any menu.
Ballistics fields
The ballistics block defines how the weapon fires. Each field is a single float or integer value in the asset file. A modder changing these values changes the fundamental feel of the weapon without touching any visual asset or animation.
Ballistics
| Field | Value |
|---|---|
| Range | 200 |
| Firerate | 4 |
| Action | Trigger |
| Caliber | 1 |
| Muzzle | 3 |
| Magazine | 6 |
| Ammo_Min | 10 |
| Ammo_Max | 30 |
Range
Range is 200. This is the distance, in game units, at which the projectile's damage falloff begins to apply. A modder who wants the Eaglefire to be effective at longer distance would raise this value. A modder making a carbine variant might lower it. The value is a floating-point number in the asset, so 250 or 175 are both valid edits.
Firerate
Firerate is 4. This is the internal tick count between shots. Lower values mean the weapon cycles faster. The engine divides its internal tick rate by this number to determine how many ticks must pass before the next shot can fire. When a modder wants a faster-firing variant, they lower this field; a slower heavy variant raises it.
Action
Action is Trigger. This is an enum field that tells the engine which firing mode animation to play and which internal firing logic to use. Trigger means the weapon fires once per input press when in Semi mode. The other common values in Unturned are Bolt (a manual cycle animation between shots), Pump (a pump-action cycle), and Break (a break-action reload). A modder cannot write an arbitrary string here; they must use one of the values the engine recognises.
Caliber
Caliber is 1. This is an enum that maps the weapon to an ammunition type. The engine uses this integer in a lookup table. Caliber 1 corresponds to Military ammunition magazines and boxes. If a modder changes this to, say, 2, the Eaglefire would accept Timberwolf magazines instead. Changing Caliber also changes which ammo boxes the weapon consumes when a player reloads from inventory.
The Caliber enum system is broader than just magazine compatibility. It governs three distinct mechanics: which magazine attachments are accepted by the weapon, which ammo boxes are consumed during reload, and which damage type is assigned to the projectile for the purpose of armour resistance calculations. All three are controlled by the same single Caliber integer. This means a modder cannot make the Eaglefire accept Military magazines while consuming Civilian ammo boxes, for instance; the Caliber value binds all three behaviours together. The Unturned engine defines a fixed set of Caliber values: 1 is Military, 2 is Timberwolf (high-calibre sniper), 3 is Civilian, 4 is Ranger, and so on. Each Caliber value has its own set of associated magazine assets and ammo box assets, defined by their own Caliber field matching the weapon's value. A modder who wants the Eaglefire to use a custom ammunition type that does not exist in the vanilla game would create a new magazine asset and a new ammo box asset, assign them both a Caliber value that is not in use by any vanilla item, and set the weapon's Caliber field to that value. The magazine must also have a socket enum compatible with the weapon's Magazine field (6), so the attachment hook system and the Caliber system must both agree for the attachment to function.
Muzzle
Muzzle is 3. This is an enum that controls which muzzle-attachment socket type the barrel uses. A value of 3 means the weapon accepts Military barrel attachments (suppressors, muzzle brakes, and the like that have the corresponding barrel-socket enum). A modder changing this to 4 would make the Eaglefire accept the larger-calibre barrel attachments.
Magazine
Magazine is 6. This is an enum that controls which magazine-attachment socket type the weapon uses. A value of 6 means the weapon accepts Military magazines. Changing this field changes which magazine items can be attached. A modder who wants a civilian-only variant might change this to a lower enum value.
Ammo_Min and Ammo_Max
Ammo_Min is 10 and Ammo_Max is 30. These define the range of ammunition the weapon can spawn with when it appears in the world. When the engine places an Eaglefire on the ground from a spawn table, it rolls a random integer between Ammo_Min and Ammo_Max inclusive and fills the attached magazine with that many rounds. These fields do not affect the magazine capacity; the capacity is determined by the magazine attachment asset itself. A modder who wants the Eaglefire to always spawn loaded would set Ammo_Min equal to Ammo_Max.
How the engine uses the ballistics block at runtime
When a player pulls the trigger and the Eaglefire fires, the engine executes a sequence of operations that spans multiple internal systems. First, the engine checks the fire-mode flag (Semi) to determine whether this trigger pull is permitted under the current fire mode. If permitted, the engine reads the Firerate value of 4 and logs the current tick count. The engine runs at a fixed tick rate; a Firerate of 4 means that four engine ticks must elapse before the next shot can be authorised. If the player pulls the trigger again on an intermediate tick, the shot is queued and fires once the cooldown expires. If the weapon had the Auto flag and the trigger was held continuously, the weapon would fire every 4 ticks for as long as the trigger remains held. A modder who sets Firerate to a lower number increases the fire rate; a higher number slows it down. The relationship is linear: halving the Firerate value doubles the cyclic rate of fire.
Once the shot is authorised by the fire-rate gate, the engine spawns a projectile at the barrel socket position. The projectile inherits the direction of the camera, with the Spread_Aim angular offset applied (described in the handling section). The engine then performs a raycast from the barrel position along this direction. The raycast extends for a distance equal to the Range value of 200 game units. A game unit in Unturned is roughly equivalent to one metre in the game world, so a Range of 200 means the projectile can strike a target up to approximately 200 metres away before the engine stops checking for collisions. The engine iterates through every collider the ray passes through, ordered by distance from the barrel. If the ray reaches its maximum range without intersecting a valid target collider, the projectile despawns without dealing damage and the engine plays a surface-impact effect on the world geometry at the raycast endpoint.
The Action enum of Trigger further controls what happens between successive shots at the animation level. When the Action is Trigger, the engine plays a single firing animation and immediately returns the weapon to its idle pose. There is no intermediate cycling animation between shots -- that behaviour would require Bolt or Pump as the action type. This means the Firerate tick cooldown is the only factor pacing the Eaglefire's shots; there is no animation lockout adding additional delay. This is typical for modern assault rifles in Unturned: the action type is kept simple so that Firerate alone controls the fire cadence. A modder who sets Action to Bolt on the Eaglefire would introduce a manual cycle step after each shot, dramatically slowing the weapon regardless of the Firerate value. The Action and the fire-mode flags (Semi and the absent Auto) work in concert: the Action defines the mechanical cycle, while the flags define which trigger behaviours are permitted.
When the player reloads the Eaglefire, the engine refers to the Caliber and Magazine fields rather than the Ammo_Min and Ammo_Max fields. The reload sequence is: the engine checks which magazine attachment is currently equipped (determined by the Magazine socket type of 6), reads the magazine's internal capacity, and attempts to transfer that many rounds from the player's ammunition pool. The ammunition pool item is identified by the Caliber enum value of 1, mapping to Military ammunition boxes. If the player's inventory does not contain enough Military ammunition to fill the magazine to capacity, the engine fills whatever is available. The Ammo_Min and Ammo_Max fields are only consulted during world spawn; they do not constrain how many rounds can be loaded during a manual reload. A modder who wants the Eaglefire to spawn with a partially loaded magazine sets Ammo_Min lower than the magazine's capacity; a modder who wants every spawned Eaglefire to come fully loaded sets both fields to the magazine's maximum capacity.
When the raycast hits a valid target, the engine enters the damage pipeline. It reads the base damage value for the target type: Player_Damage of 40 for a player hit, Zombie_Damage of 99 for a zombie hit, or Animal_Damage of 40 for an animal hit. It then identifies which hitbox on the target's skeleton was struck and looks up the corresponding multiplier from the weapon's hit-zone multiplier fields. The base damage is multiplied by that multiplier to produce the raw applied damage value. The engine then checks whether the target has any damage-modifying equipment or buffs -- armour items, skills like Vitality, or plugin-applied modifiers -- and applies those reductions multiplicatively. The resulting net damage is subtracted from the target's health pool. If the pool reaches zero, the target enters the death state: a ragdoll spawns, items drop into the world, the kill-feed updates, and any subscribed plugin events fire in sequence. This entire pipeline, from trigger pull to health subtraction, executes within a single frame.
Player damage fields
The player damage block defines how much damage each hit of the Eaglefire inflicts on another player, and how that damage is multiplied when the hit lands on a specific body part.
Player damage
| Field | Value |
|---|---|
| Player_Damage | 40 |
| Player_Leg_Multiplier | 0.6 |
| Player_Arm_Multiplier | 0.6 |
| Player_Spine_Multiplier | 0.8 |
| Player_Skull_Multiplier | 1.1 |
Player_Damage
Player_Damage is 40. This is the base damage value before any multiplier is applied. The engine subtracts this number from the target player's health pool. A modder raising this to 50 increases the base lethality against players; lowering it to 30 does the reverse.
Hit-zone multipliers
The four multiplier fields work as follows: when a projectile hits a player, the engine checks which hitbox was struck and multiplies Player_Damage by the corresponding multiplier.
Player_Leg_Multiplieris0.6. A leg hit does 60 percent of base damage.Player_Arm_Multiplieris0.6. An arm hit does 60 percent of base damage.Player_Spine_Multiplieris0.8. A spine (torso) hit does 80 percent of base damage.Player_Skull_Multiplieris1.1. A skull (head) hit does 110 percent of base damage.
Multipliers above 1.0 amplify damage; multipliers below 1.0 reduce it. The hit-zone multiplier system is uniform across all Unturned guns: every gun that deals player damage has these same four fields, but the values differ per weapon. A modder who wants to make headshots more punishing on their server would raise Player_Skull_Multiplier.
How the engine resolves hit-zone damage on players
When a projectile hits a player, the engine does not simply subtract the base damage value. It starts by identifying which collider on the player model was struck. Unturned player models are rigged with a skeleton that includes named hitbox colliders: the skull collider covers the head, the spine collider covers the torso, and the arm and leg colliders cover the limbs. Each collider is tagged internally with a hit-zone identifier that the engine reads during the damage-resolution step. The engine looks up the multiplier field that corresponds to that hit-zone identifier: Player_Skull_Multiplier for a head hit, Player_Spine_Multiplier for a torso hit, Player_Arm_Multiplier for an arm hit, and Player_Leg_Multiplier for a leg hit. If a collider is not clearly classified into one of these four categories -- which can occur with custom character models or modded player skeletons -- the engine typically falls back to the spine multiplier as the default zone.
The raycast that carries the projectile can pass through multiple colliders before terminating. The engine uses the first valid collider hit as the target, meaning the damage is applied to the entity whose collider was intersected first. If the ray passes through a thin wall or object before hitting a player, the engine checks whether the intermediate collider belongs to a destructible object or a world-static piece. If it is a world-static piece (a building wall, a terrain piece), the projectile stops at that collider and does not reach the player behind it. If it is a destructible object (a barricade, a vehicle part), the engine may apply damage to both the object and the player if the projectile has enough penetration, though penetration mechanics vary by weapon type and the Eaglefire does not have high penetration as a standard assault rifle. The hit-zone detection is independent of the raycast path: the zone is determined by which body-part collider was struck, not by the angle or distance of the shot.
A subtle aspect of the damage pipeline is that the hit-zone multiplier is applied before any skill or armour reductions, but after the base damage is selected. This ordering is fixed by the engine and cannot be changed by a modder editing the .dat file. The engine also applies a damage-type flag alongside the numeric damage value. The damage type is derived from the weapon's Caliber enum (1, Military) and is used by armour items that have specific resistance values against particular damage types. For example, an armour item might specify different reduction percentages for Military damage versus Civilian damage. The Eaglefire's Caliber of 1 tags every hit as Military-type damage, which means armour with Military-specific resistance will apply that resistance against the Eaglefire's shots. A modder creating a custom armour set that should be particularly resistant to the Eaglefire would add a Military damage-resistance value in the armour's .dat file.
Once the correct multiplier is identified, the engine performs the multiplication: Player_Damage of 40 multiplied by the hit-zone multiplier produces the raw damage value. This raw value is then passed through the target's damage-modification pipeline. The engine checks the target player's equipped clothing and armour items; each armour piece can carry its own damage-reduction modifier, applied as a percentage multiplier on incoming damage. The engine also checks the target's skill levels: the Vitality skill reduces all incoming damage by a percentage per skill level invested. These reductions are applied multiplicatively -- armour reduces first, then skills reduce the remainder -- so the final damage value that reaches the health pool can be substantially lower than the raw product of the base damage and the zone multiplier. A modder writing a damage-calculator plugin that accounts for armour and skills must chain these modifiers in the correct order: final = base * zone_multiplier * (1 - armour_reduction) * (1 - skill_reduction).
The armour-reduction step deserves careful attention because different armour pieces protect different hit zones. A Military Vest protects the spine (torso) hit zone; a Military Helmet protects the skull (head) hit zone. Arm and leg hit zones are generally unprotected by vanilla armour items, meaning arm and leg shots bypass the armour-reduction step entirely and go straight to the skill-reduction step. This has practical consequences for the Eaglefire's effective damage output: a skull hit with its 44 raw damage against a player wearing a Military Helmet is reduced by the helmet's damage-reduction percentage first, then further reduced by the target's Vitality skill. A leg hit with 24 raw damage is only reduced by the Vitality skill, not by any armour. A modder balancing the Eaglefire for a server where armour use is common should factor in that head and torso hits -- which have the highest raw damage -- are also the hits most likely to be mitigated by armour, while limb hits -- having the lowest raw damage -- bypass armour entirely. This creates a counter-intuitive balance dynamic where, against a fully armoured opponent, a limb shot may deal more net damage than a spine shot after armour reduction, depending on the armour values in play.
Computed player damage by hit zone
When a modder needs to know the actual damage number that will be subtracted from a player's health on each hit, they multiply the base by the zone multiplier. The table below shows the result for the Eaglefire's base damage of 40.
Player damage per hit zone (computed, use verbatim)
| Hit zone | Multiplier | Damage (base 40) |
|---|---|---|
| Skull | 1.1 | 44 |
| Spine | 0.8 | 32 |
| Arm | 0.6 | 24 |
| Leg | 0.6 | 24 |
The engine applies these damage values as floating-point numbers. The health pool is also a float, so fractional damage is preserved. A modder writing a damage calculator plugin should use these product values directly rather than re-deriving them from the base and multiplier fields.
Using computed player damage values in practice
The computed values in the table above are what a modder uses directly in balance calculations. A plugin developer writing a damage-logging plugin reads these product values rather than re-multiplying the base and multipliers at runtime, because the product values are what the engine actually subtracts from the health pool after zone resolution. A server owner tuning weapon balance checks these computed numbers to understand the damage profile across hit zones. The skull damage of 44 and spine damage of 32 are the two most relevant values for player-versus-player balance because head and torso are the hit zones most frequently struck in combat. Arm and leg hits of 24 represent peripheral shots; a modder who wants limb shots to be less punishing would lower the Player_Arm_Multiplier and Player_Leg_Multiplier fields. The skull multiplier of 1.1 on a base of 40 produces 44, which is a fractional increase over the base damage. A modder using these values in a spreadsheet or calculator plugin should preserve the exact product rather than rounding to an integer, because the engine itself does not round -- it subtracts the exact floating-point product from the target's health pool. Accumulated rounding across multiple hits in a damage-tracking plugin would produce a discrepancy between the plugin's prediction and the actual remaining health.
When comparing the Eaglefire to other assault rifles in a balance spreadsheet, the computed damage values provide the most direct basis for comparison. A modder evaluating whether the Eaglefire is appropriately balanced for its rarity tier (Rare) would compare its skull damage of 44 against the skull damage of other Rare-tier primary weapons. If the average Rare-tier assault rifle deals skull damage in a certain range and the Eaglefire is outside that range, the modder has a data-driven justification for adjusting either Player_Damage or Player_Skull_Multiplier. The same comparison applies to spine and limb damage, though limb damage is typically weighted less in balance decisions because it represents a miss rather than an intentional shot. A modder who systematically audits all Rare-tier primary weapons and plots their computed damage values against the Eaglefire's values gains a quantitative understanding of where the Eaglefire sits in the weapon ecosystem. This approach is more reliable than eyeballing the stats or relying on community perception, because it is grounded in the numbers the engine actually uses.
Zombie damage fields
The zombie damage block is structurally identical to the player damage block, but it applies to hits against zombie entities. The base damage and multipliers are independent values in the asset file.
Zombie damage
| Field | Value |
|---|---|
| Zombie_Damage | 99 |
| Zombie_Leg_Multiplier | 0.3 |
| Zombie_Arm_Multiplier | 0.3 |
| Zombie_Spine_Multiplier | 0.6 |
| Zombie_Skull_Multiplier | 1.1 |
Zombie_Damage
Zombie_Damage is 99. This is the base damage per hit against zombie entities. It is independent of Player_Damage: the Eaglefire does 40 to players and 99 to zombies. Every weapon in Unturned has separate player, zombie, and animal base-damage fields. A modder making a weapon that is effective against zombies but weak against players would set Zombie_Damage high and Player_Damage low.
Zombie hit-zone multipliers
The zombie multiplier fields use the same body-part structure as the player multipliers, but the values differ. Zombie leg and arm multipliers are 0.3 (half of the player 0.6), and the spine multiplier is 0.6 (compared to the player 0.8). The skull multiplier is 1.1 for both target types.
Zombie_Leg_Multiplieris0.3. A leg hit on a zombie does 30 percent ofZombie_Damage.Zombie_Arm_Multiplieris0.3. An arm hit on a zombie does 30 percent ofZombie_Damage.Zombie_Spine_Multiplieris0.6. A spine hit on a zombie does 60 percent ofZombie_Damage.Zombie_Skull_Multiplieris1.1. A skull hit on a zombie does 110 percent ofZombie_Damage.
The lower limb multipliers for zombies mean that a missed headshot or spine shot is punished more heavily against zombies than against players, relative to the weapon's base damage against each target type.
Zombie damage-pipeline differences
The zombie damage pipeline follows the same hit-zone detection pattern as the player pipeline, but with two important differences. First, zombies do not wear armour and do not have skill levels, so there are no damage-reduction modifiers applied after the hit-zone multiplication. The raw computed value -- the product of Zombie_Damage and the relevant multiplier -- is the exact final value subtracted from the zombie's health pool. This makes zombie damage tuning simpler and more predictable: the numbers in the computed table are what the zombie actually receives, with no further modification from equipment or skills. Second, zombie hitboxes are larger and less granular than player hitboxes. A standard zombie uses fewer hitbox colliders, and the limb collider often covers both arms and both legs as a single combined group. This is why Zombie_Arm_Multiplier and Zombie_Leg_Multiplier share the same value of 0.3: they frequently resolve to the same broad limb collider in practice. A modder who wants the Eaglefire to perform differently against crawling zombies versus standing zombies would need to work at the zombie-asset level -- changing the crawling zombie's hitbox configuration or health values -- not at the weapon-asset level, because the weapon provides a single Zombie_Leg_Multiplier that applies to all zombie leg hits regardless of the zombie's stance or variant type.
Unturned includes multiple zombie types, each defined by its own asset with its own hitbox configuration, movement speed, and special behaviour flags. Common zombies are the baseline; they have the standard three-category hitbox setup. Special zombies such as Burners, Flankers, Spitters, and Mega Zombies may have different hitbox arrangements, different health pools, or damage-resistance modifiers defined in their own assets. The Eaglefire's zombie damage values apply uniformly to all zombie types because the damage is determined by the weapon, not the target -- the weapon declares Zombie_Damage and the four multipliers, and those values are used regardless of which zombie variant is hit. However, a special zombie that has a damage-resistance modifier in its own asset (for example, a Mega Zombie that takes reduced damage from all sources) would reduce the Eaglefire's damage after the weapon's multipliers are applied, at the zombie-asset level. A modder auditing zombie kill efficiency across all zombie types must account for these per-zombie resistances, which are not visible in the weapon asset and must be read from each individual zombie's asset file. For the standard common zombie with no special resistances, the computed values in the table above are the exact damage numbers.
Computed zombie damage by hit zone
Zombie damage per hit zone (computed, use verbatim)
| Hit zone | Multiplier | Damage (base 99) |
|---|---|---|
| Skull | 1.1 | 108.9 |
| Spine | 0.6 | 59.4 |
| Arm | 0.3 | 29.7 |
| Leg | 0.3 | 29.7 |
Using computed zombie damage values in practice
The zombie computed values highlight how the Eaglefire performs against zombie targets across the four hit zones. The skull damage of 108.9 is substantially higher than the spine damage of 59.4, which itself is double the limb damage of 29.7. A modder building a hardcore zombie-survival server would look at these numbers and consider reducing Zombie_Damage so that headshots are less dominant, while a server owner running a more casual experience might leave the values as they are or even raise Zombie_Skull_Multiplier. The steep drop from 108.9 on skull hits to 29.7 on limb hits reveals a clear design principle: the Eaglefire heavily rewards accurate shots on zombies because the limb multipliers are set very low (0.3). A modder designing a new zombie-focused weapon should observe this pattern and decide whether their weapon follows the same accuracy-rewarding philosophy or takes a flatter curve with higher limb multipliers. When writing a damage-calculator plugin, the exact product of 99 * 1.1 = 108.9 should be used rather than a rounded integer, because zombie health pools are tracked as floating-point values in the engine and fractional damage is preserved across consecutive hits.
Animal damage fields
The animal damage block applies to hits against animal entities (deer, pigs, cows, and any other entity the engine classifies as an animal).
Animal damage
| Field | Value |
|---|---|
| Animal_Damage | 40 |
| Animal_Leg_Multiplier | 0.6 |
| Animal_Spine_Multiplier | 0.8 |
| Animal_Skull_Multiplier | 1.1 |
Animal_Damage
Animal_Damage is 40. This matches the Eaglefire's Player_Damage value. There is no Animal_Arm_Multiplier field because animals do not have an arm hitbox; the animal hitbox set is legs, spine, and skull only. This is true of every weapon in Unturned: the animal damage block has three multipliers, not four.
Animal hit-zone multipliers
Animal_Leg_Multiplieris0.6. A leg hit on an animal does 60 percent ofAnimal_Damage.Animal_Spine_Multiplieris0.8. A spine hit on an animal does 80 percent ofAnimal_Damage.Animal_Skull_Multiplieris1.1. A skull hit on an animal does 110 percent ofAnimal_Damage.
The animal multipliers for the Eaglefire are identical to the player multipliers.
Animal damage-pipeline specifics
The animal damage pipeline is the simplest of the three target-type pipelines because animals have the fewest hitboxes and, like zombies, have no armour or skill-based damage reduction. The engine checks whether the projectile struck a skull, spine, or leg collider on the animal model and applies the corresponding multiplier. Because there is no arm collider on animal models, a shot that would hit the arm on a player model typically passes through an animal's limb hitbox and registers as a leg hit instead. Different animal types in Unturned have different hitbox configurations: a deer has a long spine collider and a small skull collider, making headshots harder to land, while a pig has a proportionally larger skull collider relative to its body size. These hitbox differences are defined in the animal asset, not the weapon asset, so the Eaglefire's animal damage values apply uniformly regardless of which animal is being hunted. A modder who wants the Eaglefire to be more effective against larger-bodied animals cannot achieve this through the weapon's damage fields alone; they would need to either raise Animal_Damage uniformly for all animal types or modify the individual animal assets to have different damage-reception properties. The absence of an Animal_Arm_Multiplier field also means that any plugin iterating through hit-zone multipliers must handle the missing field gracefully -- checking for its existence before attempting to read it, and falling back to the spine multiplier when the arm multiplier is absent from the weapon's data block.
The animal entities in Unturned include deer, pigs, cows, bears, and wolves, each with its own behavioural AI and hitbox configuration. Bears and wolves are aggressive and will charge the player, while deer, pigs, and cows are passive and flee when attacked. The Eaglefire's animal damage values do not differentiate between these types; a skull shot on a bear deals the same 44 damage as a skull shot on a deer. However, bears and wolves typically have higher health pools in their animal assets, making them more resilient despite taking the same per-hit damage. A modder running a server where bears are common and considered a threat might raise Animal_Damage on the Eaglefire specifically to make it a more effective anti-bear weapon, while leaving Zombie_Damage and Player_Damage untouched. The independence of the three damage blocks enables this kind of surgical balance tuning without side effects on other combat scenarios.
Computed animal damage by hit zone
Animal damage per hit zone (computed, use verbatim)
| Hit zone | Multiplier | Damage (base 40) |
|---|---|---|
| Skull | 1.1 | 44 |
| Spine | 0.8 | 32 |
| Leg | 0.6 | 24 |
Using computed animal damage values in practice
The animal computed values show that damage against animals mirrors the player damage profile exactly: skull damage of 44, spine damage of 32, and leg damage of 24. This is because Animal_Damage (40) matches Player_Damage (40) and the three animal multipliers match the corresponding player multipliers. For a modder, this means the Eaglefire is equally effective against animals as it is against players on a per-hit basis. A hunting-focused server where animals have increased survivability would benefit from a mod that raises Animal_Damage on the Eaglefire separately from Player_Damage, preserving player-versus-player balance while making the weapon viable for hunting. Since the animal damage block is independent from the player damage block, these changes do not cross-contaminate between target types. A plugin that overrides Animal_Damage at runtime, using the GUID b03d581a5c1a490f995f8deba57b0f17 to locate the asset, can apply a per-server tuning value without affecting any other weapon and without touching the underlying .dat file on disk.
Testing animal damage values in the editor requires a different approach than testing player damage. The Unturned editor does not have a built-in animal-spawn panel in the same way it has an item-spawn panel. To test the Eaglefire's animal damage, the modder must load a map that contains animal spawn nodes, find or spawn an animal entity, and fire at it while monitoring the damage output. The most efficient workflow is to use the debug overlay (enabled via the console or a debug plugin) to display entity health values in real time. With the debug overlay active, the modder can shoot an animal in each hit zone -- skull, spine, and leg -- and confirm that the damage values match the computed table. If the values do not match, the discrepancy is typically caused by one of three issues: the .dat file changes were not reloaded, a plugin is overriding the damage values at runtime, or the animal asset being tested has its own damage-reception modifiers that differ from the default. The modder should also test against multiple animal types (deer, pig, cow) to confirm that the damage values are consistent across types, since animal hitbox configurations vary between species and a leg shot on a deer may resolve to a different collider than a leg shot on a pig.
Handling fields
The handling block controls how the weapon moves the camera when fired. These fields define the recoil pattern, the aiming spread, and the camera shake.
Handling
| Field | Value |
|---|---|
| Recoil_Min_X | 0.5 |
| Recoil_Min_Y | 3 |
| Recoil_Max_X | 1.5 |
| Recoil_Max_Y | 4 |
| Spread_Aim | 0.05 |
| Shake_Min_X | -0.0025 |
| Shake_Max_X | 0.0025 |
Recoil_Min_X and Recoil_Max_X
Recoil_Min_X is 0.5 and Recoil_Max_X is 1.5. These define the horizontal recoil range. On each shot, the engine rolls a random float between these two values and adds it to the camera's current horizontal angle. Both values are positive, which means the Eaglefire recoils exclusively to the right on the horizontal axis. A modder who wants a weapon that kicks left instead would set both values negative. A modder who wants random left-right kick would set one negative and one positive.
Recoil_Min_Y and Recoil_Max_Y
Recoil_Min_Y is 3 and Recoil_Max_Y is 4. These define the vertical recoil range. On each shot, the engine rolls a random float between these two values and adds it to the camera's vertical angle. Both values are positive, which means the camera always kicks upward. The small gap between 3 and 4 means the vertical recoil is fairly consistent from shot to shot.
Spread_Aim
Spread_Aim is 0.05. This is the base spread value when the player is aiming down sights. The engine adds this value as a random angular offset to the projectile's direction each time the weapon fires. A lower value means tighter shot grouping when aiming. Sniper rifles typically have values of 0.001 or lower; the Eaglefire's 0.05 is typical for an assault rifle. A modder making a marksman variant would lower this toward 0.01.
Shake_Min_X and Shake_Max_X
Shake_Min_X is -0.0025 and Shake_Max_X is 0.0025. These define the camera-shake offset range applied to the viewport on each shot. The engine rolls a random float between these two values and translates the camera on the X axis by that amount for one frame. The shake is cosmetic; it does not affect where the projectile lands. Because the range is symmetric around zero, the camera shakes equally left and right. There are no corresponding Shake_Min_Y or Shake_Max_Y fields in the asset for the Eaglefire.
How the engine applies handling values per shot
When the Eaglefire fires, the handling block values are applied in a specific order within the engine's per-frame update loop. After the projectile is spawned and the damage pipeline runs, the engine reads the recoil fields. It rolls a random float between Recoil_Min_X (0.5) and Recoil_Max_X (1.5) and adds it to the camera's current horizontal rotation. Simultaneously, it rolls a random float between Recoil_Min_Y (3) and Recoil_Max_Y (4) and adds it to the camera's vertical rotation. Both additions happen in the same frame, so the camera immediately jumps by the combined recoil amounts. The engine then applies a recoil-recovery curve that gradually returns the camera toward its pre-shot position over several subsequent frames. This recovery curve is not configurable per-weapon in the .dat file; it is influenced by the player's Sharpshooter skill level and by certain grip attachments that carry a recoil-recovery modifier component.
The Spread_Aim value of 0.05 is applied to the projectile direction vector before the raycast is performed. The engine takes the camera's forward-direction vector and rotates it by a random angle drawn from a cone whose angular radius is Spread_Aim. This means the actual impact point can differ from where the player's crosshair is visually centred. The spread is always applied, even on the first shot of a burst; Unturned's default ballistics system does not grant a first-shot accuracy bonus. A larger spread value makes the weapon less accurate at range because the angular error translates to a proportionally larger positional error as the distance from the barrel increases. A modder lowering Spread_Aim would see tighter shot groupings, making the Eaglefire effective as a longer-range weapon. The value of 0.05 places the Eaglefire squarely in the assault-rifle category for spread: tighter than a typical submachine gun, wider than a dedicated sniper rifle.
When the player is not aiming down sights (hip-firing), the engine applies a separate spread multiplier on top of Spread_Aim. The hip-fire spread multiplier is a global value configured in the game's settings, not in the weapon asset. The Eaglefire's Spread_Aim of 0.05 is the base spread, and the engine multiplies it by the hip-fire spread multiplier when the player fires from the hip. This means the weapon is always most accurate when the player is aiming down sights, which is the intended gameplay design for an assault rifle. A modder who wants to create a weapon that is equally accurate whether hip-fired or aimed would need to set Spread_Aim low enough that even after the hip-fire multiplier is applied, the spread remains acceptable. There is no separate Spread_Hip field in the Eaglefire's asset; hip-fire spread is derived from Spread_Aim via the global multiplier.
The recoil-recovery curve mentioned above is worth understanding in detail because it directly affects how the weapon feels during sustained fire. After the engine applies the per-shot recoil jump (the random values between the Recoil_Min_ and Recoil_Max_ ranges), the camera does not stay at the displaced position. Over the next several frames, the engine applies a recoil-recovery force that pulls the camera back toward its original orientation. The speed and strength of this recovery are controlled by the player's Sharpshooter skill level and by any equipped grip attachments that have a recoil-recovery stat. A higher Sharpshooter level means faster and stronger recovery, which means the camera returns to its original position more quickly and the player can reacquire their target sooner. The recovery curve is not linear; it decelerates as the camera approaches its original position, which creates a smooth settling effect rather than an abrupt snap. A modder who wants the Eaglefire to kick hard but recover quickly would keep the Recoil_ values high but ensure the player has access to grip attachments with strong recovery stats. Conversely, a modder who wants the weapon to kick hard and stay kicked would keep the recovery stats low while keeping the Recoil_ values high.
The camera shake fields are purely visual and do not interact with the damage pipeline or the projectile trajectory. The engine translates the camera's local position by a random offset between Shake_Min_X (-0.0025) and Shake_Max_X (0.0025) for the duration of a single frame, then snaps the position back. This creates the perception of recoil impulse without affecting where subsequent shots land. Because the range of 0.0025 units is very small, the visual effect on the Eaglefire is subtle -- appropriate for an assault rifle that should feel manageable and controllable. A modder building a heavy-calibre rifle would set the shake range much wider to produce a more pronounced screen jolt on each shot. The absence of Shake_Min_Y and Shake_Max_Y fields means the Eaglefire has no vertical camera shake component; the engine only applies horizontal shake for this weapon. A modder who wants vertical shake would need to verify whether the weapon template supports adding those fields or whether they are exclusive to certain weapon archetypes.
Aiming-down-sights and hip-fire behaviour
When the player aims down sights (ADS) with the Eaglefire, the engine applies two separate changes to the weapon's handling profile. First, the Spread_Aim value of 0.05 becomes active as the projectile-spread radius. Second, the engine applies a field-of-view reduction and a sensitivity multiplier, both of which are global settings rather than per-weapon values. The recoil values (Recoil_Min_X, Recoil_Max_X, Recoil_Min_Y, Recoil_Max_Y) and the camera shake values are applied identically whether the player is aiming or hip-firing; the .dat format does not have separate recoil fields for ADS versus hip-fire. This means that a weapon that kicks hard when hip-fired kicks just as hard when aimed, which can create a mismatch where the visual feedback (scope zoom) makes the recoil feel more jarring when aiming. A modder who wants the Eaglefire to be more controllable when aimed would need to lower the Recoil_ values globally, accepting that this also affects hip-fire behaviour.
The relationship between ADS and spread is particularly important for the Eaglefire's effective engagement range. With Spread_Aim at 0.05, the angular error at a distance of 200 game units (the weapon's Range) translates to a positional uncertainty that is large enough to make consistent headshots unreliable at maximum range. This is by design: the Eaglefire is an assault rifle meant for mid-range engagement, not a precision weapon. A modder who wants the Eaglefire to compete with sniper rifles at 200 units would lower Spread_Aim substantially. A modder who wants the Eaglefire to be strictly a close-to-mid-range weapon would leave Spread_Aim as is or even raise it, and would also consider lowering Range to match the intended engagement envelope. These two fields (Spread_Aim and Range) are the primary tuning levers for the weapon's effective combat distance, and they should be adjusted in concert to maintain a coherent weapon identity.
Flags
The enum flags on a gun asset control which behaviours the engine activates for that weapon. Every flag is a named boolean stored as a bitmask in the asset. The Eaglefire asset declares these flags:
Flags present: "7b82c125a5a54984b8bb26576b59e977", Blueprints, Hook_Barrel, Hook_Grip, Hook_Sight, Hook_Tactical, InputItems, RequiresNearbyCraftingTags, Safety, Semi, [, ], {, }
GUID flag
The string "7b82c125a5a54984b8bb26576b59e977" is not a flag name; it is a GUID embedded in the flags block. This GUID may reference a master asset or a parent table. When a modder clones the Eaglefire to create a variant, they should either remove this GUID or replace it with a new one they generate.
Blueprints
The Blueprints flag enables the crafting-recipe system for this item. When this flag is present, the engine reads the Blueprints block in the asset file and makes those recipes available at the appropriate crafting station. A modder adding a repair recipe or a dismantle recipe to the Eaglefire would read and edit the Blueprints block; the flag itself must already be present for those recipes to function.
The Blueprints block in a .dat file is structured as a list of recipe entries, each containing an output item, input ingredients with quantities, a required crafting station or tool, and optionally a skill requirement. For the Eaglefire, having the Blueprints flag set means the weapon can appear as a crafting output in other items' blueprints as well, not just that it produces recipes of its own. The flag signals to the engine that this asset participates in the crafting ecosystem. A modder who wants the Eaglefire to be craftable at a forge or workbench would add a blueprint entry to a crafting station's recipe table that lists the Eaglefire as an output, with the required input ingredients. Conversely, if the Eaglefire itself has its own Blueprints block, those recipes produce items using the Eaglefire as a crafting station -- which is unusual for a gun and more typical of crafting stations like forges, sawmills, or workbenches. The presence of the Blueprints flag on a weapon often indicates it has a repair recipe (input: the damaged Eaglefire plus materials, output: a repaired Eaglefire) or a dismantle recipe (input: the Eaglefire, output: scrap materials).
Hook flags
Hook_Barrel, Hook_Grip, Hook_Sight, and Hook_Tactical are attachment-socket flags. Each one tells the engine: "this weapon has a socket of this type, and the player can attach items that match it." The engine uses these flags to render the attachment slot in the inventory UI and to validate whether a dragged attachment is compatible. A modder who removes Hook_Grip from the flags list makes the grip slot disappear from the inventory UI entirely.
InputItems
InputItems is a flag related to item transfer. When this flag is present, the engine processes the InputItems block in the asset, which defines items that are consumed when the weapon performs a specific action (commonly, items consumed during a crafting operation).
RequiresNearbyCraftingTags
The RequiresNearbyCraftingTags flag means the weapon's crafting recipes require the player to be standing near a world object that carries a matching tag. Without this flag, recipes work anywhere. With this flag, the engine checks the player's proximity to tagged objects before allowing a recipe to execute.
Safety and Semi
Safety and Semi are fire-mode flags. Safety means the weapon defaults to a safe mode that prevents firing until the player switches modes. Semi means the weapon supports semi-automatic fire (one shot per trigger pull). The Eaglefire does not have the Auto flag; it is semi-automatic only according to its asset definition.
Bracket flags
The flags [, ], {, and } are structural delimiters. They are not functional flags in the traditional sense. They exist because the flags list in the .dat file uses bracket-delimited sections. When you see these in a raw asset file, they mark the boundaries of flag subgroups. A modder editing the flags in a text editor should preserve these delimiters exactly as they appear, or the asset parser may fail to read the file.
Notable absent flags
The Eaglefire does not have the Auto flag. This means the weapon cannot fire in automatic mode. It does not have the Burst flag for burst-fire capability. It does not have the Invulnerable flag, which would prevent durability loss. It does not have Durability or Wear flags in its flags list (those fields, if present, are in a separate block). A modder who wants a full-auto Eaglefire variant would add Auto to the flags list.
Beyond the absence of Auto, several other flags commonly found on Unturned weapons are absent from the Eaglefire's flag list and worth noting. The Barrel flag, found on heavy weapons like rocket launchers and LMGs, enables continuous barrel-spin animation and overheating mechanics; the Eaglefire does not have it, which is correct for a standard assault rifle. The Aim_Spread flag, found on weapons with dynamic spread that increases during sustained fire, is absent, meaning the Eaglefire's Spread_Aim of 0.05 is a fixed value that does not increase with consecutive shots. The Drop flag, which causes the weapon to drop as a physics object when unequipped rather than returning to the inventory, is absent. The Dual_Wield flag is absent, confirming the Eaglefire cannot be dual-wielded. A modder reviewing a flag list for completeness should compare the present flags against a comprehensive flag reference to understand not just what the weapon does, but what it explicitly does not do. These absences are not bugs or omissions; they are deliberate design choices that define the Eaglefire as a standard, single-wield, semi-automatic assault rifle with fixed spread and no special behaviours.
Flag storage and bitmask encoding
The flags block in a .dat asset is stored as an integer bitmask: a single numeric value where each bit position represents one boolean flag. The engine maintains an internal mapping from each named flag -- Semi, Auto, Safety, Blueprints, each Hook_ variant, and every other recognised flag name -- to a specific bit position. When a flag name appears in the asset's flags list, the engine sets the corresponding bit to 1; when the flag name is absent from the list, the bit remains 0. The human-readable flag list shown in the .dat file, with its bracket-enclosed groups, is a text-serialised representation of this bitmask. The engine parser reads the text file, matches each token against its flag-name registry, and assembles the final bitmask integer during the asset-loading phase. At runtime, the engine checks individual flags by performing a bitwise AND against the stored integer: it extracts the bit corresponding to the flag being queried and evaluates whether it is set. A modder writing a plugin that reads an item's flags programmatically can use the same bitwise-AND pattern against the asset's exposed flags property.
The bracket characters [, ], {, and } in the flags list are structural markers, not functional flags. They define logical groupings within the flags block: square brackets [...] typically enclose one category of related flags, and curly braces {...} enclose a subgroup nested within that category. These delimiters are not mapped to any bit in the bitmask; they exist only in the text file to make the flag list human-readable and to signal to the parser where one group ends and another begins. When a modder copies a flags block to create a new weapon variant, the bracket structure must be preserved verbatim. Removing a closing bracket or mismatching an opening and closing brace causes the asset parser to fail to read the entire flags block, which typically results in every flag being silently set to zero -- effectively disabling all flag-controlled behaviours for that weapon. The safest approach when editing flags in a text editor is to add or remove flag names without touching the bracket characters at all.
When a flag bit is set to 1, it triggers a specific behaviour path in the engine's item-handling code. When Semi is set, the fire-input handler sees that the semi-automatic bit is active and enters the single-shot-per-trigger-press logic, enforcing the Firerate tick cooldown between shots. When Hook_Barrel is set, the inventory UI rendering code checks the bit and draws a barrel-attachment slot in the weapon's detail panel; if the bit is 0, the slot is not rendered and the player cannot drag a barrel attachment onto the weapon at all, regardless of socket enum compatibility. When Blueprints is set, the crafting-station UI queries the asset for its Blueprints block and populates the recipe list accordingly. The GUID string "7b82c125a5a54984b8bb26576b59e977" embedded in the flags block is a special case: it is not a boolean entry in the bitmask, but rather a string value stored alongside the flags integer. The engine reads this GUID during the asset-loading phase and uses it to resolve a reference to a parent or master asset. A modder who removes the GUID from the flags block must also verify that no other part of the asset -- and no dependent asset -- relies on that parent reference for correct loading.
A plugin developer reading an item's flags at runtime accesses the flags bitmask through the ItemAsset object. The bitmask is typically exposed as an integer property, and the developer checks individual flags by performing a bitwise AND with a constant defined for each flag. For example, to check whether the weapon has the Auto flag, the plugin code would evaluate (asset.flags & FLAG_AUTO) != 0, where the constant FLAG_AUTO is the bit position assigned to that flag in the engine's internal mapping. The exact bit positions for each flag are not documented in the .dat file itself; they are defined in the engine's source code or in the modding SDK headers. A modder who needs to know which bit corresponds to which flag for a specific version of Unturned can cross-reference the Unturned modding SDK documentation or inspect the engine's decompiled flag-constant definitions. The flag-to-bit mapping is stable across minor game updates but can shift between major versions, so a plugin that relies on specific bit positions should be tested against each major game version it targets.
Where it spawns
The loot tables below are the spawn tables in which the Eaglefire appears. Each row is a table entry from a specific map. "Chance per roll" is the probability, on a single roll of that table, that the engine selects the Eaglefire entry. The engine rolls these tables many times during map generation, so the chance that the Eaglefire appears at least once in a given world is higher than any single-roll percentage.
WHERE IT SPAWNS (pre-rendered, use verbatim)
| Map | Spawn table | Chance per roll |
|---|---|---|
| Greece | Greece_Military_Guns_Low | 26.087% |
| Core | Guns_America_Guns | 25.000% |
| Core | Militia_Russia_Guns | 25.000% |
| Ireland | Cliffs_Military_Low_Guns | 22.222% |
| RioDeJaneiro | Brazil_Military_Low_Guns | 20.000% |
| Ireland | Cliffs_Military_High_Guns | 18.750% |
| Core | Arena_Guns_Military_Common | 16.667% |
| Core | Civilian_America_Guns | 16.667% |
| EasterIsland | Easter_Police_High_Guns | 16.667% |
| Core | Washington Arena_Arena_Guns_Military | 14.875% |
| Core | Arena_Guns_Military | 14.875% |
| Core | PEI Arena_Arena_Guns_Military | 14.875% |
| Core | Alpha Valley_Arena_Guns_Military | 14.875% |
| Ireland | Cliffs_Special_Low_Guns | 9.375% |
| France | Carepackage_France_Weapons | 7.194% |
| France | Carepackage_France | 5.036% |
| Core | Washington_Guns_America | 4.278% |
| Core | Guns_America | 4.278% |
| Ireland | Cliffs_Military_High_Cliffs | 2.885% |
| Ireland | Cliffs_Military_Low_Cliffs | 1.949% |
Showing 20 of 40 tables that can produce this weapon.
How spawn tables work as weighted lists
Every spawn table in Unturned is fundamentally a weighted list of entries. Each entry in the table carries two essential fields: an ID (the item ID of the asset to spawn) and a Weight (an integer value that controls how often this entry is selected relative to other entries). When the engine rolls a spawn table, it sums every weight in the table to produce a total weight, then generates a random integer between zero and that total. It iterates through the entries in order, subtracting each entry's weight from the running random value until the running value reaches zero or below. The entry at that point is the selected entry, and the engine spawns the corresponding item at the spawn node's world position. The "Chance per roll" percentages shown in the table above are derived values: they are computed by dividing each individual entry's weight by the sum of all weights in that table, then multiplying by 100.
Because every entry's probability depends on the sum of all weights, adding or removing an entry from a table changes the effective probability of every other entry in that table. If a server owner adds a new item with any non-zero weight, the total weight sum increases, and every existing entry's percentage chance decreases slightly -- even if the existing entries' individual weights were not changed. Conversely, removing an entry decreases the total sum, which increases the chance of every remaining entry. A modder who wants precise control over the Eaglefire's spawn rate across all tables must account for this weight-interaction effect: setting a specific weight value in one table does not produce a fixed percentage unless the modder also knows the weights of every other entry in that same table and recalculates the total.
The engine does not roll every spawn table exactly once during map generation. Spawn tables exist within a hierarchy: at the top level, each map defines spawn-region nodes at specific world-coordinate ranges. Each spawn-region node references a spawn table by its asset name. During world generation, the engine iterates over every spawn node in the region, and for each node, rolls the referenced table one time. This means that if a map has many loot-spawn nodes all referencing the same table -- Greece_Military_Guns_Low, for instance -- the engine rolls that table once per node. The total number of rolls is controlled by the map author's placement of spawn nodes in the map file, not by the spawn table itself. A server owner editing spawn tables cannot change how many times a table is rolled without modifying the map file's spawn-node layout.
A server owner edits spawn weights by opening the spawn table's .dat file, which lives in a map-specific Sources/Spawns/ directory, finding the entry whose ID field matches 4 (the Eaglefire's item ID), and changing the associated Weight value. Increasing the weight increases the entry's selection probability relative to other entries in that table; decreasing the weight decreases it. Deleting the entry entirely removes the Eaglefire from that table's pool. Alternatively, a server owner can use a plugin to override spawn weights at runtime. RocketMod provides a SpawnTableRebuild event that fires when spawn tables are loaded into memory, and a plugin subscribed to this event can programmatically read and adjust weights before the engine uses them for world generation. The runtime-override approach is useful because it does not modify the original .dat files, which means game-update file verification will not flag the changes as corruption and overwrite them.
When a spawn table includes a Min_Rarity or Max_Rarity constraint, the engine filters entries before the weight-based selection step. The engine iterates through every entry in the table, checks the entry's item's rarity tier against the table's rarity bounds, and removes any entry that falls outside the range. Only after this filtering step does the engine compute the weight total and perform the weighted random selection. This has an important consequence for the Eaglefire: if a table that normally includes the Eaglefire (Rare) has its Min_Rarity raised above Rare -- to Epic, for instance -- the Eaglefire entry is excluded before the weight total is computed. The percentages shown for the remaining entries then increase because the total weight sum is smaller. A modder auditing why the Eaglefire is missing from a map should check not only whether its entry exists in the spawn tables, but also whether any rarity filter on those tables is excluding the Rare tier.
A plugin-based spawn audit works by iterating through every loaded spawn table at runtime, checking for entries with ID 4, and logging the table name, the entry's weight, and any rarity constraints on the table. This provides a complete picture of the Eaglefire's spawn footprint faster than opening each .dat file manually. A plugin can also simulate spawn-table rolls -- running the weighted random selection repeatedly and counting how often ID 4 is selected -- to produce an empirical spawn-rate estimate for a given number of world generations. This simulation approach accounts for the rarity-filter interaction and the weight-sum dynamics described above, giving the server owner a data-driven basis for weight adjustments rather than relying on trial-and-error observation.
Reading the spawn-table data
Each row in the table above is a spawn-table asset entry. The "Map" column tells you which official or curated map owns the table. The "Spawn table" column gives the internal asset name of the spawn table. The "Chance per roll" column is the weight-based probability that a single roll of that table selects the Eaglefire.
A modder looking at this data can answer several practical questions. The highest single-roll chance is 26.087% in the Greece_Military_Guns_Low table on the Greece map. The lowest shown chance is 1.949% in Cliffs_Military_Low_Cliffs on Ireland. The Core map has the most tables that include the Eaglefire, spread across military, militia, arena, and civilian tables. This distribution pattern -- military tables at high percentages, arena tables at moderate percentages, and broad loot tables at low percentages -- is typical for a Rare-tier primary weapon in Unturned. It reflects the design intent: the Eaglefire is primarily a military-location weapon, secondarily an arena-mode weapon, and only incidentally available in civilian or broad-loot scenarios.
A server owner who wants to remove the Eaglefire from a specific map would delete the Eaglefire entry from each spawn table for that map. A server owner who wants the Eaglefire to be more common would increase the weight value in the spawn table (which recalculates the percentage for every entry in the table). A server owner who wants to disable world spawns entirely and make the Eaglefire airdrop-only would remove it from all tables except the airdrop tables.
The note "Showing 20 of 40 tables" means the extracted asset data excerpted 20 tables; the weapon appears in 40 distinct spawn tables across all maps. A modder doing an exhaustive spawn audit should check all 40 tables, not just the 20 shown. The full set includes tables not excerpted here, potentially including additional curated-map tables, event-specific tables, and tables from maps not covered in the excerpt. A thorough audit also verifies that each table's map is actually present in the server's map rotation; a table from a map the server never runs does not contribute to the weapon's observed spawn frequency.
Arena tables
Several entries reference arena tables: Arena_Guns_Military_Common, Washington Arena_Arena_Guns_Military, Arena_Guns_Military, PEI Arena_Arena_Guns_Military, and Alpha Valley_Arena_Guns_Military. Arena tables are rolled during arena-mode matches. Four of these tables share the same chance of 14.875%, which suggests they are structurally similar tables cloned per-arena map with identical weight distributions. The Arena_Guns_Military_Common table has a slightly higher chance of 16.667%.
Arena-mode spawns work differently from survival-mode spawns in several respects that affect how a modder interprets these numbers. In arena mode, the engine rolls spawn tables during the match-preparation phase, not during persistent world generation. The spawn tables are typically rolled fewer times per match than a survival-mode world generation because arena maps have fewer loot-spawn nodes arranged in a more controlled layout. Additionally, arena matches are shorter-lived than survival sessions, so the impact of a single Eaglefire spawn on the match's balance is higher than it would be in a survival world where a weapon can sit undiscovered for hours. A modder designing an arena-specific variant of the Eaglefire should consider that the weapon will be encountered in a short, high-intensity match format, which puts a premium on the weapon's handling characteristics (recoil, spread, and shake) more than its spawn frequency. A weapon that is hard to control may be balanced in survival where encounters are spaced out, but oppressive in arena where every fight is immediate and decisive.
Carepackage tables
The Eaglefire appears in two French carepackage tables: Carepackage_France_Weapons at 7.194% and Carepackage_France at 5.036%. Carepackages are airdrop-style loot containers that the engine spawns periodically; their tables typically contain higher-rarity items. The presence of the Eaglefire in carepackage tables means it can appear as airdrop loot on the France map.
Carepackage spawn mechanics differ from standard world-spawn mechanics in that the engine does not roll carepackage tables during map generation. Instead, the engine rolls the carepackage table each time a carepackage is spawned during a live gameplay session. The spawn interval and spawn location are controlled by the map's carepackage configuration, not by the spawn table itself. A server owner adjusting the Eaglefire's carepackage frequency has two levers: the weight in the carepackage table (which affects per-drop probability) and the map-level carepackage spawn interval (which affects how many drops occur overall). Reducing the weight in the carepackage table lowers the chance that any single drop contains the Eaglefire. Reducing the carepackage spawn interval means fewer drops occur total, which indirectly reduces the weapon's appearance rate. A modder who wants the Eaglefire to be exclusively a carepackage weapon would remove it from all standard world-spawn tables and keep it only in the carepackage tables, creating a high-rarity airdrop-only weapon that players must actively seek during a live session rather than finding passively in a looted building.
Cliff tables on Ireland
The Ireland map has four cliff-related tables: Cliffs_Military_Low_Guns, Cliffs_Military_High_Guns, Cliffs_Military_High_Cliffs, and Cliffs_Military_Low_Cliffs. The "Guns" suffix tables have substantially higher per-roll chances (22.222% and 18.750%) than the "Cliffs" suffix tables (2.885% and 1.949%). This is because the "Guns" tables are narrow tables containing only gun entries, while the "Cliffs" tables are broader tables that mix guns with other item types like clothing, food, and medical supplies. A modder who wants cliff loot to produce guns more reliably would adjust the weights in the narrow "Guns" tables rather than the broad "Cliffs" tables.
The Ireland map's cliff loot structure illustrates a broader design pattern present across many Unturned maps. Map authors commonly create multiple spawn tables for the same geographic area at different loot quality levels. The "Low" suffix tables (both Guns and Cliffs variants) are typically referenced by more numerous spawn nodes and produce more common items more frequently. The "High" suffix tables are referenced by fewer, more-elite spawn nodes and have a higher concentration of rare items. A modder auditing the Eaglefire's presence on Ireland should check not only which tables contain the entry, but which nodes reference each table, because a high-percentage table referenced by only a few nodes may produce fewer total Eaglefire spawns than a low-percentage table referenced by many nodes. This node-count multiplier effect applies to every map and every weapon; the "Chance per roll" column in the table tells only half the story. The other half is how many times the table is rolled during world generation, which depends on the map author's spawn-node layout.
Spawn distribution across map types
The Eaglefire's spawn-table footprint across all maps reveals a consistent rarity-based distribution strategy. On the Core map -- which serves as the baseline for vanilla spawn design -- the Eaglefire appears in military tables (Guns_America_Guns at 25.000%, Militia_Russia_Guns at 25.000%), arena tables (multiple at 14.875% and 16.667%), and even a civilian table (Civilian_America_Guns at 16.667%). The civilian table inclusion is notable for a Rare-tier military weapon and suggests the Core map's design intent is to make the Eaglefire broadly accessible across different loot zones, not restricted exclusively to military locations. On the Greece map, the weapon appears only in the Greece_Military_Guns_Low table at 26.087%, which is the single highest per-roll chance in the entire data set and suggests a design choice to concentrate the weapon in Greece's military loot locations rather than spread it across multiple table types. On Ireland, the Eaglefire appears across six distinct tables spanning three categories (Guns, Cliffs, and Special), indicating the most distributed approach of any map -- Ireland's designers chose to make the weapon available through multiple parallel loot channels, each at a different probability tier.
A modder studying these distribution patterns gains insight into how different map authors balance weapon rarity. The Core map's approach -- broad distribution across many table types at varying percentages -- makes the Eaglefire a weapon that players can expect to find eventually across multiple sessions. The Greece map's approach -- concentrated in a single high-percentage table -- makes the Eaglefire highly probable within military zones but entirely absent from other loot locations. The Ireland map's approach -- tiered distribution across six tables -- creates a graduated availability where the weapon is common in some specific contexts and rare in others. A modder designing a custom map's spawn layout for a new weapon should study these patterns and decide which distribution strategy matches the intended role of their weapon in the map's loot economy.
Canned Beans
The Eaglefire brief contains no bean data. There are no Bean, Canned_Beans, or Beans entries in the spawn tables listed for this weapon, nor is there a bean-related flag or field in the asset definition. This absence is unsurprising: the Eaglefire is a military-pattern assault rifle that spawns in military, arena, militia, and police loot tables. Canned beans are a civilian food item and do not share spawn-table space with Rare-tier primary weapons. If you are looking for bean lore on this map or across the game, see Canned Beans Lore.
How the three damage blocks coexist in the asset
A point worth understanding when reading the raw Eaglefire .dat file is that the player, zombie, and animal damage blocks are independent sections within the same asset. Each block has its own heading, its own base damage field, and its own set of multipliers. They are parsed separately by the engine and stored in separate fields on the ItemAsset object. This independence means a modder can tune the weapon for each target type without affecting the others. The Player_Damage field lives in one block with its four multipliers; the Zombie_Damage field lives in another block with its own four multipliers; and Animal_Damage lives in a third block with its three multipliers.
If a modder opens the raw .dat file, they will see these blocks laid out sequentially in the file, typically in the order: player damage block first, zombie damage block second, animal damage block last. Each block is a self-contained section within the file, delimited by the bracket and brace characters that structure the entire .dat format. The ordering matters to the parser but not to the engine's runtime behaviour: the engine loads all three blocks into memory regardless of their order in the file. If a modder deletes one of the damage blocks entirely (for example, removing the animal damage block), the engine fills the missing values with defaults -- typically zero for the base damage and 1.0 for all multipliers -- which effectively makes the weapon deal zero animal damage. This is a common accidental outcome when a modder copies only part of the damage blocks during a clone operation, forgetting to copy all three blocks from the source asset.
How the socket enum system connects attachments to weapons
Beyond the flag-based hook system, the attachment compatibility chain relies on the socket enum fields in the weapon's ballistics block. The Muzzle field (3) and the Magazine field (6) are the two socket enum values that gate which specific attachments fit. This is a two-tier compatibility system: the first tier is the hook flag (Hook_Barrel, Hook_Grip, Hook_Sight, Hook_Tactical), which determines whether the weapon has a slot of that type at all. The second tier is the socket enum, which determines which specific attachments within that slot type are compatible.
For the Muzzle field, a value of 3 corresponds to the Military barrel-attachment socket. The engine maintains a lookup: when a player drags a barrel attachment onto the weapon, it reads the attachment's socket enum field and compares it against the weapon's Muzzle value. If they match, the attachment is accepted. If they do not match, the attachment is rejected even though the barrel slot exists in the UI. The same logic applies to Magazine (6, Military magazine socket). The Hook_Grip, Hook_Sight, and Hook_Tactical flags do not have corresponding socket enum fields in the ballistics block because grip, sight, and tactical attachments are universally compatible across weapons that have the relevant hook flag. A weapon with Hook_Sight accepts any sight attachment regardless of its socket enum, because the engine does not validate a socket enum for sights. Only barrel and magazine attachments are gated by both the hook flag and the socket enum.
This dual-gate system means that a modder creating a variant Eaglefire that uses a different barrel type must change two things: the Muzzle field in the ballistics block (to change the socket enum value) and potentially the Hook_Barrel flag (if the variant should not have a barrel slot at all). Changing only the socket enum while leaving Hook_Barrel present means the barrel slot still appears in the UI but only accepts attachments with the new socket enum. Removing Hook_Barrel means the barrel slot disappears entirely, regardless of the Muzzle field's value. A modder debugging barrel-attachment compatibility should trace both paths: check the hook flag first, then check the socket enum.
Practical use for server owners and modders
Cloning the Eaglefire for a custom variant
To create a custom Eaglefire variant, a modder would:
Copy the
Eaglefire.datasset file to a new file with a unique asset name. In the Unturned editor, navigate to theEaglefireitem in the Items directory, right-click, and select "Duplicate." This creates a copy in the same source directory. Rename the file to the variant's new asset name -- for example,Eaglefire_Custom.dat. The filename must end in.datand must not contain spaces; use underscores or PascalCase. The file must remain in a directory registered in the engine's asset-source list. If the variant is part of a workshop mod, the file goes in the mod'sSources/Items/directory within the mod's workshop folder structure.Generate a new GUID. The GUID must be a 32-character hexadecimal string with no dashes or braces. You can generate one using any GUID generator tool, or use
uuidgenin a terminal and strip the dashes from the output. The generated GUID must not collide with any existing asset GUID in the vanilla game or in any loaded mod. There is no built-in collision checker in the editor, so generate a value that is as random as possible. In the duplicated.datfile, find theGUIDfield near the top of the file and replace the original GUID with the newly generated one. If two loaded assets share the same GUID, the engine logs an error and only one of the two assets functions correctly.Assign a new item ID that does not conflict with vanilla IDs or other modded IDs. Workshop mods should use an ID range that does not overlap with vanilla items or with other installed mods. In the duplicated
.datfile, find theIDfield and replace4with the new integer. After changing the ID, check every block in the file that references item IDs: theBlueprintsblock (if present and containing recipes that consume or produce items by ID) and any spawn table entries the variant is intended to populate. A single mismatched ID reference causes the engine to fail to locate the asset when attempting to spawn, craft, or resolve the item by ID.Edit the fields described in this reference. Open the
.datfile in a text editor and locate the ballistics block, the three damage blocks, and the handling block. To make the variant hit harder, raisePlayer_Damageabove40. To make it fire faster, lowerFireratefrom4. To give it longer effective range, raiseRangeabove200. To adjust recoil, modify the fourRecoil_fields. Save the file after each batch of edits. The Unturned editor's "Reload Assets" button -- or a full game restart -- is required for the engine to parse the changed file. Test the variant immediately by spawning it in-game: open the editor's item-spawn panel, search for the new asset name, click "Spawn," and equip the item to verify that the changed fields produce the intended behaviour.Add or remove flags depending on the variant's intended behaviour. In the flags block of the
.datfile, locate the list of flags enclosed in brackets and braces. To make a full-auto variant, typeAutointo the flag list, typically placed near the existingSemiandSafetyentries. To remove an attachment slot, delete the correspondingHook_flag from the list. After editing flags, reload the asset in the editor. Test the flag changes by equipping the weapon in-game and verifying that attachment slots appear or disappear in the inventory UI as expected, and that the firing-mode switch cycles through the correct modes for the flags present.Add the new asset to a spawn table if you want it to appear in the world. Open the spawn table
.datfile for the target table, add a new entry block containing the variant's new itemIDand aWeightvalue, and save the file. The weight determines how often the variant appears relative to the other entries in that table. Reload the map and generate a new world to confirm the variant spawns at the expected frequency. If the variant should not spawn naturally and should instead be distributed as a kit item, skip the spawn-table step and use a plugin or the server's kit system to give the item to players on join or via a command. Distributing as a kit during testing avoids affecting the existing loot economy until the variant's balance is confirmed.
Complete testing workflow for a custom variant
After completing all six steps above, the modder should run through a structured testing checklist before distributing the variant. First, spawn the weapon in a single-player test world using the editor's item-spawn panel. Verify that the weapon appears with the correct name, description, rarity colour (Rare, light blue), and inventory icon. Equip the weapon and confirm that the attachment slots (barrel, grip, sight, tactical) appear in the inventory UI and that the correct socket types display. Second, test the firing behaviour: fire a single shot and verify the recoil feels appropriate. Fire in Semi mode and confirm that only one shot is registered per trigger pull. If the Auto flag was added, verify that holding the trigger produces continuous fire at the expected Firerate cadence. Third, test damage output: spawn a test target (a friend on a local server, or a spawned entity in single-player), fire one shot at each hit zone, and verify the damage numbers match the intended values from the edited fields. Fourth, test reload behaviour: empty the magazine, reload from inventory, and confirm the correct ammunition type is consumed and the magazine fills to the expected capacity. Fifth, if the variant was added to spawn tables, generate a new world and search loot locations where the spawn table is active, verifying that the variant appears at a rate consistent with its assigned weight. Only after all five checks pass should the variant be considered ready for broader distribution.
Server-side damage tuning
A server owner who runs a RocketMod or OpenMod plugin can read and modify the Eaglefire's damage values at runtime, without requiring every player to install a client-side mod. The plugin subscribes to the damage-event hook: in RocketMod, this is typically DamageTool.damagePlayerRequested or the higher-level OnPlayerDamaged event; in OpenMod, the pattern uses the IUserDamagedEvent or equivalent abstraction. When the damage event fires, the plugin checks whether the weapon that dealt the damage carries the GUID b03d581a5c1a490f995f8deba57b0f17. If the GUID matches, the plugin can read the event's damage property and multiply it by a server-configured scalar before the engine processes it. For example, a plugin that reduces Eaglefire damage would apply a scalar below 1.0, making the weapon less lethal across all hit zones uniformly. The plugin can also override specific multiplier fields: reading the hit-zone information from the damage event (skull, spine, arm, leg) and applying a per-zone override gives finer control but requires more code. The same event-driven pattern extends to other weapon parameters: a plugin can intercept the projectile-spawn event to modify Range or Firerate dynamically, or hook into the recoil system to adjust the Recoil_ fields on a per-weapon basis. These runtime overrides are ephemeral -- they reset when the server restarts, because they do not modify the .dat file on disk. A plugin typically reads its balance configuration from a separate JSON or XML config file, which the server owner edits to set the desired override values, and the plugin applies those values each time the server starts and the assets are loaded.
Spawn table auditing
If a server owner notices the Eaglefire appearing too frequently or not appearing at all, the first step is to determine which maps the server is running. If the server cycles through multiple maps, every relevant map must be audited separately. The server owner opens each spawn table .dat file for the maps in question -- these are in the map-specific Sources/Spawns/ directory -- and locates the entry with ID 4. If the entry is present, the Weight field is the number to adjust. If the entry is absent from a table, the Eaglefire cannot spawn from that table at all. A server owner might discover that the Eaglefire is unexpectedly absent because a previously installed mod overwrote the spawn table file, removing the entry. To restore it, the entry must be re-added manually with the correct ID and Weight, or the original spawn table file must be restored from a backup or from the game's file-integrity verification tool.
The percentage shown in the "Chance per roll" column is computed from the entry's weight divided by the sum of all weights in the table. To increase the Eaglefire's frequency, increase its weight in the target table. To decrease it, lower the weight. To remove it, delete the entry entirely. Because spawn tables are rolled independently per spawn node -- once for every loot spawn node that references the table -- reducing the weight in a frequently-rolled table has a larger impact on the weapon's actual world frequency than reducing the weight in a rarely-rolled table. A methodical auditor works table by table, adjusts weights incrementally, and tests the results by generating a fresh map and observing Eaglefire occurrence counts across multiple world generations before declaring the balance change complete.
Attachment compatibility
The Hook_Barrel, Hook_Grip, Hook_Sight, and Hook_Tactical flags mean the Eaglefire accepts attachments in these four categories. The specific attachments that fit depend on the socket enum values: Muzzle of 3 means the barrel socket accepts Military-type barrel attachments such as the Military Suppressor and the Military Muzzle Brake, and Magazine of 6 means the magazine socket accepts Military-type magazine attachments such as the Military Magazine and the Military Drum. A modder creating a new attachment that should be compatible with the Eaglefire must set that attachment's Caliber or socket enum to match the Eaglefire's corresponding enum value. For a new barrel attachment, the attachment's socket enum must be 3 or the attachment must declare 3 as one of its compatible socket types. For a new magazine, the attachment's socket enum must be 6. The attachment asset must also carry the correct hook flag: a barrel attachment needs Hook_Barrel, a grip needs Hook_Grip, and so on.
When the player drags an attachment onto the Eaglefire in the inventory UI, the engine performs a two-part compatibility check. First, it verifies that the weapon has the matching hook flag (Hook_Barrel, for example). If the weapon lacks the hook flag, the attachment slot does not even appear in the UI and the drag operation is rejected before the socket check executes. Second, the engine verifies that the attachment's socket enum matches the weapon's corresponding enum field. If the socket enums do not match, the attachment slot is drawn (because the hook flag is present) but the dragged attachment is rejected and the player sees the slot highlight in red. A modder debugging an attachment that refuses to attach should check both conditions in order: verify the hook flag exists in the weapon's flags list, then verify the socket enum values match between the weapon and the attachment. If both checks pass and the attachment still fails to attach, the issue is likely in the attachment asset itself -- a missing hook flag, a mismatched socket enum, or a parsing error in the attachment's .dat file.
Common pitfalls and debugging techniques
When a modder edits an Eaglefire .dat file and the changes do not appear in-game, the most frequent cause is a cached asset. The Unturned engine loads .dat files once at startup and does not watch them for changes on disk. A simple save of the .dat file is not enough; the modder must either click "Reload Assets" in the Unturned editor (which re-parses every loaded asset) or restart the entire game. A server owner making balance changes must restart the server for .dat file edits to take effect, unless the changes are applied through a plugin that reads its own config file and overrides values at runtime.
A common mistake when cloning the Eaglefire is forgetting to update the item ID in all referenced locations. The .dat file contains an ID field at the top, but if the Blueprints block exists and references item IDs in recipe inputs or outputs, those references must be updated to the new ID as well. Similarly, if the variant is added to spawn tables, the spawn table entry must use the new ID, not the original 4. A mismatch causes the engine to log a warning on startup and silently fail to spawn or craft the item. A methodical check of every numeric field that references an item ID, followed by a test spawn in a clean world, catches this error before the variant reaches players.
Another frequent issue is flag-list corruption. If a modder deletes or misplaces a bracket character ([, ], {, }) while editing the flags block in a text editor, the asset parser may fail to read the entire flags section. The symptom is that every flag on the weapon silently becomes disabled: attachment slots disappear from the UI, fire modes stop working, and crafting recipes fail to register. The fix is to restore the original bracket structure exactly. Keeping a backup of the original .dat file before editing the flags block is the simplest precaution against this class of error.
When testing damage values, a modder should spawn a fresh Eaglefire and test against a known target in a controlled environment rather than relying on the damage numbers displayed in the editor. The editor's item preview panel shows the base damage values from the asset, but it does not account for hit-zone multipliers, armour reduction, or skill modifiers. The best testing workflow is: edit the .dat file, reload assets, spawn the weapon in a test map with a friend or a bot, and verify the actual damage-per-hit by observing the target's health change. For zombie damage testing, a single-player world with spawned zombies and the debug HUD enabled provides the fastest iteration loop. For player damage testing, a local server with a second client connected via LAN or localhost provides the most accurate reproduction of the multiplayer damage pipeline.
When a modder publishes an Eaglefire variant as a workshop mod, the .dat file must be placed in the correct workshop folder structure. The mod's root folder contains a Sources/Items/ directory, and the .dat file lives inside that directory alongside any other asset files the mod depends on (models, textures, and sound files go in separate directories within the mod's structure). The mod's Item folder name within the editor must match the mod's display name. A mismatch between the folder name in the editor and the actual file path in the workshop upload causes the mod to load incorrectly on subscribed clients. Before uploading, the modder should test the mod by subscribing to it on a test Steam account and verifying that the weapon appears in the spawn menu with all intended stats and flags intact.
A final practical consideration for any modder working with .dat files: keep a versioned backup of the original asset before making changes. A simple copy of the Eaglefire.dat file into a backup folder, named with a date or version number, allows the modder to revert changes instantly if an edit breaks the asset. This applies equally to spawning a custom variant (backup the original before cloning) and to editing spawn tables (backup each table's .dat file before adjusting weights). The Unturned editor's "Reload Assets" function will reload every asset in memory, including the now-broken one, and if the broken asset causes a parsing error, the editor may refuse to open the asset for repair. In that situation, restoring from the backup and restarting the editor is faster than trying to reconstruct the original field values from memory. The backup also serves as a diff reference: if a change causes unexpected behaviour, the modder can compare the original and modified files side by side to identify which field was accidentally altered. This is particularly useful when editing the flags block, where a single misplaced bracket character can cascade into multiple silent failures.
Key references for further work
This article is the field-level reference for the Eaglefire asset. For broader topics that build on the data presented here, consult these related resources. For general .dat file structure and block formatting rules, see the Unturned asset format documentation. For the complete list of Caliber enum values and their associated ammunition types, see the ammunition reference. For the full flag registry with bit-position mappings, see the flag constants reference in the Unturned modding SDK. For spawn-table design principles and node-placement tutorials, see the map-making guide. For RocketMod and OpenMod plugin development with item assets, see the respective framework documentation. Every field, value, and table in this article is directly usable in those broader contexts.
The data in this article is derived from the vanilla Unturned asset files and verified against the in-game behaviour. Field values are accurate as of the current game version. If a game update changes the Eaglefire's stats, flags, or spawn tables, a regenerated version of this article will reflect those changes. For the most current data, always reference the latest version of this page in conjunction with the live asset files in your Unturned installation.