Snayperskya Rifle Asset Reference
The Snayperskya is one of the long-range precision weapons available in Unturned, and if you are here searching for its exact item ID, GUID, damage values, or spawn locations for your mod or server configuration, this reference is the complete source. The in-game description reads: Russian sharpshooter rifle chambered in Snayperskya ammunition. This article covers every single stat exposed in the game's asset files, explains in detail what each individual field controls inside the engine, and provides the full spawn table so you know exactly where this weapon can appear on every official map. If you have never opened a .dat file before, the explanations below treat every individual field as if you are encountering it for the first time. The goal is not just to give you a table of numbers. The goal is to give you the confidence to open a .dat file, change a value, and understand with precision why your change produces the result it produces. That understanding is what separates a modder who copies and pastes from a modder who designs.
The Snayperskya asset carries item ID 129 and GUID 5942d0d5f7024df094eba61b4372c7ab. Its rarity classification is Rare and it occupies the Primary equipment slot. At a high level, these four pieces of metadata are the fundamental keys you need to reference this weapon in any Unturned modding context. The item ID is the integer the engine uses internally for inventory lookups, for spawn commands like /give, and for save data persistence. When the game writes your character's inventory to disk, it does not store the weapon's name. It stores the integer 129 and a few other pieces of state like durability and attachment IDs. When the game loads that save file back, it looks up item ID 129 in its item registry and finds the Snayperskya asset. That is why two items can never safely share the same item ID: the save system would have no way to tell them apart, and whichever asset loads second would overwrite the first in the registry.
The GUID is a 32-character hexadecimal string -- 5942d0d5f7024df094eba61b4372c7ab -- and it functions as the unique asset identifier that Unity's asset bundle system relies on. Every item, vehicle, structure, and effect in the game has exactly one GUID. No two assets across the entire set of official content share a GUID. The GUID is what the asset bundle loader uses to locate the correct .dat file and the correct associated assets like models, textures, and sounds when the game needs to instantiate a Snayperskya in the world. If you are creating a custom weapon, you must generate a fresh GUID. You cannot reuse 5942d0d5f7024df094eba61b4372c7ab unless you are intentionally replacing the vanilla Snayperskya entirely. For a standalone custom weapon, generate a new UUID v4 string, write it in lowercase without braces or dashes, and place it in your .dat file's metadata block. The engine reads that metadata block first, before it parses any of the stat tables that follow.
The rarity value of Rare tells the engine how to present this weapon to the player. The rarity system in Unturned controls two things primarily. First, it determines the colour of the item's nameplate in the inventory UI. A Rare item gets a distinct colour treatment that signals to the player that this is not a common find. Second, and more importantly for modders, the rarity value feeds into the loot system's item selection logic. When a spawn table is rolled and the engine is choosing among multiple possible items, rarity can act as a weighting factor. Rare items are less likely to be selected than Common items when both appear in the same weighted pool, though the exact weighting formula depends on the specific spawn table configuration and whether the table uses explicit probability percentages or relies on rarity-based selection. For the Snayperskya, the spawn tables documented later in this article use explicit percentage weights, so the Rare classification here primarily affects the UI colour rather than the loot probability math in those particular tables. But if you ever add this weapon to a rarity-weighted spawn table -- one that does not use explicit percentages -- the Rare tag will become part of the selection calculation.
The Primary slot assignment means the Snayperskya occupies your character's main weapon slot, which is bound to the number 1 key by default. The game has three weapon-related equipment slots: Primary, Secondary, and a third slot for melee or other small items. The Primary slot is where rifles, shotguns, LMGs, and other two-handed weapons live. You cannot carry the Snayperskya in your Secondary slot, and you cannot dual-wield it. When the player presses the switch-weapon key, the engine swaps between the Primary and Secondary slots (or to a melee slot depending on key bindings). The slot assignment is more than a UI convenience: it interacts with inventory management, hotbar arrangement, and certain game mechanics that check which slot an item occupies. If you were to change the slot to Secondary in a custom weapon, the player could carry two rifles at once, which would be a significant departure from vanilla balance and should be done deliberately, not accidentally.
Now, let us walk through each stat table exactly as it appears in the weapon's .dat file. Every table below is a verbatim reproduction of the values defined in the asset data. The prose surrounding each table explains what the fields mean, how the engine processes them at runtime, what happens when you change them, and what you should consider before making those changes.
Understanding the ballistics table
The ballistics table is the first major block of numeric data in the Snayperskya's .dat file. It defines the fundamental firing behaviour of the weapon. These are not derived or calculated values. They are the raw numbers literally stored in the asset file, read by the engine every time the weapon is fired. Each field governs exactly one specific aspect of how a shot travels from the barrel to its target. Understanding this table fully is the prerequisite for understanding everything else the weapon does, because every subsequent table -- damage, handling, spawn behaviour -- sits on top of the foundation that these ballistics values lay down.
| Field | Value |
|---|---|
| Range | 250 |
| Firerate | 13 |
| Action | Trigger |
| Caliber | 11 |
| Muzzle | 4 |
| Magazine | 130 |
| Ammo_Min | 1 |
| Ammo_Max | 7 |
Let us take each field in turn, starting with the first one in the table and working our way down. Every field gets its own detailed treatment.
Range
Range, with a value of 250, sets the maximum distance in metres at which a projectile from this rifle will register a hit on a target. The way this works inside the engine is straightforward. When a player pulls the trigger, the game performs a raycast. A raycast is a line trace that starts at the weapon's muzzle position -- the exact 3D coordinate where the barrel ends -- and extends forward along the player's aim direction vector. The ray checks for intersections with collision geometry and with entity hitboxes as it travels. The Range value is what tells the raycast how far to go before it gives up and returns "no hit." At 250 metres, the ray stops. Any enemy standing at 251 metres or beyond, even if your crosshair is dead-centre on them and there is nothing but open air between you, will not be hit. The ray simply does not reach them.
This has practical implications for map designers and server owners. If you are building a custom map with long sightlines -- an open desert, a mountain range, a coastal highway -- and you place a sightline that extends 400 metres from the typical player firing position to the typical target position, the Snayperskya physically cannot engage targets at the far end of that sightline. A player could see the enemy, track them through a high-magnification scope, pull the trigger, and nothing would happen. The bullet would expire at the 250-metre mark. If you want the Snayperskya to be effective on your long-sightline map, you would increase Range accordingly, to 400 or 500 or whatever distance matches your longest combat sightline. Conversely, if your map is a dense urban environment where no sightline exceeds 80 metres, the 250-metre range is more than enough and you may not need to touch this field at all.
The balance implication of Range is that it interacts directly with the player's choice of optic. The Snayperskya's 250-metre range means an 8x or 16x scope is still a useful attachment, because the scope lets you see targets that are within the projectile's reach. If you reduce Range to 80 while keeping the weapon compatible with high-magnification optics, you create a situation where the scope is misleading: the player can see the target perfectly clearly at 200 metres, centre the crosshair on their head, fire, and miss because the projectile expires before it gets there. That is a frustrating experience that you should avoid in your custom weapon designs. Either match the range to the expected optic, or remove the optic compatibility if you deliberately want a short-range weapon.
Firerate
Firerate has a value of 13. In the context of Unturned's .dat file format, this is an abstract engine tick value that governs the minimum delay between consecutive shots. It is not a rounds-per-minute count and it is not a real-world time interval expressed in seconds. It is a tick count. When you fire the weapon, the engine starts a cooldown counter. That counter decrements by one every engine tick. When the counter reaches zero, the weapon is ready to fire again. The Firerate value of 13 tells the engine: "after firing, wait 13 ticks before you allow the next shot." A lower Firerate value produces a shorter delay -- the weapon fires faster because fewer ticks need to elapse. A higher value produces a longer delay -- the weapon fires slower because more ticks need to elapse.
The relationship between this tick value and real-world time depends on the server's simulation tick rate, which is not part of this weapon's asset data and is not something you can determine just by looking at the .dat file. The tick rate may vary between single-player and multiplayer, between different server configurations, and potentially between different versions of the game. This is why you should not attempt to convert the Firerate value into seconds-per-shot or rounds-per-minute without access to the server's tick configuration. Instead, think of Firerate as a relative comparator: a weapon with Firerate 5 fires faster than a weapon with Firerate 13, which fires faster than a weapon with Firerate 30. When you are tuning a custom weapon, test it on a live server with the same tick rate your players will experience, and adjust the Firerate value up or down until the weapon's firing cadence feels right. Do not rely on a mathematical conversion.
Action
Action is set to Trigger. This defines the firing mode activation mechanism. A trigger-action weapon fires exactly once each time you press the fire key, provided the magazine is not empty and the firerate cooldown has elapsed since the last shot. If you hold down the fire key after the shot, nothing happens. The weapon will not fire again until you release the key and press it again. This is different from an automatic action, where holding the key would cause the weapon to fire continuously as long as ammunition remains. It is also different from a bolt-action or pump-action mechanism, where the player would need to cycle the action manually between shots.
The Trigger action pairs logically with the Snayperskya's identity as a precision rifle. Each shot is a deliberate decision. The player acquires a target, lines up the shot, presses the button, watches the hit land (or miss), and then consciously decides whether to fire again. There is no spray-and-pray option with a Trigger-action weapon, which channels the player toward careful, aimed shooting. If you change Action to Auto in a custom weapon, you fundamentally change the handling identity of the weapon, turning it from a marksman's tool into something closer to an automatic rifle. The Trigger value also interacts with the Semi flag discussed later in the flags section: together, they form the complete definition of the weapon's fire control system.
Caliber
Caliber has a value of 11. This is an internal identifier that links the weapon to a specific ammunition type. The number 11 is not a measurement in millimetres or inches. It is a category index that the game's item system uses to match weapons with their corresponding ammunition items. Every ammunition item in the game also has a caliber field in its own .dat file. When the Snayperskya's magazine reaches zero and the player attempts to reload, the engine checks the player's inventory for any ammunition item whose caliber matches 11. If it finds one, it consumes that ammunition to refill the magazine. If it finds none, the reload fails and the magazine stays empty.
This is one of the single most impactful fields for cross-mod compatibility. If you change the Snayperskya's caliber to a value that your mod provides but another mod does not, players who only have the other mod's ammunition installed will not be able to reload this weapon. Conversely, if your custom ammunition mod sets its caliber to 11, it will be compatible with every vanilla weapon that uses caliber 11 ammunition, including the Snayperskya. When you are designing a custom ammunition system, you need to decide whether you want to slot into the existing caliber ecosystem (use 11 and be compatible with vanilla weapons) or create a parallel ecosystem (use a custom caliber number and design weapons and ammunition that exist only within your mod's closed loop).
There is another design consideration with caliber: the calibre number also determines which ammunition types NPCs and loot containers recognize as "ammunition for this weapon." If the game's loot logic tries to spawn ammunition near a weapon or in the same container, it uses the caliber field to find matching ammunition. So if you change the Snayperskya's caliber to a custom value, you also need to ensure that custom ammunition items with that caliber appear in loot tables with appropriate frequency, or the weapon may spawn without compatible ammunition anywhere on the map.
Muzzle
Muzzle set to 4 is an internal attachment slot identifier. It determines which muzzle devices -- suppressors, muzzle brakes, compensators, and any other barrel-end attachments -- can be mounted on the Snayperskya. The engine compares the muzzle value of the weapon with the type values defined in each muzzle attachment's own .dat file. If the attachment declares that it is compatible with muzzle type 4, and the weapon's Muzzle field is 4, the engine allows the attachment to connect. If the types do not match, the attachment cannot be installed.
The value 4 is not inherently meaningful beyond being the category number. It is simply the index that was chosen for this particular weapon's muzzle family. Other weapons might use muzzle type 1, 2, 3, 5, or any other integer. The important thing to know as a modder is that if you build a custom muzzle attachment and you want it to fit the Snayperskya, you must include type 4 in your attachment's compatibility list. If you want to restrict which muzzle devices fit your custom rifle, you assign a different muzzle number and create matching attachments for that number. This is how Unturned creates attachment ecosystems: groups of weapons that share a muzzle type can pool the same set of muzzle attachments, while weapons with unique muzzle types require their own exclusive attachments.
Magazine
Magazine has a value of 130. This is the item ID of the default magazine that the Snayperskya spawns with. Item ID 130 is a separate asset with its own .dat file, its own model, its own capacity stat, and its own spawn behaviour. The Magazine field in the weapon's .dat does nothing more than create the link. It says: "when this weapon is instantiated, load it with the magazine whose item ID is 130." The magazine itself is what determines how many rounds the weapon holds. If the magazine asset with ID 130 has a capacity of, say, 7 rounds, then the Snayperskya holds 7 rounds per magazine. If you create a custom magazine with a different capacity -- perhaps an extended magazine with a capacity of 10 or a drum magazine with 30 -- you would change this field to point at your custom magazine's item ID.
The engine does not validate that the magazine's caliber matches the weapon's caliber. It trusts that you, the modder, have set up the data correctly. If you link the Snayperskya to a magazine that holds a different caliber of ammunition, you can create a situation where the weapon fires a projectile that does not correspond to the ammunition type the player loaded into it, which may cause unexpected behaviour. Always verify that the magazine you are linking to contains ammunition of the same caliber as the weapon's Caliber field.
Ammo_Min and Ammo_Max
Ammo_Min at 1 and Ammo_Max at 7 define the range of ammunition rounds that the Snayperskya carries when it first spawns in the world. When the engine places a Snayperskya into a loot container, onto the ground, or into a freshly-created inventory from a spawn command, it generates a random integer between the minimum and maximum inclusive. That integer determines how many rounds are loaded in the weapon's magazine when the player first picks it up.
The range of 1 to 7 means a freshly spawned Snayperskya can arrive with as few as a single round or as many as seven. You might pick up the weapon and find it fully loaded and ready for a full engagement. Or you might pick it up with one round in the chamber, needing to scrounge for ammunition before you can use it effectively. This variability is a deliberate design choice that adds texture to the looting experience. A player finding a Snayperskya with one round has a different immediate problem to solve than a player finding one with seven rounds.
The engine will never generate an ammunition count higher than the linked magazine's own capacity. Even if you set Ammo_Max to 99 in this field, the actual loaded ammunition at spawn time would be capped at whatever the magazine item with ID 130 says its maximum capacity is. The Ammo_Max field is a ceiling that is itself subject to the magazine's ceiling. So if the magazine has a capacity of 7, and you set Ammo_Max to 10, the effective maximum is still 7. When you are designing a custom weapon, make sure your Ammo_Max value does not exceed the linked magazine's capacity, or you are embedding an expectation in your data that the engine will silently violate.
If you want every spawned Snayperskya to come fully loaded, set both Ammo_Min and Ammo_Max to 7. If you want the spawn ammunition to always be at a disadvantageous level for balance reasons -- making the weapon require immediate ammunition scavenging -- set both to 1. The spread between min and max is yours to tune according to how variable or predictable you want the initial pickup experience to be.
Player damage: what each hit zone means
Player damage in Unturned is computed through a two-stage pipeline. The first stage is hit zone detection: the engine determines which part of the target player's hitbox the projectile intersected. The second stage is the damage calculation: the base damage value is multiplied by the zone-specific multiplier for the detected hit zone. This section documents every value in the player damage table exactly as it appears in the Snayperskya's asset data.
| Field | Value |
|---|---|
| Player_Damage | 65 |
| Player_Leg_Multiplier | 0.6 |
| Player_Arm_Multiplier | 0.6 |
| Player_Spine_Multiplier | 0.8 |
| Player_Skull_Multiplier | 1.1 |
Player_Damage: the base value
Player_Damage at 65 is the foundation of every damage calculation against a player target. Before any multiplier is applied, before any hit zone is considered, the engine starts with 65. If the engine were unable to determine which hit zone was struck -- for example, if the hitbox detection system returned a null or unknown zone -- the weapon would deal exactly 65 damage, unmodified. In practice, the hitbox system in Unturned rarely fails to resolve a zone, so most shots go through the full multiplier pipeline. But the base value of 65 is what sits underneath every calculation. It is the constant.
For server owners doing balance passes, 65 is the primary tuning knob for PvP damage output. Increasing it to 70 gives every hit zone approximately a 7.7% damage bump, because each multiplier is applied to the new, higher base. Decreasing it to 50 weakens every hit zone proportionally. Because the base damage applies globally, changing it is the broadest stroke you can make. The per-zone multipliers are for finer, more targeted adjustments.
Player_Leg_Multiplier and Player_Arm_Multiplier: limb shots
Both Player_Leg_Multiplier and Player_Arm_Multiplier are set to 0.6. A multiplier of 0.6 means the engine takes the base damage of 65 and multiplies it by 0.6, producing a lower final damage value for any shot that strikes a leg or arm hitbox. In the engine's model, limb shots on players are penalized identically. There is no distinction between a shot to the thigh and a shot to the forearm. Both get the 0.6 treatment.
From a game design standpoint, a multiplier below 1.0 on limbs encodes a clear message to the player: aim for centre mass or the head. Shooting at limbs is wasteful. It takes more shots to eliminate a target when you are hitting arms and legs, which means more ammunition consumed, more time exposed, and more opportunities for the enemy to retaliate or escape. The 0.6 value is low enough to matter but not so low that a limb shot feels like a total waste. It is a discouragement, not a hard block.
If you are building a custom weapon and you want limb shots to matter even less -- perhaps for a dedicated sniper where only centre-mass and headshots should be viable -- you could lower both multipliers to 0.4 or 0.3. If you want a weapon where limb hits are punishing -- a heavy shotgun, for example, or a high-calibre pistol -- you could raise them to 0.8 or even 1.0.
Player_Spine_Multiplier: torso shots
Player_Spine_Multiplier at 0.8 applies to shots that strike the spine or torso region of a player's hitbox. At 80% of the base 65, a spine shot is substantially more effective than a limb shot but less effective than a skull shot. The 0.8 value makes the torso the "reliable" target zone: it is larger and easier to hit than the head, and it delivers most of the weapon's potential damage, even if it is not the theoretical maximum.
The relationship between the spine multiplier of 0.8 and the skull multiplier of 1.1 creates a meaningful tradeoff for the player. Aiming for the torso is faster and more likely to land a hit, especially against a moving target at range. Aiming for the head is riskier -- the target is smaller and harder to track -- but the reward is a higher damage value. The 0.8-to-1.1 spread between torso and head means the headshot is worth roughly 37.5% more damage than the torso shot. That is a significant but not overwhelming bonus; it rewards precision without making the weapon useless if you cannot land headshots consistently.
Player_Skull_Multiplier: headshots
Player_Skull_Multiplier at 1.1 is the only player hit zone where the multiplier exceeds 1.0. A headshot amplifies the base damage rather than reducing it. This is the Snayperskya's highest-damage hit zone against players. The value of 1.1 means a headshot deals 110% of whatever the base damage is, which for the Snayperskya means the skull shot is the clear best option in every PvP engagement.
The pattern of having a single multiplier above 1.0 with the rest below is a common design choice across many Unturned weapons. It concentrates the weapon's damage potential into the most demanding shot -- the head -- while making every other zone a less efficient alternative. This creates a skill gradient where better aim directly translates to faster kills. If you were to set the skull multiplier to 1.0 and raise the spine multiplier to 1.0, the weapon would deal the same damage to head and torso, removing the precision incentive. If you were to raise the skull multiplier to 2.0 while keeping the spine at 0.8, the headshot becomes dramatically more valuable and the weapon becomes a true one-shot-kill sniper in the hands of a skilled marksman.
Zombie damage: a different scale for AI targets
Zombie damage uses the same multiplier architecture as player damage but with entirely different base values and multipliers. The Snayperskya treats zombie targets as a separate category, and the engine uses a different set of fields to calculate damage against them. This independence between player and zombie damage tables is what allows a weapon to feel powerful in PvE without being overpowered in PvP, or vice versa.
| 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: a higher base than players
Zombie_Damage at 99 is notably higher than the Player_Damage of 65. The difference of 34 points, from 65 to 99, reflects a deliberate design choice by the weapon's creators. The Snayperskya is significantly more effective against AI-controlled zombies than it is against human players. This makes sense in the context of Unturned's survival gameplay: zombies are numerous, they are often encountered in groups, and they do not use cover, heal, or retreat. Giving the weapon a higher base damage against zombies means a player who invests in precision shooting can clear zombie threats efficiently without the weapon feeling overpowered in PvP.
For a server owner running a PvE-focused server with large zombie populations, the Zombie_Damage value matters more than the Player_Damage value. Your players will spend most of their ammunition on zombies, and the 99 base damage means each shot does substantial work. If you want zombies to be more threatening and require more shots to dispatch, you would lower this value. If you want the Snayperskya to be the definitive zombie-clearing sniper, you could raise it further.
Zombie leg and arm multipliers: heavily penalized
Zombie_Leg_Multiplier and Zombie_Arm_Multiplier are both 0.3, which is exactly half the player limb multiplier of 0.6. This is a significant downward adjustment. A limb shot on a zombie yields only 30% of the base 99, while the same limb shot on a player yields 60% of the base 65. The engine is telling you, through these numbers, that aiming for zombie limbs with the Snayperskya is nearly a waste of ammunition. The damage is so heavily reduced that a player who repeatedly hits zombie limbs will burn through their magazine without achieving much.
This harsh limb penalty shapes how players use the weapon against zombie hordes. The correct approach is to aim for the head every time. A skull shot delivers 110% of base 99, while a limb shot delivers 30%. That is a nearly four-to-one ratio between the best and worst hit zones. If you are building a custom weapon and you want to create a similar headshot-incentive design for zombie combat, keeping the skull multiplier at or above 1.0 while pushing the limb multipliers down to 0.2 or 0.3 is how you encode that incentive into the data.
Zombie_Spine_Multiplier: a reduced centre mass
Zombie_Spine_Multiplier at 0.6 is lower than the player spine multiplier of 0.8. A torso shot on a zombie delivers 60% of base 99, which is noticeably less than the 80% of base 65 that the same shot would deliver on a player. The reduction from 0.8 to 0.6 represents the game's way of saying that zombies are more resilient to body shots than players are. Perhaps the undead are less affected by centre-mass trauma. Whatever the fictional justification, the practical effect for the player is that body shots on zombies are only moderately effective, while headshots remain the premium option.
Zombie_Skull_Multiplier: consistency across target types
Zombie_Skull_Multiplier at 1.1 matches the player skull multiplier exactly. Across both players and zombies, a headshot gets a 10% bonus over the base damage. This consistency is one of the Snayperskya's design signatures: regardless of what you are shooting at, the head is always the best target. The multiplier does not change between target types, which means the player can develop reliable muscle memory and targeting habits that work the same in PvP and PvE.
The fact that the skull multiplier is consistently 1.1 while the limb and spine multipliers vary between target types tells you something about the weapon's design priorities. The headshot is the constant. The other zones are tuned around it to create different damage profiles for different target types without changing the fundamental "aim for the head" directive. As a modder, you can use this same pattern in your custom weapons: lock the skull multiplier to a consistent value across all target types, and vary the limb and spine multipliers to differentiate the weapon's anti-player and anti-zombie performance.
Animal damage: the third target category
Beyond players and zombies, Unturned supports a third distinct target category for damage calculation: animals. The Snayperskya has its own dedicated set of damage fields for animal targets, with a base value that mirrors the player base damage but with a slightly different set of defined hit zones.
| Field | Value |
|---|---|
| Animal_Damage | 65 |
| Animal_Leg_Multiplier | 0.6 |
| Animal_Spine_Multiplier | 0.8 |
| Animal_Skull_Multiplier | 1.1 |
Animal_Damage: matching the player base
Animal_Damage at 65 is identical to Player_Damage. This symmetry means the Snayperskya treats animals and players as equivalently durable targets at the base level. Before multipliers, a deer is as tough as a rival survivor. For server owners who want hunting to feel rewarding without making the weapon overpowered in PvP, this symmetry is convenient: the rifle hits animals with the same base force it applies to players, and the multipliers handle the differentiation.
Animal multiplier pattern
Animal_Leg_Multiplier at 0.6 and Animal_Spine_Multiplier at 0.8 mirror the player multiplier values exactly. A leg shot on an animal deals 60% of base 65. A spine shot deals 80%. Animal_Skull_Multiplier at 1.1 again matches the pattern: the 10% headshot bonus is universal across all three target categories. The animal damage profile is, in effect, a subset of the player damage profile. The numbers are the same; only the set of defined zones differs.
The missing arm multiplier
Notice that the animal damage table does not define an Animal_Arm_Multiplier. This is not an accidental omission. The Snayperskya's asset file simply does not include a separate arm multiplier for animal targets. The animal hitbox model in Unturned likely categorizes forelimb hits differently from the human arm hitbox system. Depending on the specific animal rig, a front leg might be classified as a leg hit (applying the 0.6 multiplier) or as a generic body hit (applying the base value unmodified). The absence of a dedicated arm field means the engine falls back to whatever default behaviour it uses when a multiplier is not explicitly defined for a given zone, which is typically to apply the base damage value without modification.
This is an important lesson for modders. The .dat file format in Unturned does not require you to define every possible hit zone multiplier. If you omit a field, the engine uses its default behaviour for that field. The default is usually to apply the base damage unmodified, but the exact fallback logic depends on the hitbox system and is not something you can know without testing. When you are building a custom weapon and you want a specific behaviour for a specific hit zone, define the multiplier explicitly rather than relying on the default. The completeness of your damage table is a form of documentation for yourself and anyone else who reads your .dat file later.
Handling: recoil, spread, and weapon feel
The handling table controls the physical feedback the weapon produces when fired and the precision with which the projectile follows the crosshair. These values are what make the Snayperskya "feel" like a sniper rifle rather than a submachine gun or a shotgun. They govern camera behaviour, aim deviation, and the amount of manual correction the player needs to apply between shots.
| Field | Value |
|---|---|
| Recoil_Min_X | 5 |
| Recoil_Min_Y | 10 |
| Recoil_Max_X | 10 |
| Recoil_Max_Y | 15 |
| Spread_Aim | 0.005 |
| Shake_Min_X | -0.005 |
| Shake_Max_X | 0.005 |
Understanding recoil mechanics
Recoil in Unturned is expressed as pairs of minimum and maximum values, one pair for the horizontal aim axis (X) and one pair for the vertical aim axis (Y). Each time the weapon fires, the engine generates a random horizontal offset somewhere between Recoil_Min_X and Recoil_Max_X, and a random vertical offset somewhere between Recoil_Min_Y and Recoil_Max_Y. Both offsets are applied to the player's current aim point immediately after the shot is resolved. The horizontal offset can be in either direction -- left or right -- chosen randomly by the engine. The vertical offset is always upward, representing the muzzle climb that occurs when a firearm is discharged.
The recoil values accumulate. If you fire three shots in rapid succession without waiting for the recoil to settle, the third shot's aim point will have been displaced by the sum of the first two shots' recoil offsets plus its own. The longer you fire without pause, the further your aim point drifts from the original target. This is the mechanic that prevents players from simply holding down the trigger and maintaining pinpoint accuracy at long range, even with a weapon that has zero spread.
Recoil_Min_X at 5 and Recoil_Max_X at 10 define the horizontal recoil range for the Snayperskya. Every shot pushes the aim point sideways by an amount between 5 and 10 units. The fact that the min and max are not the same value means the horizontal kick is variable. Some shots will push 5 units sideways. Other shots will push 10. The player cannot predict the exact amount and therefore cannot perfectly compensate with a counter-movement. This variability is intentional. It prevents the weapon from feeling mechanical and keeps engagements dynamic.
Recoil_Min_Y at 10 and Recoil_Max_Y at 15 define the vertical recoil range. The Y-axis values are higher than the X-axis values, which means the Snayperskya's recoil pattern is predominantly vertical. It kicks upward more than it kicks sideways. This is a deliberate design choice: vertical recoil is predictable and can be compensated for by pulling the mouse down, while horizontal recoil is random and cannot be compensated for. A weapon with strong vertical recoil and weak horizontal recoil rewards players who learn the recoil pattern and develop the muscle memory to counteract it. A weapon with strong horizontal recoil frustrates players because no amount of practice can fully neutralize random sideways drift.
For a custom sniper rifle, you might want higher vertical recoil than the Snayperskya to enforce a "one shot, one kill" playstyle. If the vertical recoil is severe -- say, 20 to 30 -- the player cannot fire accurate follow-up shots without a long pause to let the aim settle. This channels them toward making the first shot count, then repositioning or waiting rather than attempting a rapid second shot. Conversely, for a designated marksman rifle that is meant to support rapid follow-up shots, you would keep vertical recoil low and allow the player to stay on target through multiple trigger pulls.
Spread_Aim: shot-to-shot angular deviation
Spread_Aim at 0.005 defines the angular deviation applied to the projectile's flight path when the player is aiming down sights. This value sets the half-angle of a cone. The engine constructs an invisible cone with its tip at the weapon's muzzle and the cone's walls expanding outward along the aim direction. The actual projectile trajectory is randomly selected from anywhere within that cone. The Spread_Aim value determines how wide the cone is.
A value of 0.005 degrees is extremely narrow. At the Snayperskya's full 250-metre range, the maximum possible deviation of the projectile from the exact aim point is miniscule. The bullet goes where the crosshair points. This is what you would expect from a precision rifle: when you are scoped in and you pull the trigger, the bullet obeys the crosshair. There is no meaningful RNG spread. The weapon's accuracy is bounded by the player's aim, not by the weapon's inherent imprecision.
For comparison, a shotgun or an SMG might have a Spread_Aim value of 0.5, 1.0, or higher. At that level of spread, the cone is wide enough that even at moderate ranges, a pellet can miss a target that is perfectly centred in the crosshair. The spread becomes a deliberate weapon characteristic rather than an incidental property. For the Snayperskya, the spread is deliberately negligible. If you increase Spread_Aim on this weapon -- even to 0.1 -- you introduce an element of RNG to every shot that undermines the weapon's identity as a precision instrument. A player who lines up a perfect headshot at 200 metres and misses because the bullet randomly deviated will not blame their aim. They will blame the weapon, and they will be right to do so.
Shake: camera feedback, not mechanical recoil
Shake_Min_X at -0.005 and Shake_Max_X at 0.005 define the range of horizontal camera displacement that occurs when the weapon fires. This is a visual effect, not a mechanical one. Shake values move the camera independently of the aim point. They create a perception of recoil and power without actually affecting where the next shot will land. The shake is a layer of feedback that sits on top of the mechanical recoil system.
The values for the Snayperskya are very small: -0.005 to +0.005. The negative minimum means the camera can be nudged slightly to the left. The positive maximum means it can be nudged equally slightly to the right. The symmetry of the range means there is no directional bias; the camera wobbles left or right with equal probability and equal magnitude. The small magnitude means the wobble is subtle. The player perceives a faint jolt through the scope, just enough to communicate that a round was fired, but not enough to disrupt target tracking or blur the sight picture.
Only the X axis is defined for shake. There is no Shake_Min_Y or Shake_Max_Y in the Snayperskya's handling table. This means the engine applies zero vertical camera shake when the weapon fires. All camera movement is horizontal. This is a deliberate choice for a precision weapon. Vertical shake would bounce the camera up and temporarily obscure the target from view, interfering with the player's ability to observe the shot's impact and prepare a follow-up shot. By restricting shake to the horizontal axis and keeping the magnitude minimal, the Snayperskya allows the shooter to watch the bullet land through the scope without the camera jumping around.
If you are building a custom weapon and you want it to feel like it has immense physical force, you would increase the shake magnitudes significantly. Something like -0.1 to 0.1 for both X and Y axes would produce a dramatic camera kick that makes the weapon feel heavy and powerful. The key insight is that shake is a subjective design tool. It shapes the player's emotional experience of firing the weapon more than it shapes the weapon's mechanical performance. A weapon with zero shake and zero recoil would feel weightless and toy-like, even if its damage values were high. A weapon with heavy shake would feel substantial and authoritative, even if its damage was moderate.
Computed damage: seeing the multiplier math applied
The tables below show the Snayperskya's effective damage output to each hit zone for every target type. These numbers are computed by multiplying the base damage by each zone's multiplier, using exactly the values documented in the preceding sections. The engine does not store these computed values in the .dat file. They do not appear as separate fields that you can edit. The engine performs the multiplication at runtime, every time a shot lands, using the base damage and multiplier values that you have already seen. These tables exist as a quick reference so that you can understand, at a glance, how the damage scales across hit zones without performing the multiplication yourself. They are a map, not the territory. The territory is the base damage fields and the multiplier fields you edit in the .dat file.
Player damage per hit zone
| Hit zone | Multiplier | Damage (base 65) |
|---|---|---|
| Skull | 1.1 | 71.5 |
| Spine | 0.8 | 52 |
| Arm | 0.6 | 39 |
| Leg | 0.6 | 39 |
A skull shot against a player produces a damage value of 71.5. A spine shot produces 52. Arm and leg shots both produce 39. The ratio between the best and worst hit zones is substantial: 71.5 compared to 39 is approximately a 1.83-to-1 ratio, meaning a headshot is worth nearly double what a limb shot is worth. For a weapon that typically carries between one and seven rounds per magazine, this spread matters. A headshot plus a body shot might be sufficient for an elimination where two body shots alone might not be. Understanding these relationships at the table level, rather than trying to feel them out through gameplay, lets you make informed decisions about whether the Snayperskya's damage profile fits your server's or mod's balance goals.
Zombie damage per hit zone
| 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 |
Against zombies, the skull shot yields 108.9 damage. The spine shot yields 59.4. Limb shots yield 29.7. The spread from best to worst is dramatic: 108.9 divided by 29.7 equals approximately 3.67. A headshot is worth more than three and a half limb shots. This extreme ratio is the engine's mechanism for making the Snayperskya feel like a specialized anti-zombie precision tool. The weapon is devastating when used correctly -- aimed at the head -- and nearly useless when used incorrectly -- sprayed at limbs. This design channels player behaviour: you learn quickly that wasting ammunition on zombie limbs is a losing strategy, and you develop the discipline to aim for the head with every shot. If you want a more forgiving anti-zombie weapon, you would compress this ratio by raising the limb and spine multipliers. If you want an even more demanding weapon, you would widen it by lowering them further.
Animal damage per hit zone
| Hit zone | Multiplier | Damage (base 65) |
|---|---|---|
| Skull | 1.1 | 71.5 |
| Spine | 0.8 | 52 |
| Leg | 0.6 | 39 |
The animal damage profile mirrors the player damage profile in every defined zone. Skull yields 71.5, spine yields 52, and leg yields 39. The arm row is absent because, as discussed, the Snayperskya's asset data does not define an Animal_Arm_Multiplier. The effective damage for an arm hit on an animal is not computable from the data in this extraction alone, because it depends on how the engine's hitbox system categorizes animal forelimbs. When you are testing a custom weapon against animal targets, pay attention to whether arm hits produce the leg multiplier value, the spine value, or the base value, and add an explicit Animal_Arm_Multiplier to your .dat if the engine's default behaviour does not match your intent.
Asset flags and what they enable
The flag list is a collection of string tokens embedded in the Snayperskya's .dat file. These tokens are not numeric stats. They function as boolean-like toggles, attachment slot declarations, structural markers, and crafting system hooks. Each flag tells the engine to enable or expose a specific subsystem for this weapon. Understanding the flag list is essential because many modding bugs originate from incorrect flag configuration: a custom weapon that has the right damage numbers but the wrong flags may be missing attachment slots, may not appear in crafting menus, or may simply not function in ways that are not immediately obvious from looking at stat tables alone.
Flags present: "7b82c125a5a54984b8bb26576b59e977", "e73a23b102f24520a32ec0b2afaa6157", Blueprints, Hook_Barrel, Hook_Grip, Hook_Sight, Hook_Tactical, InputItems, OutputItems, RequiresNearbyCraftingTags, Safety, Semi, [, ], {, }
Internal GUID references
The two quoted GUID strings at the start of the flag list -- "7b82c125a5a54984b8bb26576b59e977" and "e73a23b102f24520a32ec0b2afaa6157" -- are internal asset references. They are not fields that a typical modder would need to modify or even understand in depth. They point to other assets or behaviours that the weapon depends on at runtime. For example, one of these might reference a shared ballistic behaviour definition, a damage calculation module, or a visual effect asset. Their exact purpose is internal to the engine's asset resolution system.
When you are cloning the Snayperskya's .dat to create a custom derivative weapon, you should preserve these GUID references unless you have a specific reason to change them. Stripping them out may cause the weapon to fail to initialize or to lose functionality that you will not notice until you test it thoroughly in-game. On the other hand, if you are intentionally building a weapon that should not inherit certain behaviours from the Snayperskya base, you may need to replace these GUIDs with references to your own custom behaviour assets. That kind of deep asset manipulation is beyond the scope of a basic stat tutorial, but it is worth knowing that these strings exist and that they are not decorative.
Blueprints
Blueprints is a flag that enrols this weapon in the game's crafting blueprint system. When Blueprints is present, the engine allows crafting recipes -- defined elsewhere in the game's data -- to reference this weapon's item ID as either a crafting input or a crafting output. Without the Blueprints flag, the weapon is strictly a loot item. It can be found, picked up, equipped, and fired, but it can never appear in a crafting recipe. You cannot craft it, and you cannot use it as an ingredient to craft something else.
If you remove the Blueprints flag from a custom weapon, you are making a design statement: this weapon is loot-only. It must be scavenged from the world. Players cannot manufacture it, and they cannot repurpose it into other items. This is a common choice for high-tier rare weapons that should feel special and irreplaceable. If you leave Blueprints in, players with access to the right crafting stations and ingredients can produce the weapon on demand, which changes its economic role in the game world from a precious find to a farmable resource.
Attachment hooks
Hook_Barrel, Hook_Grip, Hook_Sight, and Hook_Tactical are the four attachment slot declarations. Each one carves out a socket on the weapon where a specific category of attachment can be installed.
Hook_Barrel means the Snayperskya has a barrel attachment slot. Suppressors, muzzle brakes, and compensators can be attached here. The barrel attachment changes the weapon's muzzle flash visibility, firing sound profile, or recoil pattern depending on which specific barrel device is installed. Without Hook_Barrel, the barrel socket does not exist, and no muzzle attachment can be installed regardless of what the attachment's own compatibility data says.
Hook_Grip enables a foregrip attachment. Grips typically reduce recoil or improve handling characteristics. The presence of this flag means the Snayperskya has a rail or mounting point forward of the trigger guard where a grip can be attached.
Hook_Sight enables optics. Scopes, red dot sights, holographic sights, and iron sight upgrades connect through this hook. The Hook_Sight flag is particularly important for a sniper rifle because the weapon's effective range of 250 metres demands magnification that only a scope can provide. Without Hook_Sight, the Snayperskya would be limited to its built-in iron sights, which would make long-range shots impractical and effectively waste the 250-metre range value.
Hook_Tactical enables tactical accessories like lasers and flashlights. These are utility attachments that improve visibility in dark environments or provide a visible aiming aid.
If your custom weapon should accept a different set of attachments than the Snayperskya, you modify the hook flags accordingly. To create a stripped-down survival rifle with no rails or mounting points, remove all four hooks. To create a weapon that accepts scopes but not tactical accessories, keep Hook_Sight and remove Hook_Tactical. Each hook is independent; you can mix and match them to define exactly which attachment categories your weapon supports.
Crafting system flags
InputItems signals that the Snayperskya can appear as an ingredient in crafting recipes. A player can consume this weapon -- scrap it, combine it, transform it -- in a crafting station to produce something else. The OutputItems flag signals that the Snayperskya can appear as the result of a crafting recipe. A player can combine ingredients in a crafting station to produce this weapon.
A weapon that has OutputItems but not InputItems can be crafted but cannot be consumed by other recipes. A weapon that has InputItems but not OutputItems can be used as crafting material but cannot itself be crafted. A weapon with both flags can appear on either side of a crafting recipe. The Snayperskya has both, which means the asset data supports both crafting the weapon from ingredients and using the weapon as an ingredient to craft other things.
RequiresNearbyCraftingTags is a constraint on crafting. When this flag is present, the player cannot craft the Snayperskya (or craft with it) from their inventory anywhere in the world. They must be within range of a crafting station or environmental object that carries a specific authorized tag. The exact tags required are not defined in the weapon's .dat file -- they are part of the crafting station definitions elsewhere in the game's data. But the flag itself tells you an important thing: the Snayperskya is not a gun you can build in the middle of a field. You need infrastructure.
Safety and Semi
Safety enables a manual safety toggle on the weapon. The player can engage the safety, which prevents the weapon from firing even when the fire key is pressed. This is a quality-of-life feature that lets players carry a loaded weapon without risk of accidental discharge during non-combat activities. The safety toggle is available in the weapon's interaction menu or through a dedicated keybind, depending on the game's control scheme.
Semi declares the weapon's fire mode as semi-automatic. One round is discharged per trigger pull. The weapon's action cycles automatically after firing -- no manual bolt operation required -- chambering the next round from the magazine. The Semi flag works together with the Action: Trigger value from the ballistics table to define the complete fire control behaviour. Semi says the weapon is self-loading. Trigger says it fires on discrete button presses, not continuous hold. Together, they describe a weapon where you press the button, one round fires, the next round chambers automatically, and you must press the button again for the next shot.
Bracket tokens
The bracket characters [, ], {, and } are literal string tokens in the flag array. They serve as structural delimiters within the flag list's internal representation. The engine's .dat parser likely uses these brackets to group flags, separate sections of the flag array, or mark metadata boundaries. They are not functional flags in the sense that Semi or Safety are. They exist because of how the data is serialized and parsed, not because they represent gameplay features.
When copying the Snayperskya's flags to a custom weapon, preserve these bracket tokens. If you remove them, the parser may misinterpret the flag array's structure, which could cause some flags to be ignored or misapplied. The safest approach when cloning flag data is to copy the entire flag list as-is and then add, remove, or modify only the flags you understand. Touch the structural tokens only if you have read the engine's .dat parser source code and you know exactly what they do.
Where the Snayperskya spawns
The spawn table is the most actionable section of this reference for server owners and modders who want to adjust loot availability. Each row in this table represents one spawn table entry on one map where the Snayperskya has a defined probability of appearing when that table is rolled. The chance column is a percentage: the probability that a single roll of that specific spawn table will select the Snayperskya as the output item.
| 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% |
| Core | Military_Low_Guns | 25.000% |
| RioDeJaneiro | Exterminators_Low_Weapons | 20.000% |
| Ireland | Cliffs_IFR_High_Guns | 19.737% |
| France | Milita_Special_France_Guns | 11.628% |
| Core | Militia_Special | 9.091% |
| Core | Syndicate_Special | 9.091% |
| Ireland | Cliffs_Airdrop_Weapons_Ranger | 4.348% |
| RioDeJaneiro | Carepackage_Brazil | 4.167% |
| RioDeJaneiro | Brazil_Carepackage_Brazil | 4.167% |
| Greece | Greece_Carepackage_Survivalist | 2.312% |
| RioDeJaneiro | Exterminators_Low | 1.860% |
| RioDeJaneiro | Low_Exterminators_Low | 1.860% |
| Ireland | Cliffs_IFR_High | 1.645% |
| RioDeJaneiro | Exterminators_High | 1.627% |
| RioDeJaneiro | High_Exterminators_High | 1.627% |
| France | Milita_Special_France | 0.822% |
| France | France_Milita_Special_France | 0.822% |
Showing 20 of 32 tables that can produce this weapon.
How to read the spawn table
Let us work through each column's meaning in detail, because understanding spawn tables is one of the most practical skills a server owner or modder can develop. The Map column identifies which official Unturned map the spawn table belongs to. Core is not a specific map -- it denotes the base game's shared loot configuration, which is used by the original maps including PEI, Washington, and Yukon. If you are running any of those maps, the Core spawn tables are active. RioDeJaneiro, Ireland, France, and Greece are DLC or curated maps that have their own map-specific spawn configurations. A weapon that appears in a Core table can drop on any Core map. A weapon that appears only in an Ireland table can only drop on the Ireland map.
The Spawn table column names the specific loot table definition. A spawn table is a weighted list of items. Every lootable container, every ground spawn point, and certain event-driven spawns (like airdrops and care packages) are assigned a spawn table. When the engine decides it is time to populate a container with loot, it rolls against whatever spawn table that container has been configured to use. The table name describes the context. Arena_Guns_Ranger_Common is a ranger-tier gun table used in arena locations. Military_Low_Guns is a low-tier military weapon table. Carepackage_Brazil is an airdrop loot table for the Rio de Janeiro map. Syndicate_Special is a special-tier loot table for syndicate faction locations.
The Chance per roll column is the probability, expressed as a percentage, that a single dice roll on that spawn table will produce the Snayperskya. A value of 33.333% means approximately a one-in-three chance per roll. A value of 0.822% means less than a one-in-one-hundred chance per roll. These probabilities are not rounded for display in the original data; they are recorded to three decimal places, reflecting the precision with which they are stored in the asset files.
The probability spread: from common to rare
The Snayperskya's spawn probability varies dramatically across tables. The highest probability is 33.333% in the Arena_Guns_Ranger_Common table on Core maps. The lowest probability shown in this excerpt is 0.822% in the two French militia tables (Milita_Special_France and France_Milita_Special_France). The ratio between the most common and rarest spawn sources shown here is approximately 40 to 1. That is an enormous spread. It means a player looting arena locations on a Core map is roughly 40 times more likely to find a Snayperskya per roll than a player looting militia special locations on the France map.
The probabilities decline roughly as you move down the table because the tables near the top are specialized weapon tables -- they contain relatively few items, so each individual weapon gets a larger share of the probability pie. The tables near the bottom are general loot tables that contain many possible items across multiple categories, diluting any single item's probability. Milita_Special_France at 0.822% shares its table with many other special-tier militia items, reducing the Snayperskya's individual chance.
Notice also that some tables appear to be duplicates or variants. Carepackage_Brazil and Brazil_Carepackage_Brazil on the Rio map both have a 4.167% chance. Exterminators_Low and Low_Exterminators_Low both have a 1.860% chance. Exterminators_High and High_Exterminators_High both have a 1.627% chance. And the two France militia tables both have a 0.822% chance. These likely represent different naming conventions or spawn definitions that functionally produce the same loot opportunity for the player. The duplication does not mean the weapon spawns twice from the same container; it means the engine can reach the weapon through two differently-named but equivalently-weighted table references.
The 20 of 32 note
The footnote "Showing 20 of 32 tables that can produce this weapon" is essential context. The data displayed here covers approximately 62.5% of the total spawn tables that include the Snayperskya. There are 12 additional tables, not shown, where this weapon can also appear. When you are doing a complete loot balance assessment, you need the full set of 32 tables. If you delete this weapon from the 20 tables shown here but forget about the 12 unlisted ones, the weapon will still appear in the world through those remaining tables, and your loot changes may not have the effect you intended. The partial listing in this article is sufficient for understanding where the weapon is most commonly found, but it is not sufficient for a comprehensive loot audit.
Practical implications for server configuration
For a server owner, the spawn table gives you a direct lever for controlling the Snayperskya's availability. If you want the weapon to be rare and special, remove it from the high-probability Core tables (the ones at 25% and above) and keep it only in the airdrop and care package tables, which already sit at low single-digit percentages. If you want the weapon to be a common military find that any player can acquire within their first hour, leave it in the Core tables and consider adding it to additional map-specific general loot tables.
When you add the weapon to a custom spawn table on your own map, the existing probabilities in this table give you a reference range for what the vanilla game considers appropriate. A specialized weapon table can carry a 20-33% chance per weapon slot. A general loot table might allocate 0.8-4% to a rare primary weapon like the Snayperskya. Use these figures as calibration references for your own spawn table tuning. If you set a custom sniper to 50% on a table that is rolled frequently, you are making the weapon significantly more common than anything in the vanilla game, which may or may not be your intent.
Canned Beans: absence in the Snayperskya data
Canned Beans occupy a recurring position in the canon of the 57 Studios wiki. They appear across many different asset references, sometimes in unexpected places, and their presence or absence has become a documented thread that connects disparate parts of the Unturned data ecosystem. For the Snayperskya, however, that thread does not extend. The Snayperskya's asset data contains no mention of Canned Beans whatsoever.
The weapon's spawn tables do not include any bean-related items. The crafting flags -- Blueprints, InputItems, OutputItems -- do not reference Canned Beans as a crafting ingredient or as a recipe result. The ammunition system, the attachment slots, and the damage tables are all concerned with ballistics and combat, not with food items. If there is a bean connection for the Snayperskya anywhere in the game's data, it has not been verified and does not appear in the asset data that this extraction covers.
This absence is worth noting precisely because the Canned Beans thread is a deliberate feature of the wiki. Not every item has a bean connection, and documenting the absences honestly -- "this weapon does not interact with beans in any documented way" -- is as important as documenting the presences. A reader who comes to this page looking for the Snayperskya's bean lore can see immediately that there is none and can move on without having to search other pages to confirm that they have not missed something.
For readers who are new to the wiki and encountering the Canned Beans canon for the first time, the full thread is documented at /lore/canned-beans-lore. That page explains what the Canned Beans thread is, how it originated, and which items in the Unturned data do have verified bean connections. The Snayperskya is not one of those items, and that is the end of the story for this particular asset reference.
Practical use for server owners and modders
Everything in this article converges on two practical questions: how do I use this information as a server owner to adjust the game's balance, and how do I use this information as a modder to create a new weapon derived from the Snayperskya. The answers draw on every section above.
Server owner workflow
If you are a server owner and the Snayperskya is causing balance problems on your server -- too common, too rare, too powerful, too weak -- the spawn table is usually where you start. The most impactful change you can make with the least effort is to adjust which spawn tables reference this weapon. Removing the Snayperskya from the five Core tables (at 33.333%, 29.749%, 29.749%, 25.000%, and 9.091% respectively) and keeping it only in the airdrop and care package tables will dramatically reduce its availability while preserving the excitement of finding one. Players will still encounter the weapon, but it will feel like a special occurrence rather than a routine military loot pickup.
If the weapon's damage is the concern rather than its availability, you have a few options depending on how deep you want to go. The simplest change is adjusting Player_Damage from 65. Raising it makes the weapon stronger in PvP; lowering it makes the weapon weaker. The next level of nuance is adjusting individual multipliers. If you think the Snayperskya is too punishing on headshots, you could lower Player_Skull_Multiplier below 1.1. If you think limb shots are too weak and the weapon feels frustrating to use when you do not land headshots, you could raise Player_Leg_Multiplier and Player_Arm_Multiplier above 0.6.
For PvE-focused servers, the Zombie_Damage field at 99 is more relevant than the player damage fields. If your zombie population is large and players are struggling to manage hordes even with the Snayperskya, raising Zombie_Damage gives the weapon more PvE utility without affecting PvP balance at all. The separation between player and zombie damage tables is one of Unturned's most useful modding features for PvE servers.
Modder workflow: creating a derivative weapon
If you are a modder and you want to create a new weapon based on the Snayperskya's stats, here is the step-by-step workflow. First, duplicate the .dat file to your custom mod directory. Second, assign a new GUID. Use any UUID v4 generator -- available in every programming language's standard library or through online tools -- to create a fresh 32-character lowercase hex string. Never reuse 5942d0d5f7024df094eba61b4372c7ab. Third, assign a new item ID. Pick an integer that does not conflict with any vanilla item or any other modded item you are running. The vanilla item ID range is mostly below 2000, but always check your specific mod setup.
Fourth, decide what to change. The most common customizations and their effects:
- Change
Player_DamageandZombie_Damageto tune the weapon's overall lethality. - Change
Firerate(higher number means slower fire) to adjust the firing cadence. - Change
Rangeto make the weapon effective at different engagement distances. - Change
Caliberto make the weapon use a custom ammunition type. - Change the multiplier fields to reshape the damage profile across hit zones.
- Add or remove attachment hook flags to control which accessories the weapon accepts.
- Add or remove crafting flags (
Blueprints,InputItems,OutputItems,RequiresNearbyCraftingTags) to control whether and how the weapon can be crafted. - Change
Actionand theSemiflag to alter the fire mode between semi-automatic and automatic. - Adjust recoil and spread values to change the weapon's handling feel.
After making your changes, test the weapon thoroughly. Spawn it with the /give command. Verify that the item ID and GUID are correct. Test every hit zone on every target type to confirm that damage values match your expectations. Test every attachment slot to confirm that accessories attach and detach correctly. Test the spawn tables by observing several loot cycles on your target map. Test the crafting recipes if you have defined any. Do not skip any of these tests. A weapon that looks right in the .dat file but has not been verified in-game is not a finished weapon.
Spawn table integration for custom maps
If you are adding the Snayperskya (or a derivative) to a custom map, the probabilities in the vanilla spawn table serve as your calibration reference. For a specialized weapon spawn, a probability between 15% and 33% is consistent with the vanilla game's treatment of this rifle. For a general loot spawn, a probability between 1% and 5% is appropriate. If your custom map has only a few spawn points for the weapon's table, you may need to set the probability higher than you would on a vanilla map to achieve the same effective drop rate. Remember that the "chance per roll" is only half the equation; the number of times the table is rolled per loot cycle is the other half. A table with a 5% chance that is rolled by 100 spawn points will produce more weapons over time than a table with a 33% chance that is rolled by only 2 spawn points.
The caliber cross-mod compatibility warning
The Caliber field at 11 is the single most impactful field for cross-mod compatibility. Many weapon mods use caliber 11 ammunition. If you change the Snayperskya's caliber to a custom value, players will need your custom ammunition to feed the weapon, and ammunition from other mods will not work. This can be a deliberate design choice -- you might want the weapon to use a rare, custom ammunition type that players must craft or find through specific means. But if you are not careful, you can create a weapon that spawns with no obtainable ammunition anywhere on the server, making it literally unusable. Always ensure that the caliber value you assign to a custom weapon has a corresponding ammunition item that spawns in the world, and test that ammunition can actually be loaded into the weapon before releasing your mod.
The Snayperskya is a well-documented weapon with a stable set of stats, a clear role in the Unturned arsenal, and a spawn profile that server owners can tune with precision. Whether you are using it as a balance reference for your server, cloning it as a template for a custom weapon, or simply satisfying your curiosity about the numbers that make the weapon work, this reference should give you everything you need to work with the asset data confidently and correctly.