Maplestrike Weapon Reference
The Maplestrike is an Unturned firearm defined by the asset Maplestrike with item ID 363 and GUID 38508a1f73c8417a8a68cb675460d0b6. It is an Epic primary-slot assault rifle chambered in Military ammunition. This reference documents every field a modder reads and edits when working with the Maplestrike in the Unturned editor or in a raw .dat file. It covers the ballistics table, the three damage tables, the handling parameters, the enum flags that control behaviour, and the loot tables the weapon appears in across all official and curated maps.
If you searched for "Maplestrike damage", "Maplestrike spawn", "Maplestrike stats", "Maplestrike GUID", or "Maplestrike item ID", this page is the canonical data reference for what the game files actually contain. It does not tell you how to play; it tells you what the asset declares and how a modder interprets those declarations.
Asset identity
Every gun in Unturned is a .dat asset file. The fields below are read directly from the asset. The key identifiers are:
| Property | Value |
|---|---|
| Asset name | Maplestrike |
| Item ID | 363 |
| GUID | 38508a1f73c8417a8a68cb675460d0b6 |
| Rarity tier | Epic |
| Slot | Primary |
Understanding the .dat asset format
Every item, vehicle, animal, and resource in Unturned is defined by a .dat file on disk. These files sit inside the game's Bundles/ directory tree, packed into .unity3d asset bundle files, one bundle per category. The raw .dat file itself is a plain-text UTF-8 file with a nested key-value structure using curly-brace blocks and bracket-delimited lists. Each field is written as Field_Name Value on its own line. Comments are not supported in the vanilla parser, so modders keep a separate notes file or use the Unturned editor's built-in field tooltips as their documentation.
When the engine starts, it reads every .dat file in the active bundles and builds an in-memory asset registry keyed by GUID. This registry is what the inventory system, loot spawner, crafting manager, and plugin API all query. The asset file is loaded once at startup and never re-read during gameplay, which means hot-reloading edited .dat values requires either a server restart or a workshop mod reload. A modder working on a balance pass typically iterates by editing the .dat file in a text editor, restarting the local singleplayer session, and testing.
To read a raw .dat file outside the editor, a modder uses a standard text editor like Notepad++ or VS Code. The file is not encrypted or obfuscated; every field is human-readable. A modder creating a new variant of the Maplestrike copies the original Maplestrike.dat file, renames it, and edits the fields directly. The Unturned editor provides a graphical interface for these same fields, with dropdowns for enums and sliders for float values, but the underlying data on disk is always the same plain-text format.
The GUID 38508a1f73c8417a8a68cb675460d0b6 is the asset's permanent identity. In plugin code, a developer uses this GUID to look up the asset at runtime. For example, a RocketMod plugin that modifies weapon damage calls Assets.find(EAssetType.ITEM, new Guid("38508a1f73c8417a8a68cb675460d0b6")) to get a reference to the Maplestrike asset object, then reads or writes its fields. The GUID never changes between updates unless the asset is intentionally deprecated and replaced. If a modder clones the Maplestrike, they must generate a new GUID so the engine treats it as a distinct asset; failing to do so causes the clone to silently overwrite the original in the asset registry.
The item ID 363 is the integer that the engine uses in save files, network packets, and spawn-table weight entries. When a player picks up a Maplestrike, the save file records item ID 363 with its current durability, attachments, and magazine state. When the loot spawner selects an item from a weighted table, it resolves the table entry's item ID to an asset and places it in the world. If a server owner edits a spawn table and references item ID 363, they are pointing at the Maplestrike regardless of what the asset file is named.
The rarity tier Epic controls two things: the color of the item name text in the inventory UI, and the loot-pool filtering logic. In the UI, Epic items display with a purple name plate, which signals to the player that the item is high-tier military gear. In the loot system, the rarity tier is one of several properties the engine can use to filter or weight spawn-table entries. A modder who changes the Maplestrike's rarity to Rare would see the name color shift to blue in the UI, but the mechanical behaviour of the weapon would not change unless the spawn tables also respect rarity filtering -- which most vanilla tables do not. Rarity is primarily a visual cue and a loose-tier signal; it does not directly gate damage, durability, or attachment slots.
The asset name is what you type in the editor spawn menu and what appears in spawn-table entries. The item ID is the integer the engine uses internally; it is the value stored in save files and sent over the network. The GUID is a 32-character hex string that uniquely identifies the asset across every map, mod, and server. If you write a plugin that references the Maplestrike by GUID, you use 38508a1f73c8417a8a68cb675460d0b6. The rarity tier controls the colour of the item name in the inventory UI and is one of the factors the loot system uses when deciding which spawn table to roll. The slot determines which inventory row the item occupies.
The in-game description string is: Canadian assault rifle chambered in Military ammunition. This string is read from the asset's Description field and displayed in the inventory tooltip.
Ballistics fields
The ballistics block defines how the weapon fires. Each field is a single float or integer value in the asset file. A modder changing these values changes the fundamental feel of the weapon without touching any visual asset or animation.
Ballistics
| Field | Value |
|---|---|
| Range | 200 |
| Firerate | 5 |
| Action | Trigger |
| Caliber | 1 |
| Muzzle | 3 |
| Magazine | 6 |
| Ammo_Min | 10 |
| Ammo_Max | 30 |
Range
Range is 200. This is the distance, in game units, at which the projectile's damage falloff begins to apply. A modder who wants the Maplestrike to be effective at longer distance would raise this value. A modder making a carbine variant might lower it. The value is a floating-point number in the asset, so 250 or 175 are both valid edits.
Firerate
Firerate is 5. This is the internal tick count between shots. Lower values mean the weapon cycles faster. The Maplestrike's 5 is one tick slower than the Eaglefire's 4, which means the Eaglefire cycles faster in the engine's internal tick system. A modder creating a higher-tier Maplestrike variant might lower this to 4 or 3.
Action
Action is Trigger. This is an enum field that tells the engine which firing mode animation to play and which internal firing logic to use. Trigger means the weapon uses a standard trigger-based firing cycle. When the Auto flag is present (and it is on the Maplestrike), Trigger action combined with the Auto flag produces fully automatic fire. The action value itself does not change between semi-automatic and automatic modes; the flags control the available modes, and Trigger is the action type that supports both.
Caliber
Caliber is 1. This is an enum that maps the weapon to an ammunition type. Caliber 1 corresponds to Military ammunition magazines and boxes. The Maplestrike shares Caliber 1 with the Eaglefire, which means they accept the same ammunition type. A modder changing this to another integer would switch the weapon to a different ammunition family.
Muzzle
Muzzle is 3. This is an enum that controls which muzzle-attachment socket type the barrel uses. A value of 3 means the weapon accepts Military barrel attachments.
Magazine
Magazine is 6. This is an enum that controls which magazine-attachment socket type the weapon uses. A value of 6 means the weapon accepts Military magazines.
Ammo_Min and Ammo_Max
Ammo_Min is 10 and Ammo_Max is 30. These define the range of ammunition the weapon can spawn with when it appears in the world. When the engine places a Maplestrike on the ground from a spawn table, it rolls a random integer between Ammo_Min and Ammo_Max inclusive and fills the attached magazine with that many rounds. A modder who sets Ammo_Min to 30 makes the weapon always spawn with a full magazine.
Understanding the ballistics pipeline in the engine
When the player pulls the trigger, the engine runs a sequence of checks before a projectile is created. First it checks the current firemode flag -- if the weapon is in Safety, the sequence stops and no projectile is created. If the weapon is in Semi or Auto, the engine checks whether the firerate cooldown has elapsed since the last shot. If it has, the engine consumes one round from the magazine, applies the current recoil and spread offsets to the camera, and spawns the projectile at the muzzle position. The projectile then travels in a straight line toward the crosshair direction offset by the spread angle.
The Action enum determines which internal state machine the engine uses for the firing cycle. Trigger action means the weapon uses the standard cycle: on fire-input, play the fire animation, apply recoil, spawn projectile, start cooldown. Other action values exist for pump-action (Pump), bolt-action (Bolt), and break-action (Break) weapons, each with its own animation timing and cooldown logic. Because the Maplestrike uses Trigger action, the firing cycle is immediate on input and the cooldown is purely governed by the Firerate tick count. There is no pump delay, no bolt-cycling animation lockout, and no break-action reload interlock. This is what makes the Trigger + Auto flag combination produce smooth, uninterrupted automatic fire.
The Firerate value of 5 means that once the first shot is fired, the engine waits 5 ticks before the next shot can begin. If the player is holding the fire key and the weapon is in Auto mode, the engine will continue to fire every 5 ticks until the magazine is empty or the fire key is released. In Semi mode, the engine fires one shot and ignores the held key until the key is released and pressed again. The Firemode flags (Auto, Semi, Safety) are a separate system from the Action enum: Action defines the mechanical behaviour of a single shot, while the firemode flags define which firemodes are available and how the engine responds to the fire key being held. A weapon with Action set to Pump cannot meaningfully use the Auto flag because the pump-action cycle introduces a mandatory animation delay between shots regardless of the firerate value.
The Ammo_Min and Ammo_Max system is a world-spawn concern, not a combat concern. Once the weapon is in a player's inventory, the ammo count is whatever the player loaded into it. The Ammo_Min/Ammo_Max range only affects the initial state of a freshly spawned weapon. A server owner who wants to reduce early-game ammunition scarcity on their server might raise Ammo_Min globally on all military weapons; a hardcore server owner might lower Ammo_Max to force players to find separate ammunition boxes.
The Caliber enum value of 1 maps the Maplestrike to the Military ammunition family, which is consumed from Military ammunition boxes and Military magazines. When the player reloads, the engine checks the ammo items in the player's inventory for any that match the weapon's Caliber enum. The ammo item itself also carries a Caliber field, and the match is an integer comparison: if the weapon's Caliber equals the ammo's Caliber, the ammo can be loaded. This is why the Maplestrike and Eaglefire can share ammunition: both have Caliber set to 1. A modder changing the Maplestrike's Caliber to a different integer would make it incompatible with Military ammunition and require the creation of a new ammunition type with the matching caliber value.
The Muzzle and Magazine enum values (3 and 6 respectively) work on the same enum-matching principle as Caliber. Attachments carry a socket enum value, and the engine compares the attachment's socket value to the weapon's corresponding slot value. A muzzle attachment with socket value 3 matches the Maplestrike's Muzzle of 3. A magazine attachment with socket value 6 matches the Maplestrike's Magazine of 6. If a modder changes these enum values, they must also ensure that compatible attachments exist with matching socket values, or the weapon will have no functional attachments for that slot.
Player damage fields
The player damage block defines how much damage each hit of the Maplestrike inflicts on another player, and how that damage is multiplied when the hit lands on a specific body part.
Player damage
| Field | Value |
|---|---|
| Player_Damage | 40 |
| Player_Leg_Multiplier | 0.6 |
| Player_Arm_Multiplier | 0.6 |
| Player_Spine_Multiplier | 0.8 |
| Player_Skull_Multiplier | 1.1 |
Player_Damage
Player_Damage is 40. This is the base damage value before any multiplier is applied. This is identical to the Eaglefire's Player_Damage of 40. Both weapons share the same base damage against players despite the Maplestrike having a higher rarity tier and a different firerate.
Hit-zone multipliers
The four multiplier fields work as follows: when a projectile hits a player, the engine checks which hitbox was struck and multiplies Player_Damage by the corresponding multiplier.
Player_Leg_Multiplieris0.6. A leg hit does 60 percent of base damage.Player_Arm_Multiplieris0.6. An arm hit does 60 percent of base damage.Player_Spine_Multiplieris0.8. A spine (torso) hit does 80 percent of base damage.Player_Skull_Multiplieris1.1. A skull (head) hit does 110 percent of base damage.
The Maplestrike's player hit-zone multipliers are identical to the Eaglefire's across all four zones. A modder balancing the two weapons against each other would look at other differentiating fields (Firerate, Auto flag, recoil pattern, and spawn table availability) rather than damage per hit.
How the damage pipeline processes a hit
When a projectile from the Maplestrike collides with a player entity, the engine does not simply subtract Player_Damage from the target's health. The full sequence is: the engine identifies the hitbox that was struck on the target's ragdoll skeleton, reads the corresponding multiplier for that hitbox from the weapon's asset, multiplies Player_Damage by that multiplier, applies any armour reduction from the target's equipped vest or helmet, checks for any plugin-level damage modifiers, subtracts the final computed damage from the target's health, and broadcasts the damage event to all clients. If the target has armour, the armour's damage-reduction percentage is applied after the hit-zone multiplier but before the health subtraction, which means a Skull hit against a helmeted target can be significantly reduced despite the 1.1 multiplier.
The hitbox detection uses the ragdoll skeleton's bone hierarchy, which varies between the default player model and any custom character models. The engine maps bone names to hit zone categories internally. A modder who creates a custom player model must ensure the skeleton bones that correspond to the skull, spine, arm, and leg hit zones are named correctly, or the damage pipeline will fall back to a default body-hit multiplier (typically 1.0). For the Maplestrike specifically, a missed hit zone match on a custom model would apply the full Player_Damage of 40 without any multiplier reduction, effectively making every hit a high-damage body shot.
The Player_Damage value of 40 is relative to the player health pool defined by the game's configuration, not by the weapon. This is important for modders: changing Player_Damage on the Maplestrike changes how many hits the Maplestrike requires, but it does not change how many hits other weapons require. A modder who wants a global damage rebalance must edit every weapon's Player_Damage individually, or use a server-side plugin to apply a global multiplier to all outgoing damage.
Computed player damage by hit zone
When a modder needs to know the actual damage number that will be subtracted from a player's health on each hit, they multiply the base by the zone multiplier. The table below shows the result for the Maplestrike's base damage of 40.
Player damage per hit zone (computed, use verbatim)
| Hit zone | Multiplier | Damage (base 40) |
|---|---|---|
| Skull | 1.1 | 44 |
| Spine | 0.8 | 32 |
| Arm | 0.6 | 24 |
| Leg | 0.6 | 24 |
Using computed player damage values in practice
A server owner balancing PvP encounters uses these computed values to understand breakpoints. The computed damage numbers tell the server owner exactly how much health a player loses on each hit before armour is applied. For example, a Skull hit deals 44 damage; if the server uses the default health configuration, the server owner knows this is the highest single-hit value the Maplestrike can deliver to a player. A Spine hit deals 32 damage, which is a significant reduction from the headshot value and rewards torso shots with less lethality. Arm and Leg hits both deal 24 damage, meaning that limb shots are mechanically identical for the Maplestrike regardless of whether the hit lands on an arm or a leg.
A plugin developer building a custom damage-feedback system, such as a hitmarker sound that changes pitch based on damage dealt, would read these computed values to set thresholds. The developer might make 44 damage trigger a distinct high-damage hitmarker, 32 trigger a standard hitmarker, and 24 trigger a low-damage hitmarker. By referencing the computed table rather than re-deriving the values in code, the plugin developer avoids hardcoding the multiplier math and reduces the chance of an arithmetic error.
A modder creating a Maplestrike variant with higher damage might raise Player_Damage to a new value and then compute the new hit-zone values using the same multipliers. If the modder sets Player_Damage to a new base, the Skull multiplier of 1.1 continues to apply, and the modder recomputes the table to check that the new headshot value achieves the desired lethality. This is the standard workflow for every damage block in every gun asset.
Zombie damage fields
The zombie damage block is structurally identical to the player damage block, but it applies to hits against zombie entities.
Zombie damage
| Field | Value |
|---|---|
| Zombie_Damage | 99 |
| Zombie_Leg_Multiplier | 0.3 |
| Zombie_Arm_Multiplier | 0.3 |
| Zombie_Spine_Multiplier | 0.6 |
| Zombie_Skull_Multiplier | 1.1 |
Zombie_Damage
Zombie_Damage is 99. This is the base damage per hit against zombie entities and is identical to the Eaglefire's zombie damage value. Both weapons deal 99 base damage to zombies.
Zombie hit-zone multipliers
Zombie_Leg_Multiplieris0.3. A leg hit on a zombie does 30 percent ofZombie_Damage.Zombie_Arm_Multiplieris0.3. An arm hit on a zombie does 30 percent ofZombie_Damage.Zombie_Spine_Multiplieris0.6. A spine hit on a zombie does 60 percent ofZombie_Damage.Zombie_Skull_Multiplieris1.1. A skull hit on a zombie does 110 percent ofZombie_Damage.
Why zombie damage is tuned separately from player damage
The zombie damage pipeline is an independent block from the player damage pipeline because zombie entities have different health pools, different behaviour scripts, and a different hitbox skeleton. The engine does not use the Player_Damage value when the projectile hits a zombie; it uses Zombie_Damage instead. This means a modder can adjust how lethal the Maplestrike is against zombies without affecting its PvP balance at all. A common modding pattern is to raise Zombie_Damage on all weapons in a zombie-survival server pack while leaving Player_Damage at vanilla values, making zombies easier to kill without making PvP more lethal.
The zombie hit-zone multipliers are lower than the player multipliers for limb and spine hits. Where a player limb hit uses a 0.6 multiplier, a zombie limb hit uses a 0.3 multiplier. This means limb shots on zombies are significantly less effective than limb shots on players -- the zombie takes only 30 percent of base damage to an arm or leg, compared to 60 percent for a player. The design intent is to make body and head shots more important when fighting zombies, rewarding accuracy over volume of fire. A modder who wants zombies to feel squishier would raise the Zombie_Leg_Multiplier and Zombie_Arm_Multiplier toward 0.6 to match the player multipliers. A modder who wants zombies to feel tankier would lower Zombie_Spine_Multiplier to force headshots as the only efficient kill method.
The Zombie_Skull_Multiplier of 1.1 is the same as the Player_Skull_Multiplier. Both headshot multipliers are 1.1, which means the engine applies a consistent 10 percent bonus for headshots regardless of whether the target is a player or a zombie. This consistency simplifies balance reasoning for modders: the headshot bonus is a universal constant on this weapon, and the differentiation between PvE and PvP is entirely in the base damage value and the limb/torso multipliers.
The zombie damage system is separate from the difficulty settings that control zombie health pools. Zombie health is defined in the map or server configuration, not in the weapon asset. A server that sets zombie health to a higher value (via the difficulty configuration) makes every zombie take more hits regardless of the weapon's Zombie_Damage. A server that sets zombie health lower makes the Maplestrike kill zombies in fewer hits. The weapon's Zombie_Damage of 99 defines how much damage each hit deals, and the zombie's health pool defines how much damage it can absorb. The interaction between these two values is a pure subtraction: zombie health minus applied damage per hit, repeating until health reaches zero. The number of hits required is the zombie's health pool divided by the per-hit damage, rounded up to the next whole hit. A modder tuning zombie difficulty can either change the zombie health pool globally, change the weapon's Zombie_Damage individually, or both.
Computed zombie damage by hit zone
Zombie damage per hit zone (computed, use verbatim)
| Hit zone | Multiplier | Damage (base 99) |
|---|---|---|
| Skull | 1.1 | 108.9 |
| Spine | 0.6 | 59.4 |
| Arm | 0.3 | 29.7 |
| Leg | 0.3 | 29.7 |
Using computed zombie damage values in practice
A server owner tuning PvE difficulty uses the zombie computed damage table to understand how quickly players can clear zombie hordes with the Maplestrike. A Skull hit deals 108.9 damage, which is more than double the damage of a Spine hit at 59.4. This gap between headshot and body-shot damage is the single most important number for zombie combat balance: it means a player who consistently lands headshots will clear zombies in roughly half the number of hits compared to a player who aims for center mass. A server owner who wants to reward accuracy can lean into this gap; a server owner who wants more forgiving PvE can close it by raising Zombie_Spine_Multiplier.
Arm and Leg hits both deal 29.7 damage on zombies, which is substantially lower than the 108.9 of a Skull hit. A player who panic-sprays into a zombie's limbs is dealing less than a third of headshot damage per hit. This is a deliberate game-design choice that pushes players toward precision in PvE encounters. A modder creating a survival-horror server pack might lower Zombie_Damage globally, making every weapon require more hits to kill a zombie, while keeping the multiplier ratios intact so that headshots remain the optimal target.
When building a custom HUD that displays damage numbers to the player, a plugin developer uses these computed values as the source of truth. The developer would check the hit zone on each damage event and look up the corresponding computed value to display the floating damage number in the correct colour and size. Using the precomputed values from this table rather than computing them in real-time avoids floating-point precision issues in the plugin code.
Animal damage fields
The animal damage block applies to hits against animal entities.
Animal damage
| Field | Value |
|---|---|
| Animal_Damage | 40 |
| Animal_Leg_Multiplier | 0.6 |
| Animal_Spine_Multiplier | 0.8 |
| Animal_Skull_Multiplier | 1.1 |
Animal_Damage
Animal_Damage is 40. This matches the Player_Damage value. There is no Animal_Arm_Multiplier field because animals do not have an arm hitbox.
Animal hit-zone multipliers
Animal_Leg_Multiplieris0.6. A leg hit on an animal does 60 percent ofAnimal_Damage.Animal_Spine_Multiplieris0.8. A spine hit on an animal does 80 percent ofAnimal_Damage.Animal_Skull_Multiplieris1.1. A skull hit on an animal does 110 percent ofAnimal_Damage.
How the animal damage category fits into the damage pipeline
The animal damage block is the third independent damage category in the Maplestrike's asset, alongside player damage and zombie damage. Each category is isolated in the engine: a hit against an animal entity reads only the animal damage fields, never the player or zombie fields. This isolation means a modder can tune the Maplestrike's hunting effectiveness without touching its PvP or zombie-clearing balance. The animal damage block has fewer fields than the other two categories because the animal skeleton has fewer hit zones: there are no distinct left/right arm bones on the standard animal rigs, so the engine uses a simplified three-zone model of skull, spine, and legs.
The Animal_Damage value of 40 matches the Player_Damage value, which places animals and players on the same base damage tier for the Maplestrike. This is a common pattern across military-grade weapons in Unturned: the weapon deals consistent base damage to living targets, and the differentiation comes from the multiplier ratios and the target's health pool. A deer has a different health pool than a player, so the same 40 base damage results in a different practical effect. A modder referencing this table for a hunting-focused server would note that Animal_Damage of 40 is high enough to make the Maplestrike a viable hunting tool, but the weapon's full-auto capability and military ammunition consumption make it overkill for most hunting scenarios.
The absence of an Animal_Arm_Multiplier is not a bug or an omission by the asset author. Animal entities in Unturned use a simplified rig that does not include arm bones. The engine's hitbox-to-multiplier mapping for animals skips the arm check entirely. If a modder were to add an Animal_Arm_Multiplier field to the asset, the engine would ignore it because no animal hitbox maps to that category. A modder working on a custom animal entity with an arm bone would also need to ensure the engine's hit-zone mapping code is updated -- adding the field to the asset alone is not sufficient.
Computed animal damage by hit zone
Animal damage per hit zone (computed, use verbatim)
| Hit zone | Multiplier | Damage (base 40) |
|---|---|---|
| Skull | 1.1 | 44 |
| Spine | 0.8 | 32 |
| Leg | 0.6 | 24 |
Using computed animal damage values in practice
A server owner running a hunting-oriented or survival server uses these computed values to understand how the Maplestrike performs against the game's animal entities. The Skull hit at 44 damage is the optimal hunting shot; a player who can land headshots on moving animals will drop them efficiently. The Spine hit at 32 damage represents a center-mass shot that deals less damage but is easier to land, especially against smaller or faster animals like wolves. The Leg hit at 24 damage is the least efficient shot, dealing just over half of headshot damage, and represents a rushed or panic shot at a fleeing animal.
A modder creating a dedicated hunting rifle variant of the Maplestrike would likely raise Animal_Damage and lower or remove the Auto flag, turning the weapon into a semi-automatic marksman's rifle for hunting. The modder would also lower Spread_Aim to improve precision at range. This is a common modding pattern: take a military assault rifle base, strip the full-auto capability, increase the hunting-specific damage, and tighten the spread to create a designated hunting weapon. The computed damage table gives the modder the numbers to verify that the new Animal_Damage value achieves the desired lethality against each animal type.
Handling fields
The handling block controls how the weapon moves the camera when fired. These fields define the recoil pattern, the aiming spread, and the camera shake.
Handling
| Field | Value |
|---|---|
| Recoil_Min_X | -0.5 |
| Recoil_Min_Y | 4 |
| Recoil_Max_X | 0.5 |
| Recoil_Max_Y | 5 |
| Spread_Aim | 0.05 |
| Shake_Min_X | -0.0025 |
| Shake_Max_X | 0.0025 |
Recoil_Min_X and Recoil_Max_X
Recoil_Min_X is -0.5 and Recoil_Max_X is 0.5. These define the horizontal recoil range. On each shot, the engine rolls a random float between these two values and adds it to the camera's current horizontal angle. Because the minimum is negative and the maximum is positive, the Maplestrike can kick left or right on any given shot -- the horizontal recoil is bidirectional. This contrasts with the Eaglefire, whose Recoil_Min_X of 0.5 and Recoil_Max_X of 1.5 mean it always kicks right. A modder who wants a weapon that always kicks left would set both values negative. A modder who wants more horizontal unpredictability would widen the gap (for example, -1.0 to 1.0).
Recoil_Min_Y and Recoil_Max_Y
Recoil_Min_Y is 4 and Recoil_Max_Y is 5. These define the vertical recoil range. On each shot, the engine rolls a random float between these two values and adds it to the camera's vertical angle. Both values are positive, which means the camera always kicks upward. The gap between 4 and 5 is narrow, giving the Maplestrike fairly consistent vertical climb per shot. Compared to the Eaglefire's vertical range of 3 to 4, the Maplestrike has slightly stronger upward recoil.
Spread_Aim
Spread_Aim is 0.05. This is the base spread value when the player is aiming down sights. The engine adds this value as a random angular offset to the projectile's direction each time the weapon fires. The value of 0.05 matches the Eaglefire. A lower value would tighten shot grouping; a higher value would widen it. A modder making a DMR variant of the Maplestrike might lower this to 0.01.
Shake_Min_X and Shake_Max_X
Shake_Min_X is -0.0025 and Shake_Max_X is 0.0025. These define the camera-shake offset range applied to the viewport on each shot. The range is symmetric around zero, so the camera shakes equally left and right. These values are identical to the Eaglefire's shake parameters.
Understanding recoil as a cumulative system
The recoil values in the handling block are per-shot offsets, but the player experiences recoil as a cumulative effect. On each shot in automatic fire, the engine adds the new random offset to the current camera angle without resetting to zero between shots. This means that sustained automatic fire with the Maplestrike produces a cumulative climb and drift pattern: the vertical recoil pushes the camera upward over multiple shots, and the bidirectional horizontal recoil causes the aim point to wander left and right. The Recoil_Min_X of -0.5 and Recoil_Max_X of 0.5 together create a horizontal wandering pattern where, over many shots, the crosshair drifts in both directions with roughly equal probability, because the random roll is uniform between the two bounds and the bounds are symmetric around zero.
A modder who wants to model a real-world recoil impulse pattern might make the horizontal recoil range asymmetric -- for example, -0.3 to 0.7 -- to simulate a weapon that predominantly kicks right due to the shooter's handedness and stance. This is an intentional design choice, not a data error. The Maplestrike's symmetric horizontal recoil range is a deliberate balance decision: it gives the weapon an unpredictable horizontal kick that makes sustained full-auto fire harder to control than a right-biased recoil pattern would, because the player cannot compensate with a consistent counter-strafe.
The Spread_Aim value of 0.05 is applied independently of recoil. Recoil moves the camera; spread offsets the projectile's direction relative to the camera's aim direction. In practical terms, even if the player perfectly compensates for recoil by pulling the mouse downward, the Spread_Aim of 0.05 still introduces random angular deviation to each shot. At the Maplestrike's Range of 200, a spread angle of 0.05 translates to a projectile deviation of several game units at maximum range, which can be the difference between a hit and a miss against a distant target. A modder who reduces Spread_Aim is effectively increasing the weapon's effective range without changing the Range field, because the projectiles will cluster more tightly at distance.
The handling block does not include a recoil-recovery field. In Unturned, recoil does not automatically reset toward center after each shot. The camera stays at whatever angle the cumulative recoil offsets have pushed it to, and it is the player's responsibility to pull the camera back toward the target. This absence of automatic recoil recovery is a core design choice that makes sustained automatic fire genuinely difficult to control with the Maplestrike. If the player fires a 30-round magazine on full auto without compensating, the camera will have climbed by a cumulative total of approximately 30 times the average vertical recoil, which is a substantial upward displacement. The player must actively pull down on the mouse throughout the burst to keep the crosshair on target. A modder who wants a more forgiving recoil system would need to implement recoil recovery through a server-side plugin, because the .dat format has no native field for automatic recovery.
The camera-shake values (Shake_Min_X and Shake_Max_X) are purely visual and do not affect where the projectile goes. Camera shake is a screen-space effect that jitters the viewport without changing the camera's actual aim direction or the projectile's trajectory. The shake is cosmetic feedback that communicates the weapon's power to the player. The symmetric range of -0.0025 to 0.0025 produces a subtle horizontal jitter on each shot that feels responsive without being disorienting. A modder who raises these values (for example, to -0.01 and 0.01) creates a heavier-feeling weapon with more visual kick, even though the actual recoil and spread are unchanged. This separation of visual shake from mechanical recoil is important for modders to understand: you can make a weapon feel more powerful through shake alone without touching the balance-sensitive recoil and spread values.
The handling fields interact with the Firerate field in automatic fire. At Firerate of 5 ticks per shot, the camera receives a new recoil offset and spread offset every 5 ticks in auto mode. The cumulative effect over a full magazine can be thought of as a random walk starting from the initial aim point. With bidirectional horizontal recoil, the walk drifts left and right with roughly equal probability. With positive-only vertical recoil, the walk consistently climbs upward. The Spread_Aim adds a random angular deviation at each step, which means the projectiles themselves are not following the camera's exact aim path -- they are spreading out in a cone around the camera's current direction. This means that even if the player perfectly tracks the recoil pattern, the Spread_Aim value introduces irreducible inaccuracy. A modder who wants a weapon that rewards perfect recoil control would lower Spread_Aim toward 0.0; a modder who wants a weapon that punishes sustained fire would increase Spread_Aim so that even well-compensated bursts scatter at range.
Flags
Understanding the enum flags system
The flags on a gun asset are stored as a bitmask integer in memory, but in the .dat file they are written as a bracket-delimited list of string identifiers. Each flag name corresponds to a specific bit position in the bitmask. When the engine loads the asset, it parses the flag list, maps each string to its enum value, and sets the corresponding bits in the weapon's runtime flag field. This means that flags in the .dat file are not simple strings that the engine does a text-match against; they are entries in a compile-time enum that maps to specific bitmask positions. If a modder misspells a flag name in the .dat file, the engine silently ignores it because the string does not match any enum value. The flag simply does not activate, and no error is logged.
The flag system is additive: a weapon can have any combination of flags, and the engine checks each flag independently when deciding how to behave. For example, the engine checks the Auto flag to determine whether the firemode cycling UI includes an automatic option; it checks the Semi flag to determine whether semi-automatic fire is available; and it checks the Safety flag to determine whether the weapon defaults to safe mode on equip. Each check is a bitwise AND against the weapon's flag bitmask, not a switch-case on the full flag set, so flag combinations are flexible and non-exclusive.
When a modder clones the Maplestrike to create a variant, they copy the flag list verbatim and then add or remove individual flags. Removing a flag is a simple deletion of that line from the bracket-delimited list. Adding a flag is adding its name to the list. The order of flags within the brackets does not matter because the engine maps each flag name to its bit position independently. A modder can write the flags in any order and the engine will produce the same bitmask. The bracket characters [, ], {, and } are structural tokens that the .dat parser uses to delimit the flag list and any nested flag subgroups. If a modder deletes a bracket while editing, the parser will fail to parse the flag block and the weapon may load with no flags at all, which would disable all attachment hooks, firemodes, and behaviours. This is one of the most common causes of a "broken weapon" after a text-editor modding session.
Some flags in the Unturned enum system are conditional on other flags. For example, the Auto flag only has meaning if Trigger action is set and Semi is also present (to provide the fire-mode cycling UI). If a modder adds Auto to a weapon with Pump action, the engine will not produce automatic fire because the Pump action state machine does not support the Auto flag's continuous-fire logic. The engine does not validate flag-and-action compatibility at load time; it simply runs the firing state machine for the given action and only checks flags that are relevant to that state machine. A modder who adds an incompatible flag will not see an error -- the flag will simply have no effect. This is why it is safe to copy a flag list from one weapon type to another (for example, copying the Maplestrike's hook flags to a pistol) -- incompatible flags will be silently ignored, and only the flags relevant to the weapon's action and category will take effect.
The GUID flag (b7b82c125a5a54984b8bb26576b59e977) embedded in the flag list is a special case. It is technically not a functional flag enum value but a master-asset reference GUID that the engine uses in certain inheritance scenarios. In the .dat file format, the GUID appears inside the flag bracket block as a quoted string, which the parser treats as a flag-like token. If the modder is creating a standalone clone that does not inherit from the Maplestrike, this GUID should be removed. If the clone is intended to inherit default values from the Maplestrike as a parent asset, the GUID should be replaced with the clone's own GUID or left unchanged to maintain the inheritance chain. The exact behaviour depends on the Unturned version and whether the engine's asset-inheritance system is active for the item category in question.
The enum flags on a gun asset control which behaviours the engine activates for that weapon. Every flag is a named boolean stored as a bitmask in the asset. The Maplestrike asset declares these flags:
Flags present: "7b82c125a5a54984b8bb26576b59e977", Auto, Blueprints, Hook_Barrel, Hook_Grip, Hook_Sight, Hook_Tactical, InputItems, RequiresNearbyCraftingTags, Safety, Semi, [, ], {, }
GUID flag
The string "7b82c125a5a54984b8bb26576b59e977" is a GUID embedded in the flags block, not a functional flag name. This GUID may reference a master asset or a parent table. When a modder clones the Maplestrike to create a variant, they should either remove this GUID or replace it with a new one they generate.
Auto
The Auto flag is the most important distinguishing flag on the Maplestrike. It enables fully automatic fire: while the player holds the fire input, the weapon continues to cycle and fire rounds at its Firerate interval. The Eaglefire does not have this flag. The presence of Auto combined with Semi and Safety means the Maplestrike has three fire modes: Safety, Semi, and Auto. The player cycles through them with the fire-mode keybind. A modder removing the Auto flag would make the Maplestrike semi-automatic only. A modder adding Burst would create a fourth fire mode.
Blueprints
The Blueprints flag enables the crafting-recipe system for this item. When this flag is present, the engine reads the Blueprints block in the asset file and makes those recipes available at the appropriate crafting station.
Hook flags
Hook_Barrel, Hook_Grip, Hook_Sight, and Hook_Tactical are attachment-socket flags. Each one tells the engine: "this weapon has a socket of this type, and the player can attach items that match it." These four flags are identical to the Eaglefire's hook flags: both weapons support barrel, grip, sight, and tactical attachments.
InputItems
InputItems is a flag related to item transfer. When this flag is present, the engine processes the InputItems block in the asset, which defines items that are consumed when the weapon performs a specific action.
RequiresNearbyCraftingTags
The RequiresNearbyCraftingTags flag means the weapon's crafting recipes require the player to be standing near a world object that carries a matching tag.
Safety and Semi
Safety and Semi are fire-mode flags. Safety means the weapon defaults to a safe mode that prevents firing until the player switches modes. Semi means the weapon supports semi-automatic fire. The presence of both of these plus Auto gives the Maplestrike its three-mode fire selector.
Bracket flags
The flags [, ], {, and } are structural delimiters in the .dat file format. They mark the boundaries of flag subgroups and must be preserved exactly when editing the asset in a text editor.
Notable absent flags
The Maplestrike does not have the Invulnerable flag, so it takes durability damage with use. It does not have the Burst flag. It does not have the Hook_Barrel and Hook_Grip only; like the Eaglefire, it has four hook flags, which means it supports the full suite of Military-pattern attachments.
Where it spawns
How spawn tables work as weighted lists
A spawn table in Unturned is not a simple list of items. It is a weighted list: each entry in the table has an item ID, a weight value, and optional conditions. When the engine rolls a spawn table, it sums the weights of all eligible entries and then generates a random number in that range. The entry whose cumulative weight range contains the random number is selected. An entry's "chance per roll" is its weight divided by the total weight of the table, expressed as a percentage. This means that changing one entry's weight changes every other entry's chance per roll, because the total weight changes. A modder who increases the Maplestrike's weight in a table is effectively reducing the chance of every other entry in that same table.
The engine rolls spawn tables at specified intervals and locations determined by the map's spawn-node configuration. Each spawn node references a spawn table by its ID string (for example, Military_Canada_Guns). The engine iterates over active spawn nodes, checks if the node is due for a respawn based on its cooldown timer, and if it is, rolls the referenced table. The selected item is placed at the node's world position and the node's cooldown timer resets. This means the 50.000% chance per roll on the Military_Canada_Guns table does not mean that half of all items in Canadian military locations are Maplestrikes at any given moment. It means that each time a military gun spawn node in a Canadian location respawns, there is a 50 percent chance that the spawned gun will be a Maplestrike.
Spawn tables can be shared across multiple maps and multiple spawn nodes. The Military_Canada_Guns table appears on every map that has Canadian military faction locations, not just on a single map. The Core map in the table data represents the base game's map set (PEI, Washington, Yukon, Germany, and Russia), which all share the same spawn-table definitions with only the spawn-node placements differing. A curated map like France or Ireland has its own spawn-table definitions, which is why the Maplestrike appears in carepackage tables rather than general world-spawn tables on those maps.
The loot tables below are the spawn tables in which the Maplestrike appears. Each row is a table entry from a specific map. "Chance per roll" is the probability, on a single roll of that table, that the engine selects the Maplestrike entry.
WHERE IT SPAWNS (pre-rendered, use verbatim)
| Map | Spawn table | Chance per roll |
|---|---|---|
| Core | Military_Canada_Guns | 50.000% |
| Core | Arena_Guns_Military_Common | 16.667% |
| Core | Washington Arena_Arena_Guns_Military | 14.875% |
| Core | Arena_Guns_Military | 14.875% |
| Core | PEI Arena_Arena_Guns_Military | 14.875% |
| Core | Alpha Valley_Arena_Guns_Military | 14.875% |
| EasterIsland | Easter_Airdrop_Guns | 8.000% |
| France | Carepackage_France_Weapons | 7.194% |
| EasterIsland | Easter_Airdrop | 5.576% |
| France | Carepackage_France | 5.036% |
| Belgium | Belgium_Carepackage | 3.899% |
| Ireland | Cliffs_Airdrop_Weapons_Military | 3.279% |
Reading the spawn-table data
The Maplestrike appears in 12 tables shown in the extracted asset data. The highest single-roll chance is 50.000% in the Military_Canada_Guns table on the Core map. This means that when the engine rolls the Military_Canada_Guns table, there is a 50 percent chance per roll that the result is the Maplestrike. This is the defining spawn characteristic of the weapon: it is the primary Canadian military rifle, and the Canadian military gun table gives it a dominant weight.
The next four entries are arena tables, all sharing 14.875% or 16.667%. These percentages are identical to the Eaglefire's arena-table percentages, which suggests that Military-pattern assault rifles share a common weight tier in arena tables.
The remaining tables are airdrop and carepackage tables. The Maplestrike appears in airdrops on Easter Island (Easter_Airdrop_Guns at 8.000% and Easter_Airdrop at 5.576%), carepackages in France (Carepackage_France_Weapons at 7.194% and Carepackage_France at 5.036%), a carepackage in Belgium (Belgium_Carepackage at 3.899%), and a military airdrop on Ireland (Cliffs_Airdrop_Weapons_Military at 3.279%).
In the spawn-table data, the "Map" column indicates which map or map group a table belongs to, not necessarily which map's world the table is exclusive to. "Core" represents the base game's map set, which includes PEI, Washington, Yukon, Germany, and Russia. These maps share a common set of spawn-table definitions, so a table listed under "Core" is active on every Core map that has spawn nodes referencing it. A table listed under a specific curated map name (EasterIsland, France, Belgium, Ireland) is only active on that map. This is why the Maplestrike has five Core-table entries but only appears in Canadian military locations on Core maps -- the Military_Canada_Guns table is only referenced by spawn nodes that are placed in Canadian military areas, and if a Core map does not have Canadian military spawn nodes (as some maps do not), that table simply never rolls on that map.
The "Chance per roll" percentage is a per-roll probability, not a per-session or per-player probability. A player who visits a Canadian military location with 10 active gun spawn nodes, each rolling the Military_Canada_Guns table once per respawn cycle, can expect roughly 5 of those 10 rolls to produce Maplestrikes on average. But this is a statistical expectation, not a guarantee. The engine's random number generator produces uniform random rolls, so the actual number of Maplestrikes in a given loot run varies. Over many loot runs, the average converges on the percentage. A server owner who wants to understand how many Maplestrikes enter circulation on their server per hour would multiply the number of active Canadian military gun spawn nodes by the 50.000% chance per roll and by the number of respawn cycles per hour. This is the practical application of per-roll probabilities in spawn-table auditing.
Canadian military table dominance
The Military_Canada_Guns table at 50.000% is the highest single-roll chance for any weapon in the briefs in this series. A server owner who wants to make Canadian military locations a reliable source of firepower would leave this weight as-is. A server owner who wants to make the Maplestrike rarer would reduce this weight and redistribute it across other entries in the table.
The significance of the 50.000% chance goes beyond a single number. It means that the Maplestrike occupies half the weight budget of the entire Military_Canada_Guns table. The remaining 50 percent is split among every other weapon that can spawn in Canadian military gun locations. This weight distribution ensures that any player looting a Canadian military armory has a coin-flip chance of finding a Maplestrike on each gun spawn node. Over multiple nodes and multiple loot cycles, the Maplestrike becomes the most commonly encountered weapon in Canadian military areas. This is the mechanical expression of the weapon's identity as the standard-issue Canadian service rifle.
The Canadian military table dominance also affects the broader loot economy of any map that includes Canadian military spawn nodes. Because the Maplestrike is an Epic-rarity weapon with full-auto capability and high damage, its high appearance rate in Canadian military locations makes those locations high-value loot targets. Players who know the spawn-table data will prioritize Canadian military areas over other faction areas when seeking a Maplestrike, because no other table offers a chance per roll above 16.667%. A map designer placing Canadian military spawn nodes on a new map must account for the fact that these nodes will produce Maplestrikes at a much higher rate than any other faction's nodes produce their respective signature weapons.
The 50.000% chance also means that the Maplestrike has effectively no competition from other rifles within its own table. Whatever other weapon shares the Military_Canada_Guns table with the Maplestrike, its combined weight with every other entry must total the remaining 50 percent. If there are three other weapons in the table, each one averages roughly 16.667% -- comparable to the Maplestrike's arena-table chances. If there is only one other weapon, that weapon could also have 50.000%, making the table a two-weapon split. The engine does not enforce any minimum or maximum number of entries in a spawn table, so the specific composition of the Military_Canada_Guns table varies by game version. What remains constant is the Maplestrike's 50.000% weight as the dominant entry.
A server owner who wants to reshape the Canadian military loot economy without touching the Maplestrike's weight directly can add new entries to the Military_Canada_Guns table. Adding a new weapon entry with its own weight increases the total weight of the table, which reduces every existing entry's chance per roll, including the Maplestrike's 50.000%. This is a softer approach than directly editing the Maplestrike's weight: the Maplestrike's absolute weight stays the same, but its relative chance decreases because the table now has more total weight to roll against. This is how vanilla Unturned introduces new weapons into existing spawn tables without rebalancing every single entry -- the new weapon is added, total weight increases, and all existing chances scale down proportionally.
The Maplestrike does not appear in general world-spawn tables for maps outside the Core map, with the sole exception of carepackage/airdrop tables. If you play on a curated map like France or Ireland and want a Maplestrike, you must find an airdrop or carepackage.
Arena tables
The five arena tables (Arena_Guns_Military_Common, Washington Arena_Arena_Guns_Military, Arena_Guns_Military, PEI Arena_Arena_Guns_Military, and Alpha Valley_Arena_Guns_Military) mean the Maplestrike is available in arena mode on all major arena maps. The Arena_Guns_Military_Common table has a slightly higher chance (16.667%) than the four map-specific tables (14.875% each). This mirrors the Eaglefire's arena distribution.
The arena-table structure reveals how the game separates arena loot from survival loot. Arena mode uses dedicated spawn tables that are not shared with the survival-mode world-spawn system. This allows the arena tables to be balanced independently of the survival economy. The Maplestrike's arena-table chances all fall in the 14.875% to 16.667% range, which represents a moderate weight among military weapons in arena rotations. The Arena_Guns_Military_Common table at 16.667% is a shared table used across all arena maps for common military weapon spawns, while the map-specific tables like Washington Arena_Arena_Guns_Military provide per-map customization. A server owner running a custom arena map would add the Maplestrike to that map's arena tables by copying the weight values from one of these existing tables to maintain consistency with the vanilla arena balance.
The difference between the common arena table at 16.667% and the map-specific tables at 14.875% is small but mechanically significant. The Arena_Guns_Military_Common table rolls on every arena map regardless of the map's theme, which means the Maplestrike has a consistent 16.667% baseline presence in arena mode alongside the map-specific 14.875% roll. On maps that have both the common table and a map-specific table active (Washington, for example, has both Arena_Guns_Military_Common at 16.667% and Washington Arena_Arena_Guns_Military at 14.875%), the Maplestrike can appear from either table, effectively giving it two independent chances to roll on each relevant spawn cycle. This dual-table presence is not unique to the Maplestrike -- it is the intended design for all military-grade weapons in arena mode -- but it means the Maplestrike's effective arena availability is the sum of every active table in which it appears, not just the highest single-table chance. A modder auditing arena weapon balance must account for cumulative probability across all active tables, not just per-table percentages.
Carepackage and airdrop tables
The Maplestrike's presence in carepackage and airdrop tables but not in general world-spawn tables on curated maps is a deliberate loot-design choice. The weapon is tied to Canadian military identity on the Core map and is only available through special loot events elsewhere. A modder adding the Maplestrike to a new curated map would either create a Canadian military faction spawn table with it, or add it to that map's airdrop tables.
The carepackage and airdrop chances on curated maps follow a descending tier pattern: Easter Island's Easter_Airdrop_Guns at 8.000% is the highest curated-map chance for the Maplestrike, followed by France's carepackage tables at 7.194% and 5.036%, then Belgium at 3.899%, and finally Ireland at 3.279%. These descending percentages reflect the intended rarity gradient across curated maps. The Maplestrike is most accessible on Easter Island via airdrops, moderately available on France via carepackages, and progressively rarer on Belgium and Ireland. A modder creating a new curated map would decide where on this rarity gradient to place their map's Maplestrike spawn chance based on how central the weapon should be to that map's loot economy.
The distinction between an airdrop table and a carepackage table is mechanical, not just thematic. Airdrops are triggered by map events (a plane flies overhead and drops a crate at a semi-random location), while carepackages are typically static or semi-static loot containers placed by the map designer. This means the Maplestrike's appearance on Easter Island is tied to a dynamic, contested world event, while its appearance in France is tied to looting specific carepackage locations. A server owner who wants to make the Maplestrike accessible on a curated map without adding Canadian military spawn nodes should prefer airdrop tables, because the dynamic nature of airdrops creates emergent gameplay around contested loot drops.
On each curated map, the Maplestrike appears in two related tables: a weapon-specific table and a general table. In France, for example, the weapon-specific Carepackage_France_Weapons at 7.194% and the general Carepackage_France at 5.036% both contain the Maplestrike. The weapon-specific table is rolled when the carepackage is designated to contain a weapon, while the general table is rolled for any carepackage regardless of category. The Maplestrike's weight in the weapon-specific table is higher than in the general table, which follows the pattern that weapons are more likely to appear from weapon-dedicated tables than from general-purpose tables. A modder adjusting carepackage loot on a curated map can increase the Maplestrike's availability by raising its weight in either table, but raising the weapon-specific table's weight has a more targeted effect on weapon spawns without inflating the general table.
The Belgium Belgium_Carepackage at 3.899% and Ireland Cliffs_Airdrop_Weapons_Military at 3.279% represent the lowest per-roll chances for the Maplestrike across all 12 spawn tables. At these percentages, a single roll of the carepackage or airdrop table has less than a 1-in-25 chance of producing a Maplestrike. On a server with standard respawn timers, a player might go through multiple carepackage or airdrop cycles without ever seeing a Maplestrike. This rarity on Belgium and Ireland is the furthest expression of the weapon's curated-map design philosophy: the Maplestrike is a Core-map weapon first, and its presence on curated maps is a deliberate rarity concession, not a guaranteed spawn. A server owner who wants the Maplestrike to be a regular part of the loot economy on Belgium or Ireland should add it to a general world-spawn table rather than relying on the low-percentage carepackage or airdrop rolls.
Canned Beans
The Maplestrike brief contains no bean data. There are no Canned_Beans entries in the spawn tables listed for this weapon, nor is there a bean-related flag or field in the asset definition. The Maplestrike appears exclusively in military, arena, airdrop, and carepackage tables -- none of which are civilian food tables. The absence of beans from a weapon reference is the norm; only civilian or survivalist loot tables intermix weapons and food items. For bean lore across the game, see Canned Beans Lore.
Practical use for server owners and modders
Cloning the Maplestrike for a custom variant
To create a custom Maplestrike variant, a modder starts by locating the original Maplestrike.dat file in the game's asset bundles. The modder copies this file to a new file in their workshop mod's Bundles/Items/ directory, giving it a unique asset name that does not conflict with any vanilla or workshop item. The file copy must preserve the exact UTF-8 encoding and Unix-style line endings that the vanilla asset uses, because the engine's .dat parser is sensitive to encoding mismatches and carriage-return characters can cause parse failures.
The modder then generates a new GUID. This step is mandatory: two assets with the same GUID will collide in the engine's asset registry, and the second one loaded will silently overwrite the first. A modder generates a GUID using any standard GUID generator or by typing a 32-character hex string that they know is unique. The new GUID is written into the asset's GUID field and, if the variant is not inheriting from the Maplestrike, the GUID flag in the flag list is removed or replaced. The modder also assigns a new item ID that does not conflict with vanilla IDs (0 through approximately 2000) or with any other workshop mod's IDs. Workshop modders often coordinate ID ranges through community conventions to avoid collisions.
With the identity fields set, the modder edits the gameplay fields described throughout this reference. Adjusting Player_Damage changes the per-hit lethality. Adjusting Firerate changes the weapon's cycling speed. Adjusting Range changes the damage-falloff distance. Each multiplier field can be tuned independently to create a weapon with a different damage profile against specific hit zones. The modder adds or removes flags from the bracket-delimited flag list to change the weapon's behaviours. Removing Auto makes the weapon semi-automatic only. Lowering Spread_Aim to a tighter value like 0.01 creates a more accurate DMR-style variant. Raising Firerate to a lower tick value like 3 and increasing Spread_Aim creates a close-quarters bullet-hose variant.
After editing the asset, the modder places the new .dat file and its associated Unity bundle (containing the 3D model, textures, and animations) into their workshop mod directory. The modder then tests the variant in a local singleplayer session by spawning it through the editor's item spawn menu, verifying that the weapon appears with the correct name, fires with the expected fire modes, deals the expected damage, and accepts the correct attachments. If any field is misconfigured, the modder edits the .dat file and restarts the session. This edit-test-restart cycle is the standard modding workflow.
When testing a custom Maplestrike variant, the modder should verify each fire mode independently. In Safety mode, the weapon should not fire when the fire key is pressed. In Semi mode, each click should produce one shot with the correct recoil and spread. In Auto mode, holding the fire key should produce continuous fire at the Firerate interval until the magazine is empty. The modder should also test the variant against each entity type (player, zombie, animal) to confirm that the damage values for each are being applied correctly, and test each hit zone to confirm that the multipliers produce the expected computed damage. A variant that passes all three fire modes, all three entity types, and all hit zones is ready for spawn-table integration.
Finally, the modder adds the new asset to the desired spawn tables. This involves editing the spawn-table .dat files for the target maps, adding a new entry with the variant's item ID and a weight value. The weight determines how frequently the variant appears relative to other entries in the same table. The modder tests the spawn integration by flying around the map in the editor and confirming that the variant appears at the expected spawn nodes with the expected frequency.
Server-side damage and fire-mode tuning
A server owner who runs a RocketMod or OpenMod plugin can read and modify the Maplestrike's values at runtime. The plugin obtains a reference to the Maplestrike asset using the GUID 38508a1f73c8417a8a68cb675460d0b6 and then reads or writes individual fields on the asset object. Runtime modifications do not persist across server restarts unless the plugin re-applies them on each load, so the server owner either configures the plugin to apply modifications on every startup or writes the modifications to a configuration file that the plugin reads on load.
A common server-side change is to remove the Auto flag from the Maplestrike at runtime. The plugin clears the flag bit from the weapon's flag mask, and from that point forward the weapon behaves as a semi-automatic-only rifle for all players on the server. The fire-mode cycling UI updates immediately because the engine re-checks the flag mask on every fire-mode switch. This is a balance change that affects only that server session and does not modify the underlying asset file, so a server restart without the plugin re-applying the change returns the Maplestrike to its vanilla full-auto behaviour.
Another common server-side change is to adjust the recoil fields to make sustained automatic fire more difficult. By increasing Recoil_Min_Y and Recoil_Max_Y, the server owner makes the vertical climb per shot more aggressive, which means players must compensate more actively to keep the crosshair on target during automatic fire. By widening the horizontal recoil range (for example, changing Recoil_Min_X to -1.0 and Recoil_Max_X to 1.0), the server owner introduces more horizontal unpredictability. These changes are applied through the plugin's asset-modification API and take effect immediately for all instances of the Maplestrike in the world.
Server owners can also modify the Player_Damage and multiplier fields at runtime to adjust PvP lethality. Raising Player_Damage makes the Maplestrike kill players in fewer hits. Lowering it makes the weapon less lethal. Changing individual multipliers allows granular balance: raising Player_Skull_Multiplier makes headshots more rewarding without affecting body-shot damage, while raising Player_Spine_Multiplier makes torso shots more forgiving. These runtime modifications apply to all Maplestrike instances, including those already in player inventories and those that will spawn in the future.
A server owner who wants to create distinct weapon tiers within a single asset can use a plugin to apply different stat overrides based on the weapon's durability or a custom metadata tag. For example, a plugin might apply one set of damage and recoil values when the Maplestrike has full durability and a reduced set when durability drops below 50 percent, simulating weapon degradation. Another approach is to assign different stat profiles to Maplestrikes found in different spawn tables, so that a Maplestrike from the Military_Canada_Guns table at 50.000% has different handling than one from an airdrop table. These tiering systems are entirely plugin-driven and do not exist in the vanilla asset -- the vanilla engine applies the same stat values to every instance of the Maplestrike regardless of where or how it was obtained.
Spawn table auditing
The Military_Canada_Guns table at 50.000% per roll is the dominant spawn source. If a server owner wants the Maplestrike to be rarer, reducing its weight in this single table has more impact than adjusting any other table. The server owner locates the Military_Canada_Guns table definition in the spawn-table assets, edits the Maplestrike entry's weight to a lower value, and the change takes effect on the next server restart. Because spawn tables are loaded at startup and not re-read during gameplay, spawn-table changes always require a restart.
A server owner who wants to make the Maplestrike more accessible on a curated map where it only appears in carepackages or airdrops has two options. The first option is to increase the Maplestrike's weight in the existing carepackage or airdrop tables, which increases the chance that a given carepackage or airdrop contains a Maplestrike but does not increase the number of carepackages or airdrops that occur. The second option is to add the Maplestrike to a general world-spawn table on that map, which makes it appear at regular loot spawn nodes. The second option is a more invasive change that significantly alters the map's loot economy, because it introduces the Maplestrike to locations where players can repeatedly loot it rather than making it a special-event item.
Conversely, if the Maplestrike is not appearing on a curated map when a server owner expects it to, the server owner should check that the map's carepackage and airdrop tables are rolling correctly. The server owner verifies that the spawn nodes for carepackages and airdrops are active, that their cooldown timers are ticking, and that the tables they reference include the Maplestrike entry. A misconfigured spawn node that references the wrong table ID, or a table that has been inadvertently edited to remove the Maplestrike entry, will result in the weapon never appearing despite being defined in other tables.
A server owner can also verify spawn-table behaviour using a plugin that logs every spawn-table roll to a file or console. By filtering the log for the Maplestrike's item ID 363, the server owner can see exactly which tables rolled the Maplestrike, on which spawn nodes, and at what time. This audit trail is more reliable than manually checking spawn locations, because a manual check only captures a single point in time while a log captures every roll over the audit period. If the Maplestrike is rolling at roughly half the Military_Canada_Guns rolls, the 50.000% chance is working as expected. If it is rolling at a significantly different rate, a weight value has been modified somewhere in the table definition, or another plugin or mod is intercepting and altering the loot spawn results.
For server owners who want to give every player a guaranteed Maplestrike at spawn, the approach is to write a plugin that listens for the player-spawn event and uses the giveItem API with item ID 363. This bypasses the spawn-table system entirely and does not require any .dat file edits. The plugin can fill the spawned Maplestrike with a full magazine by setting the ammo count to Ammo_Max of 30, or it can leave the ammo at random by letting the engine roll Ammo_Min to Ammo_Max. The plugin can also pre-attach a specific set of attachments by adding them to the weapon's attachment slots in code. This is a common setup for arena servers, kit-PvP servers, or any server where players are expected to start with a standard loadout rather than looting their weapons from the world.
When designing a kit-PvP loadout that includes a Maplestrike, the server owner must decide how much ammunition to give the player at spawn. The vanilla Ammo_Max of 30 provides one full magazine, which is enough for a single engagement but not for sustained fighting. A common kit-PvP setup gives the player the Maplestrike with 30 rounds loaded plus one or two Military ammunition boxes in the inventory, providing enough ammunition for multiple engagements. The server owner can also pre-attach a scope (for long-range engagements), a grip (for reduced recoil), and a suppressor (for reduced audio signature), depending on the intended playstyle of the kit. Each attachment is added by its item ID in the plugin code, and the plugin must verify that the attachment's socket enum matches the Maplestrike's corresponding slot value before attaching it.
Attachment compatibility
The Hook_Barrel, Hook_Grip, Hook_Sight, and Hook_Tactical flags mean the Maplestrike accepts attachments in these four categories. The specific attachments that fit depend on the socket enum values in the ballistics block. When a player attempts to attach an item to the Maplestrike, the engine checks two conditions: first, that the weapon has the corresponding Hook_ flag for the attachment's category; second, that the attachment's socket enum matches the weapon's corresponding socket enum value. For example, a barrel attachment with socket enum 3 will attach to the Maplestrike because the Maplestrike's Muzzle value is 3 and the Hook_Barrel flag is present. A barrel attachment with socket enum 1 (Civilian) would not attach because the socket enum does not match, even though the Hook_Barrel flag is present.
A modder creating a new attachment for the Maplestrike must ensure the attachment carries the correct socket enum value that matches the Maplestrike's Muzzle or Magazine value, and that the attachment carries a Hook_ flag that corresponds to the slot it occupies. The modder also adds the attachment's item ID to the appropriate spawn tables so that players can find it in the world. The attachment does not need to reference the Maplestrike specifically; the socket-enum and flag system means any attachment with matching socket values will fit any weapon with the corresponding hook flags. This is the modular design principle that allows a single Military suppressor to fit every weapon with Muzzle set to 3 and Hook_Barrel present.
The four hook flags on the Maplestrike (Hook_Barrel, Hook_Grip, Hook_Sight, Hook_Tactical) are the standard set for military-grade primary weapons. They do not include Hook_Magazine because the magazine attachment slot is handled by the Magazine enum in the ballistics block, not by a hook flag. The engine treats the magazine slot differently from the barrel, grip, sight, and tactical slots: the magazine is loaded through the reload mechanic, while the other attachments are added through the attachment UI. A modder who adds Hook_Magazine to the flag list would not create a new attachment slot; the engine would either ignore the flag or, depending on the game version, cause a conflict with the ballistics Magazine field. Modders should use the ballistics Magazine enum to control magazine compatibility and use the hook flags only for the non-magazine attachment slots.
A server owner who wants to restrict the Maplestrike's attachment options can remove individual hook flags at runtime through a plugin. Removing Hook_Barrel prevents players from attaching barrel items. Removing Hook_Sight prevents players from attaching scopes and sights, forcing iron-sight use. These flag removals take effect immediately: any currently attached items in the removed slot become detached and drop into the player's inventory or onto the ground. A server owner running a hardcore or realism server might remove Hook_Sight from all weapons to create an iron-sights-only PvP environment without modifying any weapon stats.
Comparing Maplestrike to Eaglefire for modding
Both weapons share Player_Damage of 40, Zombie_Damage of 99, Animal_Damage of 40, identical hit-zone multipliers, identical Range of 200, and identical Spread_Aim of 0.05. They share the same Caliber (1), Muzzle (3), and Magazine (6) enums. They share the same attachment hook flags. The differences that a modder works with are:
Firerate: Maplestrike5vs Eaglefire4(Eaglefire cycles faster).Autoflag: present on Maplestrike, absent on Eaglefire.- Recoil pattern: Maplestrike has bidirectional horizontal recoil (
-0.5to0.5); Eaglefire kicks exclusively right (0.5to1.5). Maplestrike has higher vertical recoil (4to5) than Eaglefire (3to4). - Rarity: Maplestrike is
Epic; Eaglefire isRare. - Spawn tables: Maplestrike is dominated by the Canadian military table; Eaglefire is distributed across American and Russian militia tables plus civilian and police tables.
A modder creating a custom weapon family would model these two as a case study in how the same damage profile can support two different weapon identities through firerate, fire-mode flags, recoil, and spawn-table placement.
The Maplestrike and Eaglefire are the clearest example in the vanilla Unturned arsenal of two weapons that share a damage profile but occupy entirely different roles. Both deal the same base damage to players, zombies, and animals across the same hit-zone multipliers. Both have the same effective range and the same aiming spread. Both accept the same attachments and use the same ammunition type. In raw per-hit numbers, they are functionally identical weapons. Yet no player would confuse them in practice, and no modder would consider them interchangeable, because the differences sit entirely in the fields that control how the weapon fires and where it can be found.
The Auto flag on the Maplestrike is the single most important differentiating field. It gives the Maplestrike a capability -- sustained automatic fire -- that the Eaglefire simply does not have. This changes the weapon's role from a precision semi-automatic rifle to a volume-of-fire assault rifle. The Auto flag also changes how the weapon feels in the player's hands: holding the fire key with the Maplestrike produces a continuous firing experience, while the Eaglefire demands a click for every shot. This is a fundamentally different player input pattern that shapes how each weapon is used in combat. A player with a Maplestrike can suppress an area, clear a room, or engage multiple targets with a single trigger hold. A player with an Eaglefire must place each shot deliberately.
The firerate difference reinforces this role distinction. The Eaglefire cycles at 4 ticks per shot, making it one tick faster per shot than the Maplestrike's 5-tick cycle. In semi-automatic use, the Eaglefire can fire slightly faster than the Maplestrike in semi-auto mode, which rewards a player who clicks accurately and quickly. But the Maplestrike's 5-tick cycle in full-auto mode fires faster than any player can click semi-automatically, because the engine cycles the weapon automatically without waiting for a click. This means the Maplestrike in Auto mode outputs more damage over time than the Eaglefire in Semi mode, despite the per-tick firerate being slower, because the automatic cycling eliminates the human input delay between shots.
The recoil patterns reflect the different firing roles. The Maplestrike's bidirectional horizontal recoil (-0.5 to 0.5) makes sustained automatic fire wander left and right unpredictably, which is a deliberate balancing mechanism: the weapon can fire automatically, but controlling that automatic fire requires active mouse correction. The Eaglefire's right-only horizontal recoil (0.5 to 1.5) is predictable and consistent, which rewards the semi-automatic marksman who can compensate with a steady leftward mouse pull. The Maplestrike's higher vertical recoil (4 to 5) versus the Eaglefire's (3 to 4) adds additional climb that the full-auto user must manage. Together, these recoil differences mean that the Maplestrike demands more recoil-control skill from the player in exchange for its full-auto capability, while the Eaglefire's gentler and more predictable recoil complements its semi-automatic precision role.
The rarity and spawn-table differences complete the picture. The Maplestrike is Epic and tied to Canadian military locations, making it a faction-specific treasure that rewards players who seek out Canadian military areas. The Eaglefire is Rare and distributed across multiple militia, civilian, and police tables, making it more widely available but less of a specialist's weapon. A player who wants the full-auto Canadian assault rifle goes to Canadian military locations. A player who wants a reliable semi-automatic rifle can find an Eaglefire in many more places. This faction-tying of the Maplestrike versus the broad distribution of the Eaglefire is not an accident of the spawn-table data; it is a deliberate worldbuilding choice that ties weapon identity to map geography. The Maplestrike is Canada's rifle, and you find it where Canadian military presence exists. The Eaglefire is a general-purpose military rifle, and you find it wherever military loot appears.
For a modder, the lesson is that damage numbers are only one axis of weapon identity. The same damage profile can produce two entirely different weapons when firerate, fire-mode flags, recoil pattern, rarity, and spawn-table geography are varied. A modder creating a new weapon family should start by defining the damage profile and then ask: what firerate distinguishes this weapon, what fire modes does it support, how does its recoil feel in each mode, what rarity tier signals its value to the player, and where in the world does the player find it. The Maplestrike and Eaglefire together demonstrate that these non-damage fields are not secondary details -- they are the primary fields that define a weapon's identity in the player's hands and on the map.
The Maplestrike's design is a case study in how a weapon's identity is shaped by where it appears, not just what it does. If the Maplestrike had the exact same stats but spawned in civilian trash piles at 5.000%, it would be perceived as a lucky junk find rather than a faction-specific trophy. If it had the exact same stats but had no Auto flag, it would be a slightly slower Eaglefire with a Canadian coat of paint. The identity of the Maplestrike is the sum of its fields read together: Epic rarity plus Canadian spawn-table dominance plus Auto flag plus bidirectional recoil plus the visual design that the .dat file references but does not define. A modder who changes any one of these fields changes the weapon's identity. A modder who wants to understand why the Maplestrike feels the way it does must read every field in this reference, not just the damage numbers.
The most important concept for a modder to internalize from this reference is that the Maplestrike does not exist in isolation. It is part of a weapon ecosystem: its damage profile is shared with the Eaglefire, its ammunition type is shared with every Caliber-1 weapon, its attachment sockets are shared with every Military-socket weapon, and its spawn tables are shared with every weapon that appears in Canadian military, arena, airdrop, and carepackage tables. Every change a modder makes to the Maplestrike ripples through this ecosystem. Making the Maplestrike more powerful makes Canadian military locations more desirable. Changing its Caliber breaks its ammunition compatibility with other Military weapons. Adding it to a new spawn table changes the loot balance of every map that references that table. The modder who reads this entire reference before making changes is the modder whose changes work as intended across the full game, not just in a single test session.
Every weapon in Unturned has three independent damage blocks, and a modder can tune any block without affecting the other two. The Maplestrike's Player_Damage of 40 and Zombie_Damage of 99 are different base values applied to different entity types, and changing one has no effect on the other. This independence is intentional: it allows the game designers to balance PvP lethality and PvE efficiency separately. A weapon that is balanced for PvP at 40 base damage might feel too weak against zombies, so Zombie_Damage of 99 compensates. A modder who wants to create a weapon that excels against zombies but is weak against players would lower Player_Damage while raising Zombie_Damage. The Maplestrike's existing split between PvE and PvP damage is not an inconsistency -- it is the design pattern that all military-grade weapons follow, and a modder creating new weapons should follow the same pattern unless they have a specific reason to deviate.
The same GUID that identifies the Maplestrike asset (38508a1f73c8417a8a68cb675460d0b6) is also used when a workshop mod declares the Maplestrike as a dependency. In the mod's manifest, the author references this GUID to tell the engine: "this mod requires the Maplestrike asset to exist, do not load without it." This allows workshop mods to extend or modify the Maplestrike through custom spawn tables, crafting recipes, or plugin code without bundling a copy of the vanilla asset. The dependency system ensures that the mod loads after the vanilla Maplestrike asset and can safely reference it by GUID at runtime.