Yuri Carbine Asset Reference
The Yuri is a Rare Secondary weapon in Unturned, defined by item ID 1041 and carrying the globally unique identifier 5f49e7e1f8584797a9a859d66722d19c. If you are searching for "Yuri carbine unturned stats" or "item ID 1041 damage values" or "5f49e7e1f8584797a9a859d66722d19c spawn locations", this reference is the complete mechanical breakdown of every field in the asset file. This document is written for modders and server owners who need to understand exactly what the game engine reads from the asset data -- not for players looking for a weapon tier list or a gameplay strategy guide. Every number on this page comes directly from the game files. Nothing is estimated, nothing is inferred, and nothing is pulled from general Unturned knowledge that is not explicitly present in the asset definition for this specific weapon.
This article walks through every data block in order: identity keys, ballistics, damage profiles for all three target types (players, zombies, animals), handling, asset flags, and the complete spawn table reference across five maps. If you are reading this to learn how Unturned weapon data works in general, the Yuri is a complete worked example -- it has every major data category a weapon can carry.
What the Yuri is, at the asset level
At the asset level, the Yuri is a collection of key-value pairs and flag tokens stored in a Unity asset bundle. The game engine loads this bundle during the initialisation sequence -- either at world load for server-authoritative items or at client connection for client-predicted items -- and deserialises every field into in-memory data structures that the gameplay systems can query. When a player picks up a Yuri, the engine does not read the bundle again; it references the already-deserialised asset data in memory. When the player fires the weapon, the engine reads the ballistic fields from that in-memory structure. When the projectile hits a target, the engine reads the damage fields. At no point during runtime gameplay does the engine touch the original asset file on disk; the deserialisation happens once at load time, and all subsequent operations work against the cached data.
This load-once, query-many architecture has practical implications for modders. If you modify a value in the asset bundle and the game is already running, the change will not take effect until the asset is reloaded -- typically by restarting the game or, on a server, by triggering a plugin-driven asset reload if your server framework supports it. If you are creating a workshop mod that overrides the Yuri, your mod's asset bundle is loaded instead of the base game's bundle when your mod is active, and your values are the ones that get deserialised. The base game's bundle still exists on disk, but the engine uses the override.
The in-game description reads: "Russian carbine chambered in Ranger ammunition." This description is a localised string stored alongside the asset in the same bundle. The game displays this string in the inventory panel when a player hovers over or inspects the item. It is purely cosmetic from a mechanical standpoint -- changing this string does not alter how the weapon fires, how much damage it does, what ammunition it accepts, or how it interacts with any other game system. It exists only to give the item a flavour identity within the game's fiction. The word "Ranger" in the description corresponds to the Caliber field, which we will examine in detail in the ballistics section below. The string "Russian carbine" communicates the weapon's real-world inspiration, but again, it has no mechanical weight -- the engine does not parse the description string, does not use it for any lookup or matching operation, and does not change any behaviour based on its contents.
Identity keys: item ID, GUID, rarity, and slot
Every item in Unturned has an item ID, which is a plain integer that the game uses as a runtime handle to look up the asset. The Yuri has item ID 1041. This number appears in spawn table definitions (as we will see in the spawn table section), in save files when a player's inventory is serialised to disk, in server log output when a plugin reports which item a player interacted with, and in any mod or plugin that needs to reference the Yuri programmatically.
Item ID 1041 is the integer you pass to server commands, plugin APIs, and loot-table configuration files when you want to add, remove, or query this specific weapon. On a RocketMod server, a command like /give Butter 1041 would place a Yuri in the player named Butter's inventory. In an OpenMod plugin written in C#, you would reference the Yuri by its item ID when calling asset-query methods. In a JSON loot-table override file, you would write "itemId": 1041 to specify that a particular loot slot should contain the Yuri.
The relationship between item IDs and asset data is a simple index. The game maintains an internal array or dictionary that maps integer item IDs to asset objects. When the engine needs to resolve item ID 1041, it looks up index 1041 in that table and retrieves the deserialised Yuri asset. This means item IDs are positional in the asset registration order. If a mod registers a new item at index 1041 before the base game's Yuri is loaded, the lookup for 1041 will return the mod's item instead. This is why GUID-based references are preferred for cross-mod compatibility -- the GUID bypasses the positional registration order entirely.
The GUID, 5f49e7e1f8584797a9a859d66722d19c, is a different kind of identifier. It is a 128-bit hex string -- thirty-two hexadecimal characters, typically displayed as a single contiguous string with no hyphens or grouping -- that uniquely identifies the asset object across the entire Unturned ecosystem. GUIDs are generated once when the asset is first created in the Unity Editor, and they persist across file renames, repacks, workshop uploads, and game updates. The GUID does not change if the Yuri's item ID changes. It does not change if the asset bundle is moved to a different folder. It does not change if a mod overrides the item ID 1041 slot with a different item. The GUID is a property of the Unity asset object itself, not a property of its registration index.
When a plugin or a server configuration references the Yuri by its GUID rather than its item ID, the engine resolves the reference by searching its loaded asset registry for the object with the matching GUID. This search is not positional -- it does not depend on what order items were registered -- which makes GUID references inherently more stable across mod load orders and game version updates. If you are writing a mod that needs to find the Yuri's asset reliably regardless of what other mods the player has installed, reference it by GUID 5f49e7e1f8584797a9a859d66722d19c, not by item ID 1041.
The rarity of the Yuri is Rare. Rarity in Unturned is a categorical field with a fixed set of values, not a continuous probability. The possible rarity values form a discrete scale -- Common, Uncommon, Rare, Epic, Legendary, Mythical -- and each item is assigned exactly one value from that scale. The engine reads the rarity value from the asset during the deserialisation step and uses it for two purposes.
First, it determines the colour that the item's name text renders in when the player views it in the inventory interface, in loot containers, on the ground as a dropped item, and in any other UI context that displays item names. Rare items in the standard Unturned colour scheme are typically displayed in a blue-tinted text colour, though the exact colour mapping is a UI theme constant and may differ if the player uses a custom UI mod or a colour-blind accessibility mode.
Second, the rarity value interacts with spawn tables that are configured to filter or weight items by rarity. A spawn table that is tagged to include items up to the Rare tier will consider the Yuri eligible. A spawn table that is tagged for Common items only will exclude the Yuri. The rarity value does not by itself determine how likely the Yuri is to spawn -- that is determined by the weight or percentage value in each specific spawn table entry, as detailed in the spawn table section later in this document. Rarity is a filter criterion that the spawn system uses to decide whether to include the item in candidate selection at all, not a direct probability.
The slot is Secondary. This means the Yuri occupies the secondary weapon slot in the player's inventory -- the same slot that handguns, sawn-off shotguns, compact submachine guns, and other one-handed or compact two-handed weapons occupy. The game enforces the slot assignment mechanically and unconditionally. A player cannot equip a Secondary weapon in the Primary slot. The engine will not allow the equip operation, and the UI will not present the option. A player cannot have two Secondary weapons equipped at the same time -- equipping a new Secondary weapon replaces the currently equipped one, and the displaced item moves to an available inventory slot or drops to the ground if no space is available.
The slot assignment also determines the default hotkey binding. In the standard Unturned control scheme, the Primary weapon is mapped to the "1" key and the Secondary weapon is mapped to the "2" key. When a player presses "2", the engine checks whether the Secondary inventory slot contains an item, and if it contains the Yuri, the engine initiates the equip animation sequence and makes the Yuri the active wielded item. The slot assignment is independent of the weapon's size, weight, or real-world classification. A compact carbine and a large revolver both occupy the Secondary slot if their asset data says so.
Ballistics: the firing behaviour of the Yuri
Ballistics in Unturned are not a physics simulation. The game does not model bullet drop, wind resistance, air density, barrel temperature, Coriolis effect, or any of the other physical phenomena that real-world ballistics must account for. Instead, the engine reads a small set of numeric and string fields from the asset and applies a set of deterministic, engine-level rules that govern how the projectile is spawned, how far it travels before it despawns, how quickly successive shots can be discharged, what firing mode the weapon defaults to, what ammunition type it accepts, what muzzle device thread pattern it uses, and how much ammunition it carries when it first appears in the world.
Each of these pieces of behaviour is governed by exactly one field or a combination of two fields. There are no hidden modifiers, no derived statistics computed from combinations of other values, and no global constants that scale these values differently depending on game mode, difficulty, or server settings. The values below are the values the engine reads, and they are the only values that matter for this weapon's firing behaviour.
Here is the ballistic table for the Yuri, exactly as it appears in the asset definition:
| Field | Value |
|---|---|
| Range | 100 |
| Firerate | 3 |
| Action | Trigger |
| Caliber | 27 |
| Muzzle | 3 |
| Magazine | 1042 |
| Ammo_Min | 16 |
| Ammo_Max | 64 |
Let us walk through each field, one at a time, and explain not just what the value is, but what the engine does with it internally, step by step, and what would happen if you changed it.
Range
Range is set to 100. In the Unturned engine, the Range field defines the maximum distance, in game units, that a projectile from this weapon will travel from its spawn point before the engine destroys it. When the player pulls the trigger and the weapon discharges, the engine spawns a projectile object at a position determined by the barrel attachment point transform on the weapon's 3D model. The projectile object has a velocity vector (its direction and speed) and a lifetime counter that is initialised to zero. On each simulation tick -- each invocation of the game's FixedUpdate loop -- the engine advances the projectile's position along its velocity vector by an amount determined by the projectile's speed and the tick delta, and then increments the lifetime counter by the distance travelled during that tick.
After advancing the position, the engine checks whether the accumulated distance (the distance from the spawn point to the current position) exceeds the Range value. If it does not, the projectile continues to exist; the engine performs collision checks against hitboxes in the projectile's path, and if a collision is detected, the projectile deals damage and is destroyed. If the accumulated distance does exceed 100, the engine destroys the projectile immediately without doing any further collision checks and without dealing any damage.
The value 100 is the literal integer stored in the asset. The engine does not add any multiplier, conversion factor, or modifier to it. It does not convert it from game units to real-world metres. It does not scale it based on the player's skill level, the server's difficulty setting, or any status effect. If you were to lower this value -- change it to 50, for example -- the projectile would despawn at half the distance, effectively halving the weapon's maximum effective range. If you were to raise it to 200, the projectile would travel twice as far before being culled. The relationship between the stored integer and the engine behaviour is direct and linear.
Firerate
Firerate is set to 3. This field governs the delay between successive shots when the weapon is fired. The engine reads the Firerate value during the weapon initialisation step and stores it as part of the weapon's runtime state. When the player pulls the trigger, the engine fires one shot and then enters a cooldown state. During the cooldown state, further trigger inputs are ignored. The cooldown state lasts for a number of simulation ticks that is derived from the Firerate value according to the engine's internal timing formula -- a formula that is an engine-level constant, not a per-weapon parameter.
A lower Firerate value produces a longer delay between shots. A higher Firerate value produces a shorter delay. The value 3 is the literal integer from the asset file, and it is the only number you should use when comparing the Yuri's rate of fire against other weapons in the game's data. Do not convert Firerate 3 into a rounds-per-minute value or a seconds-between-shots value unless you are working inside a plugin that has access to the engine's tick-rate constant and can perform the conversion accurately. The conversion depends on a constant that is not part of this weapon's asset data and is therefore outside the scope of this reference.
If you were to change the Firerate value from 3 to a different integer, the cooldown between shots would change accordingly. The exact magnitude of the change depends on the engine's tick-rate-to-delay mapping, but the direction is consistent: higher integer equals shorter delay. If you are balancing the Yuri against other weapons in your server configuration, compare Firerate values directly -- do not convert them first, because the conversion step introduces opportunities for error and because different server frameworks may use different conversion formulas.
Action
Action is set to Trigger. The Action field tells the engine which firing behaviour to use as the weapon's default fire mode -- the mode the weapon is in when it is first equipped or when the player has not manually cycled to a different mode via the fire-selector keybind.
"Trigger" as an Action value means that each activation of the fire input (typically a mouse click or controller trigger pull) produces exactly one shot. When the player presses the fire key, the engine checks the current fire mode, sees Trigger, discharges one projectile, and then waits for the fire key to be released and pressed again before discharging another. This is distinct from an Action value of "Auto," which would cause the weapon to discharge continuously as long as the fire key is held down, cycling through the Firerate-based cooldown between each shot automatically.
The Action field is the base firing behaviour. The Yuri also carries Auto and Semi flags (discussed in the flags section below), which means the player can cycle the fire mode to Auto or Semi in addition to the default Trigger behaviour. The Action field determines what mode the weapon starts in; the flags determine what other modes are available for the player to cycle to. If the Auto flag were absent but the Action field remained Trigger, the weapon would be locked to Trigger-only behaviour regardless of the fire-selector keybind.
Caliber
Caliber is set to 27. The Caliber field is an integer that identifies an ammunition type. When the game checks whether a magazine item or a loose ammunition item can be loaded into the Yuri, it compares the Caliber value of the ammunition item against the Caliber value of the weapon. If both values are 27, the engine allows the loading operation -- the magazine snaps into the weapon, the loose round chambers, the reload animation plays, and the ammunition counter updates. If the ammunition item's Caliber value is anything other than 27, the engine rejects the operation. The player may see an error message, a red outline on the incompatible item, or simply no response from the reload key -- the exact UX behaviour depends on the engine's inventory system implementation, not on the Yuri asset.
The value 27 is not a real-world calibre measurement in millimetres or inches. It is an internal Unturned ammunition type ID -- an arbitrary integer that the game's designers assigned to group weapons and their compatible ammunition together. The in-game description calls this ammunition type "Ranger ammunition," which is the display name associated with Caliber 27 in the game's localisation files. Other weapons in Unturned may also use Caliber 27, and any of them will accept the same ammunition pool as the Yuri.
If you were to change the Yuri's Caliber from 27 to a different number -- say, 1, which might correspond to a different ammunition family -- the Yuri would stop accepting Caliber 27 magazines and ammunition and would instead accept magazines and ammunition with Caliber 1. It would also stop being compatible with the Ranger ammunition display name (assuming that name is tied to Caliber 27 in the localisation) and would adopt whatever display name is associated with the new Caliber value. The Caliber field is the single source of truth for ammunition compatibility; changing it changes everything about what the weapon can be loaded with.
Muzzle
Muzzle is set to 3. The Muzzle field is an integer that identifies a type of muzzle attachment socket -- sometimes called a "barrel thread pattern" or "muzzle device mount" in firearm terminology. When the game checks whether a barrel attachment (a suppressor, a muzzle brake, a compensator, a flash hider, a bayonet lug) can be attached to the Yuri, it compares the Muzzle value of the attachment item against the Muzzle value of the weapon.
The comparison is a direct integer equality check. If the attachment's Muzzle value is 3, the engine allows the attachment operation. If the attachment's Muzzle value is any other integer, the engine rejects it. The engine does not consider the weapon's Caliber, its physical barrel diameter, its barrel length, or any other property. The Muzzle field is the sole gate for barrel attachment compatibility.
If you are creating a custom barrel attachment for the Yuri, set your attachment's Muzzle field to 3, and the engine will permit it to be mounted. If you are creating a barrel attachment that you want to be compatible with multiple weapons, you must ensure that all of those weapons share the same Muzzle value. If you want the Yuri to accept a different set of barrel attachments, change its Muzzle value to match the value used by the attachments you want to permit.
Magazine
Magazine is set to 1042. The Magazine field does not store a capacity number -- it does not tell you how many rounds the magazine can hold. Instead, it stores an item ID. The value 1042 is the item ID of the magazine item that the Yuri accepts as its default feeding device.
When the engine spawns a Yuri in the world -- whether from a loot container, a spawn node, an admin command, or a plugin invocation -- it reads the Magazine value, looks up item ID 1042 in the item registry, finds the magazine asset, instantiates a magazine object from that asset, and attaches it to the Yuri. The magazine object contains its own fields: its own item ID, its own Caliber (which must match the Yuri's Caliber of 27 for the magazine to have been associated with the Yuri in the first place), and its own capacity value that defines how many cartridges the magazine can hold.
The capacity of the magazine -- the maximum number of rounds it can contain when fully loaded -- is a property of item ID 1042, not of the Yuri asset 1041. This document does not describe item 1042; it describes item 1041. If you want to know the Yuri's magazine capacity, you must look up item 1042. The Yuri asset only tells you which magazine it references; the magazine asset tells you what that magazine can do.
If you were to change the Magazine field from 1042 to a different item ID, the Yuri would spawn with that different magazine instead. This change would only work correctly if the replacement magazine also has Caliber 27 (matching the Yuri's Caliber) and if the replacement magazine's model and animations are compatible with the Yuri's 3D model rig. Otherwise, you would see visual glitches, animation errors, or an ammunition misconfiguration at runtime.
Ammo_Min and Ammo_Max
Ammo_Min is set to 16 and Ammo_Max is set to 64. These two fields define the range of ammunition load that the Yuri can have when the engine creates a fresh instance of the weapon. When the engine instantiates a new Yuri -- whether it is spawning in a loot crate, appearing on the ground as a world drop, or being generated by an admin command -- it performs the following procedure for the ammunition state:
- It retrieves the Ammo_Min and Ammo_Max values from the asset.
- It generates a random integer within the inclusive range bounded by Ammo_Min and Ammo_Max. The specific random-generation algorithm used is not defined in the asset; it is part of the engine's item-spawning subsystem. The range is inclusive at both ends, meaning the generated value can be exactly 16 or exactly 64.
- It sets the remaining ammunition count in the attached magazine to the generated value. If the generated value exceeds the magazine's actual capacity (as defined in the magazine asset 1042), the engine clamps the ammunition count to the magazine's capacity. If the generated value is below zero -- which cannot happen because Ammo_Min is 16 -- the engine clamps it to zero.
Ammo_Min of 16 means the weapon will never spawn with fewer than 16 rounds in its loaded magazine. Ammo_Max of 64 means the weapon will never spawn with more than 64 rounds in its loaded magazine. These values do not represent the magazine's capacity -- as noted above, the magazine capacity is defined in the magazine asset item 1042. Ammo_Min and Ammo_Max represent the initial ammunition state of a freshly spawned weapon instance. This distinction is important for server owners who configure loot economy settings. If you want every spawned Yuri to come with a full magazine, set Ammo_Min and Ammo_Max both equal to the magazine's capacity. If you want the ammunition to vary unpredictably, widen the gap between Ammo_Min and Ammo_Max.
Player damage: how the Yuri harms other players
When the Yuri's projectile intersects a player hitbox, the engine applies damage according to a two-step calculation. This is the same calculation used for all ranged weapons in Unturned, which means understanding the Yuri's specific values also teaches you how to read the damage block of any other weapon.
Step one: the engine retrieves the base Player_Damage value from the asset. Step two: the engine identifies which body part the projectile struck by checking which hitbox was intersected (the leg hitbox, the arm hitbox, the spine/torso hitbox, or the skull/head hitbox) and retrieves the corresponding multiplier from the asset -- Player_Leg_Multiplier, Player_Arm_Multiplier, Player_Spine_Multiplier, or Player_Skull_Multiplier. The engine then multiplies the base damage by the hit-zone multiplier, and the result is the actual damage value subtracted from the target player's health pool.
This calculation is deterministic. The same base damage and the same multiplier combination always produce the same result. There is no random variation, no damage falloff over distance (the Range field only governs projectile lifetime, not damage scaling), no critical hit chance, and no armour penetration calculation at this step -- armour and other damage modifiers are applied by the engine after the base damage calculation, in a separate pass that is not governed by the weapon's asset values and is therefore outside the scope of this reference.
Here is the player damage multiplier table, exactly as it appears in the asset definition:
| Field | Value |
|---|---|
| Player_Damage | 22 |
| 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 set to 22. This is the base damage value the engine uses as the starting point for all player damage calculations with this weapon. Every hit against a player target begins with 22 as the raw damage number, and then the multiplier for the struck body part scales it up or down from there.
The value 22 is an abstract damage point in the Unturned health system. The engine does not display this number to players during gameplay, nor does it represent any real-world unit of kinetic energy or tissue trauma. It is simply the value that the game's health subtraction logic operates on. If you were to raise Player_Damage from 22 to a higher number, every body-part hit would deal proportionally more damage, because the multipliers would be applied to a larger base. If you were to lower it, every hit would deal less damage. The multipliers themselves would not change, but the final result of every multiplication would shift up or down in lockstep with the base.
The choice to set Player_Damage to 22 is a balance decision by the game's designers. It reflects their assessment of how powerful a carbine should feel against player targets given the overall health economy of the game. Changing this value is the simplest and most direct way to rebalance the Yuri's player-versus-player performance without touching the per-hit-zone multipliers.
Player_Leg_Multiplier
Player_Leg_Multiplier is set to 0.6. When a Yuri projectile hits a player's leg hitbox, the engine multiplies the base Player_Damage of 22 by 0.6. The result is a value that is 60% of the base damage. This reduction reflects the game's assumption that extremity hits are less immediately incapacitating than centre-mass or head hits.
The multiplier is applied as a direct scalar multiplication. The engine does not clamp the result, apply a curve, or cap it at any maximum. It does not check whether the player is sprinting, crouching, or standing still. It does not apply a different multiplier for the left leg versus the right leg -- leg hitboxes on either side of the character model are treated identically by the same multiplier value.
If you were to change Player_Leg_Multiplier from 0.6 to a different value, leg shots would deal a different proportion of the base damage. Setting it to 0.3, for example, would make leg shots deal only 30% of base damage, while leaving all other hit zones unchanged. Setting it to 1.0 would make leg shots deal the full base damage, removing the penalty for extremity hits entirely.
Player_Arm_Multiplier
Player_Arm_Multiplier is set to 0.6. Arm hits are treated identically to leg hits by this weapon's damage profile. The engine applies the same 0.6 multiplier to base damage when the projectile strikes an arm hitbox.
The symmetry between the arm and leg multipliers (both 0.6) means the Yuri makes no mechanical distinction between upper and lower limb hits against player targets. A shot to the arm and a shot to the leg deal the same damage. This is a designer choice, not an engine constraint -- the asset format supports different values for each multiplier, and some other weapons in Unturned may have asymmetric limb multipliers. The Yuri chooses symmetry: 0.6 for both.
Player_Spine_Multiplier
Player_Spine_Multiplier is set to 0.8. A hit to the spine or torso region multiplies the base damage by 0.8. This is higher than the limb multipliers (0.6) but lower than the skull multiplier (1.1), creating a three-tier damage gradient: limbs at the bottom, torso in the middle, and head at the top.
The spine multiplier of 0.8 means that a torso hit deals 80% of the base damage -- still less than the full 22, but significantly more than a limb hit's 60%. The designers have chosen to make the torso a more rewarding target than the limbs but not as rewarding as the head. This creates a risk-reward trade-off in aim placement: aiming for the torso is safer (it is the largest hitbox on most character models) but less damaging than aiming for the head, which is smaller and harder to hit under movement.
Player_Skull_Multiplier
Player_Skull_Multiplier is set to 1.1. The skull is the only body part that receives a multiplier above 1.0 from this weapon. A headshot against a player target deals 110% of the base damage -- 10% more than the base value of 22.
The skull multiplier of 1.1 is notable because it is above 1.0 -- it is a damage bonus, not a penalty. Every other hit zone on a player target uses a multiplier below 1.0, meaning those hits deal less than the full base damage. The skull is the only zone where the Yuri actually exceeds its base damage value. This makes headshots the optimal choice for maximising damage output against player targets, though the difference between a torso hit at 0.8 and a skull hit at 1.1, while meaningful, is not as extreme as it could be if the skull multiplier were, say, 2.0 or 3.0.
Pre-computed player hit-zone damage
The extracted asset data provides a pre-computed per-hit-zone table for player targets. These values are derived by multiplying the base Player_Damage of 22 by each body part's multiplier. They are presented exactly as computed in the extracted asset data, and the computation is not re-performed here:
| Hit zone | Multiplier | Damage (base 22) |
|---|---|---|
| Skull | 1.1 | 24.2 |
| Spine | 0.8 | 17.6 |
| Arm | 0.6 | 13.2 |
| Leg | 0.6 | 13.2 |
This table is a convenience view of the same data already described. It consolidates the base damage and the multiplier into a single "effective damage per hit" number, which is useful when you are configuring a damage-override plugin that asks for per-zone absolute damage values rather than base-plus-multiplier pairs.
The Skull entry of 24.2 corresponds to Player_Damage 22 multiplied by Player_Skull_Multiplier 1.1. The Spine entry of 17.6 corresponds to 22 multiplied by 0.8. The Arm and Leg entries are both 13.2, corresponding to 22 multiplied by 0.6 in both cases. The symmetry in the Arm and Leg values is a direct consequence of the multipliers both being 0.6.
When you are modding this weapon, you have two possible modification strategies. Strategy one: change Player_Damage, which moves every hit-zone value up or down together while preserving the ratios between zones. Strategy two: change a specific multiplier, which moves only that hit zone's final damage without affecting the others, altering the relative reward of hitting that zone versus others.
Zombie damage: how the Yuri harms zombie NPCs
Zombies use a completely different damage configuration block from players. The fields have the same names and the same structural logic -- base damage, leg multiplier, arm multiplier, spine multiplier, skull multiplier -- but the values are independent. A weapon can be devastating against zombies and weak against players, or vice versa, and the asset format fully supports this separation.
The Yuri exploits this separation aggressively. Its Zombie_Damage base is 80, which is significantly higher than its Player_Damage base of 22. This means the Yuri deals substantially more damage per hit to zombie targets than to player targets, before any multiplier is applied. The game's designers have chosen to make the Yuri a potent anti-zombie weapon while keeping its player-versus-player damage more restrained. The reason for this choice is a game-design decision, not a technical constraint, and it is visible directly in the asset values below.
Here is the zombie damage multiplier table, exactly as it appears in the asset definition:
| Field | Value |
|---|---|
| Zombie_Damage | 80 |
| 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 set to 80. This is the base damage value for zombie targets. Compare this to the Player_Damage of 22: the zombie base is more than three and a half times larger. Every hit against a zombie starts from 80 rather than 22. Even a limb hit, which we will see is heavily penalised by the zombie multipliers, still computes from a starting point of 80 before the multiplier reduces it.
The separation of zombie and player damage into independent base values is one of the most powerful balancing tools available to modders working with Unturned weapon assets. You can tune the Yuri's PvE performance without affecting its PvP performance. You can make it a zombie-clearing powerhouse while keeping it balanced against human opponents. Or you can invert the relationship -- set Zombie_Damage lower than Player_Damage -- to create a weapon that is specialised for player combat and weak against the undead. The asset format imposes no relationship between the two values.
Zombie_Leg_Multiplier
Zombie_Leg_Multiplier is set to 0.3. Leg hits on zombies are more punishingly reduced than leg hits on players, which use a 0.6 multiplier. Where a player leg hit deals 60% of the (lower) base of 22, a zombie leg hit deals only 30% of the (higher) base of 80.
This steep reduction -- cutting the damage to less than a third of the base -- incentivises aim discipline when fighting zombies with the Yuri. A misaimed leg shot against a zombie wastes a significant fraction of the weapon's potential damage output. The multiplier of 0.3 is the lowest multiplier in the Yuri's entire damage profile across all three target types, making zombie leg hits the least efficient way to use this weapon.
Zombie_Arm_Multiplier
Zombie_Arm_Multiplier is set to 0.3. As with the player damage profile, the arm and leg multipliers are symmetric for zombie targets. An arm hit applies the same 0.3 multiplier as a leg hit. The engine treats all limb hitboxes on zombie character models as the same damage category, with no distinction between upper and lower extremities.
Zombie_Spine_Multiplier
Zombie_Spine_Multiplier is set to 0.6. A torso hit against a zombie applies 60% of the base damage of 80. This is double the limb multiplier of 0.3 -- a torso hit deals twice as much damage as a limb hit against the same zombie target. The jump from 0.3 to 0.6 is significant and creates a clear incentive to aim for centre mass rather than extremities when engaging zombies.
Zombie_Skull_Multiplier
Zombie_Skull_Multiplier is set to 1.1. The skull multiplier for zombies is the same value as the skull multiplier for players -- 1.1, a 10% bonus above the base. This is the only multiplier value that is identical across the player and zombie damage profiles. The designers made the headshot bonus a universal constant for the Yuri while tuning every other multiplier differently for different target types.
Because the zombie base damage is 80 rather than 22, the absolute bonus from a zombie headshot is larger in damage-point terms even though the percentage bonus is the same. The headshot adds 10% of 80 (8 additional damage points) compared to 10% of 22 (2.2 additional damage points) for a player target.
Pre-computed zombie hit-zone damage
Here is the pre-computed zombie damage per hit zone, exactly as it appears in the extracted asset data:
| Hit zone | Multiplier | Damage (base 80) |
|---|---|---|
| Skull | 1.1 | 88 |
| Spine | 0.6 | 48 |
| Arm | 0.3 | 24 |
| Leg | 0.3 | 24 |
A skull hit against a zombie delivers 88 damage. This is Zombie_Damage 80 multiplied by Zombie_Skull_Multiplier 1.1. The Spine hit delivers 48 damage -- 80 multiplied by 0.6. The Arm and Leg entries both deliver 24 damage -- 80 multiplied by 0.3. The tiered structure is the same as the player damage profile in terms of which body parts rank where (skull at the top, spine in the middle, limbs at the bottom), but the absolute numbers are substantially larger because the base is 80 instead of 22.
Note the progression: 24 (limbs) to 48 (spine) to 88 (skull). Each step up the body ladder roughly doubles the damage output against zombies with this weapon.
Animal damage: how the Yuri harms animal NPCs
Animals form a third damage category in the Yuri's asset, separate from both players and zombies but sharing certain structural properties with the player damage profile. The Yuri's animal damage profile shares its base value with the player damage profile (22, compared to the zombie base of 80), and it also shares the player profile's leg and spine multipliers. The key difference -- and it is a structural one, not just a numeric one -- is that the animal damage block does not include an Arm multiplier at all, because the hitbox configuration for animal NPCs in Unturned does not include a distinct arm region.
Here is the animal damage multiplier table, exactly as it appears in the asset definition:
| Field | Value |
|---|---|
| Animal_Damage | 22 |
| Animal_Leg_Multiplier | 0.6 |
| Animal_Spine_Multiplier | 0.8 |
| Animal_Skull_Multiplier | 1.1 |
Animal_Damage
Animal_Damage is set to 22. This is identical to the Player_Damage base of 22. The Yuri treats animal targets the same as player targets at the base damage level, which means any differentiation between how the weapon performs against animals versus players comes entirely from the multiplier configuration, not from the base value.
Animal_Leg_Multiplier
Animal_Leg_Multiplier is set to 0.6. A leg hit on an animal reduces the base damage to 60%, the same proportion as a player leg hit. This is notably higher than the zombie leg multiplier of 0.3, meaning leg shots against animals are less heavily penalised than leg shots against zombies, relative to their respective base values.
Animal_Spine_Multiplier
Animal_Spine_Multiplier is set to 0.8. A torso hit applies the same multiplier as a player torso hit. The Yuri groups animals and players together on the spine multiplier, while reserving the harsher limb penalty (0.3 instead of 0.6) for zombies.
Animal_Skull_Multiplier
Animal_Skull_Multiplier is set to 1.1. The skull multiplier of 1.1 is consistent across all three target types -- players, zombies, and animals all use a 1.1 skull multiplier for the Yuri. This suggests that the weapon's headshot bonus is treated as a universal constant by the designers rather than something that is tuned differently per target type.
Pre-computed animal hit-zone damage
The extracted asset data provides a pre-computed per-hit-zone table for animal targets. Note that there is no Arm row because animal hitboxes do not expose a separate arm zone in the game's character rig:
| Hit zone | Multiplier | Damage (base 22) |
|---|---|---|
| Skull | 1.1 | 24.2 |
| Spine | 0.8 | 17.6 |
| Leg | 0.6 | 13.2 |
The Skull value of 24.2 for animals is identical to the Skull value for players, because both use base damage 22 and a 1.1 multiplier. The Spine value of 17.6 is also identical to the player Spine value. The Leg value of 13.2 matches the player leg value. Effectively, the animal and player damage profiles for the Yuri are identical for the hit zones they share.
The absence of an Arm row is not a gap or a defect in the data. It reflects the fact that the animal hitbox system in Unturned does not define an arm zone, so the Yuri asset does not define an Animal_Arm_Multiplier field. If you were modding this weapon to target a custom NPC type that does have an arm hitbox, you would need to add the arm multiplier field to the asset yourself.
Handling: recoil, spread, and camera shake
The handling block controls how the weapon behaves in the player's hands during and after firing. It defines recoil patterns -- the predictable and random components of how the aim point shifts after each shot -- as well as aim spread (the baseline deviation of the projectile from the crosshair centre) and camera shake (a transient screen wobble effect that is separate from persistent recoil).
These values are consumed by two game systems: the first-person camera controller and the crosshair rendering system. When the weapon discharges, the engine reads the recoil values to compute a new aim offset, reads the spread value to determine how much random deviation to apply to the projectile's trajectory, and reads the shake values to compute a temporary camera displacement that decays over a short duration. All of these computations happen inside the same firing event, and they are independent of each other -- changing the recoil does not affect the shake, and changing the spread does not affect the recoil.
Here is the handling table, exactly as it appears in the asset definition:
| Field | Value |
|---|---|
| Recoil_Min_X | 1 |
| Recoil_Min_Y | 2.5 |
| Recoil_Max_X | 2 |
| Recoil_Max_Y | 3.5 |
| Spread_Aim | 0.1 |
| Shake_Min_X | -0.001 |
| Shake_Max_X | 0.001 |
Recoil_Min_X and Recoil_Max_X
Recoil_Min_X is set to 1 and Recoil_Max_X is set to 2. These two values define the range of horizontal recoil applied to the player's aim point each time the Yuri fires. The X axis in Unturned's coordinate system corresponds to horizontal movement of the aim reticle -- left and right drift across the screen.
When the weapon discharges, the engine generates a random recoil vector. The X component of this vector is a random value bounded below by Recoil_Min_X (1) and above by Recoil_Max_X (2). The engine does not bias the randomisation toward the centre of the range or toward either bound; the randomisation algorithm used is internal to the engine and may follow a uniform distribution, a normal distribution, or a custom curve. Because the asset only specifies the bounds, not the distribution shape, all you can assert from the data is that every shot's horizontal recoil will fall somewhere between 1 and 2, inclusive.
The gap between the minimum (1) and the maximum (2) is 1 unit wide. This relatively narrow range means the horizontal recoil is fairly predictable: the player will experience a consistent horizontal nudge with a modest randomisation component. A weapon with a wider gap -- say, Recoil_Min_X of 0.5 and Recoil_Max_X of 5 -- would feel more erratic because the shot-to-shot horizontal variation would be much larger.
Recoil_Min_Y and Recoil_Max_Y
Recoil_Min_Y is set to 2.5 and Recoil_Max_Y is set to 3.5. These define the vertical recoil range. The Y axis corresponds to vertical movement of the aim reticle -- upward climb of the weapon's muzzle during sustained fire.
Notice that both the minimum and maximum Y values are larger than their X counterparts. Recoil_Min_Y of 2.5 is larger than Recoil_Max_X of 2. This asymmetry means the Yuri's recoil pattern is predominantly vertical -- the weapon climbs upward more aggressively than it drifts horizontally. This is consistent with the real-world behaviour of firearms, where muzzle rise (vertical recoil) is typically the dominant component, but the specific ratio chosen by the designers is encoded directly in these four numbers.
The gap between Recoil_Min_Y (2.5) and Recoil_Max_Y (3.5) is also 1 unit wide, matching the X-axis gap. The randomisation component is the same width on both axes, but because the Y-axis values are higher overall, the absolute randomness is the same magnitude while the base recoil is larger on Y. This means the weapon kicks up consistently, with a small random side-to-side jitter and a small random variation in the upward kick strength from shot to shot.
Spread_Aim
Spread_Aim is set to 0.1. This value governs the crosshair bloom or shot deviation when the player is aiming down sights (ADS). The distinction between aimed and hip-fire spread is important: Spread_Aim applies specifically when the player is in the ADS state, typically triggered by holding the right mouse button or an equivalent aim key. A separate spread field (not shown in this asset extract, and possibly defaulting to a higher value) applies to hip-fire, where the weapon is fired from the shoulder without using the sights.
The value 0.1 represents the base spread radius or angle in the engine's internal aiming units. A lower spread value means the projectile is more likely to travel close to the precise centre of the crosshair -- the weapon is more accurate. A higher value means the projectile can deviate further from the aim point. The engine uses this value as a parameter in its projectile trajectory initialisation: when the projectile is spawned, the engine computes the aim direction from the camera's forward vector, then applies a random angular deviation bounded by the spread value to compute the actual trajectory.
The value 0.1 is the literal number from the asset. Changing it to a smaller number (like 0.05) would make the weapon more accurate while aiming. Changing it to a larger number (like 0.5) would introduce more randomness into aimed shots, making the weapon less reliable at range despite its Range value of 100.
Shake_Min_X and Shake_Max_X
Shake_Min_X is set to -0.001 and Shake_Max_X is set to 0.001. These two values define the range of horizontal camera shake applied when the Yuri fires. Camera shake is a different effect from recoil, and the distinction matters for modders who want to adjust the weapon's feel.
Recoil moves the aim point persistently. When a recoil vector of (1.5, 3.0) is applied, the player's crosshair moves to a new position, and it stays there. The player must manually counter-steer (typically by moving the mouse downward) to bring the crosshair back to the original target. Recoil accumulates over successive shots; if the player fires five shots without correcting, the crosshair drifts further and further from the first shot's aim point.
Camera shake is transient. When a shake vector is applied, the camera wobbles briefly (typically over a fraction of a second) and then returns to its original position. The effect is purely visual -- it makes the screen jitter during firing to communicate the physical sensation of recoil -- but it does not change where the weapon is actually pointing. The aim point returns to its pre-shake position once the shake decays.
The shake values for the Yuri are very small: between -0.001 and 0.001. This range is two thousandths of a unit wide, centred at zero. The small magnitude means the camera shake from this weapon is subtle -- barely perceptible compared to the recoil kick, which operates on values between 1 and 3.5. The symmetry around zero (equal magnitude in the negative and positive directions) means the shake has no directional bias on the X axis; the screen wobbles equally left and right.
Asset flags: behavioural toggles and metadata
In addition to the numeric and string fields described above, the Yuri asset carries a set of flags. Flags are string tokens stored alongside the key-value pairs in the asset bundle. The engine reads these flags during the asset deserialisation step and enables or disables specific game systems based on which flags are present. A flag's presence is a binary condition: the flag is either in the list, or it is not. There is no "strength," "weight," or "degree" associated with a flag. If the flag token appears in the asset, the behaviour it represents is active. If the token does not appear, the behaviour is inactive.
The flags present on the Yuri asset are:
"7b82c125a5a54984b8bb26576b59e977", Auto, Blueprints, Hook_Barrel, Hook_Sight, Hook_Tactical, InputItems, RequiresNearbyCraftingTags, Safety, Semi, [, ],
Let us examine each flag, grouped by the game system it affects.
Fire-mode flags: Auto, Semi, Safety
Three flags in the Yuri's flag list govern its available fire modes: Auto, Semi, and Safety. These flags work in conjunction with the Action field (which we examined in the ballistics section and which is set to Trigger). Together, the Action field and the fire-mode flags define the complete set of fire modes the player can cycle through.
Auto: When this flag is present, the weapon offers a fully automatic fire mode. In automatic mode, the weapon discharges continuously as long as the fire key is held down, cycling through the Firerate-based cooldown between each shot automatically. The player does not need to release and re-press the fire key for each shot.
Semi: When this flag is present, the weapon offers a semi-automatic fire mode. In semi-automatic mode, one shot is discharged per fire-key activation, and the player must release and re-press the key for each subsequent shot. Semi-automatic is similar to the Action field's Trigger behaviour, but having it as a flag means the mode can be cycled via the fire-selector keybind rather than being hardcoded as the only available mode.
Safety: When this flag is present, the weapon includes a "safe" position. When the player cycles the fire mode to Safety, pulling the trigger has no effect -- the weapon will not discharge. Safety mode prevents accidental or intentional firing until the player cycles back to Semi or Auto.
With all three flags present plus the Trigger Action field, the Yuri's fire-mode selector cycles through (at minimum) Safety, Semi, and Auto. The Trigger Action field provides the default starting mode when the weapon is first equipped; the exact default in the presence of multiple fire-mode flags may be determined by engine logic that prioritises certain modes over others.
Attachment hook flags: Hook_Barrel, Hook_Sight, Hook_Tactical
Three flags govern the weapon's attachment compatibility at the 3D model level: Hook_Barrel, Hook_Sight, and Hook_Tactical.
Hook_Barrel: This flag tells the engine that the Yuri's 3D model has a named transform (a GameObject or empty transform node in the Unity hierarchy) designated as the barrel attachment point. When a player attaches a barrel accessory -- a suppressor, a muzzle brake, a compensator, a flash hider -- the engine parents the attachment's 3D model to this transform, positioning and orienting it relative to the weapon's muzzle. Without the Hook_Barrel flag, the engine would refuse to attach any barrel accessory to the Yuri, regardless of Muzzle field compatibility.
Hook_Sight: This flag indicates that the weapon model has a sight attachment point, typically located on the top rail or receiver. When a player attaches a sight -- a red dot sight, a holographic sight, a magnified scope -- the engine parents the sight model to this transform and adjusts the player's first-person view through the sight accordingly. Without this flag, sight attachments cannot be mounted.
Hook_Tactical: This flag indicates a tactical attachment point, typically located on a side rail, under-barrel rail, or handguard. Tactical attachments include laser sights (which project a visible laser dot to indicate the aim point), flashlights (which illuminate the area in front of the player), and rangefinders. Without this flag, tactical attachments cannot be mounted.
The presence of all three hook flags means the Yuri has a full complement of attachment hardpoints: barrel, sight, and tactical. This makes the weapon highly customisable from a modder's perspective, because you can create custom attachments for any of these three categories and they will be mountable on the Yuri as long as the attachment's compatibility integer matches the weapon's relevant field (Muzzle for barrel attachments, and equivalent fields for sight and tactical attachments which are not shown in this asset extract).
Crafting flags: Blueprints, InputItems, RequiresNearbyCraftingTags
Three flags relate to the game's crafting system.
Blueprints: This flag indicates that the Yuri participates in at least one crafting blueprint -- either as an ingredient item that is consumed during a craft, as a result item that is produced by a craft, or as a required tool that must be present in the crafting interface (but is not consumed) for the craft to execute. The engine uses this flag as a filter when displaying items in the crafting search interface; items without the Blueprints flag are excluded from crafting search results even if they appear in blueprint data elsewhere.
InputItems: This flag signals that the Yuri accepts input items during a crafting operation. An input item is an item that is consumed or transformed as part of a crafting recipe. For example, if a blueprint requires a Yuri as an ingredient to produce a modified or upgraded version of the weapon, the Yuri would need the InputItems flag to be eligible for placement in the crafting interface's ingredient slots.
RequiresNearbyCraftingTags: This flag imposes a location requirement on crafting operations that involve the Yuri. When this flag is present, the engine checks whether the player is standing within range of a world object that carries a matching crafting tag. For instance, if a blueprint that produces the Yuri requires the crafting tag "GunsmithingBench," the player must be near a world object (such as a placed workbench or a map-specific crafting station) that also carries the tag "GunsmithingBench" for the craft to be executable. This flag gates crafting behind physical proximity to specific world objects, preventing players from crafting the item anywhere at any time.
Asset reference flag: "7b82c125a5a54984b8bb26576b59e977"
The flag "7b82c125a5a54984b8bb26576b59e977" is a GUID-formatted string -- thirty-two hexadecimal characters with no grouping hyphens, matching the format of the Yuri's own GUID (5f49e7e1f8584797a9a859d66722d19c) and of Unity asset GUIDs in general. This flag is not a behavioural keyword like Auto or Blueprints; it is a reference to another asset object, identified by its GUID.
What this GUID refers to is not resolved from the Yuri asset alone. It might be a specific skin or cosmetic override that is linked to the Yuri's default appearance. It might be an effect prefab -- a muzzle flash particle system, a sound effect template, or an animation override. It might be a related item that the Yuri references for a specific interaction. To determine what the GUID resolves to, you would need to search the game's full asset registry for the object with that specific GUID, which is outside the scope of this per-weapon reference.
Bracket characters: [, ],
The flags [, ], {, and } appear in the extracted asset data's flag list. These are single-character tokens -- a left square bracket, a right square bracket, a left curly brace, and a right curly brace. In some asset serialisation formats (particularly those that store flag arrays as JSON-like or text-serialised data structures), bracket characters can appear as array delimiters or object delimiters rather than as meaningful flags. If the asset data was exported in a format that serialises the flag list as a JSON array, for example, the list might be written as ["Auto", "Semi", ...] with the brackets framing the array. The export tool or the extracted asset data author may have treated these framing characters as part of the flag list.
These characters do not correspond to any known behavioural flag in the standard Unturned flag taxonomy -- opening or closing brackets are not a flag that the engine checks for to enable or disable any gameplay system. If you are writing a plugin or configuration that processes the Yuri's flag list, you should exclude or ignore these characters unless you have specific evidence from your plugin framework's documentation that they carry meaning in your particular environment.
Where the Yuri spawns: spawn table reference
The Yuri appears in spawn tables across five maps: Core (the base game's internal content), Belgium, Ireland, France, and RioDeJaneiro. Each row in the spawning table below represents a discrete entry where the game engine can select the Yuri as a loot item when it evaluates a particular spawn table on a particular map.
The "Chance per roll" column is the probability, expressed as a percentage, that the Yuri is specifically chosen when the engine performs one evaluation (one "roll") of that spawn table. This is the per-roll probability for the Yuri specifically, not the probability that the spawn table itself is triggered. The two probabilities are connected but distinct: the spawn table must first be selected by whatever container, node, or event triggers loot generation, and then, within that table, the Yuri must be selected from among all the possible items. The percentages below describe only the second step.
The spawn table data below is copied exactly from the extracted asset data and must not be reordered, recalculated, or reformatted:
| Map | Spawn table | Chance per roll |
|---|---|---|
| Core | Arena_Guns_Ranger_Common | 33.333% |
| Core | Monolith_Arena_Guns_Ranger | 29.749% |
| Core | Arena_Guns_Ranger | 29.749% |
| Belgium | Militia_Belgium_Guns | 25.000% |
| Core | Military_Low_Guns | 25.000% |
| Ireland | Cliffs_IFR_High_Guns | 19.737% |
| France | Milita_Special_France_Guns | 11.628% |
| Ireland | Cliffs_Airdrop_Weapons_Ranger | 6.522% |
| RioDeJaneiro | Carepackage_Brazil | 4.167% |
| RioDeJaneiro | Brazil_Carepackage_Brazil | 4.167% |
| Ireland | Cliffs_IFR_High | 1.645% |
| Belgium | Militia_Belgium | 1.040% |
| France | Milita_Special_France | 0.822% |
| France | France_Milita_Special_France | 0.822% |
| France | Milita_Super_France | 0.649% |
| France | France_Milita_Super_France | 0.649% |
| France | Rula_France_Living | 0.164% |
| France | France_Rula_France_Living | 0.164% |
| France | Rula_France_Hyrdro | 0.145% |
| France | France_Rula_France_Hydro | 0.145% |
How to read this table
Each row represents a discrete spawn configuration. The "Map" column tells you which game world the spawn table is associated with. The "Spawn table" column gives the internal name of the table, which is the string you use when targeting this specific entry in a loot override plugin or configuration file. The "Chance per roll" column gives the probability that the Yuri is the chosen item when the engine evaluates that table.
It is important to understand the distinction between the per-roll probability and the practical frequency at which a player encounters the Yuri. A spawn table with a 33.333% chance per roll that is only triggered once per map load (for example, a table associated with a single unique loot container in a boss room) will produce far fewer Yuri instances than a spawn table with a 1.000% chance that is triggered by hundreds of common loot nodes every time the map populates. The per-roll percentage is only one factor in the overall loot economy; the trigger frequency of the spawn table is the other factor, and it is determined by map design, server configuration (loot multiplier, respawn interval), and game mode rules -- none of which are encoded in the Yuri asset itself.
The Core map spawn tables
The Core map hosts four spawn table entries for the Yuri, three of which appear in the top five highest-probability entries across all maps.
Arena_Guns_Ranger_Common carries a 33.333% chance per roll. This is the highest probability for the Yuri anywhere in the game's spawn data. The table name tells us several things: it is an "Arena" table (likely associated with a horde-mode or wave-survival arena present in the base game), it belongs to the "Guns" category within that arena, it specifically covers "Ranger" weapons (weapons using Caliber 27 ammunition), and the Yuri's position within it is categorised as "Common" -- meaning it is among the most frequently appearing Ranger weapons in that specific arena context.
Monolith_Arena_Guns_Ranger has a 29.749% chance per roll. The "Monolith" prefix likely designates a specific arena variant or a specific location within the arena map where this table is used. The probability is just under 30%, which is very high relative to most other entries on this list.
Arena_Guns_Ranger also has a 29.749% chance per roll -- identical to the Monolith variant. This is the generic version of the Ranger gun arena table, without a location prefix. The identical probabilities between the Monolith and generic variants suggest the Yuri is weighted the same way across the different arena sub-tables.
Military_Low_Guns has a 25.000% chance per roll. This table is tagged "Low" tier -- within the military weapon category, it occupies the lower tier of loot quality. Despite the "Low" designation, the 25.000% probability is still substantial, putting the Yuri at one in four rolls in this specific table. This is a general military loot table, not an arena table, meaning the Yuri can appear in standard military loot zones on Core maps through this entry.
The Belgium map spawn tables
Militia_Belgium_Guns has a 25.000% chance per roll, matching the Core Military_Low_Guns probability. The "Militia" designation in the table name refers to a militia or resistance faction loot pool specific to the Belgium map. The "_Guns" suffix identifies this as the weapon-specific sub-table within the broader Militia loot ecosystem. At 25.000%, the Yuri is a one-in-four pick when this table is rolled.
Militia_Belgium has a 1.040% chance per roll. Note the missing "_Guns" suffix -- this is the broader Militia loot table that includes items across multiple categories (weapons, ammunition, gear, supplies). Because the item pool is larger and more diverse in the broader table, the probability for any single specific weapon drops dramatically compared to the guns-only sub-table.
The Ireland map spawn tables
Cliffs_IFR_High_Guns has a 19.737% chance per roll. The "Cliffs_IFR" prefix refers to the Irish Forces Rangers or a similar faction associated with the Cliffs landmark on the Ireland map. The "_High_Guns" suffix tags this as a high-tier weapon table, and the 19.737% probability places it in the upper tier of spawn chances for this weapon.
Cliffs_Airdrop_Weapons_Ranger has a 6.522% chance per roll. Airdrop tables are triggered by supply-drop events that occur periodically on the map. The lower probability reflects the fact that airdrops are rarer events with a curated (smaller) selection of possible items; when a Ranger weapon airdrop does trigger, the Yuri is the outcome roughly 6.5% of the time.
Cliffs_IFR_High has a 1.645% chance per roll. As with the Belgium Militia entry, the absence of a "_Guns" suffix means this is a broader loot table containing items beyond just weapons, which dilutes the probability for any single item.
The France map spawn tables
The France map has the largest number of spawn table entries for the Yuri: nine distinct entries. This reflects the France map's larger loot table ecosystem or the designers' decision to distribute the Yuri across more specific, narrow-context tables rather than a few broad ones.
Milita_Special_France_Guns has an 11.628% chance per roll. The "Milita" spelling (with one "i," matching the in-game table name as preserved in the extracted asset data) and the "Special" designation suggest a specific faction sub-table. This is the highest-probability entry for the Yuri on the France map.
Milita_Special_France and France_Milita_Special_France both have a 0.822% chance per roll. These are paired entries -- two different table names with the same probability. The naming pattern (one with and one without a "France_" prefix) suggests that two different spawn point configurations or loot container types reference the same underlying loot pool through different table aliases.
Milita_Super_France and France_Milita_Super_France both have a 0.649% chance per roll. These follow the same paired-entry pattern as the Special tables, but at a lower probability level.
Rula_France_Living and France_Rula_France_Living both have a 0.164% chance per roll. The "Living" designation in the table name suggests civilian or residential area loot on the France map. The probability is below two-tenths of a percent.
Rula_France_Hyrdro and France_Rula_France_Hydro both have a 0.145% chance per roll. These are the lowest-probability entries for the Yuri across all maps. Note the spelling discrepancy between the two table names: the first entry spells it "Hyrdro" (with the "r" before the "d") and the second spells it "Hydro" (with the "r" after the "d"). The extracted asset data preserves both spellings exactly as they appear in the game data. If you are writing a spawn table override that targets one of these tables, you must match the spelling exactly, including the inconsistency, or your override will not apply to the intended table.
The RioDeJaneiro map spawn tables
Carepackage_Brazil and Brazil_Carepackage_Brazil both have a 4.167% chance per roll. These are care package or airdrop-style spawn tables specific to the RioDeJaneiro map, where "Brazil" is used as the map's internal identifier. The paired-entry pattern -- two table names with identical probabilities -- mirrors the pattern seen in the France map entries. At 4.167%, the Yuri is a moderate-probability outcome when a Brazilian care package is opened, sitting between the higher arena probabilities and the lower civilian-area probabilities.
Understanding the probability gradient
When you read the spawn table from top to bottom, the per-roll probability descends from 33.333% down to 0.145%. This gradient is not random; it reflects deliberate loot design choices. The highest-probability entries are concentrated on the Core map and are associated with arena combat contexts where weapons are expected to be plentiful, frequently cycled, and balanced around rapid acquisition and use. The middle-tier probabilities (roughly the 25% to 6% range) are associated with military or militia loot tables on expansion maps, where the Yuri competes for spawn slots against a variety of map-specific content. The lowest probabilities (below 2%) are associated with broad non-weapon loot tables or civilian residential areas, where the Yuri is one of many possible items in a large and diverse pool.
This gradient does not translate directly into "the Yuri is easiest to find on Core" in practical gameplay terms, because the trigger frequency of each spawn table determines the actual number of Yuri instances generated per map load, and trigger frequency is a map-design and server-configuration parameter, not a property of the asset. A spawn table with a 0.145% probability that is evaluated by hundreds of civilian loot containers every map load could generate more total Yuri instances than an arena table with a 33.333% probability that is only evaluated once during a specific wave event.
Canned Beans
The Yuri brief does not mention Canned Beans. This is not an oversight -- it is a deliberate absence that tells us something meaningful about the Yuri's position in the Unturned item ecosystem.
Canned Beans are a running thread in the 57 Studios modding documentation canon. Across the wiki, many item references include a Canned Beans section that traces the item's connection to beans: whether the item appears in the same loot tables that produce Canned Beans, whether it references Canned Beans as a crafting ingredient, whether it shares a Caliber, rarity tier, or item category with beans. The Yuri has none of these connections.
Its spawn tables are all firearm-specific (Arena_Guns_Ranger_Common, Militia_Belgium_Guns, Cliffs_IFR_High_Guns) or faction-specific military loot tables. None of them are civilian food tables, grocery tables, or general supply tables -- the categories where Canned Beans would appear. The Yuri's Caliber is 27, which is a Ranger ammunition type, not a consumable item category. Its Magazine is 1042, a firearm magazine, not a food item. Its crafting flags -- Blueprints, InputItems, RequiresNearbyCraftingTags -- point toward weapon modification and gunsmithing recipes, not toward cooking or food preparation. Its attachment hooks (Barrel, Sight, Tactical) all relate to firearm accessories.
The absence of Canned Beans from the Yuri's data means this weapon exists in a completely separate mechanical universe from the bean economy. A server owner who adjusts Yuri spawn rates does not affect Canned Bean availability. A modder who adds Canned Beans to a custom zombie loot table does not affect the Yuri's behaviour, damage output, or spawn frequency. A plugin that tracks how many Canned Beans a player has collected will never interact with the Yuri's asset data. The two items may coexist in a player's inventory, but they do not reference each other, compete with each other in the same loot tables, or participate in the same crafting recipes.
This separation is typical of weapons in Unturned, and it illustrates a broader design principle in the game's item taxonomy: firearms and consumables are categorically different types of items with different data blocks, different spawn table ecosystems, and different in-game roles. The Canned Beans lore is a consumable-world phenomenon. The Yuri is a weapon-world phenomenon. They intersect only at the level of the player's inventory grid, not at the level of asset data.
For the full canonical treatment of Canned Beans in Unturned's item ecosystem, including their spawn tables, crafting roles, and cultural significance in the modding community, see the dedicated reference page: /lore/canned-beans-lore.
Practical use for server owners and modders
If you are configuring an Unturned server or building a mod or plugin that involves the Yuri, this reference gives you the exact field names, exact values, and exact data structures you need. Every number in this document is a literal value from the asset file, not a derived conversion, not a rounded approximation, and not a community consensus estimate. You can copy these values directly into a RocketMod plugin configuration, an OpenMod JSON file, a custom spawn table override, a Unity asset patch, or any other modding tool that accepts Unturned item data, without worrying about format mismatches or precision errors.
Adjusting damage balance
The three independent damage bases -- Player_Damage (22), Zombie_Damage (80), and Animal_Damage (22) -- are your primary tuning knobs for the Yuri's combat balance. Because these values are completely independent, you have full control over the weapon's performance against each target type.
To make the Yuri stronger in PvP without affecting PvE: raise Player_Damage above 22. All player hit-zone values will scale up proportionally because the multipliers (0.6 for limbs, 0.8 for spine, 1.1 for skull) are applied to the new base.
To make the Yuri weaker against zombies without changing anything about player or animal combat: lower Zombie_Damage from 80 to a smaller number. The zombie hit-zone values (currently 88, 48, 24, 24) will drop in proportion.
To adjust the headshot reward uniformly across all target types: change the skull multiplier. It is currently 1.1 for all three target types. If you want headshots to matter more, raise the skull multiplier. If you want headshots to matter less, lower it. You can also change the skull multiplier for only one target type while leaving the others unchanged.
To make limb hits more or less punishing: adjust the leg and arm multipliers. The current limb multipliers are 0.6 for players and animals, and 0.3 for zombies. Raising these values makes limb hits deal more damage relative to the base. Lowering them makes limb hits less efficient.
Adjusting handling and feel
The handling table gives you four recoil values, one spread value, and two shake values to adjust. Changes to these values affect how the weapon feels in the player's hands during combat.
To increase the vertical kick, raise Recoil_Min_Y and Recoil_Max_Y. The current values are 2.5 and 3.5. Raising both by the same amount preserves the randomisation range while making the overall vertical recoil stronger.
To make the recoil more unpredictable, widen the gap between the minimum and maximum values. For example, keeping Recoil_Min_X at 1 but raising Recoil_Max_X to 4 would make the horizontal recoil vary between 1 and 4 instead of between 1 and 2, producing more erratic left-right drift.
To make the weapon less accurate while aiming, raise Spread_Aim above 0.1. A value of 0.2 would roughly double the projectile deviation while aiming. To make it more accurate, lower Spread_Aim toward zero. At a value of 0, the projectile would travel exactly along the aim direction with no random deviation -- perfect accuracy while ADS.
The camera shake values (Shake_Min_X and Shake_Max_X, currently -0.001 and 0.001) control a visual effect rather than a mechanical one. Most players will not notice changes to these values unless you make them significantly larger.
Configuring spawn behaviour
Each entry in the spawn table is an independent configuration point that you can target with a spawn-override plugin or server configuration. The table names are the strings you use to identify which spawn rule you are modifying.
To make the Yuri more common in Belgian militia loot: target the Militia_Belgium_Guns table (currently at 25.000%) and increase its weight or probability relative to the other items in that table. The exact mechanism for adjusting per-item probability within a spawn table depends on your server framework's plugin API.
To remove the Yuri from a specific map entirely: remove or zero out all spawn table entries for that map. For example, to remove the Yuri from the France map, you would need to remove or disable nine spawn table entries: Milita_Special_France_Guns, Milita_Special_France, France_Milita_Special_France, Milita_Super_France, France_Milita_Super_France, Rula_France_Living, France_Rula_France_Living, Rula_France_Hyrdro, and France_Rula_France_Hydro.
To make the Yuri appear in a spawn table where it is not currently present: add a new entry to your spawn override configuration that references item ID 1041 (or GUID 5f49e7e1f8584797a9a859d66722d19c) in the desired spawn table on the desired map, with your chosen probability.
Working with the item ID and GUID in code
For plugin development:
Item ID 1041 is the integer handle. Use this when calling plugin API methods that accept an item ID parameter, such as
giveItem(1041),player.inventory.hasItem(1041), orspawnTable.addItem(1041, weight). The item ID is the fastest lookup path in the engine's item registry, but it is vulnerable to conflicts if mods register items at the same index.GUID 5f49e7e1f8584797a9a859d66722d19c is the stable asset reference. Use this when you need to find the Yuri's asset regardless of load order, such as in a mod manifest that declares a hard dependency on the Yuri asset, or in a configuration file that must survive game updates where item IDs may shift. GUID-based lookups are slightly slower than item-ID lookups because they require a dictionary search rather than an array index, but they are immune to ID collisions.
In JSON configuration files, if your plugin framework supports GUID references, prefer
"guid": "5f49e7e1f8584797a9a859d66722d19c"over"itemId": 1041. If your framework only supports item IDs, use"itemId": 1041and be aware that mod load order could affect which item is returned.
Attachment compatibility
The Muzzle value of 3 is the integer key that gates barrel attachment compatibility. When you create a custom barrel attachment -- a custom suppressor model, a custom muzzle brake, a custom compensator -- set your custom attachment's Muzzle field to 3, and the engine will permit it to be mounted on the Yuri. If you want your custom barrel attachment to be compatible with the Yuri and with other weapons that use the same attachment thread, find those other weapons' Muzzle values and ensure they are also 3, or set your attachment's Muzzle to match theirs.
The Hook_Barrel flag confirms that the Yuri's model physically supports barrel attachments. If you create a sight attachment instead, you do not need to check the Muzzle value -- you need to check whatever field governs sight compatibility (often called Sight or Scope, not shown in this asset extract). The Hook_Sight flag confirms that the Yuri model has a sight attachment transform. The same logic applies to tactical attachments: check the relevant compatibility field and confirm Hook_Tactical is present.
Understanding what is not here
This reference intentionally omits several types of information that a gameplay strategy guide or weapon comparison video might include. It does not tell you how many shots it takes to kill a player, because the answer depends on the target's current health value, any armour they are wearing, any damage-reduction status effects they have active, and any server-side damage multipliers configured by the server operator -- none of which are encoded in the Yuri's asset file. The Yuri asset tells you what damage the projectile deals on hit; it does not tell you how many hits a particular target can survive, because the target's survivability is not a property of the weapon.
It does not tell you the rounds-per-minute or the seconds between shots, because converting the Firerate value of 3 into real-world time requires knowing the engine's tick rate -- an engine-level constant that is not specific to this weapon and is not included in this asset reference. If you need a time-based rate-of-fire figure, consult your plugin framework's documentation or the engine's configuration constants to obtain the tick rate, and perform the conversion yourself using both the tick rate and the Firerate value of 3.
It does not list specific compatible attachments by name (for example, "the Yuri is compatible with the Ranger Suppressor and the Military Suppressor"), because attachment compatibility is governed by integer type IDs (Muzzle 3 for barrel attachments), not by named item lists stored in the weapon asset. To compile a list of every specific barrel attachment the Yuri accepts, you would need to search the entire item catalog for every item with Muzzle set to 3, which is a separate cross-referencing exercise beyond the scope of a single-weapon reference.
It does not rank the Yuri against other Unturned weapons. Ranking depends on subjective criteria -- is damage per shot more important than rate of fire? Is anti-zombie performance more important than anti-player performance? Is spawn availability more important than per-hit damage? -- and this reference does not assert any ranking. It provides the raw data so that you can apply your own ranking methodology.
Data integrity note
Every value in this document comes from a verified data export of the Yuri asset, identified by item ID 1041 and GUID 5f49e7e1f8584797a9a859d66722d19c. No value has been translated, normalised, converted, recalculated, estimated, or inferred. The damage-per-hit-zone tables include pre-computed values that were calculated by the extracted asset data author using the base damage and multiplier values from the asset, and those pre-computed values are reproduced here exactly as they appear in the extracted asset data -- the computation was not reperformed during the writing of this article.
The spawn table entries preserve the exact spelling and capitalisation present in the game's internal table name strings. This includes spelling inconsistencies such as "Hyrdro" versus "Hydro" in the Rula_France table names and "Milita" (with one "i") versus the more common "Militia" spelling. These are not transcription errors introduced during the writing of this article; they are the literal strings stored in the game's spawn table data. Modders who write spawn table overrides targeting these tables must match the strings exactly, spelling inconsistencies included. A spawn override that targets "Rula_France_Hydro" (with the "r" in the correct position) will not match the table named "Rula_France_Hyrdro" (with the transposed "r" and "d") unless the override's string-matching logic is case-and-spelling-insensitive, which most Unturned server frameworks' spawn-table targeting is not.