Pine Bow
The Pine Bow is one of four bows in Unturned.
It appears as asset Bow_Pine with item ID 356 and GUID 41873f4fca354e6482b48f7663f22aac.
Its rarity is Common and it occupies the Primary weapon slot.
The in-game item description reads: Pine bow chambered in Arrows.
It fires Arrow ammunition with the best range and tightest spread among the three wooden bows, making it the strongest wooden bow for precision shooting at distance.
Across the wooden bow family, the Birch Bow, Maple Bow, and Pine Bow share an identical damage profile and an identical set of behavioural flags.
The mechanical distinction between the three is purely a matter of ballistics and handling: how far the projectile flies at full power, how tight the aiming cone is, and what the recoil and shake feel like.
Damage output per hit is exactly the same whether you are holding a Birch, Maple, or Pine bow.
The Pine Bow appears naturally in exactly one spawn table on one official map, making its natural availability narrow compared to weapons that populate multiple tables across several maps.
This limited spawn footprint is a deliberate design choice that makes the Pine Bow a regional find rather than a globally available weapon.
This article is a complete data reference for the Pine Bow asset file.
Every field, value, multiplier, and spawn entry is presented exactly as it appears in the game data.
The only arithmetic present in this article is the per-zone damage multiplication that the extracted asset data itself provides in the form of pre-computed tables -- no additional numbers are derived, estimated, or inferred.
Each section begins with an explanation of what the block of fields controls and how the engine processes those values at runtime.
The explanation covers why the block exists in the asset file, what the engine does with each value, and how the values in the block interact with each other.
After the block-level explanation, every individual field in the corresponding table receives its own detailed walkthrough.
Each field walkthrough describes what the field means, what its specific value represents for the Pine Bow, how that value compares to the other bows, and what happens when a modder changes it.
If you are a modder opening a weapon asset file for the first time, the explanations are written to teach you how to read the data: what each value means, where it came from, and what changes a modder or server owner can safely make.
If you are a server owner looking up where the Pine Bow spawns or how to add it to your map, the spawn section and the practical-use closing section contain the specific configuration information you need.
The article does not cover gameplay advice, strategy recommendations, or performance comparisons against specific enemy health pools.
It covers what the asset file says.
That is enough to work with the weapon as a data object, whether you are tuning stats, designing spawn distributions, or building a custom variant.
Asset identity
When the Unturned engine starts up and loads the game data, it reads every weapon asset file from the game's installation directory and from any active workshop mod directories.
Each asset file is a JSON or DAT structure that defines one item.
The engine parses this file, extracts the identity fields, and registers the asset in an internal registry keyed by its GUID.
This registry is what the spawn system, the crafting system, the inventory system, and every plugin and admin command use to locate and reference the item.
If the identity fields in the asset file are corrupt, missing, or duplicated, the engine may skip the asset entirely during the loading phase, or it may load incorrect data that causes downstream breakage in spawn tables and crafting recipes.
Understanding how these identity fields work is the foundation of reading and editing any Unturned weapon asset.
The asset name Bow_Pine is the filename stem from which the engine derives the in-engine name string.
The engine strips the file extension from the filename, converts the name to lowercase for internal lookup operations, and uses it as a display fallback when no localised name string is available for the player's selected language.
The asset name is not the primary identity key.
The GUID is the primary identity key.
If a modder renames the asset file from Bow_Pine.dat to CustomBow_Pine.dat and keeps the GUID unchanged inside the file, the engine will still find the same GUID during registration and register it under the same identity.
Every external reference -- spawn table entries that list the GUID, blueprint recipe references that point to the GUID, plugin item definitions that target the GUID -- will continue to resolve correctly because they key on the GUID, not on the filename.
This means a modder can reorganise their mod's file structure, rename individual asset files, and move files into nested subdirectories without breaking saved games or server configurations.
The single rule is: do not change the GUID.
The GUID 41873f4fca354e6482b48f7663f22aac is a 32-character hexadecimal string generated when the asset was first authored in the Unity editor or written by hand in a text editor.
Every asset in Unturned must have a GUID, and every GUID must be unique across all loaded mods and official content.
When the engine builds its asset registry at startup, it creates a hash table that maps each GUID string to the parsed asset data structure in memory.
When a spawn table entry says "spawn the item with GUID 41873f4fca354e6482b48f7663f22aac," the engine performs an O(1) hash-table lookup, finds the Pine Bow asset data, and creates an instance of the weapon.
The GUID is the stable identity across sessions, game updates, mod republishing, and asset reorganisation.
If a modder creates a copy of the Pine Bow asset file to build a custom variant, they must generate a new GUID for the copy.
If two loaded assets share the same GUID, the engine cannot distinguish them during registration.
It will either load one of the two arbitrarily, or it will skip both and log a conflict warning.
Generating a new GUID is a one-time operation performed at asset creation time.
After the GUID is assigned and the asset is published to the Steam Workshop or distributed to players, the GUID should never change.
Changing a published asset's GUID breaks every external reference: spawn table entries stop working, blueprint recipes fail to resolve, and plugin commands that target the old GUID become invalid.
The item ID 356 is an unsigned 16-bit integer that the inventory system uses for fast internal comparisons.
When the Pine Bow occupies a player's backpack slot, a hotbar slot, a storage container, or exists as a ground item entity in the world, the engine stores the integer 356 rather than the full 32-character GUID string.
Integer comparison is orders of magnitude faster than string comparison, which matters when the engine is scanning a player's inventory of dozens of items every frame to check for valid ammunition matches, crafting ingredient availability, or equip condition validation.
Among the four bow variants, the Pine Bow has the highest item ID at 356.
The Maple Bow uses item ID 353.
There is a gap at ID 354 where no bow exists.
The Birch Bow uses item ID 355.
The Compound Bow uses item ID 357.
The IDs are sequential and clustered closely together in the range 353 to 357.
The ordering does not correlate with mechanical power.
The Birch Bow at ID 355 is mechanically weaker than the Pine Bow at ID 356, yet the Compound Bow at ID 357 is the strongest of all four.
The item ID is not guaranteed to be stable across game updates.
The game's developer may renumber items for internal engine reasons, and any mod or plugin that relies solely on item IDs may break after an update.
The GUID is the guaranteed stable reference that survives renumbering.
When a server owner or plugin developer needs to reference the Pine Bow in configuration files, they should use the GUID for stability and the item ID only when the target system -- such as an admin command parser or a plugin API -- requires an integer key and does not accept GUID strings.
If two mods both define item ID 356, the engine resolves the conflict using load order.
The last mod loaded wins, and the first mod's item with ID 356 becomes inaccessible.
This is why custom items should use high ID ranges -- 30000 and above is a widely adopted community convention -- to avoid collisions with vanilla item IDs and with other published mods that also define custom items.
The Rarity field is set to Common.
Unturned's rarity system assigns each item to one of six tiers, and each tier is associated with a display colour that controls how the item's name appears in the inventory user interface.
The six tiers, in ascending order of perceived value, are: Common (displayed in white or grey text), Uncommon (green text), Rare (blue text), Epic (purple text), Legendary (orange or gold text), and Mythical (red text).
The rarity is a classification label and a display directive.
It does not directly control spawn probability, because spawn tables have their own explicit per-item weight system that is completely independent of the Rarity field on the item asset.
It does not control damage output, projectile speed, durability, ammunition capacity, or any other mechanical property of the weapon.
It only controls the colour of the item's name text in the inventory UI, the ground-item nameplate, and the container inspection pane.
For a server owner running a custom loot crate plugin that reads the Rarity field to sort items into loot quality tiers, the Common rarity of the Pine Bow means the plugin will classify it alongside other Common-tier weapons and will not treat it as a premium or rare drop.
All three wooden bows share the Common rarity tier.
The Compound Bow, being a mechanically superior weapon with higher base damage against players, a tighter aiming spread, and access to attachments, has Uncommon rarity.
The rarity tier is a signal to players about the item's intended place in the game's progression ladder without being a mechanical gatekeeper that directly blocks access or modifies behaviour.
The Slot field is Primary.
Unturned divides the player's equipped items into named slots that correspond to different parts of the character model and different hotkey bindings.
The Primary slot holds exactly one weapon at a time.
The Secondary slot holds a sidearm, also one at a time.
Additional slots exist for clothing items: a Shirt slot, a Pants slot, a Vest slot, and a Backpack slot.
When a player equips a Pine Bow while already holding a different primary weapon, the old weapon is unequipped and returned to an available space in the player's inventory.
The Primary and Secondary slots operate independently: equipping or unequipping a primary weapon has no effect on whatever is currently in the secondary slot.
The slot assignment also determines the default hotkey binding.
The primary slot typically responds to the '1' key, and the secondary slot typically responds to the '2' key.
The player can rebind these keys in the game's settings menu.
The character model reflects the slot assignment by showing the bow strapped diagonally across the player's back when not actively drawn in the character's hands.
Valid slot values in an Unturned asset file include Primary, Secondary, Backpack, Shirt, Pants, and Vest.
Assigning a weapon asset to a non-weapon slot such as Shirt would cause the inventory system to behave unpredictably, because the engine expects clothing slots to hold clothing-type items that define armour values and equipment mesh overrides rather than weapon firing properties.
The slot assignment is one of the fields that a modder should never change on a weapon asset without thorough testing on a local server, because the engine's equip and unequip logic depends on the slot value matching the item type classification.
The description string Pine bow chambered in Arrows. is the flavour text displayed below the item name in the inventory tooltip when the player hovers the cursor over the Pine Bow in any inventory context.
The description is localisable.
The asset file stores a string key identifier -- a lookup token -- rather than the literal English text.
The game's localisation system performs a lookup on this key in the active language file for the player's selected language and returns the translated string.
If a player has their game language set to French, they see the French translation of the key.
If a player has it set to Korean, they see the Korean translation.
If the localisation key is not found in the active language file -- for example, if a modded weapon defines a custom string key without shipping translation data files for every supported language -- the engine falls back to displaying the key itself as raw text in the tooltip.
This is why some modded weapons display their internal string key as their description: it is a fallback behaviour, not a deliberate design choice.
The description string is informational only.
It has no effect on weapon behaviour, damage output, accuracy, projectile type, or any other mechanical property.
Changing the description field in the asset file alone will not change what players see in-game unless the new text matches an entry in the active localisation database or the asset file is configured to bypass the localisation system and display its raw text directly.
Ballistics
The ballistics block is the set of fields that define how the Pine Bow fires.
These fields control: how far the projectile travels at full damage before falloff begins, how quickly the weapon can fire successive shots (the cooldown between shots), what kind of character animation plays during the firing sequence, what type of ammunition the weapon is compatible with, and how much ammunition is pre-loaded when the weapon first appears in the world.
When the player presses and releases the attack key, the engine reads this block to determine every aspect of the resulting firing event.
The block lives in the weapon's JSON or DAT asset file alongside the damage blocks and the handling block.
Every field in the table below is required for the weapon to function as a ranged weapon.
If a field is omitted from the asset file, the engine substitutes a default fallback value, and that default may produce behaviour that does not match the modder's intent -- a zero-range weapon, a weapon that fires with no cooldown, or a weapon that does not know which ammunition to load.
For bows specifically, the ballistics block interacts with the bow's unique charge-and-release mechanic.
Unlike a rifle where one click produces one shot immediately, a bow requires the player to hold the attack key.
While the key is held, the character plays a draw animation whose duration is defined in the weapon's animation controller -- a separate asset file from the weapon data file.
The arrow is released when the player lets go of the key, or when the maximum draw time limit is reached if the player holds the key past that point.
The Firerate field in this block controls the cooldown after the arrow is released, not the draw time before release.
The Caliber field determines which ammunition items are considered compatible for reloading.
The Magazine field determines which specific ammunition item is pre-loaded into the weapon at spawn time.
Together, these seven fields form a complete specification of the Pine Bow's firing behaviour that the engine evaluates every time the player draws and releases the bowstring.
| Field | Value |
|---|---|
| Range | 160 |
| Firerate | 50 |
| Action | String |
| Caliber | 15 |
| Magazine | 352 |
| Ammo_Min | 1 |
| Ammo_Max | 1 |
The Range field holds the value 160.
This value sets the distance, measured in game metres, at which the projectile begins to experience a damage falloff curve.
Within 160 metres of the muzzle, the arrow deals its full base damage against whatever entity it strikes.
At the boundary of 160 metres, the engine begins to apply a damage reduction that scales with the distance the projectile has travelled beyond that point.
The further past 160 metres the arrow flies, the less damage it deals on impact.
The value of 160 is the highest range among the three wooden bows.
The Birch Bow has a range of 130, which is 30 metres shorter than the Pine Bow.
The Maple Bow has a range of 145, which is only 15 metres shorter.
The progression from weakest wooden bow to strongest is a clean, evenly-spaced series: Birch at 130, Maple at 145, Pine at 160.
Each step in the tier adds exactly 15 metres of effective range.
The Compound Bow then breaks the pattern with a jump to 200, a full 40 metres beyond the Pine Bow and well outside the 15-metre increments of the wooden family.
This graduated progression suggests that the three wooden bows were deliberately designed as a tiered series with even spacing, while the Compound Bow was designed as a separate, higher-tier weapon that sits outside that series entirely.
The Range value is stored as a plain numeric value in the asset file, typically as an integer.
Any positive numeric value is technically valid as input.
However, extremely high values -- values beyond the map's active render distance or beyond the projectile's engine-level despawn distance -- provide no practical benefit to the player because the projectile ceases to exist in the game world before it reaches the target, regardless of what the Range field says.
The Pine Bow's combination of the highest wooden-bow range (160) and the tightest wooden-bow spread (0.05) makes it the wooden bow most capable of landing consistent, full-damage hits at the far end of its effective engagement window.
The Firerate field holds the value 50.
This is a cooldown value measured in engine physics ticks.
After the Pine Bow fires an arrow, the engine initialises a counter at zero and increments it by one on each subsequent physics tick.
The weapon will ignore any attack key input -- the player can press the key, but nothing will happen -- until the counter reaches 50.
At that point, the weapon becomes ready to fire again.
All four bow variants -- Birch, Maple, Pine, and Compound -- share this identical Firerate value of 50.
The firerate cooldown is independent of the bow's draw mechanic.
The draw animation has its own duration parameter defined in the weapon's animation controller asset, which is a separate file from the weapon data.
If the draw animation completes in fewer than 50 ticks, the player must still wait for the firerate cooldown to expire after release before beginning the next draw.
If the draw animation takes longer than 50 ticks to complete -- for example, because the player released the key early before a full draw, or because the animation controller has a long wind-up -- then the animation is the limiting factor: the firerate cooldown has already elapsed by the time the arrow is released, and the player can begin the next draw immediately.
For a modder wanting to increase the bow's cyclic rate, the Firerate value must be reduced.
The new value must be tested in-game against the draw animation duration to confirm that the Firerate reduction actually translates to faster fire in practice.
If the draw animation remains the bottleneck, lowering the Firerate number has no observable effect.
The Firerate value is typically stored as a floating-point number in Unturned asset files, though the extracted asset data lists it as an integer for readability.
Setting it to a non-integer value such as 25.5 is valid and would be interpreted by the engine as a cooldown of 25.5 ticks.
The Action field holds the value String.
This field selects which animation set the engine plays during the weapon's firing sequence.
A value of String maps to the bow-draw animation controller, where the character model reaches back with the drawing hand, pulls the bowstring toward the anchor point, and releases it forward.
The string value comparison performed by the engine is case-sensitive.
Writing "string" with a lowercase 's' in the asset file would not match the expected animation set name, and the engine would fall back to a default animation -- typically the generic rifle-firing animation set, which would look visually incorrect when applied to a bow model.
All four bow variants use this same String action value because they all share the same bow animation controller asset.
The animation system in Unturned is separate from the weapon data file: the Action field is a pointer string that tells the engine which controller to load, and the controller itself lives in a different asset that contains the actual animation keyframes and timing data.
Changing the Action field to another recognised value, such as Pump for pump-action shotguns or Trigger for flare guns, would cause the character model to cycle a pump mechanism or squeeze a trigger while holding a bow mesh, producing a visual mismatch between the model and the animation.
For a custom bow variant that uses a different character model or rig -- such as a longbow that requires a different drawing stance -- the Action field should be set to whatever string value the new animation controller expects.
If the new animation controller also happens to be named String, no change is needed to this field.
The Caliber field holds the value 15.
This integer maps the weapon to a specific ammunition type in Unturned's internal ammunition index.
The value 15 corresponds to the Arrow calibre.
When the player has ammunition items in their inventory and presses the reload key while holding the Pine Bow, the engine scans through every item in the player's inventory, checks each item's own Caliber field, and compares it against the weapon's Caliber field.
Only items whose Caliber matches 15 -- meaning Arrow items -- are eligible to be loaded into the Pine Bow.
The Caliber field also controls which type of projectile the weapon spawns into the world when it fires, though the projectile itself is defined in a separate asset reference field that is not listed in this extraction.
The Caliber index 15 is shared across all four bow variants and any other weapon that a modder configures to accept Arrow ammunition.
If a modder creates a custom crossbow or a custom rifle receiver and sets its Caliber to 15, that weapon will accept Arrows as ammunition.
Conversely, a player carrying Arrow ammunition in their inventory will be able to reload any Caliber-15 weapon they are holding, whether it is a bow or a custom item.
Changing the Pine Bow's Caliber to a different integer value -- for example, 1 for a completely different ammunition family -- would make the bow accept that ammunition type instead of Arrows, and would also change which projectile asset the engine spawns when the bow fires.
This is a valid modding operation but should be paired with corresponding updates to the Magazine field and to the projectile reference asset to maintain internal consistency across the weapon's data.
The Magazine field holds the value 352.
This stores the item ID of the specific ammunition item that the Pine Bow spawns with when it first materialises in the game world.
The value 352 is the item ID of the standard Arrow item.
When the engine creates a new Pine Bow instance -- whether the weapon is generated by a spawn-table loot roll on the Ireland map, placed into existence by an admin /give command, or spawned by a plugin that creates items programmatically -- the engine reads the Magazine field.
It looks up the item with ID 352 in its own item registry.
It creates an instance of that item -- a single Arrow -- and attaches it to the weapon as the pre-loaded, ready-to-fire ammunition.
Because the Ammo_Min and Ammo_Max fields are both set to 1, exactly one Arrow is pre-loaded at spawn time.
The Magazine field does not restrict which ammunition the weapon can accept during reloading.
That restriction is enforced by the Caliber field, which gates reload compatibility on the calibre integer match.
The Magazine field only determines what is already in the weapon when the player first picks it up.
If a modder changes the Magazine field to reference a different item ID -- for example, 354 for a different ammunition variant -- the weapon will spawn with that different item pre-loaded, regardless of whether the Caliber field considers it compatible for reloading.
This can produce a weapon that spawns with ammunition it cannot use or cannot reload with, which is almost certainly not the modder's intended behaviour.
In normal asset configuration, the Magazine value should reference an item whose Caliber field matches the weapon's Caliber field, ensuring that the spawn-state ammunition is both compatible and reloadable.
The Ammo_Min field holds the value 1.
This sets the minimum number of ammunition items the weapon spawns with when it first appears in the world.
When the engine creates a new Pine Bow instance, it generates a random integer between Ammo_Min and Ammo_Max, inclusive of both endpoints.
It then creates that many copies of the item referenced by the Magazine field -- the Arrow item with ID 352 -- and loads them into the weapon's internal ammunition reserve.
Because Ammo_Max is also 1, the random range collapses to a single possible value, and the weapon deterministically spawns with exactly one Arrow loaded and ready to fire.
The Ammo_Min field only affects the spawn state of the weapon.
After the player picks up the Pine Bow, fires the single loaded arrow, and reloads from their inventory using additional Arrows they have found or crafted, the Ammo_Min value has no further effect on the weapon's behaviour for the rest of that weapon instance's lifetime.
If a modder changes Ammo_Min to 0, the random range would become [0, 1], and the weapon would have a 50% chance of spawning with zero arrows (requiring the player to find ammunition before using it) and a 50% chance of spawning with one arrow.
If a modder changes Ammo_Min to 3 and Ammo_Max to 7, the weapon would spawn with a uniformly random number of arrows between 3 and 7, though the bow's single-shot firing mechanism means only one is chambered at any time and the rest are held in the reserve pool.
The Ammo_Min and Ammo_Max fields together define the weapon's starting ammunition pool and are entirely separate from the weapon's magazine capacity and maximum reserve capacity, which are controlled by other fields elsewhere in the asset file.
The Ammo_Max field holds the value 1.
This sets the maximum number of ammunition items the weapon spawns with.
Combined with Ammo_Min of 1, the spawn ammunition count is deterministic: exactly one Arrow, every single time, with no randomness.
The bow always appears in the world with one Arrow pre-loaded and ready to fire on the first draw.
The player must find, craft, or otherwise acquire additional Arrows to reload the weapon after that first shot is taken.
The single-arrow starting state is consistent with the bow's role as a ranged weapon that rewards accuracy and deliberate shot placement.
The player gets one opening shot before needing to source more ammunition, and that first shot must count.
The Ammo_Max field, like Ammo_Min, only affects the initial spawn state.
If the player later reloads the weapon from their inventory and loads, for example, five Arrows, the Ammo_Max value does not prevent this because it is a spawn-time parameter, not a running capacity cap.
The actual ammunition capacity of the weapon -- the maximum number of Arrows it can hold at once, both chambered and in reserve -- is controlled by a different set of fields in the asset file's magazine configuration block.
When writing a custom weapon variant that should spawn with more than one round of starting ammunition, increase Ammo_Max to the desired maximum and optionally increase Ammo_Min if the weapon should always spawn with at least a minimum number of rounds rather than sometimes spawning empty.
Player damage
The player damage block controls how much damage the Pine Bow deals when its projectile strikes another player character, and how that damage varies depending on which part of the target's body the projectile hits.
When the engine detects a collision between a Pine Bow projectile and a player entity's hitbox, the first thing it determines is which hit zone was struck.
It determines the hit zone by checking the exact collision point of the projectile against the target player's skeletal rig, which defines four distinct hit zones: Skull (the head), Spine (the torso), Arm (the upper limbs), and Leg (the lower limbs).
Each hit zone has an associated multiplier value defined in the table below.
The engine looks up the multiplier for the struck zone, multiplies it by the base Player_Damage value of 60, subtracts any damage reduction from armour that the target player is wearing, and applies the final result to the target's health pool.
The multiplier system is how the game rewards or penalises shot placement.
Hitting a small, fast-moving, hard-to-aim-for hit zone like the Skull applies a damage bonus.
Hitting a large, easy-to-hit zone like the Legs applies a damage penalty.
The base damage and all four zone multipliers are defined once in the asset file and loaded into memory when the weapon is registered at game startup.
Changing any of these values requires replacing the asset file and either restarting the game or triggering an asset reload on the server.
The player damage profile for the Pine Bow is identical in every value to the Birch Bow and the Maple Bow.
Across all three wooden bows, the base damage and every zone multiplier in the player block are the same numbers.
Only the Compound Bow deviates from this profile, with a higher base player damage of 80 and with some versions of the Compound Bow asset using slightly different multiplier values.
This uniformity across the wooden family means the Pine Bow's advantages over the Birch and Maple Bows are in ballistics and handling -- longer range, tighter aiming spread, and a cleaner firing feel -- not in per-hit damage output against other players.
| Field | Value |
|---|---|
| Player_Damage | 60 |
| Player_Leg_Multiplier | 0.6 |
| Player_Arm_Multiplier | 0.6 |
| Player_Spine_Multiplier | 0.8 |
| Player_Skull_Multiplier | 1.1 |
The Player_Damage field holds the value 60.
This is the base damage applied before any zone multiplier or armour calculation takes place.
When a Pine Bow arrow strikes a player entity, the engine begins with this 60, multiplies it by the appropriate zone multiplier from the hit detection, subtracts any flat or percentage armour damage reduction that the target has from equipped protective gear, and subtracts the final resulting number from the target's current health.
The value of 60 is shared identically across all three wooden bows.
This means that at point-blank range where differences in range falloff and aiming spread do not matter, a Pine Bow, Maple Bow, and Birch Bow are completely indistinguishable in damage per hit against an unarmoured player.
The three bows will produce exactly the same damage number for the same hit zone every time.
The Compound Bow has a base player damage of 80, which represents a 33% increase over the wooden family's 60.
For a modder creating a custom bow variant, the player damage value is the primary tuning knob for how lethal the weapon feels in player-versus-player combat.
Setting it to 75 would create a bow that sits between the wooden tier (60) and the compound tier (80).
Setting it to 60 would keep it identical to the existing wooden bows.
Setting it to 90 would exceed the Compound Bow and create a new highest-damage bow tier.
Setting it to 40 would create a weaker, survival-oriented bow intended as an early-game or challenge weapon.
The player damage value is typically stored as a float in the asset file, so non-integer values such as 72.5 are technically valid and will be interpreted correctly by the engine.
The Player_Leg_Multiplier field holds the value 0.6.
When a Pine Bow arrow strikes a player character's leg hitbox, the engine multiplies the base damage of 60 by 0.6, producing a raw damage value of 36 before any armour reduction is applied.
The leg multiplier represents the lowest and most penalised damage zone against player targets: only 60% of the base damage is delivered on a leg hit.
Legs are the largest and most frequently exposed hit zone on a player model, especially against a moving target that is sprinting, strafing, or jumping, where the legs constitute a significant portion of the visible silhouette at most engagement distances.
The low multiplier penalises players who aim for the easiest and largest target rather than the smaller but more rewarding upper-body and head hitboxes.
All three wooden bows share this identical 0.6 leg multiplier.
For a modder, the leg multiplier controls how punishing it is to land shots on the lower body.
Raising it to 0.8 would make leg shots nearly as effective as spine shots, reducing the skill differential between a player who aims for centre mass and a player who sprays at the legs.
Lowering it to 0.4 would make leg shots even less rewarding, further incentivising deliberate aim toward the torso and head.
The leg multiplier interacts with target movement patterns: a player who is sprinting typically exposes their leg hitboxes more than a stationary or crouching player, so the low multiplier serves as a natural counterbalance to the fact that landing any hit at all on a fast-moving leg target is easier than landing a precision shot on a bobbing head.
The Player_Arm_Multiplier field holds the value 0.6.
Arm hits against player targets receive the same 60% multiplier as leg hits, applying 36 damage before armour from the base of 60.
The arm hitbox on a player character model is positioned such that it overlaps significantly with the torso hitbox from many common engagement angles.
When a shooter aims at centre mass, intending a spine hit at the 0.8 multiplier, the projectile may clip the arm hitbox on its way to the torso, and the engine registers the hit as an arm strike at 0.6 instead.
This overlap is an important detail for modders to understand: the arm multiplier is not exclusively a penalty for deliberate arm shots by inaccurate players.
It is also a common "unlucky roll" outcome for shots that were aimed at the torso but intercepted by the arm hitbox's forward position in the rig.
The similarity between the arm and leg multipliers -- both 0.6 -- means the player damage model treats all limbs as uniformly penalised.
There is no distinction in how the engine handles an arm strike versus a leg strike: both apply 60% of base damage.
A modder could break this symmetry intentionally.
Setting the arm multiplier to 0.7 while keeping the leg multiplier at 0.6 would make arm hits slightly less punishing than leg hits, creating a damage model where upper-limb hits are more forgiving -- which makes sense for a weapon where the arms are more likely to be hit because they overlap with the torso.
Conversely, lowering the arm multiplier to 0.5 while keeping the leg multiplier at 0.6 would further penalise the "almost a body shot" outcome and make precision even more important.
The Player_Spine_Multiplier field holds the value 0.8.
The spine hitbox represents the torso region of the player model -- the chest, abdomen, and back -- and is the default target for centre-mass aiming in most combat situations.
At a multiplier of 0.8, a spine hit deals 80% of the base 60 damage, producing 48 damage before armour reduction.
The spine multiplier functions as the neutral reference point in the player damage model.
It carries neither a bonus nor a severe penalty.
It represents what the player can consistently expect when they aim for the centre of the target and the projectile lands where intended, without the intervention of the arm hitbox overlap.
The spine multiplier of 0.8 is less than 1.0, which means that even a perfectly placed centre-mass body shot does not deal the full base 60 damage.
The weapon's advertised base damage of 60 is only realised in practice on a Skull hit at multiplier 1.1.
This design pattern -- where the largest and most reliably hittable zone does not receive the full base damage value -- is standard in first-person shooter damage models because it creates a headshot incentive without making body shots useless.
If body shots dealt the full base damage, there would be no mechanical reason to aim for the head beyond the satisfaction of the headshot sound.
All three wooden bows share this 0.8 spine multiplier.
A modder could raise it to 1.0 to make centre-mass body shots deal exactly the base 60 damage, which would make the weapon feel significantly punchier on body hits without changing headshot damage at all.
A modder could lower it to 0.6 to widen the gap between body and head damage, making the headshot bonus much more impactful and rewarding.
The Player_Skull_Multiplier field holds the value 1.1.
A headshot against a player character applies a 110% multiplier to the base damage of 60, resulting in 66 damage before any armour reduction.
The skull hitbox is the smallest hit zone on the player model by a significant margin.
It is positioned at the top of the character rig, meaning it moves unpredictably as the target strafes, crouches, jumps, and leans -- lateral movement causes the head to bob side to side, and vertical movement causes the head to rise and fall relative to the shooter's aim point.
The 1.1 multiplier is the game's reward for landing a hit on this small, fast-moving, difficult target.
It is a modest bonus -- a 10% increase over the base 60 -- rather than a game-changing multiplier that dramatically alters the flow of combat.
All four bows, including the Compound Bow, share this 1.1 skull multiplier.
The ratio between a perfect Skull hit (1.1) and a poor Leg hit (0.6) against players is approximately 1.83 to 1.
A headshot deals a bit less than double the damage of a leg shot.
For a modder, the skull multiplier is the single most impactful PvP tuning parameter because it controls how much the weapon rewards the most difficult shot to land.
Raising it to 1.5 would make headshots deal 90 damage, creating a weapon where one headshot dramatically outweighs any number of body shots in value.
Lowering it to 1.0 would remove the headshot bonus entirely, making every hit zone produce the same damage and eliminating the precision incentive from the weapon's damage model.
The 1.1 value used by the Pine Bow is conservative. It provides a noticeable but not overwhelming headshot reward, which aligns with the wooden bows' role as accessible, general-purpose ranged weapons rather than high-skill-ceiling specialist tools.
The computed per-zone damage values against player targets are:
| Hit zone | Multiplier | Damage (base 60) |
|---|---|---|
| Skull | 1.1 | 66 |
| Spine | 0.8 | 48 |
| Arm | 0.6 | 36 |
| Leg | 0.6 | 36 |
These values are the pre-armour raw damage numbers.
They represent what the engine subtracts from the target player's health pool before any damage reduction from equipped armour, helmets, vests, or clothing is calculated and deducted.
The values are identical to those of the Birch Bow and the Maple Bow.
The Pine Bow's listed mechanical advantages -- its 160-metre range and its aiming spread of 0.05 -- are entirely separate from these damage numbers.
Against an unarmoured player standing at close range where the range falloff curve has not yet begun and the spread cone is too small to cause a miss, all three wooden bows produce identical damage numbers per hit zone.
What makes the Pine Bow stronger in actual gameplay is its ability to deliver these same damage numbers more consistently from further away and with a higher probability of landing the shot on the intended hit zone rather than on a neighbouring one.
Zombie damage
The zombie damage block defines the Pine Bow's damage output against zombie-type entities.
It uses a completely separate base damage value and a completely separate set of per-zone multipliers from the player damage block.
The two damage profiles are fully independent: changing a value in the zombie block does not affect player damage, and vice versa.
This separation allows the asset author to balance PvE and PvP independently of each other.
A weapon that is well-balanced against other players does not need to be identically balanced against zombies, and the engine supports this design choice natively through the separate damage blocks.
When the engine detects a collision between a Pine Bow projectile and a zombie entity hitbox, it switches entirely to the zombie damage table.
It ignores the player damage table and the animal damage table for that hit.
The specific entity type of the target -- whether the engine classifies the hit entity as a player, a zombie, or an animal -- determines which damage block the engine reads.
The zombie entity in Unturned uses a different hitbox layout than the player character model.
Zombies lean forward in their idle stance and lean further forward during their pursuit and attack animations.
This hunched posture shifts the head hitbox lower, closer to the centre of the character rig, and further forward than on an upright player.
Zombie arms extend outward as the creature shambles and swings, which makes arm hitboxes more prominent and more likely to intercept a projectile than against a player target at the same angle.
The zombie damage profile accounts for these entity differences by using steeper limb penalties (lower multipliers) and a higher base damage to compensate, creating a damage model where headshots are strongly incentivised and limb shots are punishingly ineffective.
The profile is identical across all four bow variants.
Birch, Maple, Pine, and Compound bows all share the same zombie base damage and the same set of four zombie zone multipliers.
The Pine Bow's distinguishing advantage in zombie combat is not higher damage per hit, but rather its tighter aiming spread, which makes landing the high-value headshots at range more consistent and more frequent than with the wider-spread Birch or Maple Bows.
| 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 |
The Zombie_Damage field holds the value 99.
This is the base damage value applied before any zone multiplier when the Pine Bow's arrow hits a zombie entity.
The value of 99 is substantially higher than the player base damage of 60 -- a difference of 39 points, or a 65% increase over the player base.
This higher base value compensates for the much steeper limb penalties in the zombie multiplier set.
While a player leg shot applies a 0.6 multiplier (60% of base), a zombie leg shot applies only 0.3 (30% of base).
The higher base of 99 ensures that body shots and headshots remain meaningful in damage output even though the limb penalties are severe.
If the zombie base were also 60 with 0.3 limb multipliers, a leg shot would deal only 18 damage, which would make limb shots feel completely useless.
The value of 99 is shared across all four bows.
For a modder, the zombie damage base value is one of the primary PvE balance adjustment knobs.
Raising it to 120 while leaving the multipliers unchanged would make the bow proportionally stronger against all zombie types, at all hit zones, by the same percentage.
Lowering it to 75 would weaken the bow across all zombie engagements.
Because the zombie damage block is completely separate from the player damage block, a modder can raise zombie damage to create a powerful PvE weapon while leaving player damage at vanilla values for fair PvP.
A PvE-focused server might increase zombie damage on all ranged weapons to compensate for increased zombie spawn rates or tougher custom zombie variants, without touching the PvP damage balance at all.
The Zombie_Leg_Multiplier field holds the value 0.3.
At only 30% of the base 99 damage, a leg shot against a zombie deals 29.7 damage before any special resistances that certain zombie types may have.
This multiplier is exactly half the player leg multiplier of 0.6 -- the zombie damage model is twice as punishing to leg shots as the player model.
The extremely low zombie leg multiplier reflects the PvE design philosophy that zombies should be dispatched with headshots, and that ammunition spent shooting at the largest and easiest target -- the shambling legs of the zombie -- should be nearly wasted.
The 0.3 value creates a dramatic damage gradient between hit zones.
The ratio between a Skull hit and a Leg hit against zombies is approximately 3.67 to 1, compared to about 1.83 to 1 against players.
Precision is far more important against zombies than against players under this damage model.
All four bows share this identical 0.3 zombie leg multiplier.
For a modder, the zombie leg multiplier is a dial that controls how forgiving the weapon is against zombies for inaccurately placed shots.
Raising it to 0.5 would make leg shots more viable as a fallback option when the zombie's head is obscured or the player is panicking.
Raising it to 0.6 would bring it in line with the player leg multiplier, making zombie limb damage match player limb damage.
Lowering it further -- to 0.2 or even 0.1 -- would make the weapon nearly useless for anything except headshots, which might be desirable for a hardcore survival experience.
The Zombie_Arm_Multiplier field holds the value 0.3.
Arm hits against zombies deal the same 30% of base as leg hits, producing 29.7 damage from the 99 base.
The arm hitbox on a zombie model is prominent because zombies reach forward with their arms as they move and attack.
An arrow aimed at the zombie's hunched torso is very likely to clip an extended arm on its way to the body, resulting in an arm-hit registration at 0.3 rather than the intended spine hit at 0.6.
This arm-intercept behaviour makes the zombie damage model feel especially punishing for shots that were aimed at the body rather than the head.
The arm multiplier is identical to the leg multiplier across all four bows.
There is no distinction in the zombie damage model between where on the limbs a hit lands -- an arm shot and a leg shot are treated as equally ineffective.
For a modder, the arm and leg multipliers do not need to stay equal.
Raising the arm multiplier to 0.4 while keeping the leg multiplier at 0.3 would make upper-body near-misses less punishing than lower-body hits.
This could reflect a design where the zombie's arms are considered less armoured or less resilient than their legs, or where the modder wants to be slightly more forgiving to the common arm-intercept scenario.
The Zombie_Spine_Multiplier field holds the value 0.6.
A centre-mass body shot against a zombie deals 60% of the base 99 damage, producing 59.4 damage before any special zombie-type resistances.
This is lower than the player spine multiplier of 0.8.
The zombie spine hitbox is the largest upper-body zone on the leaning zombie model, covering the hunched back and torso.
At 0.6, a spine hit still represents a significant damage penalty compared to a headshot at 1.1.
The design choice to set the zombie spine multiplier lower than the player spine multiplier reinforces the "headshots are mandatory" PvE philosophy.
Even a well-aimed body shot that lands cleanly on the torso without clipping an arm still only delivers 60% of the base damage.
The value is shared across all four bows.
For a modder, the zombie spine multiplier is one of the most impactful PvE values to tune if the goal is to make zombie combat feel less punishing for players who do not reliably land headshots.
Raising it to 0.8 would bring zombie body shots in line with player body shots, making the weapon feel more consistent across PvE and PvP contexts.
Lowering it to 0.5 would further widen the headshot incentive.
The Zombie_Skull_Multiplier field holds the value 1.1.
A headshot against a zombie deals 110% of the base 99 damage, producing 108.9 damage before resistances.
This is the same skull multiplier used in the player damage block.
The value is identical across all four bows.
The zombie skull hitbox on a forward-leaning zombie model is positioned lower and more forward than the skull hitbox on an upright player, which changes where the player must aim but does not change the damage multiplier applied to a successful hit.
The steep contrast between the 1.1 skull multiplier and the 0.3 limb multipliers creates a zombie damage model where the difference between hitting the head and hitting anything else is extreme.
The ratio between Skull damage (108.9) and Arm or Leg damage (29.7) is 3.67 to 1.
This gradient is how the game communicates to the player, through its damage system, that zombies require precision headshots and that firing arrows at their bodies is an inefficient use of limited ammunition.
For a modder, raising the skull multiplier above 1.1 would exaggerate this incentive further.
A multiplier of 1.5 would make headshots deal 148.5 damage, making the weapon a dedicated precision tool where one headshot is dramatically more effective than any realistic number of body shots.
Lowering the skull multiplier to 1.0 would eliminate the headshot bonus against zombies entirely, making every hit zone equally effective -- a design choice that would make the weapon much more forgiving but would remove the skill-expression element from PvE combat.
The computed per-zone damage values against zombie targets are:
| 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 |
These values are identical across all four bows in the vanilla game data.
The Pine Bow's advantage in zombie combat is not in how hard each individual arrow hits, but in how reliably it lands those hits on the intended zone at range.
The Pine Bow's 0.05 aiming spread means that when the player's crosshair is centred on a zombie's head at 100 metres, the projectile has a much higher probability of actually striking the head hitbox than if the player were using a Birch Bow with its 0.15 spread.
Over the course of clearing a zombie-infested area, the Pine Bow's accuracy advantage translates to more headshots landed, more of the 108.9 damage values delivered, and fewer shots wasted on low-value limb hits at 29.7.
The per-hit damage numbers are the same as any other bow -- but the rate at which the high-value numbers are achieved is better with the Pine Bow.
Animal damage
The animal damage block defines the Pine Bow's damage output against animal-type entities.
Animals in Unturned include deer, wolves, bears, pigs, cows, reindeer, and any other creature tagged as belonging to the animal entity category in the game's entity type system.
Like the zombie damage block, the animal damage block uses a completely separate base damage value and a separate set of per-zone multipliers from both the player and zombie blocks.
The three damage profiles -- player, zombie, and animal -- are fully independent of each other, and changing a value in one block has no effect on the other two.
The animal entity rig uses a simplified three-zone hitbox model: Skull, Spine, and Leg.
There is no separate Arm hitbox on animal models because the animal skeletal structure does not define arm collision bones.
The field Animal_Arm_Multiplier, if it happens to be present in an asset file, is simply ignored by the engine when it processes an animal hit.
Adding the field has no effect, and removing it has no effect.
The animal damage profile is identical across all four bow variants.
The Pine Bow is an effective hunting weapon because the animal multipliers are more generous than the zombie multipliers, making body shots and leg shots viable for bringing down game animals without requiring precise headshot placement on a moving target.
Combined with the Pine Bow's long 160-metre range and tight 0.05 spread, these forgiving multipliers make it the strongest wooden bow for hunting scenarios where the target is moving erratically at medium to long range.
| Field | Value |
|---|---|
| Animal_Damage | 99 |
| Animal_Leg_Multiplier | 0.6 |
| Animal_Spine_Multiplier | 0.8 |
| Animal_Skull_Multiplier | 1.1 |
The Animal_Damage field holds the value 99.
This is the same base value used in the zombie damage block.
The game treats animals and zombies as PvE target types that share the same base damage ceiling.
The value of 99 means every arrow strike against any animal entity starts from this base before the specific zone multiplier is applied.
The equality between the zombie base and the animal base is a consistent design choice: a weapon's raw PvE power is the same whether the target is an undead creature or a wild animal.
What changes between the two entity types is not the base damage, but the zone multipliers, which create different incentives for where on the target the player should aim.
All four bows share this 99 animal base damage.
For a modder, the animal base damage is the tuning knob for how quickly the weapon dispatches wildlife.
Raising it to 120 would make the bow a dedicated hunting implement that drops game animals faster.
Lowering it to 70 would make hunting require more arrows per animal.
Because the animal block is independent, a modder can create a hunting-specialised variant by raising Animal_Damage and leaving Zombie_Damage and Player_Damage at vanilla values, producing a weapon that is powerful against wildlife but balanced against zombies and players.
The Animal_Leg_Multiplier field holds the value 0.6.
This is exactly double the zombie leg multiplier of 0.3 and exactly equal to the player leg multiplier of 0.6.
A leg shot against an animal deals 60% of the base 99 damage, yielding 59.4 damage before any species-specific resistances.
Animal leg hitboxes are proportionally large relative to the animal's total body size, especially on quadruped models like deer, wolves, and bears where the four legs constitute a significant portion of the visible silhouette from most shooting angles.
The generous 0.6 multiplier ensures that shots aimed at the lower body of a moving animal are not severely penalised.
This is important in a hunting context where animals move erratically, change direction frequently, and present their leg profiles more often than their head or torso profiles.
The leg multiplier is shared across all four bows.
For a modder, raising it to 0.8 would make leg shots nearly as effective as spine shots, making the weapon extremely forgiving for hunting where precision is difficult.
Lowering it to 0.4 would reintroduce some of the precision requirement present in the zombie damage model, making hunting more skill-dependent.
The Animal_Spine_Multiplier field holds the value 0.8.
This matches the player spine multiplier and is higher than the zombie spine multiplier of 0.6.
A centre-mass body shot against an animal deals 80% of the base 99 damage, producing 79.2 damage.
The animal spine hitbox is the largest individual hit zone on most animal models, covering the torso from the base of the neck all the way to the hindquarters.
On a deer, the spine hitbox spans nearly the entire length of the animal's flank.
On a bear, the spine hitbox covers the broad, tall torso.
The 0.8 multiplier means that a shot placed anywhere within this large and forgiving target zone deals substantial damage, making hunting accessible even for players who are not consistently landing well-aimed headshots.
This design choice -- a generous spine multiplier paired with a generous leg multiplier -- makes the animal damage model the most forgiving of the three damage profiles in the Pine Bow's asset file.
The value is shared across all bows.
A modder looking to make hunting more challenging could lower the animal spine multiplier to 0.6, bringing it in line with the zombie spine multiplier and making body shots against animals less rewarding.
The Animal_Skull_Multiplier field holds the value 1.1.
A headshot against an animal deals 110% of the base 99 damage, producing 108.9 damage.
This is the same skull multiplier used against players and zombies -- the headshot bonus is 1.1 regardless of target type.
The animal skull hitbox varies significantly by species.
A bear has a large, broad head that is relatively easy to hit from most angles.
A deer has a smaller head that moves quickly as the animal darts, stops, and changes direction unpredictably.
A wolf has a medium-sized head that sits low on a hunched-forward body posture.
The multiplier does not change per species, but the practical difficulty of landing that 1.1 headshot varies with the animal's size, movement pattern, and behaviour.
All four bows share this 1.1 animal skull multiplier.
For a hunting-specialised modded variant, raising the animal skull multiplier to 1.5 would make headshots deal 148.5 damage, creating a weapon where the reward for a precise shot on a deer's small, moving head is dramatically higher than the reward for a body shot.
This would reward skilled hunters without changing the weapon's performance against players or zombies, because the damage blocks are independent.
The computed per-zone damage values against animal targets are:
| Hit zone | Multiplier | Damage (base 99) |
|---|---|---|
| Skull | 1.1 | 108.9 |
| Spine | 0.8 | 79.2 |
| Leg | 0.6 | 59.4 |
These three values are identical across all four bows.
The Pine Bow's advantage in hunting is its range and accuracy, not its per-hit damage numbers.
A player tracking a deer across the open highlands of the Ireland map benefits from the Pine Bow's 160-metre effective range, which allows engagement from further away than with a Birch Bow at 130 metres or a Maple Bow at 145 metres.
The tighter 0.05 aiming spread means the arrow is more likely to land on the intended hit zone even at the far end of that range window, where a small angular deviation in the spread cone translates to a large displacement at the target's position.
Against a sprinting, direction-changing deer at 120 metres, the Pine Bow's combination of range and spread gives the hunter a higher probability of landing a clean spine or skull hit than any other wooden bow.
This mechanical advantage exists despite the damage numbers being identical across the family.
Handling
The handling block controls what the player feels when they fire the Pine Bow.
Unlike the damage blocks which control mechanical output (how much health the target loses), the handling block controls sensory input: how the camera moves after each shot, how much the crosshair expands, and how much the screen shakes during the firing animation.
These fields do not directly alter projectile trajectory beyond the aiming spread cone.
The projectile always flies in a straight line within the cone defined by the spread value.
Recoil shifts the player's viewpoint after the shot, which indirectly changes where the player aims for the next shot by moving the crosshair away from its pre-fire position.
Spread defines the angular radius of the inaccuracy cone: at zero spread, the arrow flies exactly along the crosshair line.
At any positive spread value, the arrow flies in a random direction within a cone whose angle is proportional to the spread value.
Screen shake applies a tiny, rapid camera displacement during and immediately after the firing animation that makes the weapon feel like it has physical weight and impact.
Together, these fields create the weapon's "feel" or "character."
A weapon with wide recoil ranges and high spread feels wild, unpredictable, and hard to control.
A weapon with tight recoil and low spread feels crisp, precise, and responsive to the player's aim.
The handling block values for the Pine Bow are identical to the other wooden bows for recoil and shake, and progressively tighter for spread as the bow tier increases.
The Pine Bow's 0.05 aiming spread is the defining handling advantage that separates it from the less accurate Birch and Maple Bows.
| Field | Value |
|---|---|
| Recoil_Min_X | -5 |
| Recoil_Min_Y | 5 |
| Recoil_Max_X | 5 |
| Recoil_Max_Y | 10 |
| Spread_Aim | 0.05 |
| Shake_Min_X | -0.005 |
| Shake_Max_X | 0.005 |
The Recoil_Min_X field holds the value -5.
In the engine's coordinate system, the X axis corresponds to horizontal camera movement: negative X values move the camera to the left, and positive X values move it to the right.
After the Pine Bow fires an arrow, the engine generates a random horizontal recoil offset between Recoil_Min_X and Recoil_Max_X, and applies that offset to the player's camera position.
The value -5 is the most leftward the camera can be pushed by a single shot's recoil.
Because Recoil_Max_X is 5 (a positive value of equal magnitude), the horizontal recoil range is perfectly symmetric: the camera can be pushed up to five units to the left, or up to five units to the right, with equal probability and magnitude.
This symmetric horizontal recoil pattern is standard across most Unturned ranged weapons.
It means the weapon does not have an inherent directional bias in its recoil -- it does not consistently pull left or right.
All four bows share this identical -5 minimum X recoil value.
For a modder, the horizontal recoil values control the weapon's side-to-side kick character.
To create a weapon that consistently pulls to the left with every shot -- perhaps a damaged or unbalanced variant -- set both Recoil_Min_X and Recoil_Max_X to negative values, creating a recoil range that lies entirely on the left side of the camera.
A weapon with both values negative would always kick leftward and never rightward.
The Recoil_Min_Y field holds the value 5.
In the engine's coordinate system, the Y axis corresponds to vertical camera movement: positive Y pushes the camera upward, and negative Y would push it downward.
After firing, the engine generates a random vertical recoil offset between Recoil_Min_Y and Recoil_Max_Y.
The value 5 is the minimum upward kick per shot.
Because both the minimum (5) and the maximum (10) are positive values, the camera always moves upward after firing and never moves downward.
This upward-only Y recoil follows the universal first-person shooter convention where sustained fire causes the weapon to climb skyward, and the player counteracts this climb by manually pulling the mouse or thumbstick downward between shots to keep the crosshair on target.
All four bows share this 5 minimum Y recoil.
For a modder, setting Recoil_Min_Y to 0 would introduce the possibility of a shot producing zero vertical recoil, which would occasionally make the weapon feel like it did not kick at all on that particular shot.
Setting Recoil_Min_Y to a negative value -- for example, -2 -- would introduce a chance of downward recoil, which is so unconventional that most players would interpret it as a bug rather than a feature.
The Recoil_Max_X field holds the value 5.
This is the maximum rightward horizontal recoil per shot, measured in engine-internal units.
Combined with Recoil_Min_X of -5, the full horizontal recoil range spans from 5 units leftward to 5 units rightward, for a total window width of 10 units.
The engine selects a uniformly random value within this range for each individual shot, so the camera's horizontal displacement varies from shot to shot but is bounded by these Min and Max extremes.
The width of the recoil window -- in this case, 10 units -- determines how unpredictable the horizontal kick feels.
A narrower window, such as -1 to 1, would produce very consistent, easily predictable horizontal recoil where the camera barely moves side to side.
A wider window, such as -20 to 20, would produce erratic, jumpy horizontal recoil where the camera snaps unpredictably far left or right on each shot.
The Pine Bow's 10-unit window is moderate.
All four bows share this value.
For a modder, widening the window to, say, -10 to 10 would double the horizontal unpredictability, making the weapon feel wilder and harder to keep on target during rapid fire.
The Recoil_Max_Y field holds the value 10.
This is the maximum upward recoil kick per shot.
Combined with Recoil_Min_Y of 5, the vertical recoil window spans from 5 units upward to 10 units upward, for a total window height of 5 units.
The vertical window is narrower than the horizontal window (5 units versus 10 units), and it is entirely above zero, meaning the recoil always pushes the camera skyward by some amount between 5 and 10 units.
The uniformity of the recoil values across all four bows suggests that the bow family's recoil profile was authored once and then copied across each variant, rather than individually tuned per bow.
This means recoil is not the dimension on which the bows are differentiated from each other.
The differentiation is in range, spread, and spawn availability.
For a practical modding workflow, recoil values are best tuned by loading the modified weapon asset in a local test game, standing at a fixed distance from a wall, and firing several shots while observing the camera displacement pattern visually, then adjusting the numbers iteratively based on what feels right.
The Spread_Aim field holds the value 0.05.
This is the most impactful single field in the entire handling block.
Spread defines the angular radius of the inaccuracy cone applied to the projectile's launch direction when the player is aiming down sights.
At 0.05, the cone is very narrow: the arrow will fly in a direction very close to the exact crosshair point, with only a small random angular deviation.
The progression of spread across the bow family reveals a deliberate and clean design: Birch Bow at 0.15, Maple Bow at 0.10, Pine Bow at 0.05, and Compound Bow at 0.01.
Each step from Birch to Maple to Pine is an exact halving of the spread value: 0.15 to 0.10 to 0.05.
The Compound Bow then breaks the pattern with a larger jump, going from 0.05 to 0.01 -- a factor of 5 rather than a factor of 2.
The Pine Bow is five times more accurate than the Birch Bow when comparing their spread values directly (0.05 versus 0.15).
At any given range, the Birch Bow's inaccuracy cone covers a cross-sectional area that is several times larger than the Pine Bow's cone, making the Birch Bow projectiles land further from the intended aim point on average.
The Pine Bow's tight spread is its defining mechanical advantage.
While the damage numbers are identical to the other wooden bows, the Pine Bow lands those damage numbers on the intended hit zone more consistently.
At 160 metres -- the Pine Bow's maximum full-damage range -- even a small angular deviation from the spread cone translates to a significant lateral displacement at the target's position, so the tighter spread directly increases the probability of a hit at long range.
The spread value is a float in the asset file.
Any positive number is technically valid.
Setting it to 0.0 would produce a perfectly accurate, laser-beam weapon with no deviation whatsoever.
Setting it to 0.1 would degrade the Pine Bow down to Maple Bow accuracy.
Setting it to 0.2 would make it less accurate than even the Birch Bow.
The spread value interacts multiplicatively with range: as range increases, the cross-sectional area of the spread cone at the target's distance grows, and with a wider base spread, this growth happens faster, making long-range hits geometrically less likely.
The Pine Bow's combination of the longest wooden-bow range (160) and the tightest wooden-bow spread (0.05) means it has the largest effective engagement window of any wooden bow -- it can shoot further and hit more reliably at those distances than its siblings.
The Shake_Min_X field holds the value -0.005.
Screen shake is a subtle, purely cosmetic effect that displaces the player's camera by a very small amount during the firing animation sequence.
The shake is not mechanical recoil; it does not affect where the crosshair settles or where the next projectile will fly.
It exists solely to provide visual feedback that a shot was fired and that the weapon has physical presence.
The value -0.005 is vanishingly small -- a displacement of five one-thousandths of an engine unit to the left at minimum.
Most players will not consciously notice screen shake at this magnitude.
The narrow range, combined with the symmetric spread from -0.005 to 0.005, creates a barely-perceptible side-to-side jitter.
This minimal shake contributes to the Pine Bow's overall character as a crisp, clean-firing weapon with almost no visual noise after each shot.
All four bows share this identical shake range.
For a modder, screen shake is the easiest handling parameter to tune for feel.
Increasing both Min and Max values by a factor of ten -- to -0.05 and 0.05 -- would make the shake noticeable and give the weapon a heavier, more impactful firing sensation.
Keeping the values at the vanilla levels preserves the bow's clean, precise shooting character.
The Shake_Max_X field holds the value 0.005.
Combined with Shake_Min_X of -0.005, the full horizontal shake window spans 0.01 units, centred on zero (the camera's natural resting position).
The shake is purely horizontal: the camera jitters left and right by a tiny amount, but does not move vertically.
There are no vertical shake fields -- no Shake_Min_Y and no Shake_Max_Y -- listed in the extracted asset data for the Pine Bow.
This means either that vertical shake fields are absent from the asset file entirely, or that they are present but set to zero, producing no effect.
The horizontal-only shake profile is consistent with a bow weapon, where the perceived recoil comes from the archer's arm releasing the string forward, which would naturally produce a subtle side-to-side tremor rather than a vertical climb.
For a modder wanting to add vertical shake to the firing feel, the Y-axis shake fields would need to be added to the asset file's handling block and set to non-zero values.
Without those fields present, the engine applies zero vertical shake and the camera remains stable on the Y axis during the firing animation.
Flags
The flags array in an Unturned weapon asset is a JSON array of string values.
Each string in the array is a flag that toggles a specific behaviour, references another asset, or (in some cases) represents a structural artifact of the JSON serialisation format rather than a functional game parameter.
When the engine loads the Pine Bow asset at startup, it iterates through this array and enables or disables weapon behaviours based on which flag strings are present.
A flag is either present in the array (the associated behaviour is active) or absent (the behaviour is inactive).
Flags do not carry parameters, numerical values, or sub-keys.
They are simple single-string tokens whose presence or absence is the entire signal.
Some flags, like Semi, are behavioural toggles that the engine's weapon system reads at runtime to determine fire mode.
Other flags, like the long hexadecimal string, are asset reference pointers that direct the engine to load a separate blueprint asset.
Still other entries in the array -- the square brackets and curly braces -- are not flags at all but rather remainders from the JSON parsing process that ended up in the array as string literals.
The engine does not interpret these bracket characters as functional flags.
Understanding which entries in the flags array are meaningful and which are format artifacts is an important skill for modders reading and editing asset files by hand.
The flags present on the Pine Bow are:
"5ff4bcf752554990bf06e103b996cef2"BlueprintsInputItemsSemi[]{}
The GUID flag "5ff4bcf752554990bf06e103b996cef2" is an asset reference, not a behavioural toggle.
This 32-character hexadecimal string is the GUID of the shared wooden bow blueprint asset.
The blueprint asset defines the crafting recipe that allows players to manufacture a wooden bow from raw materials at a crafting station in a safezone or at a player-built crafting bench.
When the player opens their crafting menu with the necessary materials present in their inventory, the engine resolves this GUID reference, loads the blueprint asset, reads the recipe's ingredient list and output item, and presents the crafting option in the UI.
All three wooden bows -- Birch, Maple, and Pine -- reference this exact same GUID in their flags arrays.
This means the three bows share a single, common crafting recipe.
If a modder edits the blueprint asset at GUID "5ff4bcf752554990bf06e103b996cef2", the recipe change affects all three wooden bows simultaneously.
If a modder wants to give the Pine Bow a unique crafting recipe that differs from the Maple and Birch recipes, they must replace this GUID with a new GUID that points to a new, separate blueprint asset, or they must add a second GUID alongside the existing one.
Removing this GUID flag entirely would make the Pine Bow uncraftable through the standard crafting system, though admin commands, spawn tables, and plugins could still distribute it.
The Blueprints flag is a functional behavioural toggle.
Its presence in the flags array instructs the engine to scan the array for GUID strings and to resolve each GUID it finds against the game's blueprint registry.
If the Blueprints flag is present and a valid blueprint GUID is also present, the engine loads the referenced blueprint and makes the corresponding crafting recipe available to players.
If the Blueprints flag is absent, the engine does not attempt to resolve any GUID strings in the array, even if a perfectly valid blueprint GUID is present.
In that scenario, the GUID sits in the flags list as an inert string with no functional effect.
If a modder adds a new blueprint GUID to the Pine Bow's flags array but forgets to ensure the Blueprints flag is also present, the new recipe will silently fail to appear in-game.
All four bow variants include the Blueprints flag in their flags arrays.
The InputItems flag is a functional toggle related to the crafting ingredient system.
Its presence tells the engine that this weapon asset is eligible to be used as an input item -- a crafting ingredient -- in any blueprint recipe that lists it as a required ingredient.
When the crafting system evaluates a blueprint recipe that calls for a Pine Bow as an ingredient (for example, a recipe that combines a Pine Bow with other materials to produce an upgraded or modified weapon), the engine checks the Pine Bow's flags array for InputItems.
If the flag is present, the Pine Bow in the player's inventory is considered a valid ingredient and can be consumed by the crafting process.
If the flag is absent, the Pine Bow cannot serve as a crafting ingredient, even if a valid blueprint recipe explicitly lists it.
The InputItems flag is present on all four bows, meaning all bows can be used as ingredients in other recipes.
For a modder creating a limited-edition or quest-reward variant that should only be obtainable through one specific method and should never be consumed as an ingredient for other recipes, removing the InputItems flag would block the variant from being used as crafting material while keeping the Blueprints flag active for crafting the variant itself.
The Semi flag is the fire mode selector.
Its presence sets the weapon to semi-automatic fire mode: one activation of the attack input (one mouse click, one controller trigger pull) produces exactly one shot.
After that shot, the player must release the attack input and then activate it again to fire the next shot.
This is the standard and only fire mode for bows in Unturned.
Bows are inherently single-shot weapons that require the player to manually draw and nock a new arrow between shots, and the semi-automatic fire mode models this behaviour at the input level.
All four bow variants carry the Semi flag.
A modder experimenting with alternative fire modes could replace Semi with Auto to create a fully automatic bow that fires continuously while the attack input is held -- though this would produce visually strange results because the bow's draw animation would play rapidly in overlapping succession, and the firerate cooldown of 50 ticks would still be the limiting factor regardless of fire mode.
The Semi flag and the Firerate field interact: even in semi-automatic mode where the player must physically release and re-press the input, the firerate cooldown counter must still reach 50 before the next shot is permitted, so rapidly clicking the mouse faster than the cooldown allows has no additional effect.
Removing the Semi flag without adding a replacement fire mode flag would leave the weapon with no defined fire mode behaviour.
In that state, the engine would fall back to a default -- most likely semi-automatic as the safest and most predictable fallback for weapons that do not explicitly declare a fire mode.
The bracket and brace characters -- [, ], {, } -- are structural artifacts of the JSON serialisation format, not functional flags.
In a properly formatted JSON object, arrays are delimited by square brackets [ and ], and nested objects are delimited by curly braces { and }.
When the terrain or level editor tool serialises the Pine Bow's flags array to disk, these delimiters define the boundaries of the array and its contained objects.
If the tool that parses the asset file preserves the raw flag strings without reconstructing the JSON structure, the opening and closing delimiters can be written into the flags array as literal string entries alongside the actual functional flags.
The engine does not interpret these bracket and brace characters as having any behavioural meaning.
They do not toggle any feature, reference any asset, or affect weapon performance in any way.
They occupy space in the flags array and increase the flag count, but they have zero runtime effect.
A modder reading or editing the asset file by hand can safely ignore these characters, and can also safely remove them from the array as long as the enclosing JSON structure -- the brackets that define the array itself in the file syntax -- remains intact and well-formed.
The four functionally meaningful flags on the Pine Bow are: the blueprint GUID reference ("5ff4bcf752554990bf06e103b996cef2"), the Blueprints toggle, the InputItems toggle, and the Semi fire mode selector.
Everything else in the array is either a format artifact or a placeholder.
Spawn location
Spawn tables in Unturned define where items can appear in the game world and at what probability.
Each spawn table is a named collection of item GUIDs and their associated weights.
A spawn table is associated with a specific geographic region, a building type, a loot container class, or a ground-spawn node category on a particular map.
When the engine needs to populate a loot container -- a crate, a shelf, a corpse, a locker, a ground-spawn pile -- it identifies which spawn table governs that container, sums the weights of every item entry in the table, normalises each item's weight relative to the total, and selects one item at random with probability equal to its weight fraction divided by the total weight.
The result of each roll is independent of every other roll.
A single loot container may trigger multiple rolls on its spawn table, producing multiple items from the same table in the same container.
A container that rolls three times on a table could produce zero Pine Bows, one Pine Bow, or (with extremely low probability) three Pine Bows, depending on how the independent rolls play out.
The probability listed in the spawn data below is the per-roll chance for the Pine Bow specifically.
It describes the outcome of a single, atomic random-selection operation within the spawn table, not the probability that a given container will contain at least one Pine Bow.
| Map | Spawn table | Chance per roll |
|---|---|---|
| Ireland | Cliffs_Castle_Cliffs | 6.667% |
This single-row table defines the Pine Bow's entire natural world-spawn footprint across all official Unturned maps.
The Pine Bow spawns on exactly one map: Ireland.
Within the Ireland map, it spawns in exactly one spawn table: Cliffs_Castle_Cliffs.
The Pine Bow does not spawn naturally on any other map.
It is absent from the default Core maps, including PEI, Washington, Yukon, Russia, Germany, Hawaii, France, and all others.
It does not appear in any general-purpose weapon tables, civilian loot tables, military armory tables, or any spawn context that spans multiple maps.
The Cliffs_Castle_Cliffs table is a regional loot context that is geographically bound to the castle cliffs area of the Ireland map.
When a player enters the castle cliffs region -- the rocky highlands with the ruined stone structures overlooking the coastline -- and opens a container or discovers a loot node linked to this table, the engine performs a roll on Cliffs_Castle_Cliffs.
On each individual roll, the Pine Bow has a 6.667% probability of being selected.
The probability 6.667% means that over a very large number of independent rolls, the Pine Bow will appear in approximately one out of every fifteen rolls on average.
The remaining 93.333% of the table's total weight is distributed across the other items defined in the Cliffs_Castle_Cliffs spawn table -- other weapons, equipment pieces, supplies, and loot appropriate to the castle-themed container context.
The Maple Bow is also present in this exact same spawn table at the exact same 6.667% probability.
Both wooden bows that spawn naturally in the world (the Birch Bow is a crafting-only item and does not appear in any natural spawn table) share the same spawn context, the same table, and the same weight.
Because the two bows have equal weight in the Cliffs_Castle_Cliffs table, they appear with equal frequency over a long sequence of rolls.
A player farming the castle cliffs for bows cannot control which specific wooden bow they will find; they will encounter both Pine and Maple bows at the same rate in the long run.
If a server owner wants to bias the spawn distribution in favour of the Pine Bow over the Maple Bow, they can edit the spawn table's weight values directly.
Doubling the Pine Bow's weight while leaving the Maple Bow's weight unchanged would make the Pine Bow appear twice as often as the Maple Bow in that region.
Removing the Pine Bow's spawn entry from the table entirely would prevent it from spawning through natural means on the Ireland map, leaving crafting and admin commands as the only access pathways.
The 6.667% figure is a per-roll probability, not a per-container guarantee.
Each time the engine evaluates this spawn table to fill a specific loot slot, it performs a fresh, independent random selection.
Rolling the table once has a 6.667% chance of producing the Pine Bow.
Rolling it twice does not double the probability to 13.334%.
The probability that at least one Pine Bow appears across two independent rolls is one minus the probability that neither roll produces the bow: 1 - (1 - 0.06667)^2, which is approximately 12.9%.
The probability that at least one Pine Bow appears increases with each additional roll, asymptotically approaching 100% as the number of rolls grows very large, but it never reaches certainty.
There is always some residual probability, however small, that an arbitrarily long sequence of independent rolls produces no Pine Bow at all.
This is standard independent-probability behaviour and is a property of the engine's spawn system design, not a quirk of the Pine Bow specifically.
Every item in every spawn table in the game operates under the same probabilistic model.
The Ireland-only restriction on the Pine Bow's natural spawning means the weapon is completely absent from the spawn ecosystem on every map that is not Ireland.
Servers running maps other than Ireland will never generate a Pine Bow in any natural loot container, ground-spawn node, or world-drop pile.
If a server owner wants to make the Pine Bow available on a non-Ireland map through natural spawning, they must edit that map's spawn asset file -- or provide a workshop mod that overrides the map's spawn configuration -- and add a new spawn table entry.
The new entry must reference the Pine Bow's GUID, 41873f4fca354e6482b48f7663f22aac, and must assign a weight value.
The weight must be calibrated relative to the summed total weight of all items in the target spawn table.
For example, if a civilian weapons table on the Washington map has a total weight sum of 2000 across all its existing items, and the server owner assigns the Pine Bow a weight of 100, the Pine Bow will have a per-roll probability of 100/2000 = 5%.
A weight of 200 would give it 10%.
The server owner should also consider the flavour and narrative fit of the target table.
Adding a hand-crafted wooden bow to a military armory spawn table makes less thematic sense than adding it to a civilian farm, rural residence, or hunting cabin table.
However, the engine does not enforce any flavour constraints.
The spawn system only cares about GUIDs and numeric weights, and the server owner has complete freedom to place the Pine Bow in any table on any map without restriction.
The Pine Bow's natural spawn situation -- one table on exactly one map at a moderate probability -- defines it as a regional specialist weapon rather than a globally common one.
Players who are familiar with the Ireland map and who know the location of the castle cliffs region can farm that area for bows.
Players on any other map encounter the Pine Bow through crafting (the shared wooden bow blueprint), through trading with other players, through admin intervention (/give [player] 356), or through server plugins that distribute items via kits, shops, crate keys, or vote rewards.
This limited natural availability is part of the Pine Bow's identity within the game's weapon ecosystem, and it should be respected when designing custom loot distributions -- making the Pine Bow globally common would change its character from a regional treasure to a standard-issue weapon.
Canned Beans
The Pine Bow asset contains no Canned Beans data of any kind.
The Pine Bow's sole spawn table, Cliffs_Castle_Cliffs, is a weapon and equipment loot context associated with the castle cliffs geography of the Ireland map.
It does not overlap with, inherit from, or reference any civilian grocery, kitchen, pantry, or general-food spawn tables where Canned Beans items would typically be found.
The Pine Bow asset file itself -- its identity fields, ballistics block, damage blocks, handling block, and flags array -- contains no reference to any bean item, bean GUID, bean calibre, or bean crafting ingredient.
The Pine Bow is a combat and hunting weapon.
It is not expected, by its asset data, to interact with, reference, drop alongside, or craft into any food item whatsoever.
This absence is genuine and makes structural sense within the game's loot architecture.
Weapons and food items live in separate, non-overlapping spawn ecosystems.
A bow discovered in a castle cliff weapon cache will not be sitting next to a can of beans because the castle cliffs spawn table was authored to contain weapons, ammunition, and adventuring equipment -- not civilian groceries.
The Cliffs_Castle_Cliffs table has no bean entries in its item list, no bean weights in its probability distribution, and no bean references in its loot context inheritance chain.
The Pine Bow shares this bean-free status with the Maple Bow.
Both wooden bows that spawn naturally appear exclusively in the Cliffs_Castle_Cliffs table, and neither table contains any food items.
The Birch Bow, as a crafting-only weapon with no natural spawn presence, is also bean-free in its asset data.
Modders who wish to establish a connection between the Pine Bow and Canned Beans -- such as a crafting recipe that requires Canned Beans as an ingredient to create a Pine Bow, or a Pine Bow variant that comes with Canned Beans as a bundled item -- should consider editing the shared wooden bow blueprint at GUID "5ff4bcf752554990bf06e103b996cef2".
Any change made to this shared blueprint asset will affect all three wooden bows (Birch, Maple, and Pine) simultaneously, because they all reference the same blueprint GUID.
Alternatively, a modder can create an entirely new blueprint GUID that is unique to the Pine Bow, assign it to the Pine Bow's flags array alongside or in place of the existing GUID, and define a new recipe that includes Canned Beans in whatever role the modder intends -- as a required ingredient, as an optional catalyst, or as a co-product of crafting.
The lore page at /lore/canned-beans-lore is the canonical reference for all Canned Beans data across the 57 Studios wiki.
Any questions about which items, maps, spawn tables, crafting recipes, or lore events are associated with Canned Beans should be directed to that page.
Practical use for server owners and modders
If your server runs the Ireland map and uses the vanilla spawn configuration, the Pine Bow is already present in the spawn pool, appearing in the Cliffs_Castle_Cliffs table at a 6.667% probability per roll.
No additional configuration steps are needed for players to discover the Pine Bow through normal gameplay in the castle cliffs region.
If you want the Pine Bow to appear more frequently than the Maple Bow within that same region, edit the spawn table weights directly.
Increase the Pine Bow's weight value in the Cliffs_Castle_Cliffs table entry while leaving the Maple Bow's weight unchanged, and the Pine Bow will appear proportionally more often during loot rolls.
If you want the Pine Bow to be available in additional regions of the Ireland map -- civilian farmhouses, militia outposts, general wilderness loot nodes -- add new spawn entries to those tables using the Pine Bow's GUID 41873f4fca354e6482b48f7663f22aac and assign an appropriate weight value based on how common or rare you want the bow to be in that context.
If your server runs any map other than Ireland, the Pine Bow will not spawn through any natural loot system.
To provide the bow to players you have several options.
The shared wooden bow blueprint at GUID "5ff4bcf752554990bf06e103b996cef2" enables players to craft the Pine Bow from raw materials at any crafting station, provided they have the required ingredients in their inventory.
This crafting path functions on every vanilla map because the blueprint asset is part of the base game data and is loaded regardless of which map is active.
Admin commands offer direct delivery: /give [player] 356 places a Pine Bow into the target player's inventory immediately.
Server plugins that manage kits, shops, loot crates, or reward systems can distribute the Pine Bow by referencing item ID 356 or GUID 41873f4fca354e6482b48f7663f22aac.
If you add custom spawn table entries for the Pine Bow on a non-Ireland map, calibrate the assigned weight against the target table's total weight so the bow appears at your intended rarity.
For a common regional weapon that players can expect to find with moderate effort, a weight that yields 10-20% per-roll probability is typical.
For a rare treasure that feels like a special find, a weight yielding 1-3% per-roll is more appropriate.
For a weapon that is meant to be a standard part of the loot ecosystem across the entire map, spread multiple entries across several geographic tables at lower individual weights rather than concentrating the weight in a single high-probability entry.
For modders building a custom Pine Bow variant, begin by duplicating the vanilla Pine Bow asset file into your mod directory.
Generate a new GUID for the duplicate -- this is the most important single step in the creation of a variant, because a duplicate GUID will cause asset conflicts.
Change the item ID to a value in the high 30000 range or above to avoid collisions with vanilla item IDs and with other published mods that also operate in the custom ID space.
The two fields that define the Pine Bow's mechanical identity within the bow family are Range at 160 and Spread_Aim at 0.05.
These are the values that separate the Pine Bow from the Birch Bow (range 130, spread 0.15) and the Maple Bow (range 145, spread 0.10).
When designing a variant, these are the values to modify if the variant should feel like a distinctly different weapon from the vanilla Pine Bow.
A direct upgrade variant could raise Player_Damage from 60 to 80, matching the Compound Bow's base damage against players while keeping the Pine Bow's wooden-bow aesthetic and the rest of its stat profile intact.
A sidegrade variant could push Range up to 200 (matching the Compound Bow's range) while lowering Player_Damage to 50, creating a long-range harassment bow that trades killing power for the ability to engage from distant perches and clifftops.
A PvE-focused variant could raise Zombie_Damage and Animal_Damage from 99 to 130 or higher, making the bow a dedicated zombie-clearing and hunting implement without affecting PvP balance at all, because the player damage block remains unchanged at 60.
Lowering Spread_Aim from 0.05 to 0.01 would give the variant Compound Bow-level accuracy while keeping the wooden bow's lower base damage, creating a high-precision, medium-power weapon that rewards skilled aim without hitting as hard as the Compound Bow per connected shot.
The shared blueprint GUID "5ff4bcf752554990bf06e103b996cef2" in the flags array means the Pine Bow's crafting recipe is currently not unique.
If the variant should have its own separate crafting recipe, change this GUID to a new value that points to a new, custom blueprint asset.
If the variant should not be craftable through the standard crafting system at all -- for example, an admin-spawned event reward or a quest-completion-only weapon -- remove the GUID flag and also remove the Blueprints flag to prevent the engine from attempting to resolve any GUID references.
Removing the GUID while keeping Blueprints has no effect because there is no GUID left to resolve.
Removing Blueprints while keeping the GUID also has no functional effect because the engine will not process the GUID without the toggle.
The InputItems flag can be left in place for variants that should be usable as crafting ingredients in other recipes.
Remove it only for limited-edition or irreplaceable variants that should never be consumed by a crafting process.
For spawn distribution design on custom maps: the vanilla Pine Bow uses a 6.667% probability in a single regional table on a single map.
A custom variant that is mechanically stronger should generally be rarer, with a lower per-roll probability.
A variant that is a sidegrade or a cosmetic reskin with unchanged stats can use similar or slightly higher probabilities without disrupting loot balance.
Weight tuning is an iterative cycle: start with a conservative weight, deploy the mod to a test server, observe over multiple play sessions how often players encounter the item, gather feedback, and adjust the weight upward or downward until the spawn rate feels right for the intended role.
The Pine Bow is the strongest of the three wooden bows.
Statistically, it offers the longest range (160), the tightest aiming spread (0.05), and damage output identical to the Maple and Birch Bows.
If you are a server owner deciding which single wooden bow to make available on a map that lacks natural wooden bow spawns, the Pine Bow is the most mechanically capable and player-rewarding choice.
It gives players the best precision-shooting tool in the wooden bow tier without introducing the Compound Bow's higher damage ceiling, its expanded range, or its attachment capability.
If your server also provides access to the Compound Bow, the Pine Bow serves as a natural progression stepping stone.
A player might start with a crafted Birch Bow, graduate to a found Maple Bow in the castle cliffs, upgrade to a found Pine Bow in the same region, and eventually work toward acquiring or crafting the Compound Bow as an endgame weapon.
Each step in this progression offers a clear and tangible improvement in ballistics and handling, even though the damage numbers remain the same across the first three steps.