Birch Rifle Reference (Unturned Gun Data)

Beginner20-30 minutesCross-platformtext editorUnity ExplorerUAssetGUI

Search terms: Birch Rifle stats, Rifle_Birch data, Unturned item 479, Birch Rifle damage, Birch Rifle flags.

The Birch Rifle is a bolt-action rifle chambered in Rifle ammunition. Its asset name is Rifle_Birch, it carries item ID 479, and its GUID is cdc4535e76db4da895649be269cdacbe. The game classifies it as Common rarity and it occupies the Primary slot. The in-game description reads: Birch rifle chambered in Rifle ammunition. This article is a data reference: it lays out every field the game files define for this weapon, explains what each field controls, and describes how a modder reads and edits those values. It is not a play guide.

Core asset fields

Every Unturned gun asset is a collection of key-value pairs stored inside the game's data files. Modders access these fields through tools like Unity Explorer (for reading live asset bundles) or UAssetGUI and custom editors (for writing into mod asset bundles). The fields below are the ones the Rifle_Birch asset declares. Fields not listed here are either absent from this asset or use engine defaults that the asset does not override.

When a modder opens the Birch Rifle asset in Unity Explorer, they see a property grid with named fields and typed values. The field names on the left are the keys the game engine reads at runtime. The values on the right are the data the game applies. The modder's job is to understand what each field name means to the engine and what each value produces in gameplay. This article provides that understanding by walking through every field, explaining its role in the game's weapon system, and showing what happens when the value changes.

Identity fields

The identity fields tell the game what this item is, how it sorts into the inventory, and how other systems reference it. These fields are the first thing a modder checks when cloning or modifying an asset, because getting them wrong causes collision and confusion.

