Maple Bow Data Reference
The Maple Bow (asset Bow_Maple, item ID 353) is a Common-rarity Primary-slot bow available in Unturned. Its GUID is 667ba2f0aba7484888bcfbec2a43798b. The in-game item description reads: Maple bow chambered in Arrows.
This article is a complete data reference for the Maple Bow weapon asset. Every number, every flag value, and every spawn table entry presented here is extracted directly from the game's asset files. Nothing has been rounded, recalculated, estimated, or inferred. The purpose of this article is to explain what each field in the asset file controls, why it has the value it has, how it interacts with other fields, and what happens when a modder changes it. The intended audience is a modder who has never opened an Unturned asset file and who needs to understand not just the raw values but their mechanical meaning and the consequences of editing them.
The Maple Bow occupies the middle tier of the wooden bow family in Unturned. The game ships with four bows, all of which fire Arrows (Caliber 15) and share the same core identity as charge-and-release ranged weapons. The Birch Bow (item ID 355) is the entry-level bow: it has the shortest effective range at 130 metres and the widest aimed spread at 0.15. The Maple Bow (the subject of this article, item ID 353) improves on both axes: range increases to 145 metres and spread tightens to 0.1. The Pine Bow (item ID 356) advances further to range 160 and spread 0.05. The Compound Bow (item ID 357) is mechanically distinct: it uses a different visual model, has range 200 and spread 0.01, and raises the player base damage from 60 to 80. Among the three wooden bows, the Maple Bow sits precisely in the middle on every stat axis. This middle position makes it the reference point for understanding bow balance: modders who want to understand how each stat increment affects weapon feel can study the Birch-Maple-Pine progression and see exactly what each 15-metre range step and each spread halving does to the weapon's combat identity.
The sections that follow walk through every block in the Maple Bow's asset file in the order they appear: identity fields that tell the engine what this item is, ballistics fields that define how it fires, damage profiles for player, zombie, and animal targets, handling fields that control recoil and accuracy, behaviour flags that toggle crafting and fire mode, and spawn data that determines where players find it. Each section begins with a general explanation of what the block as a whole controls, then walks through every field in the block individually, explaining what that specific number means, how it compares to the other bows, and what a modder would change to alter the weapon's behaviour.
Asset identity
Every weapon in Unturned begins with an identity block: a handful of fields that tell the engine what this item is, how it fits into the inventory system, and how other game systems reference it. These fields are the foundation on which everything else -- ballistics, damage, crafting, spawning -- is built. Understanding the identity block is the first step to understanding how the game's asset pipeline works.
When the game engine initialises at startup, one of its first tasks is to traverse the asset directories on disk. For each weapon asset file it finds, it opens the file, reads the JSON or key-value structure, and extracts two identifiers. The first is the asset name, a human-readable string: Bow_Maple. This is the name that appears in the file browser, in debug logs, and in certain developer tools. It is useful for humans who need to find or reference the asset quickly. The second identifier is the GUID, a 32-character hexadecimal string formatted as a standard UUID: 667ba2f0aba7484888bcfbec2a43798b. The GUID is the machine-readable persistent identity. Every cross-reference in the game -- spawn table entries that place the weapon in the world, blueprint recipes that produce it, plugin commands that grant it -- uses the GUID, never the asset name. The engine registers the asset in its internal lookup tables keyed by GUID. When a spawn table says "put the Maple Bow in this loot container," the line in the spawn file contains 667ba2f0aba7484888bcfbec2a43798b, not Bow_Maple. The string Bow_Maple is never used by any automated system.
The GUID is persistent in a way the asset name is not. If a server owner renames the file from Bow_Maple.dat to Weapon_Bow_Maple.dat and moves it three subdirectories deeper into a workshop mod's folder structure, the GUID remains 667ba2f0aba7484888bcfbec2a43798b. Every spawn table that references that GUID continues to produce the weapon. Every blueprint that references it continues to craft it. Every plugin that targets it by GUID continues to find it. The asset name is a label for humans. The GUID is the permanent address for machines. This separation is why generating a new GUID for every custom asset is the single most important step in mod creation. Two assets with the same GUID create a silent conflict: the engine arbitrarily chooses one to load and discards the other. There is no warning in the game client, no error message, and no deterministic way to predict which one wins. If a modder duplicates the Maple Bow file, changes the stats inside, but forgets to replace the GUID, the engine will load either the original or the copy arbitrarily. Sometimes the custom stats appear. Sometimes the vanilla stats appear. The behaviour is undefined and unreproducible from session to session. Generating a fresh GUID eliminates the conflict entirely.
The item ID 353 is the integer that the inventory system uses internally to track this item type. When a player picks up a Maple Bow from the ground or receives it from a command, the game does not write Bow_Maple or 667ba2f0aba7484888bcfbec2a43798b into that player's save data. It writes the integer 353. When the player opens their inventory and the UI needs to display the slot containing the Maple Bow, it looks up item 353 to find the associated icon texture, the localised name string, the description text, and the tooltip colour. When the player drags the bow to a storage container, the container's data records 353. When the server saves and later reloads, every inventory reference to 353 is re-resolved to the current asset that holds that item ID. The item ID is the compact runtime representation of the item type, used everywhere that inventory operations happen.
The item ID is faster for the engine to work with than a GUID. An integer comparison in most programming languages is a single CPU instruction. A 32-character string comparison requires a loop over the characters until a mismatch is found. When the inventory system is processing thousands of items per frame -- stacking, sorting, filtering, searching -- the difference between integer and string comparisons compounds rapidly. The item ID exists as a performance optimisation. It is not meant to be the stable reference. And it is not guaranteed to be stable. If a future game update adds new items between existing IDs, the numbering can shift. A plugin that hardcoded /give 353 might suddenly grant a different item if the indexing was renumbered. For this reason, item IDs are appropriate for immediate, temporary operations: admin commands during a play session, plugin kit definitions that can be updated if the ID changes, test scripts that run once and are discarded. GUIDs are appropriate for persistent operations: spawn table entries that ship with a map mod, blueprint recipe references that must survive game updates, plugin configurations that are distributed to other server owners.
Among the four bow variants, the Maple Bow has the lowest item ID at 353. The Compound Bow is 357, the Birch Bow is 355, and the Pine Bow is 356. The four IDs cluster tightly in the narrow range of 347 to 357, which is typical of items registered as a batch during a single development pass. The order of the IDs does not correlate with the power curve of the weapons. The Compound Bow has the lowest ID (347) but is the most powerful bow by every stat measure. The Birch Bow has an ID of 355 but is the weakest. The Maple Bow at 353 sits numerically between the Compound and Birch but mechanically in the middle of the wooden tier. Item ID ordering is an implementation detail of the order in which the asset files were processed during development, not an indicator of weapon strength or release chronology.
The Rarity field is set to Common. Unturned uses a tiered rarity system that assigns each tier a display colour. The full set of recognised tiers, in ascending order of visual distinction, is: Common (white or grey text), Uncommon (green), Rare (blue), Epic (purple), Legendary (orange or gold), and Mythical (red). The tier name is stored as a plain string in the weapon asset. The colour is applied by the UI rendering system based on a hard-coded mapping from tier name to colour. A weapon with Common rarity renders its name text in white when the player hovers over it in the inventory. A weapon with Epic rarity renders its name in purple. The Mythical tier (red text) is typically reserved for items introduced in special events or as ultra-rare world drops and is the highest visual-tier in the game.
The rarity field is purely cosmetic. It controls only the colour of the item's name in tooltips, inventory grids, and ground-item labels. It does not interact with the spawn system. Spawn rates are determined by weight values in spawn tables, which are separate data structures in map asset files. It does not interact with the damage system. Damage values come from the damage blocks discussed in later sections and are not modified by rarity. It does not affect crafting costs, skill requirements, or any mechanical gate. A Common Maple Bow and an Epic Maple Bow with identical stat values perform identically in combat. The rarity exists to signal value to the player through colour psychology: a white name says "ordinary, replaceable," a purple name says "special, keep this," and a red name says "extraordinary, show this off." That signalling is important for player satisfaction but irrelevant to game balance.
The slot field Primary determines which equipment slot the weapon occupies on the player character. The player's inventory is divided into named equipment slots. The primary slot is designed for two-handed weapons: rifles, shotguns, sniper rifles, light machine guns, and bows. The secondary slot is designed for one-handed weapons: pistols, revolvers, melee weapons, and small tools. Each slot can contain exactly one item. When the player picks up or equips a new primary-slot weapon, the engine checks whether the primary slot is already occupied. If it is, the old weapon is moved to the first available empty slot in the player's main inventory grid. If the inventory is completely full, the item swap may be blocked or the old item may be dropped to the ground, depending on the server's inventory-overflow configuration. This one-item-per-slot constraint means a player cannot carry two primary weapons simultaneously. Equipping a shotgun drops the bow into the backpack. Equipping a sniper rifle drops the shotgun. The player must choose one primary weapon at a time.
The slot assignment also controls keyboard shortcuts. On the default PC control scheme, the 1 key selects the primary slot weapon and the 2 key selects the secondary slot weapon. Pressing 1 brings the bow to the character's hands. Pressing 2 stows the bow and draws the secondary weapon. This binary key mapping means the slot determines the player's muscle memory for weapon switching. A weapon assigned to Primary will always be accessed with the 1 key. If a modder changes the slot to Secondary, the weapon moves to the 2 key and can be carried alongside a rifle. However, this changes the weapon's role in the player's mental model of their loadout. Bows are two-handed weapons visually and mechanically; moving one to the secondary slot may confuse players who expect the secondary slot to contain a pistol or a melee tool.
The description string Maple bow chambered in Arrows. is the localised text that appears in the item's tooltip when the player hovers over it in the inventory. The asset file does not store this exact string. It stores a reference key -- likely something like Description_Bow_Maple -- that the localisation system resolves at runtime. The localisation system maintains a database of string keys mapped to text values for each supported language. When a player with the game language set to English hovers over the Maple Bow, the system looks up the English mapping for Description_Bow_Maple and returns Maple bow chambered in Arrows. When a player with the language set to German hovers over the bow, the system looks up the German mapping and returns the translated string. The weapon asset file never changes regardless of how many languages are supported. To add a translation, a modder creates a localisation file in the appropriate language folder and adds an entry mapping the description key to the translated text. No asset edit is required. This design -- separating data from presentation -- is a standard pattern in game localisation and allows content creators to build assets once and ship them to all languages simultaneously.
Ballistics
The ballistics block is the mechanical core of the weapon. It defines everything about how the weapon fires: how far the projectile travels at full damage, how quickly the weapon can cycle between successive shots, which character animation plays during firing, what kind of ammunition the weapon accepts, and how much ammunition it carries when it first spawns into the world. These seven fields determine the weapon's combat identity more than any other single block.
When the player pulls the trigger on the Maple Bow, the engine executes a sequence of checks informed by these fields. First, it verifies that the firerate cooldown has elapsed (checking the Firerate tick counter). Then, it verifies that ammunition is loaded (checking the loaded-ammunition slot for an item whose Caliber matches the weapon's Caliber). Then, it initiates the firing animation (selecting the animation set identified by the Action string). Then, it spawns a projectile entity at the weapon's muzzle point. The projectile is configured with the weapon's Range value as its damage-falloff threshold. As the projectile flies, the engine tracks its distance travelled. At impact, the engine evaluates the distance: if it is less than or equal to Range, full damage is applied. If greater, falloff begins. Every one of these steps is parameterised by a value in this table.
| Field | Value |
|---|---|
| Range | 145 |
| Firerate | 50 |
| Action | String |
| Caliber | 15 |
| Magazine | 348 |
| Ammo_Min | 1 |
| Ammo_Max | 1 |
Range is 145. This is the distance in metres at which the weapon's projectile damage-falloff begins. The number functions as a threshold, not a cap. When a projectile is fired, the engine records the muzzle position as the launch point. Each physics frame, the engine updates the projectile's position along its flight path and calculates the Euclidean distance from the launch point. At every point along this path, the engine compares the distance-travelled value against the weapon's Range field. If the projectile is travelling and the distance is 145 metres or less, and the projectile hits a valid target, the engine applies the weapon's full base damage, multiplied by the appropriate hit-zone multiplier, then reduced by armour and skills. If the distance is greater than 145 metres, the engine begins applying a damage-falloff function. The function reduces the impact damage as distance increases beyond the range threshold. The falloff is a curve, not a sudden drop. Damage does not go from 100% to 0% in a single metre. It decreases progressively as the projectile travels further past the 145-metre mark. The exact shape of the falloff curve -- whether it is linear (damage decreases by a fixed amount per metre), exponential (damage halves at a set distance past the threshold), or uses a custom easing function -- is an engine-level parameter configured in the game's core files and is not exposed in the individual weapon asset. The Range field only controls the threshold distance at which falloff begins. It does not control falloff rate, projectile lifetime, or maximum travel distance.
Among the four bows, the Maple Bow's range of 145 places it in the middle of the family. The Birch Bow has the shortest range at 130 metres. The Pine Bow reaches 160 metres. The Compound Bow extends to 200 metres. The three wooden bows form a clean arithmetic progression: each step up adds exactly 15 metres. The Birch-to-Maple gap is 15 metres. The Maple-to-Pine gap is also 15 metres. The Compound Bow breaks the pattern with a 40-metre jump from the Pine, moving from 160 to 200. The consistency of the 15-metre increments among the wooden bows suggests intentional tier balancing. A developer chose 15 metres as the meaningful step size for bow range upgrades -- enough to matter in gameplay (a player with a Maple Bow can engage targets 15 metres farther before damage falloff than a Birch Bow user, which is roughly the width of a small building in the game's scale) but not so large as to make each tier a completely different weapon.
For a modder, Range is a single integer field. Changing it is a one-line edit. Setting it to 160 makes the Maple Bow match the Pine Bow's effective distance, giving it tier-3 wooden bow range while keeping its tier-2 accuracy (Spread_Aim of 0.1 rather than 0.05). Setting it to 130 demotes it to Birch Bow range, making the weapon perform worse at distance than other Maple Bows. Setting it to 200 gives it Compound Bow range, which is a dramatic upgrade that makes the weapon competitive at sniper-like distances. There is no validation on the value by the asset loader. Any positive integer is accepted. A Range of 500 creates a bow whose arrows travel half a kilometre at full damage, far beyond the render distance of most Unturned maps and effectively eliminating damage falloff as a factor in normal gameplay. A Range of 5 creates a bow whose arrows begin losing damage almost immediately after leaving the string, making it a point-blank weapon. The practical ceiling is set by the map's draw distance setting and the projectile's maximum lifetime (in seconds or in absolute distance), both of which are engine-level configurations. The practical floor is set by the minimum distance at which the weapon remains useful for its intended role.
The Range value interacts with the Spread value in a relationship that defines the weapon's effective combat envelope. A weapon with a long Range and a loose Spread presents a frustrating experience: the arrow maintains full damage at long distance, but the probability of the arrow actually hitting the intended target at that distance is low because the spread cone has grown wide. The weapon's theoretical damage output at range is high (full base damage times the multiplier), but its practical damage output is low (the arrow misses). Conversely, a weapon with a short Range and a tight Spread wastes the accuracy: the arrow reliably hits exactly where aimed, but the damage falls off so quickly that hitting from a safe distance is ineffective. A well-balanced weapon has a Range and a Spread that complement each other such that a skilled player can hit targets consistently at the weapon's maximum effective range. The Maple Bow's combination of Range 145 and Spread 0.1 represents one designer's answer to this trade-off for the middle-tier wooden bow.
Firerate is 50. This is an internal tick-count cooldown, not a rate expressed in shots-per-second or rounds-per-minute. Understanding this value requires understanding the game's physics tick. Unturned runs on a fixed-timestep simulation loop. Each iteration of this loop, called a physics tick, advances the game state: projectile positions are updated, collision checks are performed, damage is applied, and weapon cooldowns are decremented. The length of each tick is fixed at a value configured in the engine, typically tied to a target framerate on the server. The weapon's Firerate field stores the number of ticks that must elapse between successive shots from this weapon.
The mechanism operates as follows. When the Maple Bow fires a projectile, a shot-cooldown counter on the weapon's runtime state resets to zero. Each subsequent physics tick, regardless of what the player is doing, the counter increments by one. If the player pulls the trigger and the counter is less than 50, the trigger input is discarded. Nothing happens. No sound plays, no animation initiates, no projectile spawns. The input is silently ignored. When the counter reaches a value of 50 or greater, the next trigger pull is accepted. The weapon checks ammunition, plays the animation, spawns the projectile, and resets the counter to zero. The firerate is therefore the enforced minimum delay between shots, measured in ticks.
All four bows share the Firerate value of 50. They all enforce the same minimum tick delay between shots. The effective rate of fire, however, is also constrained by the bow's charge mechanic. Drawing a bowstring involves pressing and holding the fire button to charge the shot, waiting for the draw animation to complete, then releasing the button to fire. This charge cycle takes a certain amount of time that is controlled by animation data in the animation controller and charge-speed parameters in the weapon's animation configuration, neither of which appear in the weapon asset file. If the charge cycle takes longer than 50 ticks from button-press to arrow-release, the effective rate of fire is limited by the animation, not the firerate. Reducing Firerate from 50 to 25 would have no observable effect because the draw animation cannot complete in 25 ticks anyway. If the charge cycle takes fewer than 50 ticks, the firerate is the limiting factor: the weapon fires, the player re-draws the string faster than the cooldown, and then the player must wait for the tick counter to reach 50 before the next trigger pull registers.
For modders, the implication is that increasing fire rate on a bow is potentially a two-step process. First, lower Firerate to reduce the tick cooldown floor. Second, adjust the draw animation speed or charge time in the animation configuration files to ensure the draw cycle completes faster than the new cooldown. If only the firerate is changed and the draw animation remains slow, the change has no effect. If only the animation is sped up and the firerate stays at 50, the weapon still pauses for 50 ticks after each shot regardless of how fast the bowstring is drawn. The two systems interact, and tuning one without the other may produce no observable change.
Action is String. This is a case-sensitive string identifier passed to the game's animation controller to select which set of character animation clips to play during weapon handling. The animation controller is the subsystem that blends skeletal animation clips on the player character's armature based on the current weapon state -- idle, aiming, firing, reloading, switching weapons. Each weapon type has a named set of animation states associated with an action string. The String action type selects the bow animation set.
When the player equips a weapon with Action: String, the animation controller loads the following animation state machine: an idle pose where the character holds the bow frame in the off-hand with the bowstring forward; an aim-down-sights transition that brings the bow up to eye level; a draw animation where the dominant hand reaches back, grips the bowstring, and pulls it toward the anchor point near the cheek or ear; a hold-at-full-draw loop that sustains the drawn position while the player holds the fire button; and a release animation where the hand snaps forward, the bowstring moves to the resting position, and the character's body settles back into a ready pose. This set of animations is used by all four bows in the game.
The string comparison performed by the animation controller is exact. String with a capital S is the correct value as it appears in the game's action-type registry. Typing string (all lowercase), STRING (all uppercase), or any other variation causes the controller to search its registry for a matching key, find none, and fall back to a default state. The default state typically renders the weapon model in the character's hands but plays no animation. The character stands motionless in the idle pose while the weapon moves as if it were being carried. The weapon can still fire -- the ballistics system does not require animation to function -- but the visual experience is that the character freezes while arrows silently fly from the bow. This is one of the most commonly reported bugs from new modders creating a custom weapon for the first time. The fix is always the same: correct the spelling and case of the Action field. One mistyped character breaks the entire animation binding.
Other action types exist in the game for other weapon categories. Trigger selects the pistol/rifle animation set: a simple trigger-pull finger movement, a brief recoil jolt, and a return to idle. Pump selects the pump-action shotgun set: a forearm cycling the pump mechanism backward then forward between shots. Break selects the break-action rifle/shotgun set: the barrel hinging open during reload, a shell ejection or insertion, and the barrel snapping closed. String is unique to bows. If a modder applies Pump or Break to a bow, the animation will look wrong because the character model will be trying to pump a non-existent slide or break open a non-existent hinge. Conversely, applying String to a rifle would cause the character to attempt a bow draw with a weapon that has no string. The Action field must match the weapon category.
Caliber is 15. This is the ammunition type index in the game's caliber system. Unturned organises all ammunition into categories: Rifle, Civilian, Arrows, Shells, High-Caliber, and a few others. Each category is assigned a unique integer. The value 15 is the Arrow ammunition category's index. When the weapon's Caliber field is 15, it accepts any ammunition item whose own Caliber field is also 15. The caliber system is a simple filter: at ammunition load time, the engine retrieves the ammunition item's caliber integer and the weapon's caliber integer, and if they are equal, the load proceeds. If they are unequal, the load is rejected and the player sees some form of "wrong ammo" feedback (the exact feedback varies by game version but typically prevents the ammunition from being loaded into the weapon).
All four bows use Caliber 15. A stack of Arrow items of any variant (348, 351, 352, 347) can be fired from any bow. The interoperability is by design: bows are a weapon category defined by their shared ammunition type. The player does not need to distinguish between "Birch Bow Arrows" and "Maple Bow Arrows." Any Arrow item works in any bow. This simplifies inventory management for the player and simplifies asset authoring for the modder.
If a modder creates a new ammunition type -- say, "Poison Arrows" that apply a damage-over-time effect on hit -- they have two design options. Option one: assign the new ammunition item Caliber 15 alongside the existing Arrow types. The Poison Arrows now work in all bows, including the Maple Bow. The weapon's existing Arrow items also still work. The player can choose between standard and poison ammunition for any bow. Option two: assign the new ammunition item a novel Caliber value, such as 25, and change the Maple Bow's Caliber to 25 as well. The Maple Bow now only accepts Poison Arrows and rejects standard Arrows. Other bows at Caliber 15 cannot use Poison Arrows. This creates an exclusive weapon-ammunition bond: the Maple Bow becomes "the poison bow" and is defined by its unique ammunition. The caliber system supports both inclusive and exclusive designs, depending on whether the caliber integers match.
Magazine is 348. This is the item ID of the Arrow item that the weapon spawns with pre-loaded when it enters the game world. The term "Magazine" for a bow is slightly misleading because bows do not have detachable box magazines. In Unturned's internal terminology, the Magazine field stores the item ID of the default ammunition type that comes loaded in the weapon. For firearms, this is often a magazine item: a separate inventory object that attaches to the weapon and provides ammunition capacity. For bows, the Magazine field points directly to the Arrow item itself, because the bow loads arrows individually without a magazine intermediary.
When the Maple Bow spawns -- whether from a loot roll in the Cliffs_Castle_Cliffs spawn table on Ireland, from the /give 353 admin command, or from a plugin kit distribution -- the game creates the weapon entity and then immediately checks the Magazine field. It looks up the item definition for ID 348, creates one instance of that item, and places it in the weapon's loaded-ammunition slot. The bow is now "chambered" with one Arrow and ready to fire. The player who picks up the bow can fire immediately without needing to own separate Arrow items. This one-free-arrow mechanic is standard for all ranged weapons and ensures that a freshly spawned weapon is usable without the player also needing to find ammunition separately.
The Magazine IDs differ across the four bows. The Birch Bow uses Magazine 351. The Maple Bow uses 348. The Pine Bow uses 352. The Compound Bow uses 347. These are four distinct Arrow item definitions, each with its own item ID. All four share Caliber 15, making them mechanically interchangeable. The differences likely reflect version history: an Arrow item was defined at one point with ID 347 for the Compound Bow, then duplicated with different IDs as each wooden bow was added during development. The specific Arrow sub-type does not affect gameplay. Once the arrow is fired, its specific item ID is forgotten. What remains in the player's inventory after the shot is the result of hitting or missing the target, not the origin of the ammunition. The Magazine field only controls the pre-loaded arrow at spawn time. After the first shot, the weapon is empty and the player reloads with whatever Arrow items they carry, regardless of which Magazine ID those arrows originally had.
Ammo_Min is 1 and Ammo_Max is 1. These two fields define the range from which the engine randomly samples the number of ammunition rounds to load at spawn time. The sampling works as a uniform random integer draw, inclusive of both bounds. For a pistol that spawns with a magazine partially loaded, Ammo_Min might be 8 (never spawn with fewer than 8 rounds) and Ammo_Max might be 15 (never spawn with more than 15 rounds). Each individual spawn of that pistol draws a random integer from the set {8, 9, 10, 11, 12, 13, 14, 15}, each equally likely, and loads that many rounds. This creates variety in how "ready" a freshly-found weapon feels. A pistol with 15 rounds is a lucky find. A pistol with 8 rounds is still serviceable but less immediately useful.
For the Maple Bow, both values are 1. The sampling range is {1}, which contains exactly one value. Every spawn loads exactly one Arrow, with no variation. This is the standard configuration for bows. A bow fires one arrow per shot and must be manually reloaded after each shot by the player acquiring and loading a new arrow from their inventory. The weapon does not have a continuous magazine feed. Loading two arrows into a bow at spawn time would not give the bow a two-shot burst or a two-round magazine. The player would fire the first arrow, then the weapon's loaded-ammunition slot would contain the second arrow, and the player would fire that one with a second trigger pull after the firerate cooldown elapsed. But there is no mechanical way for a bow to hold multiple arrows simultaneously in the vanilla game without a mod that adds a "quiver" attachment or a custom reload behaviour. The Ammo_Min and Ammo_Max fields at 1 reflect the physical constraint of the weapon type.
Player damage
The player damage block contains the base damage value and the per-hit-zone multipliers that determine how much harm the weapon inflicts on player characters. Every projectile impact against a valid player target runs through this block. The block has six fields: one base value and five multipliers corresponding to the five hit zones the player entity model recognises.
The damage calculation pipeline is a fixed sequence of operations. When a Maple Bow arrow strikes a player, the engine first retrieves the Player_Damage base value from the weapon asset. Next, it determines which hitbox on the player entity was intersected by the projectile's collision volume, mapping the intersection point to one of the five named hit zones. Next, it looks up the multiplier for that zone. Next, it multiplies the base value by the multiplier to produce a raw zone damage number. Next, it applies the target's armour reduction: each armour piece on the target's character (helmet, vest, pants, if they cover the hit zone in question) reduces the damage by a percentage or a flat value configured in the armour's own asset. Next, it applies any active skill modifiers: skill-tree nodes like Sharpshooter or Exercise that the target has trained can further reduce or, in some cases, increase incoming damage. The final number after all these operations is subtracted from the target's health pool. This sequence order is fixed in the engine code and cannot be rearranged through any asset file edit.
| 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 |
Player_Damage is 60. This is the starting point for every damage calculation. It is the value that the multiplier modifies, the value that armour reduces from, and the value that skills further adjust. The number 60 is the nominal damage output of the Maple Bow against an unarmoured, unskilled player target in the game's numeric scale. This number does not directly correspond to hit points subtracted from the target's health because the hit-zone multiplier always applies first. Even a body shot (spine multiplier 0.8) reduces the effective damage to 48 before armour and skills. A headshot (skull multiplier 1.1) raises it to 66. The base value is the theoretical maximum before the zone system modifies it, attainable only if a zone existed with a multiplier of exactly 1.0.
The base damage of 60 is shared by all three wooden bows. The Birch Bow, the Maple Bow, and the Pine Bow all set Player_Damage to 60. Only the Compound Bow differs, with a base of 80. This means the three wooden bows deal identical per-hit-zone damage to players. A Birch Bow headshot and a Pine Bow headshot both deal 66 damage before armour and skills. The tiering between the wooden bows is not expressed through damage output. It is expressed through range (how far the arrow travels at full damage) and spread (how reliably the arrow lands where aimed). A player with a Pine Bow does not deal more damage per hit than a player with a Birch Bow. They simply hit more often (because the tighter spread means fewer arrows sail past the target) and from farther away (because the longer range means full damage extends to greater distances). This design choice means that upgrading from a Birch Bow to a Maple Bow to a Pine Bow is about consistency and effective engagement distance, not about raw per-shot power. The Compound Bow upgrade adds actual damage on top of range and accuracy improvements.
The four multiplier fields are floating-point numbers stored in the asset file. They apply multiplicatively to the base damage. A multiplier of 1.0 means the hit deals exactly the base damage. A multiplier below 1.0 reduces the damage proportionally. A multiplier above 1.0 increases it. The Maple Bow's specific values create a damage gradient across the hit zones that rewards precision and penalises sloppy aim.
Player_Leg_Multiplier of 0.6 means a shot to either leg deals 60% of the base damage. The leg hitbox covers the character model from the hip joint down to the feet, including the thighs, knees, shins, and feet. The hitbox is a contiguous volume; there is no sub-region for thighs versus shins. Any projectile collision with the leg volume applies the leg multiplier. The value 0.6 means the legs are the most resilient part of the player's body against this weapon, absorbing 40% of the projectile's damage as if the target were wearing light armour on that body part. This is consistent with most shooter games' damage models, where leg shots deal reduced damage to prevent "spray and pray" tactics from being as effective as deliberate aim.
Player_Arm_Multiplier of 0.6 is symmetric with the leg multiplier. Arm shots deal the same 60% of base damage. The arm hitbox covers from the shoulder joint to the fingertips. The symmetry between arm and leg multipliers is standard across most Unturned weapons. The game does not distinguish between upper and lower limbs for damage purposes. A shot to the shoulder, the elbow, or the hand all use the same multiplier. This uniformity keeps the damage model simple to understand and reduces the number of distinct fields a modder must populate when authoring a weapon asset.
Player_Spine_Multiplier of 0.8 means a shot to the torso deals 80% of the base damage. The spine hitbox covers the entire central trunk of the body, front and back, from the collarbone area down to the waist. A shot to the chest, the stomach, the upper back, or the lower back all use the spine multiplier. The spine zone is the largest hitbox on the humanoid player model, making it the most commonly-hit zone in combat. The multiplier of 0.8 means the most common hit deals 80% of the weapon's maximum potential, which makes the weapon feel consistent and reliable. A player who aims for centre mass, which is the natural aiming point for most players, deals approximately 48 damage per hit. This is the baseline experience of using the Maple Bow against players.
Player_Skull_Multiplier of 1.1 means a headshot deals 110% of the base damage. This is the only multiplier on this weapon above 1.0, making headshots uniquely valuable. The skull hitbox is the smallest and hardest to hit on a moving player target. The multiplier of 1.1 provides a 10% damage bonus as a reward for landing a shot on this difficult target. The bonus is modest -- a headshot deals 66 compared to a body shot's 48, a difference of 18 -- but in a protracted engagement where both players trade multiple shots, that 10% per-hit advantage accumulates. Two headshots and one body shot deal 66 + 66 + 48 = 180 total damage, whereas three body shots deal 144. The headshot bonus makes aim quality matter without making body shots worthless.
The multiplier values are not validated by the asset loader. The engine reads them as raw floats and plugs them into the damage formula. A multiplier of 0.0 makes that hit zone completely immune to damage from this weapon. Shots to that zone deal zero damage regardless of base value, armour state, or skills. A multiplier of 5.0 makes that zone deal five times the base damage. A multiplier of -1.0 would deal negative damage, which would heal the target. There is no range check, no sanity check, and no clamping. A modder who accidentally types 11.0 instead of 1.1 for the skull multiplier creates a weapon whose headshots deal 60 * 11.0 = 660 damage, which is almost certainly enough to instantly eliminate any player in the game regardless of health pool or armour. The responsibility for providing valid numbers rests entirely on the modder. There is no safety net.
The resulting per-zone damage values, computed from the base value of 60 and the multipliers:
| Hit zone | Multiplier | Damage (base 60) |
|---|---|---|
| Skull | 1.1 | 66 |
| Spine | 0.8 | 48 |
| Arm | 0.6 | 36 |
| Leg | 0.6 | 36 |
The skull value is 66. This is the highest single-hit damage the Maple Bow can deal to a player, and it requires hitting the smallest, most mobile hitbox on the target. The spine value is 48. This is the middle-ground result: a centre-mass shot that any player with basic aim can land reliably. The arm and leg values are both 36. These are the lowest outcomes from a landed hit, representing the penalty for hitting the target's extremities. The ratio between a headshot and a limb shot is 66 to 36, or approximately 1.83 to 1. A headshot deals nearly double the damage of a limb shot. The ratio between a headshot and a body shot is 66 to 48, or approximately 1.375 to 1. A headshot deals 37.5% more damage than a body shot. These ratios define the weapon's aim-dependent damage profile: accurate players are rewarded with up to nearly double damage per shot, while inaccurate players are penalised but not completely invalidated.
For a modder, the player damage block has two independent families of tuning levers. The first lever is the base damage value, Player_Damage. Changing it scales ALL zone damage values proportionally, preserving their relative ratios. Setting it from 60 to 70 changes skull to 77, spine to 56, and arm/leg to 42. Every zone gets a 16.7% increase. The relative power of a headshot compared to a limb shot stays at 1.83 to 1. The second lever family is the individual multipliers. Changing one multiplier affects only that hit zone. Setting Player_Skull_Multiplier to 2.0 changes only the skull value (to 120) while leaving spine at 48 and limbs at 36. The headshot-to-limb ratio becomes 3.33 to 1, more than doubling the original ratio. Setting Player_Leg_Multiplier to 1.0 makes leg shots deal the full 60 base damage, equalising them with the theoretical un-multipliered value. The levers can be combined arbitrarily. A modder can raise the base damage for overall power, then adjust specific multipliers to emphasise or de-emphasise the headshot reward, or to make limb shots more or less punitive.
A structured approach to tuning is recommended over random experimentation. Start by setting all multipliers to 1.0, creating a flat-damage weapon where every hit zone deals the exact base value. Test this weapon in combat. Ask: does the time it takes to eliminate a target feel right for the weapon's intended tier? If the weapon kills too quickly, lower the base. If too slowly, raise it. Once the base power level feels correct, begin adjusting multipliers. Raise the skull multiplier to set the headshot reward. Lower the limb multipliers to set the accuracy penalty. Test after each multiplier change to feel how the damage gradient changes. This methodical approach isolates each change's effect and prevents the "changed five numbers and now the weapon feels wrong but I do not know which number is the problem" situation.
Zombie damage
The zombie damage block is a completely independent damage profile that controls the weapon's effectiveness against zombie entities. It uses its own base damage value and its own set of hit-zone multipliers. The block shares no fields with the player damage block, and changes to one have no effect on the other. This architectural separation allows a modder to create a weapon that feels strong against zombies but balanced against players, or vice versa, without any cross-contamination between the two profiles.
When the engine processes a projectile impact, the first thing it determines is the entity type of the target. If the target is a player, the player damage block is used. If the target is a zombie, the zombie damage block is used. If the target is an animal, the animal damage block is used. The three blocks are read from the same weapon asset file but dispatched to entirely separate code paths based on the target type. This design means every weapon naturally has three different "feel" profiles depending on what the player is fighting.
| Field | Value |
|---|---|
| Zombie_Damage | 99 |
| Zombie_Leg_Multiplier | 0.3 |
| Zombie_Arm_Multiplier | 0.3 |
| Zombie_Spine_Multiplier | 0.6 |
| Zombie_Skull_Multiplier | 1.1 |
Zombie_Damage is 99. This is 65% higher than the player base damage of 60. Even before considering the multiplier differences, the Maple Bow hits zombies harder than it hits players. The higher base is not unique to the Maple Bow -- all four bows share Zombie_Damage of 99 -- and it reflects an intentional game-design asymmetry between the two enemy types. Player-versus-player combat in Unturned is a considered engagement. Both players have access to cover, healing items, armour, and the ability to retreat and reposition. A firefight can last thirty seconds or more as players trade shots, heal, flank, and re-engage. A weapon that deals 60 base damage per shot is appropriate for these extended engagements because each hit is meaningful but not decisive, and the combat tension comes from positioning and resource management rather than raw damage output. Zombies are a different combat paradigm. They are disposable, individually weak enemies that attack in numbers. A single zombie is not meant to be a challenging opponent. The challenge comes from managing groups, avoiding sound-based attraction, and conserving ammunition across many encounters. A weapon that dealt 60 base damage against zombies would feel weak, as if the bow were underpowered for its intended PvE role. By raising the base to 99, the developers ensured that even a body shot against a zombie deals substantial damage, and a headshot is decisive.
The zombie multipliers create a steeper damage gradient than the player multipliers. Zombie_Leg_Multiplier is 0.3, exactly half the player leg multiplier of 0.6. A limb shot against a zombie deals only 30% of the base damage, whereas a limb shot against a player deals 60%. The penalty for hitting extremities is doubled against zombies. Zombie_Arm_Multiplier is also 0.3, symmetric with the leg multiplier as in the player block. Zombie_Spine_Multiplier is 0.6, lower than the player spine multiplier of 0.8. A body shot against a zombie deals 60% of base, whereas against a player it deals 80%. The torso is less forgiving against zombies. Zombie_Skull_Multiplier is 1.1, identical to the player skull multiplier. The headshot reward is the same across both profiles. The pattern is clear when viewed across the four hit zones: non-headshot penalties are doubled or increased against zombies, while the headshot bonus is unchanged. The profile strongly incentivises headshots for zombie combat.
This design reinforces Unturned's zombie-combat doctrine. Zombies walk toward the player in a straight line at a consistent speed. They do not dodge, jump, or take cover. Their heads are relatively large targets compared to the overall body model, and they hold still between movement bursts. The difficulty of a zombie encounter comes from positioning (not letting zombies surround you), resource management (not wasting ammunition on the wrong enemy type), and threat prioritisation (targeting special zombies or screamers first). The damage multipliers ensure that the intended combat behaviour -- "aim for the head" -- produces the most efficient result. A player who sprays centre-mass at a zombie wastes arrows, because the spine multiplier is only 0.6. A player who carefully lines up a headshot is rewarded with the full 1.1 multiplier and dispatches the zombie efficiently. The damage system teaches the player through mechanical consequences rather than through tutorial pop-ups.
The resulting per-zone damage values against zombies:
| Hit zone | Multiplier | Damage (base 99) |
|---|---|---|
| Skull | 1.1 | 108.9 |
| Spine | 0.6 | 59.4 |
| Arm | 0.3 | 29.7 |
| Leg | 0.3 | 29.7 |
The skull value of 108.9 is the highest absolute damage number across all three of the weapon's damage profiles. It exceeds the player skull value (66) significantly and even exceeds the player skull value the Compound Bow would produce (Compound Bow base 80 times skull 1.1 equals 88). The Maple Bow's zombie headshot is the weapon's single most powerful hit in any context. The limb values of 29.7 mean arm and leg shots against zombies deal less than thirty damage. The ratio between a zombie headshot and a limb shot is 108.9 to 29.7, or approximately 3.67 to 1. This ratio is nearly twice the player headshot-to-limb ratio of 1.83 to 1. A headshot against a zombie is nearly four times as effective as a limb shot. This steep gradient makes aim quality vastly more consequential in zombie combat than in player combat.
For modders, the zombie block is a fully independent tuning surface with five degrees of freedom: the base and the four multipliers. The most common modification for PvE-focused servers is to raise the limb and spine multipliers to make zombie combat more forgiving for casual players. Setting limb multipliers from 0.3 to 0.6 (matching the player values) makes a limb shot deal 59.4 instead of 29.7. Setting the spine multiplier from 0.6 to 0.8 makes a body shot deal 79.2 instead of 59.4. These changes transform the zombie profile to be as forgiving as the player profile, making the weapon feel consistent across both enemy types. The base damage can also be adjusted. Raising Zombie_Damage from 99 to 150 makes a skull shot deal 165 and a spine shot deal 90. The weapon becomes a dedicated zombie-clearer that rapidly dispatches individual zombies. Lowering it to 60 aligns zombie damage with player damage.
The opposite direction -- making zombies tougher -- is also valid for servers that want to increase PvE difficulty. Set limb multipliers to 0.1 and spine to 0.4. The weapon becomes highly specialised for skilled players who can land headshots consistently. Players who cannot land headshots will find the weapon nearly useless against zombies and will need to carry a secondary weapon or avoid zombie combat. This creates a high-skill-floor PvE experience that rewards dedicated practice with the bow.
The independence of the zombie and player damage blocks is one of the most important architectural features of Unturned's weapon system. It means a modder never faces a compromise between PvP balance and PvE power. The same weapon can be a "zombie slayer" (high zombie damage, generous multipliers) and a "fair PvP weapon" (standard player damage) simultaneously. The two profiles share no code path beyond the initial projectile-hit event, at which point the entity type check dispatches to the appropriate damage calculator. This clean separation is one of the reasons Unturned's modding community can produce such a wide variety of custom weapons without breaking the delicate balance between player combat and survival combat.
Animal damage
The animal damage block is the third independent damage profile. It controls damage against wild animal entities: deer, wolves, bears, pigs, and other non-zombie, non-player creatures. The animal hit-zone model is simpler than the player and zombie models, with only three recognised zones instead of four.
| Field | Value |
|---|---|
| Animal_Damage | 99 |
| Animal_Leg_Multiplier | 0.6 |
| Animal_Spine_Multiplier | 0.8 |
| Animal_Skull_Multiplier | 1.1 |
The animal damage block has exactly three multiplier fields. There is no Animal_Arm_Multiplier row. This is not a gap in the data extraction or an oversight. Animal entity models in Unturned do not expose a separately targetable "arm" hitbox. Animal skeletons are structured differently from humanoid skeletons. The forelimbs of quadrupeds like deer, wolves, and bears are typically part of the leg hitbox in the animal hit-region map. The engine's animal damage calculator, when invoked after a projectile impact on an animal entity, checks exactly three hit zones: skull, spine, and leg. It does not check for an arm zone because the zone does not exist in the animal entity data. If a modder adds an Animal_Arm_Multiplier field to a weapon's animal damage block, the damage calculator will not read it. The field will be silently ignored. No error or warning is generated. The weapon loads successfully and functions exactly as if the extra field did not exist. This is important for modders who copy damage blocks between entity types. If you copy a player damage block (five multiplier fields) or a zombie damage block (also five multiplier fields) and rename it for animals, you must delete the arm-related multiplier line. The safest workflow is to copy the animal block from an existing vanilla bow, which is guaranteed to have the correct three fields with the correct field names.
Animal_Damage is 99. This matches the zombie base damage. The base damage of 99 is higher than the player base of 60 for the same reason the zombie base is higher: animals are non-player entities. A deer sprinting through a forest canopy or a wolf circling the player in a clearing is a different kind of target than a player strafing behind a rock. Weapons designed around PvP damage values would feel underpowered against animals, making hunting a frustrating chore rather than a viable gameplay loop. The higher animal base damage ensures that hunting with a bow is effective and satisfying. A well-placed arrow from the Maple Bow into a deer's chest does meaningful damage.
The animal multipliers are the most generous of the three damage profiles. Animal_Leg_Multiplier is 0.6, which is double the zombie leg multiplier of 0.3 and equal to the player leg multiplier. A leg shot against an animal deals 60% of the base damage, making it a respectable hit. Animal_Spine_Multiplier is 0.8, which is higher than the zombie spine multiplier of 0.6 and equal to the player spine multiplier. A body shot against an animal deals 80% of the base, making it a strong hit. Animal_Skull_Multiplier is 1.1, the same across all three profiles. The headshot reward is consistent. The overall pattern is that the animal profile is as forgiving as the player profile but applied to a higher base damage number. The result is that every hit against an animal feels powerful.
The resulting per-zone damage values against animals:
| Hit zone | Multiplier | Damage (base 99) |
|---|---|---|
| Skull | 1.1 | 108.9 |
| Spine | 0.8 | 79.2 |
| Leg | 0.6 | 59.4 |
The skull value of 108.9 is tied with the zombie skull value for the highest single-hit damage on this weapon. The spine value of 79.2 is notable: this is more damage than a player headshot from the same weapon (66). A body shot on a deer with the Maple Bow deals 79.2 damage, which exceeds a headshot against a player. This makes the Maple Bow feel powerful and efficient when hunting. The leg value of 59.4 is nearly equal to a player body shot (48). Even a poorly-aimed leg hit against an animal deals damage comparable to a well-aimed body shot against a player. The Maple Bow is a forgiving weapon in the hunting context. A player who is not a skilled archer can hunt with the Maple Bow and still bring down game with body and leg shots. A skilled archer aiming for headshots dispatches animals quickly.
For modders, the animal damage block is frequently tuned for servers where hunting is a major gameplay focus. A PvE server where players hunt for food, leather, and crafting materials benefits from making bows feel effective. Common modifications include raising Animal_Damage above 99 to create a hunting-specialised variant. Setting it to 150 makes the skull value 165, the spine value 120, and the leg value 90. A Maple Bow with these values can dispatch large game (bears, moose) in fewer hits, making hunting more accessible and rewarding. Another common modification is to set all three animal multipliers to 1.0, creating a flat-damage model where every hit deals the full base damage regardless of hit zone. This makes the weapon extremely forgiving for hunting, rewarding any contact at all, and is appropriate for servers where hunting is meant to be easy and enjoyable for all players.
If creating a weapon specifically designed for hunting, the animal block is where the bulk of the tuning effort goes. The player and zombie blocks can remain at vanilla values or even be reduced, making the weapon clearly specialised: exceptional at hunting, balanced in PvP, sub-average against zombies. The three independent profiles make this kind of role specialisation trivially easy to implement. Change three numbers in the animal block, change zero numbers elsewhere, and the weapon has a clear identity.
When creating an animal damage block from scratch, copy the block from an existing vanilla bow to ensure correct field names and count. The field names are case-sensitive and must match exactly what the animal damage calculator expects: Animal_Damage, Animal_Leg_Multiplier, Animal_Spine_Multiplier, and Animal_Skull_Multiplier. Any deviation in spelling or capitalisation causes the field to be ignored and the damage calculator falls back to a default value, which may be 0 (making the weapon deal no damage) or 1.0 (making the weapon deal the full base to that zone). The fallback behaviour is undefined and varies by engine version. Copying from a known-good vanilla asset is the safest approach.
Handling
The handling block controls the physical sensations and accuracy mechanics the player experiences when firing the weapon: camera recoil that displaces the aim point, projectile spread that scatters the shot relative to the crosshair, and screen shake that provides firing feedback. These fields do not affect projectile damage or behaviour after launch. They affect the player's ability to place the projectile on target and the sensory feel of pulling the trigger.
| Field | Value |
|---|---|
| Recoil_Min_X | -5 |
| Recoil_Min_Y | 5 |
| Recoil_Max_X | 5 |
| Recoil_Max_Y | 10 |
| Spread_Aim | 0.1 |
| Shake_Min_X | -0.005 |
| Shake_Max_X | 0.005 |
The four recoil fields define a two-dimensional rectangular sampling region. Every time the Maple Bow fires, the engine draws two independent uniform random numbers. The first is a random X value uniformly distributed between Recoil_Min_X and Recoil_Max_X. The second is a random Y value uniformly distributed between Recoil_Min_Y and Recoil_Max_Y. These two random numbers form a kick vector. The engine applies the X component as an instantaneous angular offset to the first-person camera's yaw (horizontal rotation, left/right aim movement), and the Y component as an instantaneous angular offset to the camera's pitch (vertical rotation, up/down aim movement). The kick is applied in the same frame as the projectile is spawned. The player's crosshair jumps to the new position instantly. The player must then manually correct by moving the mouse, or wait for any residual camera-recovery behaviour (if configured) to gradually settle the aim point back toward its pre-shot position.
The X recoil range runs from -5 to 5, symmetric around zero. The symmetry means the horizontal kick component is equally likely to push the camera left (negative X value) or right (positive X value). On a single shot, the kick could be anywhere from a nearly imperceptible nudge near zero to a significant push of 5 units in either direction. Over a sequence of several shots, the leftward and rightward pushes approximately balance each other, and the weapon's aim point does not develop a persistent horizontal drift. The symmetry reflects the fact that bows are symmetrical weapons with no mechanical lateral bias. A firearm with an asymmetrical recoil pattern (e.g., a rifle that always kicks up and to the right due to the bolt's ejection cycle) would have an asymmetrical X range.
The Y recoil range runs from 5 to 10. Both bounds are positive, meaning the vertical kick component is always upward. The weapon never recoils downward. The magnitude varies between 5 (the gentlest possible kick) and 10 (the most violent possible kick), uniformly distributed. The asymmetry in the Y range -- minimum 5, maximum 10 -- means every shot produces a perceptible upward camera movement. There is no shot where the camera stays perfectly still in the vertical axis. The minimum upward kick of 5 ensures the bow always has a sense of physicality and impact. The range of 5 to 10 creates variability: the player cannot predict exactly how much the camera will jump on the next shot, so recoil compensation is a continuous adjustment rather than a memorised rhythm.
The recoil values use engine-internal angular units. There is no direct mapping from a value of 5 to degrees of rotation, radians, or screen pixels, because the engine's camera system interprets the value through a chain of transformations that depend on the player's field-of-view angle, their display aspect ratio, and possibly their mouse sensitivity multiplier. A 5 on one player's setup may feel different from a 5 on another player's setup with a different FOV. Because there is no reliable unit conversion, modders tune recoil by feel. The standard workflow: equip the weapon in a test environment, stand at a known distance from a wall with a visible reference mark, fire the weapon without touching the mouse, and observe on the monitor how far the crosshair moved relative to the reference mark. If the displacement is too large for the intended weapon identity (a bow should not recoil like a shotgun), reduce the bounds. If the weapon feels like a laser with no sense of physical feedback, increase the bounds. Iterative visual feedback, not calculation, is the tuning method.
Spread_Aim of 0.1 is the projectile spread cone diameter when the player is aiming down sights. This is the single most important field in the handling block, and one of the most important differentiators between the four bows. The spread system works as follows: when the player holds the aim button (right mouse button by default), the game transitions the weapon to the aimed state. In this state, the projectile is no longer fired exactly along the muzzle's forward vector. Instead, the engine constructs a cone with its apex at the muzzle point and its axis along the forward vector. The diameter of this cone, in angular spread units, is Spread_Aim. The engine picks a random direction within this cone and fires the projectile along that direction. The result is that the arrow may deviate from the exact crosshair centre. A smaller spread value makes the cone narrower, making the arrow more likely to land close to the crosshair centre. A larger spread value makes the cone wider, increasing the average deviation.
Among the four bows, the Maple Bow's spread of 0.1 is the second-widest. The Birch Bow has the widest spread at 0.15, making it the least accurate bow. The Pine Bow has 0.05, which is half the Maple Bow's cone diameter and makes it significantly more accurate. The Compound Bow has 0.01, which is one-tenth of the Maple Bow's spread and makes it essentially a laser beam at any practical range. The wooden bow accuracy progression is: Birch (loosest), Maple (middle), Pine (tightest). Each step halves the spread value. The Compound Bow's 0.01 is an order of magnitude tighter than even the Pine Bow, which is why it is considered a different class of weapon rather than just a fourth tier in the same progression.
At the Maple Bow's effective range of 145 metres, the 0.1 spread cone projects a physical cross-section on the target plane. The diameter of this cross-section is proportional to the distance: the further the target, the larger the cross-section. At close range (20-40 metres), a spread of 0.1 produces a cross-section smaller than a player's head, so well-aimed headshots are virtually guaranteed. At mid-range (80-100 metres), the cross-section is roughly the size of a player's torso, so body shots are reliable and headshots are still likely. At maximum range (145 metres), the cross-section may exceed the size of a zombie's head, meaning a non-trivial fraction of crosshair-centred shots will miss the head and strike the body or sail past the target. The Maple Bow is most effective at close-to-mid range, where its spread is tight enough for reliable precision hits but its range is long enough to comfortably out-distance the Birch Bow.
For a modder, Spread_Aim is one of the most impactful single-field changes. Reducing it from 0.1 to 0.05 gives the Maple Bow Pine Bow accuracy while keeping its Maple Bow range of 145 -- the bow becomes a mid-range precision weapon. Reducing it to 0.01 gives Compound Bow accuracy, making the weapon a laser capable of pinpoint headshots at maximum range. Setting it to 0.0 eliminates spread entirely: the arrow always travels exactly along the muzzle's forward vector, landing at the exact pixel the crosshair was on when the trigger was pulled. Setting it above 0.2 makes the weapon noticeably inaccurate, with a significant chance of missing a standing target at medium range. Values above 0.5 produce a scatter-gun effect where the arrow may completely miss a man-sized target beyond near-point-blank range. The spread value communicates to the player how the weapon is meant to be used: tight spreads say "stand back and snipe," loose spreads say "get in close."
Shake_Min_X of -0.005 and Shake_Max_X of 0.005 control brief horizontal screen shake applied on firing. The engine picks a random offset uniformly distributed between these two bounds and applies it to the camera's screen-space X coordinate for a fraction of a second, typically around 100 milliseconds. The shake is purely cosmetic: a subtle screen jitter that provides haptic-like feedback confirming the shot was fired. The shake does not affect the projectile's trajectory (which is governed by Spread_Aim), does not interact with the recoil system (which moves the camera through angular rotation, not screen-space translation), and is not modified by any attachment or skill. The small magnitude of 0.005 means the shake is barely perceptible. The player may notice it as a slight blur or jitter of the screen edges on firing but is unlikely to be consciously aware of it unless they are looking for it.
There are no Shake_Min_Y or Shake_Max_Y fields on this weapon. The screen shake is horizontal only. This is a deliberate design choice. The recoil system already pushes the camera upward on every shot. Adding vertical screen shake on top of upward recoil would stack two vertical movement effects, making the weapon's visual feedback feel chaotic and unpredictable. The horizontal-only shake provides feedback without compounding the existing upward recoil. For a modder, adding vertical shake fields (if the engine version supports them) or increasing the horizontal shake magnitude is an option for weapons that need a more violent feedback profile, such as a heavy crossbow or a ballista.
For modders, the handling block is usually one of the last things tuned, after damage, range, and spawn data are finalised. The workflow is: set damage and range to establish the weapon's combat role, set spread to establish its accuracy identity, and then tune recoil and shake to make the weapon "feel" right. The spread value is the strategic choice that defines the weapon's optimal engagement range. The recoil values are the tactile choice that defines the weapon's physicality. The shake values are the presentational choice that provides firing feedback. Each layer builds on the previous one. A weapon tuned in the opposite order (shake first, spread last) may end up with a spread value that contradicts the feel established by the recoil patterns.
Flags
The flags array is a collection of string tokens that toggle systemic behaviours on the weapon. Flags control whether the weapon has a crafting recipe, what fire mode it operates in, how the crafting system interacts with the player's inventory, and various other engine-level features. The flags block is a flat array of quoted strings. The extraction includes the raw JSON array brackets alongside the functional strings.
The flags present on the Maple Bow:
"5ff4bcf752554990bf06e103b996cef2"BlueprintsInputItemsSemi[]{}
The first functional flag is a GUID string: "5ff4bcf752554990bf06e103b996cef2". When the engine encounters a quoted string in the flags array that matches the hexadecimal GUID pattern (32 characters, hyphenated or unhyphenated depending on the asset version) and the Blueprints system flag is also present, it treats the string as a reference to a Blueprint asset on disk. The engine opens the Blueprint file, reads its recipe definition -- a list of ingredient item GUIDs with required quantities, the output item GUID, any crafting station prerequisites, and any skill level gate -- and registers a crafting route for this weapon. At the crafting menu, the player sees the Maple Bow's recipe entry with the listed ingredients. If the player has the required ingredients in their inventory, the craft button is active. Crafting the weapon costs the ingredients and produces a Maple Bow.
This particular GUID is critical because it is shared. The Birch Bow, the Maple Bow, and the Pine Bow all have "5ff4bcf752554990bf06e103b996cef2" in their flags arrays. All three wooden bows reference the same Blueprint asset file containing the same recipe definition. Changing that recipe -- adding an ingredient, removing one, adjusting quantities, adding a crafting station requirement, adding a skill level gate -- affects all three bows simultaneously. The three bows cost the same resources to craft. Their tiering is expressed through spawn rarity and stat differences (range and spread), not through crafting cost. A modder who wants different recipes for each bow must break this sharing arrangement. The process is: generate a new GUID for the Maple Bow's blueprint reference, create a new Blueprint asset file with that GUID, define the new recipe within it, and change the GUID in the Maple Bow's flags array from the shared GUID to the new one. The original shared blueprint continues to serve the Birch and Pine bows (or the modder can remove their references to it, deprecating the shared recipe).
Blueprints is a system flag that acts as the master switch for the crafting system on this weapon. When Blueprints is present in the flags array, the engine scans the array for GUID-format strings and attempts to resolve each one as a Blueprint asset reference. When Blueprints is absent, any GUIDs in the flags array are treated as inert decorative strings with no functional effect. The weapon has no crafting recipe, regardless of what GUIDs the array contains. The Blueprints flag must be present for crafting to work. Removing it disables crafting for this weapon specifically, even if the Blueprint asset file still exists on disk and other weapons still reference it. The flag is a per-weapon toggle, not a global one.
InputItems is a crafting system flag that tells the crafting engine where to look for ingredients. When a player opens the crafting menu, selects the Maple Bow's recipe, and the game evaluates whether the player can afford the recipe, InputItems directs the system to scan the player's personal inventory. The system iterates through the player's inventory slots, comparing item GUIDs in each slot against the ingredient GUIDs listed in the Blueprint recipe, and tallying the available quantities. If all required ingredients are present in sufficient quantities, the craft button becomes clickable. If InputItems is missing from the flags array, the inventory scan never executes. The craft button stays greyed out permanently, regardless of what the player carries. The recipe is visible in the menu but is uncraftable.
InputItems and Blueprints must both be present for crafting to work. The pair operates as an AND gate: Blueprints says "this weapon has a recipe," and InputItems says "the recipe's ingredients come from the player's inventory." If either flag is missing, crafting fails. Some modders intentionally remove InputItems when they want the recipe to be visible but gated behind an external condition, such as a quest completion flag tracked by a server plugin. In this design, the recipe description text informs the player that they must, for example, "complete the Huntsman quest" before the item can be crafted. A server plugin listens for the quest completion event and then grants the weapon via a scripted /give command, bypassing the crafting menu entirely. The visible recipe with a greyed-out button serves as an advertisement for the external unlock condition.
Semi is the fire mode flag. Semi is a contraction of "semi-automatic." In semi-automatic mode, a single trigger pull produces a single discharge. The player presses the fire button; the weapon fires one projectile. If the player continues holding the button, nothing further happens. The weapon will not fire again until the player fully releases the button and then presses it again. This "one shot per trigger pull, release required between shots" behaviour is the standard fire mode for bows, pistols, most rifles, and any weapon that is not designed for sustained automatic fire.
For bows, Semi maps naturally onto the charge-and-release mechanic. The player presses and holds the fire button to draw the bowstring, releases the button to fire the arrow, and then must press again to begin the next draw. The Semi flag enforces that holding the button after releasing the arrow does nothing. The player must release and re-press. This prevents any accidental multi-shot situations where the bow fires a second arrow immediately after the first because the player was still holding the button.
Other fire mode flags exist: Auto for fully automatic weapons that fire continuously at the firerate while the trigger is held, Burst for weapons that fire a fixed burst of 2-3 rounds per trigger pull, and Safety for weapons that cannot fire at all. Applying Auto to a bow with Action: String produces undefined and likely broken behaviour because the charge mechanic is designed for a deliberate press-hold-release cycle, not for continuous, un-interrupted firing. Bows should always use Semi.
The bracket and brace characters [, ], {, } are JSON array delimiters captured by the extraction tool. [ opens the flags array. ] closes it. { and } would frame individual flag entries if the asset format uses nested object structures for flags instead of a flat string array. These four characters are structural syntax, not functional flags. The engine's JSON parser requires them to delimit the array boundaries. If a modder editing the file by hand deletes or misplaces a bracket character, the JSON becomes malformed and the entire weapon asset fails to parse. The weapon does not load. The client or server log records a parse error at the file path. To add a new functional flag, the correct procedure is to insert the new quoted string between the last existing content flag and the closing ], with a comma separating it from the previous entry. For example, to add a Durability flag: "Semi", "Durability"]. Do not touch the brackets. To remove a flag, delete only the quoted string and its trailing comma. Leave the brackets in place. A broken flags array is one of the most common causes of silent weapon-load failures in modded servers, and the fix is always to open the file in a JSON validator and correct the syntax.
Spawn location
The extracted loot data contains a single spawn entry for the Maple Bow. This one entry represents the weapon's entire natural world-spawn footprint across all vanilla Unturned maps.
| Map | Spawn table | Chance per roll |
|---|---|---|
| Ireland | Cliffs_Castle_Cliffs | 6.667% |
The map is Ireland. Ireland is one of Unturned's officially curated maps. It is set on a temperate island landmass with a rugged coastline, rolling green hills, farmland, small towns, military installations, and a prominent ruined castle perched on seaside cliffs. The map is included with the base game and selectable from the map menu for both single-player and multiplayer server configurations.
The spawn table is Cliffs_Castle_Cliffs. In Unturned's loot architecture, a spawn table is a named collection of item entries. Each entry consists of a GUID (identifying the item) and a weight integer (controlling the relative probability). The table is typically named after a geographic region, a container type, or both. Cliffs_Castle_Cliffs refers to the cliff terrain surrounding the castle ruin on the Ireland map. Every loot container assigned to this region -- ground-spawn nodes that periodically refresh with new items, searchable debris piles, barrel stashes, and possibly the inventories of zombies that naturally populate the area -- references this spawn table in its configuration. When the engine triggers a loot roll for one of these containers (because a player opened it or because a timer expired), it selects exactly one item from the table.
The chance per roll is 6.667%. This percentage is the Maple Bow's share of the total weight in the Cliffs_Castle_Cliffs table. The underlying mechanism is: the engine sums all weight values across all items in the table to compute a total weight. The Maple Bow's weight divided by the total weight equals 0.06667, which converts to 6.667%. The extracted asset data does not provide the raw weight integer for the Maple Bow, nor the weights and identities of the other items in the table. What is known is the result of the ratio: the Maple Bow accounts for roughly 6.667 out of every 100 weight units in the table, or equivalently, 1 out of every 15 weight units. The remaining 93.333% of the total weight is distributed across the other items in the table. The number and identities of those items are not known from this data point.
The 6.667% probability is per individual loot roll. This distinction matters. Each time a container linked to this table is opened or refreshes, the engine performs one independent roll. The probability of success on any single roll is 0.06667. The probability of failure is 0.93333. For a player opening one container, the chance of finding the Maple Bow is 6.667%. For two containers opened, the chance of finding at least one Maple Bow is not 13.334% (which would be a simple additive calculation that double-counts scenarios where both containers produce the bow). The correct calculation uses the complement rule: the probability of at least one success equals 1 minus the probability of zero successes. The probability of zero successes across N independent rolls is (0.93333)^N. For two rolls: 1 - (0.93333)^2, which is approximately 0.1289, or 12.89%. For three rolls: approximately 18.68%. For five rolls: approximately 29.24%. For ten rolls: approximately 49.88%, rounding to roughly 50%. For fifteen rolls: approximately 64.58%.
The long-run expected value is one Maple Bow per 15 rolls, calculated as 1 / 0.06667. But individual outcomes follow a binomial distribution, not a deterministic schedule. A player opening exactly 15 containers is not guaranteed to find a Maple Bow. About 35.42% of players who open 15 containers will find zero Maple Bows. About 38.68% of players will find exactly one. About 19.34% will find exactly two. About 5.76% will find three or more. The weapon's acquisition is probabilistic, not guaranteed. This creates variety in player experiences: some players stumble upon the Maple Bow early in their exploration of the castle cliffs, while others may search the area extensively without finding one. The probabilities smooth out over large numbers of rolls (hundreds of container interactions) but are highly variable at the small sample sizes typical of a single play session.
The Pine Bow shares this exact same spawn table entry. The two bows co-exist in the Cliffs_Castle_Cliffs table. When the engine rolls on this table, both are possible outcomes. If they have equal weight values, they have equal probability of being selected per roll. A player repeatedly looting the castle cliffs area will encounter Maple Bows and Pine Bows with roughly equal frequency over a long enough sampling period. This shared spawn context makes the castle cliffs a concentrated source for mid-tier wooden bows. A player who wants a bow better than the Birch Bow but does not have access to crafting can farm this area.
The restriction to a single map and a single spawn table means the Maple Bow is region-locked to Ireland. Players on Core maps -- Prince Edward Island, Washington, Yukon, Russia, Germany -- never encounter the Maple Bow through natural spawning. Players on other curated maps -- France, Belgium, Rio de Janeiro -- never encounter it. Players on community workshop maps encounter it only if the map author explicitly included spawn entries for the Maple Bow's GUID. If a server runs Ireland, its players have a chance to find the Maple Bow at the castle cliffs. If a server runs any other map, the weapon does not exist in the spawn ecosystem and must be introduced through alternative methods.
To add the Maple Bow to a map that does not include it, locate the map's spawn configuration file on the server. The file is typically in the map's Spawns/ or Level/ directory and has an extension such as .dat or .json. Inside the file, find the spawn table you want to modify. For broad availability, choose a civilian table that many containers across the map reference. For restricted availability, choose a military table accessible only in dangerous areas. Add a new entry consisting of the GUID 667ba2f0aba7484888bcfbec2a43798b and a weight integer. The weight determines the item's probability share within that specific table. If the existing items in the table sum to a total weight of, say, 60, and you add the Maple Bow with weight 6, the new total is 66 and the Maple Bow's probability becomes 6/66, or approximately 9.09%. If you add it with weight 3, the probability becomes 3/63, or approximately 4.76%. The weight value is not an absolute percentage. Always calculate the table's total weight before choosing your weight to achieve the intended probability. For reference, the vanilla probability is 6.667% on a single, location-specific table. To match or exceed this rarity, add the Maple Bow with a weight that produces a similar or higher percentage on each target table.
Canned Beans
The extracted asset data for this weapon contains no Canned Beans data. The Maple Bow's sole spawn table, Cliffs_Castle_Cliffs, is a weapon loot context associated with a castle ruin landmark on the Ireland map. It does not intersect with the spawn tables where Canned Beans items typically appear: civilian grocery stores, kitchen containers, restaurant crates, general food loot pools. The weapon asset file itself -- its identity block, ballistics, damage profiles, handling values, keyboard flags array -- contains zero references to any Canned Beans item GUID. The shared blueprint asset at "5ff4bcf752554990bf06e103b996cef2" defines a crafting recipe for the three wooden bows, and the extracted asset data does not include Canned Beans among the ingredients of that recipe.
This absence is genuine and complete. There is no hidden mechanical connection between the Maple Bow and Canned Beans in the vanilla game data. No obscure spawn table where both items appear together. No secondary loot pool that drops beans alongside the bow. No recipe that consumes beans as part of the bow's crafting cost. The weapon exists entirely within the weapon ecosystem. The beans exist entirely within the food ecosystem. The two systems do not cross.
If a modder wishes to create a connection, the mechanism is the shared blueprint asset. Editing the blueprint file at the flagged GUID and adding the Canned Beans item GUID to the recipe's ingredient list makes Canned Beans a required crafting material for the Maple Bow. Because the blueprint is shared, this change also affects the Birch Bow and the Pine Bow. All three wooden bows would then cost Canned Beans to craft. To make the Maple Bow uniquely require Canned Beans while sparing the other bows, the modder must break the sharing arrangement: assign the Maple Bow a unique blueprint GUID, create a new blueprint asset, and add the Canned Beans ingredient only to the Maple Bow's private recipe.
The lore page at /lore/canned-beans-lore documents the broader role of Canned Beans across the Unturned item ecosystem. It covers spawn locations, nutritional values, healing properties, appearances as crafting ingredients in various recipes, and the item's history as a recurring reference within this wiki.
Practical use for server owners and modders
If your server runs the Ireland map, the Maple Bow is already accessible to players through the Cliffs_Castle_Cliffs spawn table. The 6.667% per-roll probability means players who explore the castle cliffs region encounter the weapon at a moderate frequency. No server-side configuration is required for the weapon to exist in the world. If you want the Maple Bow to be more available, add it to additional spawn tables on Ireland. Farm tables, town civilian tables, and low-tier military tables are common choices. On each added table, choose a weight that reflects the intended rarity: a weight of 3-5 in a moderately populated table produces a medium availability, while a weight of 1 in a densely populated table makes it a rare find.
If your server does not run Ireland, the Maple Bow never spawns naturally and you must introduce it through alternative means. Three standard approaches exist. The crafting route relies on the shared blueprint. Verify that the blueprint is accessible: the required ingredients can be gathered through normal gameplay on your map, the skill required to unlock the blueprint is attainable, and any necessary crafting station exists. The plugin route uses any item-distribution plugin that addresses items by ID. Add item 353 to a spawn kit definition (players receive the bow on join or on respawn), a shop configuration (players purchase it with in-game currency), or a loot crate pool (it drops randomly at a configurable rate). The admin route uses the built-in /give command: from the console or admin chat, /give [player] 353 grants the Maple Bow directly to the named player.
For modders creating a custom Maple Bow variant, a structured workflow produces reliable results. First, duplicate the asset file and name it distinctively, such as Bow_Maple_Custom. Second, generate a fresh GUID using an online UUID generator or command-line tool and overwrite the old GUID. Third, choose a new item ID above 30000 (e.g., 30030) to avoid collisions with vanilla items and popular mods. Fourth, tune the stats to define the variant's identity. The Maple Bow's defining characteristics are its mid-range value of 145 and its mid-accuracy spread of 0.1. A direct upgrade variant raises Range to 160 and tightens Spread to 0.05, matching the Pine Bow. An accuracy-focused sidegrade raises Range to 180 but loosens Spread to 0.15, creating a bow that hits hard at long distance but requires the player to get lucky or get close. A PvE-focused variant raises Zombie_Damage and Animal_Damage to 150 while keeping player damage at 60.
Fifth, decide on the crafting design. If the variant should share a recipe with other bows, keep the existing shared blueprint GUID. If it should have its own recipe, generate a new GUID, create a new blueprint asset, and change the GUID flag in the variant's flags array. Sixth, add spawn table entries on the maps where the variant should appear. Use the 6.667% vanilla reference as a benchmark: match it for comparable rarity, exceed it for broader availability, go below it for a rare find. Seventh, package the asset file, the blueprint (if created), localisation entries, and any model changes into a workshop mod folder.
When tuning damage, remember that the three profiles are independent. Raise zombie and animal values for PvE servers while leaving player values at vanilla for PvP fairness. Raise animal multipliers to 1.0 for a hunting-specialised bow. Lower zombie multipliers to 0.1 for a hardcore survival server where bows are a trap rather than a tool. The profiles do not interact; each can be tuned to its intended context without compromise.
The shared blueprint GUID is a design constraint worth planning around. If your mod adds multiple bows and you want each to have a unique identity, give each a unique blueprint GUID and a unique recipe with different ingredient costs. If your mod adds several sidegrade bows that are all equally viable and differ only in aesthetics or minor stat tweaks, a shared recipe might be appropriate. The vanilla game's design -- three wooden bows sharing one recipe -- communicates "these three bows are the same tier; choose the one whose range and accuracy you prefer." Decide what your modifications communicate and structure the blueprint references accordingly.
Finally, test thoroughly. The most common custom-weapon bugs are a misspelled Action field (weapon equips but no animation plays), a missing Blueprints or InputItems flag (recipe visible but uncraftable), a duplicate GUID (weapon conflicts with an existing asset and randomly fails to load), and an incorrectly formatted flags array (the weapon does not appear in the game at all). Each of these is caused by a one-line typo. Each is fixable with a one-line edit. A five-minute verification in a test environment catches them before the mod ships.