• Asset name Rifle_Birch -- the internal name used in the asset bundle. Other assets reference this name when they need the Birch Rifle (for example, a crafting recipe's InputItems list or a loot table entry). The asset name is a plain string with no naming convention enforced by the engine, but community convention uses Category_Subtype formatting (Rifle_Birch, Pistol_Colt, Melee_Knife). If a modder creates a custom weapon and names it Rifle_Birch, the game will load both the vanilla asset and the mod asset as separate objects, but any system that references the asset by name may pick up the wrong one. Always assign a unique asset name to a custom weapon.
• Item ID 479 -- the numeric identifier used in commands, save files, and network messages. Server owners use this ID with the /give command and it appears in player inventory data. Item IDs must be unique within a loaded item set. The game serialises inventory contents as arrays of item IDs, so changing an item's ID changes how it is stored in save files. If a modder assigns item ID 479 to a custom weapon, that weapon will conflict with the vanilla Birch Rifle in any context that references items by numeric ID. Modders should choose item IDs that avoid the vanilla Unturned range and that avoid other installed mods' ranges.
• GUID cdc4535e76db4da895649be269cdacbe -- a 128-bit unique identifier that distinguishes the Birch Rifle from every other asset in the game. GUIDs persist across sessions and are the preferred way to reference an asset in mod code because they do not shift if item IDs are renumbered. The GUID is a 32-character lowercase hexadecimal string generated at asset creation time. Modders should never reuse a vanilla GUID, because the game treats identical GUIDs as the same asset. A GUID collision between a mod and vanilla content will cause the mod's version to silently override the vanilla version, or vice versa, depending on load order. Use a GUID generator to create a new 128-bit GUID for every custom asset.
• Rarity Common -- controls the colour of the item's name in the inventory UI and influences some loot-scoring systems. Common items display with a white name and are the baseline rarity tier. The rarity value is a string enum with defined values (Common, Uncommon, Rare, Epic, Legendary, Mythical). Each tier corresponds to a colour in the UI. Modders can change the rarity of an existing weapon by editing this string, but changing rarity does not change any numeric stat -- it only affects the item's display colour and its behaviour in rarity-aware loot systems.
• Slot Primary -- the equipment slot the weapon occupies when held. A Primary weapon occupies the character's main longarm slot and cannot be equipped simultaneously with another Primary weapon. The slot value is a string enum (Primary, Secondary, Tertiary, etc.). If a modder changes Slot from Primary to Secondary, the weapon becomes a sidearm and its equip animation, holster location, and hotkey mapping change accordingly.

Ballistics

The ballistics fields define how the weapon fires, what it fires, and the physical behaviour of the projectile. These fields are the core of any weapon asset: every shot the weapon fires is governed by the values in this table.

Field	Value
Range	175
Firerate	50
Action	Bolt
Caliber	17
Muzzle	4
Magazine	478
Ammo_Min	1
Ammo_Max	4

Each of these fields controls one aspect of the weapon's firing behaviour. A modder who understands each field can create any firing behaviour the engine supports.

Range (175) is the maximum distance in metres that the engine's hitscan raycast travels. A value of 175 means the projectile checks for a hit up to 175 metres from the muzzle. Beyond that distance the shot registers no hit -- the raycast terminates with no collision, consuming the ammunition with no effect. When a modder increases this value, the weapon can engage targets at longer distances. When a modder decreases it, the weapon becomes a shorter-range tool. The range value interacts with map design: a weapon with Range 175 is effective at most outdoor engagement distances but will not reach from one side of a large map to the other. A modder building a sniper rifle might set Range to 300 or higher; a modder building a close-quarters weapon might set Range to 50 or below.

Firerate (50) is the engine tick interval between shots. Unturned's firing system uses an internal counter measured in engine ticks. A Firerate of 50 means the weapon delays 50 ticks between successive shots. Lower values produce a shorter delay. Higher values produce a longer delay. Modders should read this field as a raw tick count and tune it by testing in-game rather than converting it to a real-time measurement. The Firerate field interacts with the Action field: for a Bolt action weapon, the bolt-cycling animation plays during this delay, and the weapon cannot fire again until both the Firerate delay expires and the bolt animation completes. If a modder sets Firerate very low on a Bolt-action weapon, the bolt animation may outlast the Firerate delay.

Action (Bolt) selects the firing animation sequence and the mechanical behaviour between shots. The Bolt action type plays a bolt-cycling animation after each shot and blocks firing during that animation. Alternative action types like Trigger or Safety behave differently. The Action field is a string lookup into the game's animation system; modders who set it to a value not defined in the engine receive a fallback animation or no visible cycling behaviour. The Action string must match exactly one of the values the engine recognises. Recognised values include Bolt, Trigger, Pump, Break, Rocket, and String. Each action type has its own animation set and its own mechanical rules. A modder who wants a bolt-action rifle should use Bolt. A modder who wants a semi-automatic rifle with no cycling animation should use Trigger.

Caliber (17) is an integer key that maps to an ammunition type. The game uses caliber IDs to match a weapon to the ammunition items it can accept. Caliber 17 corresponds to Rifle ammunition. If a modder changes this value, the weapon will accept a different ammunition type and no longer recognise Rifle magazines. The caliber system works by matching integers: a weapon with Caliber 17 will only accept magazine items that also declare Caliber 17. The caliber ID is an arbitrary integer with no hardcoded mapping -- the mapping between integer and ammunition type is defined by conventions in the asset data, not by engine code.

Muzzle (4) is an integer key that maps to a muzzle effect definition. The muzzle effect controls the visual flash, the sound clip, and the particle system that plays when the weapon fires. Muzzle 4 is a specific effect preset defined elsewhere in the game's asset bundle. Changing this value to another integer selects a different muzzle preset. Common muzzle IDs include low numbers (1 through roughly 10) for standard presets, with higher numbers potentially reserved for mod-added effects depending on the server's loaded assets. If a modder sets Muzzle to an ID that has no corresponding effect asset, the weapon fires silently with no muzzle flash.

Magazine (478) is the item ID of the magazine attachment the weapon is pre-configured to accept. The Birch Rifle's Magazine value of 478 points to the Rifle Magazine item. When a player picks up a Birch Rifle, the game checks this field to determine what magazine type it takes and validates reloads against it. A modder changing this value would make the weapon accept a different magazine type. The Magazine field works together with the Caliber field: the magazine item must have a compatible Caliber value, or the ammunition type in the magazine will not load into the weapon. Changing Magazine to an invalid item ID results in the weapon having no valid magazine, which means the weapon cannot reload and can only fire the rounds already chambered.

Ammo_Min (1) is the minimum ammunition count the weapon can hold. A value of 1 means the weapon can be loaded with as few as one round. This value interacts with the magazine system: when a player reloads, the game checks Ammo_Min to determine the smallest valid loaded state. With Ammo_Min set to 1, the Birch Rifle will accept a reload that brings it to any count between 1 and Ammo_Max. If Ammo_Min were set to 2, the weapon would reject a reload that brings it to 1 round. Most Unturned weapons set Ammo_Min to 1.

Ammo_Max (4) is the maximum ammunition capacity. A value of 4 means a full magazine holds four rounds. When a player reloads with a fully loaded magazine item, the weapon receives four rounds. This is the ceiling: no reload puts more than Ammo_Max rounds into the weapon. Ammo_Max must be greater than or equal to Ammo_Min; if Ammo_Max is less than Ammo_Min, the game's validation may reject the asset or produce undefined reload behaviour. Modders should always ensure Ammo_Max >= Ammo_Min.

Player damage

The player damage table defines how much damage the weapon deals to another player character and how that damage is modified by the hit zone. This table is the first of three damage layers the Birch Rifle carries.

Field	Value
Player_Damage	80
Player_Leg_Multiplier	0.6
Player_Arm_Multiplier	0.6
Player_Spine_Multiplier	0.8
Player_Skull_Multiplier	1.1

Player_Damage (80) is the base damage value applied on a hit. The engine takes this number and multiplies it by the relevant body-part multiplier before applying any further damage modifiers such as armour reduction or skill effects. The base damage value is a floating-point number, not an integer, so modders can set values like 80.5 or 79.25 for fine-grained tuning. The game's damage pipeline handles fractional values correctly, though some UI displays may round.

Player_Leg_Multiplier (0.6) scales the base damage when the projectile hits the leg hitbox. With a base damage of 80, a leg shot deals a final value of 80 * 0.6 = 48 before further modifiers. The multiplier is applied after the hit is confirmed and after the game determines which hitbox was struck.

Player_Arm_Multiplier (0.6) scales the base damage when the projectile hits the arm hitbox. The arm multiplier on this weapon is the same as the leg multiplier: both reduce damage to 60% of base. The game distinguishes arm and leg hitboxes as separate collision volumes on the player model, but the Birch Rifle treats them identically in damage terms. A modder could set different values for arm and leg (e.g. Arm 0.7, Leg 0.5) to create asymmetrical limb damage.

Player_Spine_Multiplier (0.8) scales the base damage when the projectile hits the spine or torso hitbox. At 0.8, a body shot deals 80% of base damage, which is higher than a limb shot and lower than a head shot. The spine hitbox is the largest hit zone on the player model, so this multiplier applies to the most common hit location. A modder who sets Spine to 1.0 would make body shots deal full base damage (no reduction). A modder who sets Spine lower (e.g. 0.6) would encourage head shots as the only way to deal full damage.

Player_Skull_Multiplier (1.1) scales the base damage when the projectile hits the skull or head hitbox. A value above 1.0 means a head shot deals more than base damage. At 1.1, a head shot multiplies base damage by 1.1, producing a final value of 80 * 1.1 = 88 before further modifiers. The head multiplier above 1.0 is a common Unturned design convention: it rewards accuracy with bonus damage rather than simply removing a penalty. A modder who wants to make head shots even more decisive can increase this value (e.g. to 1.5 or 2.0). A modder who wants to eliminate the head shot bonus can set it to 1.0.

Player damage per hit zone (computed, use verbatim)

Hit zone	Multiplier	Damage (base 80)
Skull	1.1	88
Spine	0.8	64
Arm	0.6	48
Leg	0.6	48

The computed table presents the damage value after the multiplier is applied to the base damage of 80, before armour reduction, skill modifiers, or any other post-hit calculation. A modder reading this table sees the raw per-zone output the game uses as input to its damage pipeline.

The four damage values (88, 64, 48, 48) form a three-tier gradient: the skull hit deals the highest value, the spine hit deals an intermediate value, and the limb hits (arm and leg) deal the lowest value, which is identical for both limbs because they share the same multiplier. This three-tier gradient is the standard damage profile for most Unturned firearms.

To change the damage profile, a modder edits Player_Damage to shift the entire profile up or down, or edits individual multipliers to adjust the relative importance of hitting specific zones. For example, setting Player_Skull_Multiplier to 1.5 would make head shots 1.5 times base damage, and setting Player_Leg_Multiplier to 0.8 would make leg shots more punishing. A modder who changes Player_Damage from 80 to 100 would see the computed values shift to 110 (skull), 80 (spine), and 60 (arms/legs). A modder who changes only Player_Skull_Multiplier from 1.1 to 1.2 would see only the skull value change, from 88 to 96, while the spine, arm, and leg values remain at 64, 48, and 48 respectively.

Zombie damage

The zombie damage table is a separate damage layer. The game does not share damage values between player targets and zombie targets. The Birch Rifle has its own base damage and its own multiplier set for zombie hit zones. This design allows a weapon to be powerful against one entity type and weak against another without the modder having to compromise. When the game detects that a hit has landed on a zombie entity, it switches to the zombie damage table for all subsequent calculations on that hit.

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 (99) is the base damage applied to zombie entities on a hit. This value is independent of Player_Damage: the game does not derive one from the other, and a modder can set them to completely different numbers. The zombie base of 99 is higher than the player base of 80, which means the Birch Rifle deals more raw damage to zombies than to players before multipliers are applied. This asymmetry is defined in the asset data, not in engine code -- a modder who wants the opposite (higher player damage, lower zombie damage) simply swaps the values.

Zombie_Leg_Multiplier (0.3) and Zombie_Arm_Multiplier (0.3) reduce limb hits against zombies to 30% of the zombie base damage. These are lower than the player limb multipliers (0.6), which means limb hits against zombies produce a smaller fraction of the base damage than limb hits against players. The difference between 0.6 and 0.3 is a factor of two: a limb hit against a zombie deals half the fraction of base damage that a limb hit against a player deals. This design encourages players to aim for zombie heads and torso.

Zombie_Spine_Multiplier (0.6) applies 60% of the zombie base damage to body shots. Because the zombie limb multipliers are lower (0.3 versus 0.6), the gap between a zombie body shot and a zombie limb shot is larger than the equivalent gap for players. A zombie body shot does twice the damage of a zombie limb shot (0.6 / 0.3 = 2x), whereas a player body shot does only 1.33x the damage of a player limb shot (0.8 / 0.6 = 1.33x).

Zombie_Skull_Multiplier (1.1) multiplies the zombie base damage by 1.1 on head shots. The multiplier value matches the player skull multiplier, but it is applied to a different base (99 for zombies versus 80 for players). This means a zombie head shot produces a higher absolute damage value (108.9) than a player head shot (88), not because the head multiplier is different but because the base damage is different.

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

The computed zombie damage table shows the per-zone damage with the zombie base of 99 applied. The structure mirrors the player damage table: the skull multiplier is highest, the spine multiplier is intermediate, and the limb multipliers are lowest. However, the spread between the highest and lowest values is larger for zombies (108.9 to 29.7, a range of 79.2) than for players (88 to 48, a range of 40). This wider spread reflects the lower limb multipliers in the zombie damage layer.

Modders who want zombies to be more resilient can lower Zombie_Damage from 99 to a smaller number, or reduce individual zone multipliers. Modders who want this weapon to be a dedicated anti-zombie tool can raise the zombie damage values independently of the player damage values, since the two are separate data layers. A common modding pattern is to give a weapon a high Zombie_Damage and a lower Player_Damage to make it a PvE-focused weapon, or the reverse for a PvP-focused weapon.

Animal damage

The animal damage table is a third independent damage layer. It controls damage against animal entities (deer, wolves, bears, and any other creatures tagged as animals in the entity system). When the game detects that a hit has landed on an animal entity, it switches to the animal damage table.

Field	Value
Animal_Damage	99
Animal_Leg_Multiplier	0.6
Animal_Spine_Multiplier	0.8
Animal_Skull_Multiplier	1.1

Animal_Damage (99) is the base damage applied to animal entities. This value matches the zombie base damage but is controlled by a separate field. A modder can edit it independently without affecting zombie or player damage. The Birch Rifle's animal damage of 99 is identical to its zombie damage of 99, but this is a coincidental equality, not a rule. A modder can set Animal_Damage to 50, Zombie_Damage to 99, and Player_Damage to 80 in the same weapon asset, and the game will apply the correct value based on the entity type hit.

Animal_Leg_Multiplier (0.6), Animal_Spine_Multiplier (0.8), and Animal_Skull_Multiplier (1.1) create a damage gradient across animal hit zones. Notice that the animal damage table has no Animal_Arm_Multiplier: animal entities lack a distinct arm hitbox in the game's hit detection system, so the field is absent. The three multipliers that do exist (0.6, 0.8, 1.1) are the same values as the player multipliers, which means the Birch Rifle treats animal hit zones the same way it treats player hit zones in terms of the multiplier ratio. However, because the base damage differs (99 for animals versus 80 for players), the absolute damage values differ.

Animal damage per hit zone (computed, use verbatim)

Hit zone	Multiplier	Damage (base 99)
Skull	1.1	108.9
Spine	0.8	79.2
Leg	0.6	59.4

The computed animal damage table shows three zones: skull at 108.9, spine at 79.2, and leg at 59.4. The absence of an arm row is not an error -- the game's damage pipeline does not evaluate an arm hitbox on animal entities, so there is no multiplier to apply and no computed value to show. A modder reading this table should understand that the three rows represent the three hit zones the game actually checks when a projectile hits an animal.

Handling

The handling fields define how the weapon moves the camera when fired. They control recoil, spread, and screen shake. These fields determine how the weapon feels rather than how it performs in damage terms, but feel is a critical part of weapon design. A weapon that snaps too hard on each shot is frustrating to use; a weapon with no recoil feels weightless.

Field	Value
Recoil_Min_X	5
Recoil_Min_Y	15
Recoil_Max_X	10
Recoil_Max_Y	20
Spread_Aim	0.01
Shake_Min_X	-0.005
Shake_Max_X	0.005

Recoil_Min_X (5) and Recoil_Max_X (10) define the horizontal recoil range. On each shot, the game picks a random value between Recoil_Min_X and Recoil_Max_X and applies it as a horizontal camera offset. A value of 5 to 10 means the horizontal kick ranges from 5 units to 10 units. The direction (left or right) is also randomised. If a modder sets both values to 0, the weapon has no horizontal recoil. If a modder sets both values to the same number, the horizontal recoil is deterministic rather than randomised. If a modder sets Recoil_Min_X higher than Recoil_Max_X, the game's random range function may behave unexpectedly -- always ensure Min is less than or equal to Max.

Recoil_Min_Y (15) and Recoil_Max_Y (20) define the vertical recoil range. Vertical recoil is always upward, so the engine applies the random value between 15 and 20 as an upward camera displacement. These values are larger than the horizontal values, which means the Birch Rifle's recoil is predominantly vertical. A weapon with vertical recoil of 15 to 20 and horizontal recoil of 5 to 10 will climb upward on each shot while also drifting slightly left or right. Players can compensate for vertical recoil by pulling down, but the horizontal component adds unpredictable drift.

Spread_Aim (0.01) is the aiming spread cone radius in degrees. When the player aims down sights, the projectile can deviate from the crosshair centre by up to Spread_Aim degrees. A value of 0.01 means the spread is very tight -- the shot lands extremely close to the aim point. At 175 metres (the Birch Rifle's Range), a 0.01-degree spread cone produces a very small deviation circle at the target. If a modder increases this value, the weapon becomes less precise when aimed. Spread_Aim applies only when the player is aiming; hip-fire spread is controlled by a separate field that the Birch Rifle does not override, so the engine default applies.

Shake_Min_X (-0.005) and Shake_Max_X (0.005) define the horizontal screen shake range. On each shot the game applies a random shake value between Shake_Min_X and Shake_Max_X to the camera's horizontal position. The negative minimum and positive maximum mean the shake oscillates left and right. The small magnitudes (-0.005 to 0.005) produce a subtle shake. Screen shake is purely visual -- it does not affect where the projectile lands -- but it contributes to the perceived weight and power of the weapon. A modder who wants a heavier-feeling shot can increase these magnitudes to something like -0.02 to 0.02. A modder who wants a cleaner sight picture can set both to 0.

How the engine processes a shot

Understanding the complete pipeline is essential for modders who edit weapon values. When a player fires the Birch Rifle, the engine executes the following sequence, using the fields documented in the tables above:

1. Input check. The game reads the Semi flag to confirm the weapon is in a fireable mode. It checks the Safety flag -- if the current fire mode is Safety, the trigger press is ignored.

2. Ammunition check. The game reads Ammo_Min (1) and the weapon's current loaded count. If the loaded count is below Ammo_Min, the weapon dry-fires with a click sound and no projectile is created.

3. Projectile creation. The game creates a hitscan raycast from the muzzle position. The raycast travels up to Range (175) metres. The game applies the Spread_Aim (0.01) cone if the player is aiming down sights, or the hip-fire spread if not.

4. Hit detection. If the raycast hits an entity, the game identifies the entity type (player, zombie, animal, or object) and the hit zone (skull, spine, arm, leg). The entity type selects which damage table to use. The hit zone selects which multiplier to apply within that table.

5. Damage calculation. The game takes the base damage from the selected table (e.g. Player_Damage = 80 for a player hit) and multiplies it by the hit zone multiplier (e.g. Player_Skull_Multiplier = 1.1 for a head shot). The result (88) is the pre-modifier damage. The game then applies armour reduction, skill modifiers, and any other post-hit modifiers.

6. Post-shot handling. The game applies recoil: a random value between Recoil_Min_X (5) and Recoil_Max_X (10) for horizontal, and between Recoil_Min_Y (15) and Recoil_Max_Y (20) for vertical. It applies screen shake: a random value between Shake_Min_X (-0.005) and Shake_Max_X (0.005). It decrements the loaded ammunition count by 1.

7. Fire-rate gate. The game starts the Firerate (50) tick counter. The weapon cannot fire again until the counter reaches zero. If the Action is Bolt, the bolt-cycling animation plays during this period.

A modder who understands this sequence can predict the effect of any field edit. Changing Range affects step 3. Changing Player_Damage affects step 5. Changing Recoil_Min_Y affects step 6. Changing Firerate affects step 7. The pipeline is deterministic given the field values; there is no hidden logic that a modder cannot account for by reading the tables.

Flag system

Every Unturned gun asset carries a set of flags. Flags are string tokens attached to the asset that enable or disable specific engine behaviours. The flag system is how the game's modular behaviour system works: instead of hard-coding every weapon's capabilities, the engine checks which flags are present and enables the corresponding systems. A modder can change a weapon's capabilities without editing any code by adding or removing flags.

The Birch Rifle declares the following flags:

Flags present: "21ede8ebffb14c5580e8c7ad149e335e", "5a3c4302400e400b9b9486fbb5178eca", "5ff4bcf752554990bf06e103b996cef2", "7b82c125a5a54984b8bb26576b59e977", "8c25cf28c76a4634855f404c8972c0ae", Blueprints, Hook_Barrel, Hook_Sight, InputItems, RequiresNearbyCraftingTags, Safety, Semi, [, ], {, }

The flag list contains three categories of flags: GUID flags (32-character hexadecimal strings), named behaviour flags (plain English strings), and bracket/brace characters. Each category serves a different purpose in the engine.

GUID flags

The flags that are 32-character hexadecimal strings (21ede8ebffb14c5580e8c7ad149e335e, 5a3c4302400e400b9b9486fbb5178eca, 5ff4bcf752554990bf06e103b996cef2, 7b82c125a5a54984b8bb26576b59e977, 8c25cf28c76a4634855f404c8972c0ae) are GUID references to other assets. These are not the Birch Rifle's own GUID (which is cdc4535e76db4da895649be269cdacbe) -- they are references to related assets such as crafting recipes, item spawn tables, or hook point definitions.

The GUID flag 7b82c125a5a54984b8bb26576b59e977 is the ItemFlag_Weapon flag present on most firearms. Its presence tags the Birch Rifle as a weapon-type item, which triggers weapon-specific UI, animation, and inventory behaviour. Without this flag, the item would still function as a weapon (because the ballistics and damage fields are still present) but the game's UI would not display weapon-specific elements like the ammo counter or the fire-mode indicator.

The GUID flag 8c25cf28c76a4634855f404c8972c0ae is commonly associated with firearm-type classification in the item system. Its presence further refines the item's category within the weapon supertype, distinguishing firearms from melee weapons, throwables, and tool-type items that also carry the ItemFlag_Weapon flag.

The remaining GUID flags (21ede8ebffb14c5580e8c7ad149e335e, 5a3c4302400e400b9b9486fbb5178eca, 5ff4bcf752554990bf06e103b996cef2) reference specific assets that define behaviours unique to the Birch Rifle. These could be crafting recipe sets, attachment compatibility definitions, or other asset-linked behaviours. The exact asset each GUID points to must be resolved by reading the asset bundle with Unity Explorer and looking up the GUID in the asset registry. Modders recognise these patterns by cross-referencing GUIDs against known asset registries, but the GUID alone does not tell you what it points to -- it is a pointer, not a description.

Behaviour flags

Blueprints -- tells the crafting system that this item has associated blueprint recipes. When the Blueprints flag is present, the game reads the item's nested blueprint data to populate the crafting menu. Removing this flag hides all of the Birch Rifle's crafting recipes, even if the recipe data is still present in the asset.

Hook_Barrel -- declares that the weapon asset exposes a barrel attachment point. The attachment system reads this flag to know that a barrel attachment (muzzle brake, suppressor, etc.) can be installed on this weapon. Removing Hook_Barrel disables barrel attachments.

Hook_Sight -- declares that the weapon asset exposes a sight attachment point. With this flag present, the attachment system allows sight and optic attachments to be installed on the Birch Rifle. Removing it disables sight attachments. The birch rifle exposes two hook points (Barrel and Sight), which is the minimum set for a conventional firearm in Unturned.

InputItems -- flags the asset as consuming input items in its recipes. This is paired with the Blueprints flag: Blueprints declares that recipes exist, InputItems tells the crafting system that those recipes consume items from the player's inventory. If Blueprints is present but InputItems is absent, the recipes would display in the menu but would not consume ingredients.

RequiresNearbyCraftingTags -- tells the crafting system that the item's recipes require a nearby crafting station or object with matching tags. When this flag is present, the player must be within range of a tagged object (such as a workbench or crafting table) to use the Birch Rifle's recipes. Removing this flag makes the recipes craftable from anywhere.

Safety -- marks the weapon as having a safety mode. The Safety flag enables a fire-mode state where the weapon cannot fire. It appears in the in-game fire-mode toggle alongside other modes.

Semi -- sets the fire mode to semi-automatic. The Semi flag means one trigger pull fires one round. If a modder removes Semi, the weapon would need another fire-mode flag (such as Auto) or it would lack a valid fire mode. A weapon can carry multiple fire-mode flags: Safety plus Semi gives a two-position toggle. Safety plus Semi plus Auto gives a three-position toggle.

Bracket and brace flags ([, ], {, }) -- these single-character flags are likely internal markers from the asset serialisation format that were captured as flag entries during extraction. Modders typically leave them in place when cloning or modifying the asset file, because the extraction tool may expect them in certain positions within the flag array. Removing them from a cloned asset is generally safe, but modders should test to confirm.

Where it spawns

This weapon does not appear in any extracted loot table. It is obtained another way (NPC reward, crafting, or admin-only). Say so plainly. Do not invent a spawn location.

This is the verified data from the game's loot table extraction. The Birch Rifle has no entries in the standard spawn tables. That means a player on a vanilla server will not find a Birch Rifle by looting containers, corpses, or world spawn points. The weapon must be acquired through an alternative method.

The three most common alternative acquisition paths for loot-table-absent weapons in Unturned are:

1. Crafting -- the Blueprints flag on the Birch Rifle asset confirms that crafting recipes exist for this weapon. A player with the correct input items and a nearby crafting station (because RequiresNearbyCraftingTags is present) can assemble the Birch Rifle through the crafting menu.

2. NPC reward -- some maps include NPC vendors or quest-givers whose reward tables reference items by GUID rather than by loot table. If an NPC reward entry uses GUID cdc4535e76db4da895649be269cdacbe, the player can obtain the Birch Rifle by completing the associated quest.

3. Admin command -- server operators can spawn the Birch Rifle with the command /give 479 or by referencing its GUID in a server plugin. Plugin APIs can create items by item ID or GUID from code, bypassing loot tables entirely.

For server owners, the absence from loot tables is significant: the Birch Rifle will not saturate the economy through random container spawns. Its availability is controlled entirely by the crafting recipe cost and any NPC quest gating. A server owner who wants the Birch Rifle to appear in loot can add entries to the appropriate spawn tables by creating a new spawn table entry with item ID 479 and a chosen weight, but in vanilla Unturned those entries do not exist.

How a modder reads and edits these values

Modifying the Birch Rifle follows a three-step pipeline: locate, read, edit.

Step 1: locate the asset

The asset lives in the game's asset bundle. Using Unity Explorer, navigate to the item asset list and search for asset name Rifle_Birch or GUID cdc4535e76db4da895649be269cdacbe. Selecting the asset exposes all the fields documented above in a property grid. Unity Explorer displays the fields alphabetically by default, with the field name in the left column and the field value in the right column.

For a mod asset bundle, the file is a .asset or .uasset file inside the mod's directory. The file path typically follows the pattern Bundles/Items/Guns/Rifle_Birch.asset. Tools like UAssetGUI can open the file directly and display the field list. Some modders prefer a raw JSON export workflow: export the asset to JSON, edit values in a text editor, and re-import the JSON.

When locating the asset in a mod bundle, if the modder cannot find the asset by file path, they can search by GUID across the entire bundle. Most modding tools support GUID-based search because GUIDs are the most reliable lookup key.

Step 2: read the fields

Every field in the tables above is a named entry in the asset's property list. The name on the left (e.g. Player_Damage) is the property name. The value on the right (e.g. 80) is the current setting. Before editing, confirm that you are reading the correct property by matching both the name and the current value to the tables in this reference. The Birch Rifle's vanilla values serve as a baseline that tells you "this is the unmodified asset."

If a property is missing from the asset entirely, the game uses the engine default for that property type. You can add the property by creating a new entry with the correct name and type. For example, if the Birch Rifle asset were missing Spread_Aim, the game would use whatever the engine considers the default spread value. Adding Spread_Aim with a value of 0.01 would override that default.

Some fields may appear with type indicators in UAssetGUI (e.g. float Player_Damage = 80.0). The type indicator tells the editor what data format to expect. Setting a float field to a string value would cause a validation error or an asset load failure.

Step 3: edit and save

Change the value directly. For numeric fields like Range or Player_Damage, type the new number. For flag fields, add or remove the flag string from the flag array. For GUID reference fields, paste the new GUID string. After editing, save the asset bundle and reload the mod. Test in a local game before publishing.

Common modding scenarios for the Birch Rifle, with the specific fields to edit:

• Damage tuning. Change Player_Damage from 80 to a higher or lower value. This shifts the whole player damage profile proportionally. If you only want to change one hit zone, edit that zone's multiplier instead.

• Recoil adjustment. Increase Recoil_Min_Y and Recoil_Max_Y for a stronger vertical kick. Decrease them for a flatter-shooting weapon. Set all recoil values to 0 for a weapon with no camera movement on fire.

• Ammo capacity. Change Ammo_Max from 4 to a higher value (e.g. 6 or 8) to give the Birch Rifle a larger magazine. Keep Ammo_Min at a sensible floor (1 is standard). If you increase Ammo_Max to 8 and leave Ammo_Min at 1, the weapon's valid loaded range becomes 1 to 8.

• Range adjustment. Change Range from 175 to a higher value (e.g. 250) to give the Birch Rifle longer reach, or lower it (e.g. 100) to make it a shorter-range tool.

• Flag toggling. Remove Semi and add Auto to change the fire mode. Remove Safety to disable the safety toggle. Add Hook_Grip and Hook_Tactical to give the Birch Rifle the same four hook points as the Sportshot. Be aware that removing system flags like Blueprints or InputItems will break crafting recipes.

Step 4: test and validate

After editing and saving, the modder must test the weapon in a local game. The test checklist should cover:

• Load test. Confirm the weapon appears in the inventory with the correct name and icon. Check that the item ID (479) is not duplicated by another mod.
• Fire test. Fire the weapon at a wall or distant object to confirm the muzzle effect (Muzzle 4), sound, and projectile raycast (Range 175) work correctly.
• Damage test. Fire at each hit zone type (if test targets are available) to confirm the damage values match the computed tables. The skull shot should produce 88 player damage, 108.9 zombie damage, and 108.9 animal damage.
• Handling test. Fire repeatedly and observe the recoil pattern (vertical climb of 15-20, horizontal drift of 5-10) and the screen shake (oscillation between -0.005 and 0.005).
• Reload test. Confirm the weapon accepts the Rifle Magazine (item 478), loads between Ammo_Min (1) and Ammo_Max (4), and fires at Firerate (50) between shots.
• Flag test. Confirm safety mode toggles, attachment points accept the correct attachment types, and crafting recipes appear in the crafting menu if Blueprints and InputItems are both present.

Troubleshooting common issues

Weapon does not fire. Check Semi flag is present and not overridden. Check Ammo_Min (1) is less than or equal to the loaded round count. Check that the magazine item (ID 478) is loaded and has a compatible Caliber value (17). Check that Action is set to a recognised string value (Bolt).

Weapon deals incorrect damage. Verify Player_Damage (80), Zombie_Damage (99), and Animal_Damage (99) are set to the intended values. Verify each multiplier field is spelled correctly and has the intended value. The game will silently use 0 for an unrecognised multiplier name.

Weapon has no recoil. Check Recoil_Min_X (5), Recoil_Max_X (10), Recoil_Min_Y (15), and Recoil_Max_Y (20). If all are 0, the weapon will have zero recoil. If the values are present but the weapon still has no recoil, the recoil system may be disabled by a plugin or a conflicting mod.

Crafting recipes do not appear. Check Blueprints and InputItems flags are both present. Check RequiresNearbyCraftingTags is either absent or the player is near a matching crafting station. Check the nested blueprint data in the asset is not corrupted or empty.

Attachment does not install. Check the corresponding Hook_<Category> flag is present in the Birch Rifle's flag array. The Birch Rifle carries Hook_Barrel and Hook_Sight; any attachment for a grip or tactical slot will not install because those hooks are absent.

Canned Beans

The Birch Rifle has no association with Canned Beans in the extracted data. This weapon does not appear in any loot table, which means there is no spawn table that groups the Birch Rifle alongside Canned Beans as co-located loot. The Canned Beans item (item ID 13 in vanilla Unturned) is a common food spawn found in civilian and grocery loot tables. Since the Birch Rifle does not share any of those tables, the two items are never spawned by the same loot roll.

The connection between the Birch Rifle and Canned Beans exists only in the broader Unturned crafting economy: the InputItems flag and the Blueprints flag on the Birch Rifle mean it participates in the crafting system, and Canned Beans also participates in the crafting system, but no recipe in the extracted data uses both items as inputs. A modder who adds a recipe that consumes a Birch Rifle alongside Canned Beans would create a direct data connection that does not exist in the base game files.

For the full story of Canned Beans in the 57 Studios wiki canon, see /lore/canned-beans-lore.

Practical use for server owners and modders

Server owners

The Birch Rifle's absence from loot tables makes it a controlled-distribution item. You can use it as:

• A crafting-only weapon. Let players craft it by gathering the required blueprint inputs. The crafting cost is the gate: if the recipe requires rare materials found in dangerous zones, the Birch Rifle becomes a milestone item. If it requires common materials, it becomes an early-game option.
• An NPC reward. Add the Birch Rifle to a quest NPC's reward table by referencing GUID cdc4535e76db4da895649be269cdacbe. This ties the weapon to a specific activity rather than random loot luck.
• An event drop. In a plugin-driven server, you can award the Birch Rifle on a timed event, boss kill, or seasonal drop. Because it has no natural spawn, its presence in circulation is a deliberate server operator choice.
• A donor or rank perk. Because you control distribution, you can grant the Birch Rifle through a permission group or kit without worrying that players will also find it in crates.

To add the Birch Rifle to a spawn table, create a new loot table entry with item ID 479 and assign it a weight. The per-roll chance is weight / total_table_weight * 100%. Start with a low weight (e.g. 1 or 2) to keep the weapon rare, and test on a staging server before pushing to production.

Modders

The Birch Rifle is a template firearm. Its data structure -- ballistics table, three damage layers, handling table, flag array -- is the same structure every Unturned gun uses. You can clone the Birch Rifle asset, rename it, and edit the fields to create a custom weapon.

When building a weapon mod starting from the Birch Rifle as a base:

1. Clone the asset and assign a new GUID. Do not reuse the Birch Rifle's GUID (cdc4535e76db4da895649be269cdacbe), or your mod will override the original weapon.
2. Change the asset name (e.g. Rifle_Birch_Custom) so your mod's asset does not conflict with the vanilla asset's name.
3. Assign a new item ID that does not collide with any existing item in the target server's item registry.
4. Edit the ballistics, damage, and handling fields to your desired values. The reference tables above tell you exactly which fields exist and what their vanilla values are.
5. Add loot table entries if you want your custom weapon to spawn naturally.
6. Build the mod asset bundle and test locally.

The Birch Rifle's field set is complete for a bolt-action rifle. It has the ballistics fields, the three damage tables, the handling fields, and the flag array. A modder who understands these fields for the Birch Rifle understands them for every bolt-action rifle in the game, because the field names and value types are consistent across the weapon asset family.