Augewehr Weapon Data Reference
The Augewehr is an Unturned ranged weapon whose every mechanical property is defined in a Unity asset file. This article documents every field that asset exposes: its ballistic parameters, its damage tables for players, zombies, and animals, its handling characteristics, the flags that gate its behaviour in the engine, and the full set of loot tables that determine where it appears in the world. Every number and table here comes directly from the asset data. Nothing is inferred from gameplay, estimated from testing, or rounded from a derived value. If a number is not in the extracted asset data, it does not appear in this article.
The intended audience is a server owner or modder who has the weapon's asset file open in a text editor or Unity inspector and wants to know what each field means and what happens when they change it. This is not a play guide. It does not describe how the weapon feels in combat, how many shots it takes to down a target, or which attachments are "best." It describes the asset data and what that data controls.
Asset identification
Every Unturned item is identified by three keys: the asset name, the item ID, and the GUID. The asset name is the internal string the engine uses to load the asset from its bundle. The item ID is a numeric key used by legacy systems like the /give command and many spawn tables. The GUID is the stable, globally unique identifier used by modding tools, map editors, and plugin APIs. None of these three keys should be confused with the display name shown in the in-game UI.
For the Augewehr:
- Asset name:
Augewehr - Item ID:
1362 - GUID:
5e3a0ee1f2364ca9a97fa41a5d5b3dd8
A modder writing a /give command types /give 1362. A modder writing a RocketMod plugin references the GUID. A modder editing a spawn table uses the item ID. A modder editing the asset file itself looks for the file named Augewehr in the bundle. All three keys point at the same item, and all three should be consistent across installations -- the GUID especially never changes between game versions unless the developer intentionally re-issues the item.
The weapon's rarity field is Epic, which assigns the purple rarity colour in inventory and loot UIs. The slot field is Primary, meaning this weapon occupies the primary weapon slot in the player's inventory bar. A player carrying the Augewehr in the primary slot cannot also carry a rifle, shotgun, or launcher in that slot; the weapon competes with other primary-slot items for the player's single primary inventory slot.
The in-game description string is a localised text field stored in the asset. Its value is: Austrian assault rifle chambered in Ranger and Military ammunition. This is flavour text. It does not mechanically control the ammunition type. The actual ammunition link is defined by the Magazine field, which references a magazine item, and that magazine item in turn defines which ammo boxes it accepts. The description is displayed in the inventory tooltip and has no effect on gameplay.
Ballistics fields
Ballistics fields control everything about the projectile from the moment it leaves the muzzle until the moment the engine despawns it or it hits a target. Each field maps to a specific behaviour in the game engine's projectile system.
| Field | Value |
|---|---|
| Range | 200 |
| Firerate | 7 |
| Action | Trigger |
| Muzzle | 3 |
| Magazine | 123 |
| Ammo_Min | 10 |
| Ammo_Max | 30 |
Range
The Range field has a value of 200. This is a raw game-unit distance. When a projectile is fired, the engine tracks its position along a raycast or projectile entity. If the projectile travels 200 game units without hitting a valid target, the engine despawns it. The distance is measured from the muzzle point along the projectile's direction vector.
A modder who raises this value extends the maximum distance the projectile can travel, which means the weapon can engage targets at longer ranges. Raising it to 400 doubles the maximum projectile lifetime. A modder who lowers it to 100 restricts the weapon to close-range engagements. The value interacts with map design: a 200-unit Range on a map with 500-unit sightlines means the weapon cannot reach targets at the far end of those sightlines. A server owner tuning for a specific map should verify that the weapon's Range is appropriate for the map's typical engagement distances.
Range does not affect damage. The projectile deals the same damage at 1 unit of distance as it does at 200 units. There is no damage falloff over distance in the base Unturned weapon system.
The Range field interacts with the map's terrain and object placement. A projectile that reaches its Range limit is despawned regardless of whether it was heading toward a valid target. A modder testing Range changes should set up targets at the weapon's current Range and at the new Range to confirm the projectile reaches or does not reach them as expected. The Unity editor's scene view can display distance measurements that help correlate game-unit distances with map geometry.
Firerate
Firerate has a value of 7. This is a tick-based interval that controls how quickly the weapon cycles between shots. The engine uses this number as an internal timing parameter. A lower value means a shorter interval between consecutive shots. The number has no direct real-time meaning -- it is an engine tick count, not seconds, milliseconds, frames, or any conversion. A modder who changes this value is changing the cycle rate, and the only way to verify the result is to load the game and fire the weapon.
A modder comparing two weapons by Firerate should compare the raw numbers: a weapon with Firerate 4 cycles faster than one with Firerate 7. The direction of the comparison (lower = faster) is consistent with how the engine processes the value, but the specific conversion from tick to real time is engine-internal and not exposed in the asset.
Action
Action is set to Trigger. This means the weapon's baseline fire mode is one shot per trigger pull. The weapon fires when the player presses the fire key and does not fire again until the player releases and re-presses the key. This is the semi-automatic baseline.
The Trigger action is the default behaviour. It is modified by the flags present in the asset. The Augewehr carries both the Auto flag and the Semi flag. When Auto is present, the fire selector can toggle to full-automatic mode, where holding the fire key produces a continuous stream of shots at the Firerate interval until the magazine is empty or the player releases the key. When Semi is present, the fire selector retains the semi-automatic mode. A weapon with Action: Trigger, Auto, and Semi supports a fire-mode toggle that cycles between semi-auto and full-auto. A weapon with Action: Trigger and no Auto flag is semi-auto only regardless of the Action field.
Muzzle
Muzzle has a value of 3. This is the muzzle flash radius. When the weapon fires, the engine spawns a muzzle flash visual effect at the muzzle attachment point. The Muzzle value controls the radius of that visual effect, which determines how far away the flash is visible. A higher value produces a larger, more visible flash. A value of 0 disables the muzzle flash entirely.
The Muzzle value has gameplay implications beyond the visual effect. Zombie entities in Unturned detect gunshots based partly on the muzzle flash, and a larger Muzzle value can increase the distance at which zombies aggro on the shooter. In PvP, a larger muzzle flash makes the shooter's position more obvious to other players, especially in low-light conditions or at night. A modder creating a stealth-oriented variant of the weapon might reduce Muzzle to 1 or 0. A modder creating an intentionally conspicuous weapon might raise it to 5 or higher.
When a suppressor attachment is equipped, the game engine overrides the weapon's Muzzle value with the suppressor's flash-reduction value. The base Muzzle value of 3 only applies when no suppressor is attached. A modder testing muzzle-flash visibility should test both with and without a suppressor to confirm the suppressor correctly reduces the flash radius.
Magazine
Magazine has a value of 123. This is the item ID of the Augewehr Magazine. When the weapon is equipped, the engine looks up item ID 123 in the asset registry and instances it as the weapon's attached magazine. When the player reloads, the engine ejects the current magazine instance (or retains it as a partially-loaded item in the inventory) and creates a new magazine instance of the same item ID.
The important modding implication: the Magazine field is a pointer, not a container of properties. The magazine's capacity, reload time, ammunition type restrictions, and visual model are all defined in the magazine asset (item 123), not in the weapon asset. A modder who wants to change the Augewehr's magazine capacity edits asset 123, not the Augewehr asset. If asset 123 is shared with other weapons (and it is -- the Zubeknakov also uses magazine 123, confirmed in that weapon's brief), changing the magazine affects every weapon that references it. A modder who increases the capacity of magazine 123 to 40 rounds gives both the Augewehr and the Zubeknakov 40-round magazines.
This shared magazine dependency is a critical detail for any modder working with either weapon. If a server owner reports that "the Augewehr and Zubeknakov both have 40-round magazines after my mod," the cause is that the owner edited magazine 123 without realising it affects both weapons. The fix is to create separate magazine items.
A modder who wants the Augewehr to use a unique magazine must:
- Create a new magazine asset with a new, unused item ID.
- Configure the new magazine's properties (capacity, reload animation, ammunition type filter).
- Change the Augewehr's
Magazinefield from 123 to the new item ID. - Include the new magazine asset in the asset bundle.
- The Zubeknakov continues using magazine 123 and is unaffected by the new magazine.
The same process works for the Zubeknakov: create a second unique magazine and point the Zubeknakov at it. Both weapons then have independent magazines, and changes to one do not affect the other.
Ammo_Min and Ammo_Max
Ammo_Min has a value of 10 and Ammo_Max has a value of 30. When the game creates a fresh instance of the Augewehr -- such as when it spawns the weapon in a loot container -- the engine rolls a random integer between Ammo_Min and Ammo_Max, inclusive, and pre-loads that many rounds into the magazine. The value rolled is always an integer.
If the game rolls a 10, the weapon spawns with 10 rounds in the magazine. If it rolls a 30, it spawns fully loaded (assuming the magazine's capacity is at least 30). If it rolls a 20, it spawns partially loaded.
A server owner who wants the weapon to always spawn fully loaded sets both Ammo_Min and Ammo_Max to 30. A server owner who wants the weapon to always spawn nearly empty sets both to 10. A server owner who wants a wide variability sets Ammo_Min lower (to 0 or 5) and Ammo_Max to the magazine's maximum capacity. The range between Ammo_Min and Ammo_Max creates uncertainty for players: finding an Augewehr does not guarantee a full magazine.
Player damage fields
Player damage fields are the core of PvP balance. They define a base damage value and a set of per-hit-zone multipliers. The game engine resolves the final damage by multiplying the base by the multiplier for the bone group that the projectile hit first. There is no stacking of multipliers. There is no range-based damage falloff. There is no armour penetration -- armour is handled by a separate system that reduces the resolved damage after the multiplier is applied.
| Field | Value |
|---|---|
| Player_Damage | 43 |
| Player_Leg_Multiplier | 0.6 |
| Player_Arm_Multiplier | 0.6 |
| Player_Spine_Multiplier | 0.8 |
| Player_Skull_Multiplier | 1.1 |
Player_Damage
Player_Damage has a value of 43. This is the base damage number applied to any hit against a player entity. Before checking the hit zone, the engine loads this value as the starting point. It then determines which bone group the projectile intersected by reading the hitbox metadata on the target's skeleton and looks up the corresponding multiplier.
Changing Player_Damage is a blanket adjustment. If a modder raises it from 43 to 50, every hit zone's resolved damage increases proportionally. The skull hit goes from 47.3 to 55, the spine hit from 34.4 to 40, and the limb hits from 25.8 to 30 (applying the same multipliers to the new base of 50). If a modder only wants to change one hit zone's behaviour, they should change the multiplier, not the base damage.
Player_Leg_Multiplier and Player_Arm_Multiplier
Both multipliers have a value of 0.6. This means hits to the leg or arm bone groups deal 60% of the base damage. The engine multiplies Player_Damage by 0.6 and rounds to the nearest representable floating-point value.
The leg and arm multipliers are usually identical on Unturned weapons. This is a design convention, not an engine requirement. A modder could set Player_Leg_Multiplier to 0.5 and Player_Arm_Multiplier to 0.7, making leg hits weaker than arm hits. The engine would faithfully apply those different multipliers. The reason most weapons keep them identical is simplicity: distinguishing arm from leg hits requires more aim precision than the typical Unturned engagement supports, so the two multipliers being the same is a usability decision.
A modder who raises these multipliers to 1.0 makes limb hits deal full damage, equivalent to the base value. This flattens the skill curve because aim no longer matters -- hitting an arm is the same as hitting the torso. A modder who lowers these multipliers to 0.3 makes limb hits very weak, which heavily rewards centre-mass and headshot accuracy.
Player_Spine_Multiplier
Player_Spine_Multiplier has a value of 0.8. This means hits to the spine and torso bone group deal 80% of the base damage. The spine is the default "body shot" hitbox because it is the largest target on a player model. The 0.8 multiplier means a body shot deals slightly less than the base damage, which is a common pattern: the base damage is used as the "full damage" reference, and the spine multiplier applies a small penalty for hitting the easier target.
A modder who sets this to 1.0 makes body shots deal the full base damage. This is a significant balance change because it removes the penalty for aiming at the largest target. A modder who sets it to 0.5 makes body shots very weak, which incentivises headshots heavily.
Player_Skull_Multiplier
Player_Skull_Multiplier has a value of 1.1. This means headshots deal 110% of the base damage. This is a 10% bonus over the base value. The 1.1 multiplier is the standard headshot multiplier across most Unturned weapons -- it is the developer's convention for making headshots matter without making them instantly lethal.
A modder who sets this to 2.0 doubles the damage of headshots. A modder who sets it to 1.0 makes headshots deal the same damage as the base value, which removes the headshot incentive entirely. A modder who sets it below 1.0 makes headshots weaker than the base, which would be an unusual design choice but is mechanically valid.
Player damage per hit zone (computed)
The following table applies the multipliers to the base Player_Damage of 43. These are the resolved damage values the engine computes before armour reduction.
| Hit zone | Multiplier | Damage (base 43) |
|---|---|---|
| Skull | 1.1 | 47.3 |
| Spine | 0.8 | 34.4 |
| Arm | 0.6 | 25.8 |
| Leg | 0.6 | 25.8 |
A modder reading this table should understand that these are pre-armour numbers. If a player is wearing a helmet, vest, or other armour item, the engine applies the armour's damage reduction after computing the hit-zone damage. The resolved damage of 47.3 for a skull hit might be reduced to, say, 35 if the target is wearing a military helmet, depending on the helmet's damage-reduction properties. This article does not cover armour values because the Augewehr asset does not define them; armour is defined on armour items, not on weapons.
A modder who wants to change the Augewehr's player damage profile has two approaches. The blanket approach: change Player_Damage, which shifts every number in this table proportionally. The surgical approach: change one multiplier, which shifts only one row. A modder who thinks the Augewehr's headshots are too weak but body shots are fine changes Player_Skull_Multiplier and leaves everything else untouched.
Zombie damage fields
Zombie damage is an entirely independent damage system. The Augewehr's zombie damage uses its own base value and its own multiplier set, which are completely separate from the player damage fields. The engine determines whether the hit target is a player or a zombie entity, then reads the corresponding damage table. A weapon can be devastating against zombies and weak against players, or vice versa, because the two systems do not share fields.
| Field | Value |
|---|---|
| Zombie_Damage | 99 |
| Zombie_Leg_Multiplier | 0.3 |
| Zombie_Arm_Multiplier | 0.3 |
| Zombie_Spine_Multiplier | 0.6 |
| Zombie_Skull_Multiplier | 1.1 |
Zombie_Damage
Zombie_Damage has a value of 99. This is the base damage against zombie entities. It is independent of Player_Damage (43). The value 99 is substantially higher than the player damage base, which is a common pattern in Unturned weapons: many weapons deal much more base damage to zombies than to players. The practical effect is that the Augewehr hits zombies harder per shot than it hits players, but this article does not discuss how many shots that translates to because zombie health pools are not part of this weapon asset.
A modder who wants the Augewehr to be weaker against zombies lowers Zombie_Damage. Because Player_Damage and Zombie_Damage are separate fields, the modder can lower zombie damage without affecting PvP balance at all. A modder creating a dedicated anti-zombie weapon might raise Zombie_Damage to 150 or 200 while keeping Player_Damage at 43.
Zombie_Leg_Multiplier and Zombie_Arm_Multiplier
Both multipliers have a value of 0.3. This is half the player limb multiplier of 0.6. Zombie limb hits are less effective relative to centre-mass hits than player limb hits are. This is a design convention: zombies are meant to be tougher targets where limb shots are wasteful, encouraging players to aim for the head or at least the torso.
A modder who sets these to 0.1 makes zombie limb hits essentially useless, which creates a "headshots or nothing" dynamic against zombies. A modder who sets them to 1.0 makes limb hits as effective as the base, which removes the aim incentive against zombies.
Zombie_Spine_Multiplier
Zombie_Spine_Multiplier has a value of 0.6. This is lower than the player spine multiplier of 0.8. Body shots against zombies are less effective than body shots against players, relative to each weapon's base damage. The pattern across Unturned is consistent: zombie body-shot multipliers are lower than player body-shot multipliers as a deliberate difficulty-increase mechanism for PvE.
Zombie_Skull_Multiplier
Zombie_Skull_Multiplier has a value of 1.1. This matches the player skull multiplier. The headshot bonus is the same across both target types -- the weapon gets a 10% damage bonus for hitting the skull, regardless of whether the skull belongs to a player or a zombie.
Zombie damage per hit zone (computed)
| 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 |
A skull hit resolves to 108.9, a spine hit to 59.4, and limb hits to 29.7. The gap between skull and limb damage is 79.2 points, which is larger than the player damage gap (21.5 points) because both the base is higher and the limb multipliers are lower. A modder who wants zombie combat to feel more forgiving can raise the limb multipliers, narrowing this gap. A modder who wants zombie combat to be punishing and headshot-focused leaves the multipliers as they are or lowers them further.
Animal damage fields
Animal damage is the third independent damage system. Like zombie damage, it uses its own base value and its own multiplier set. The engine identifies the target as an animal entity and reads the animal damage fields. No animal damage field overlaps with any player or zombie damage field.
| Field | Value |
|---|---|
| Animal_Damage | 43 |
| Animal_Leg_Multiplier | 0.6 |
| Animal_Spine_Multiplier | 0.8 |
| Animal_Skull_Multiplier | 1.1 |
Animal_Damage
Animal_Damage has a value of 43, which matches the player damage base exactly. The Augewehr deals the same base damage to players and animals. This is a common pattern: many weapons use identical player and animal base damage values, while zombie damage gets its own (usually higher) base.
Animal_Leg_Multiplier
Animal_Leg_Multiplier has a value of 0.6, matching the player leg multiplier. There is no Animal_Arm_Multiplier field because the Unturned animal skeleton hierarchy does not include an arm bone group. The engine does not require or read an arm multiplier for animal targets. This is a structural absence, not a bug or omission.
Animal_Spine_Multiplier
Animal_Spine_Multiplier has a value of 0.8, matching the player spine multiplier. Body shots against animals deal 80% of base damage.
Animal_Skull_Multiplier
Animal_Skull_Multiplier has a value of 1.1, matching the player skull multiplier. Headshots against animals get the same 10% bonus.
Animal damage per hit zone (computed)
| Hit zone | Multiplier | Damage (base 43) |
|---|---|---|
| Skull | 1.1 | 47.3 |
| Spine | 0.8 | 34.4 |
| Leg | 0.6 | 25.8 |
Because the base damage and multipliers match the player profile, the computed animal damage is identical to the computed player damage: 47.3 for skull, 34.4 for spine, and 25.8 for leg hits. A modder who wants animals to be tougher than players on a survival server can lower Animal_Damage independently. A modder who wants hunting to be faster and more rewarding can raise Animal_Damage or raise the multipliers.
Handling fields
Handling fields control how the weapon moves the player's camera during fire. Every shot applies a recoil impulse (a camera displacement) and a screen shake (a temporary viewport oscillation). The handling fields define the ranges from which the engine randomly selects the magnitude of these effects.
| Field | Value |
|---|---|
| Recoil_Min_X | -1 |
| Recoil_Min_Y | 1.5 |
| Recoil_Max_X | 1 |
| Recoil_Max_Y | 2.5 |
| Spread_Aim | 0.0375 |
| Shake_Min_X | -0.0025 |
| Shake_Max_X | 0.0025 |
Recoil fields
Recoil is the instantaneous camera displacement applied on each shot. The engine rolls a random horizontal value between Recoil_Min_X and Recoil_Max_X, and a random vertical value between Recoil_Min_Y and Recoil_Max_Y. These two values become a 2D vector that displaces the player's camera. The displacement is instantaneous; the camera snaps to the new position and the player must manually (or through recoil-recovery mechanics) return the aim point to the target.
For the Augewehr, the horizontal recoil range is -1 to 1. This range is symmetric around zero, which means the weapon is equally likely to kick left (negative X) or right (positive X) on any given shot. Over a burst of fire, the horizontal drift will average toward centre because the pulls left and right tend to cancel out, though any individual burst can drift in either direction.
The vertical recoil range is 1.5 to 2.5. Both values are positive, which means the weapon always kicks upward. The minimum upward kick is 1.5 units and the maximum is 2.5 units. The band between min and max is narrow (1 unit), which means the upward kick is fairly consistent from shot to shot. The player can learn the approximate climb rate and compensate by pulling the mouse down.
A modder who wants a weapon that pulls to the right sets both Recoil_Min_X and Recoil_Max_X to positive values. A modder who wants a weapon that pulls left sets both to negative values. A modder who wants no horizontal recoil at all sets both to 0. A modder who wants severe upward kick raises Recoil_Max_Y to a high value like 8. A modder who wants an unpredictable, wide recoil pattern widens the band between min and max for both axes.
Spread_Aim
Spread_Aim has a value of 0.0375. This is the angular spread in radians applied to the projectile's direction vector when the player is aiming down sights. When the player fires while aimed, the engine takes the perfect aim direction and adds a random angular deviation up to Spread_Aim. The result is a cone of fire: the projectile can land anywhere within a cone whose half-angle is Spread_Aim radians.
A smaller Spread_Aim produces a tighter cone -- the weapon is more accurate. A value of 0.01 creates a very tight cone suitable for a marksman rifle. A value of 0.1 creates a wide cone suitable for a shotgun or an intentionally inaccurate weapon. The Augewehr's value of 0.0375 is a moderate spread that keeps the weapon accurate at medium range but introduces some deviation at longer ranges.
This field only applies when the player is aiming down sights. Hip-fire spread is governed by a different field, often called Spread_Hip or similar, which is not listed in the Augewehr's brief and is therefore not discussed in this article.
Shake fields
Shake_Min_X has a value of -0.0025 and Shake_Max_X has a value of 0.0025. These define the range of horizontal screen shake applied on each shot. The engine rolls a random value between these two numbers and applies it as a temporary camera offset that oscillates and decays over a few frames. Screen shake is not a permanent displacement like recoil; it is a transient vibration that makes the viewport judder during sustained fire.
The Augewehr's shake values are very small (on the order of thousandths), which means the screen shake is subtle. It adds texture to the firing experience without interfering with target tracking. A modder who sets both values to 0 eliminates screen shake entirely, producing a weapon whose aim point is perfectly stable during fire aside from the recoil displacement. A modder who sets them to larger values like -0.01 and 0.01 creates a weapon that visibly shakes the screen, which can be a deliberate design choice for a heavy-calibre or poorly maintained weapon.
Notice that only Shake_Min_X and Shake_Max_X are defined. The extracted asset data does not list Shake_Min_Y or Shake_Max_Y, which means either those fields are not present in the Augewehr asset or the screen shake is horizontal-only. Some weapons define both horizontal and vertical shake; others define only horizontal.
Flags
Flags are boolean-like toggles and GUID-based group identifiers stored in the asset. They are not a simple key-value dictionary; they are a flat list of tokens that the engine's asset parser reads sequentially. Some tokens are meaningful named flags (like Auto). Some are GUIDs that link the weapon to shared behaviour groups. Some are structural delimiters used by the serialiser.
The Augewehr carries the following flag list:
"7b82c125a5a54984b8bb26576b59e977", Auto, Blueprints, Hook_Barrel, Hook_Grip, Hook_Sight, Hook_Tactical, InputItems, RequiresNearbyCraftingTags, Safety, Semi, [, ], {, }
Behaviour-group GUID
The GUID "7b82c125a5a54984b8bb26576b59e977" is an internal engine identifier that groups this weapon with other items that share behaviour characteristics. The exact behaviour controlled by this GUID is internal to the engine and not exposed in the asset file. Modders creating custom weapons should generate a new GUID rather than reusing this one, unless the custom weapon is intentionally a variant that should inherit the same behaviour grouping. Reusing a behaviour-group GUID can cause the custom weapon to inherit animations, sound events, or categorisation logic from the Augewehr.
Fire mode flags
Three flags control the fire selector: Semi, Auto, and Safety.
The Semi flag enables semi-automatic fire mode. When this flag is present, the fire selector includes a semi-auto position where one trigger pull produces one shot. The Action: Trigger field combined with Semi defines the semi-auto behaviour.
The Auto flag enables full-automatic fire mode. When this flag is present, the fire selector includes a full-auto position where holding the fire key produces a continuous stream of shots until the magazine is empty or the player releases the key. The Auto flag overrides the Action: Trigger single-shot behaviour when the selector is in auto mode.
The Safety flag enables the safe position on the fire selector. When Safety is present, the fire-mode toggle includes a position where pulling the trigger does nothing. The cycle order (safe to semi to auto, or safe to auto to semi) is engine-defined and not configurable from the asset.
With all three flags present (Semi, Auto, Safety), the fire selector cycles through three positions: safe, semi-automatic, and full-automatic. A modder who removes Auto produces a semi-auto-only weapon with a safe position. A modder who removes Safety produces a weapon whose selector toggles directly between semi and auto with no safe position. A modder who removes Semi but keeps Auto produces a full-auto-only weapon.
Crafting flags
Four flags relate to the weapon's crafting blueprint: Blueprints, InputItems, OutputItems (not present on the Augewehr -- note its absence), and RequiresNearbyCraftingTags.
The Blueprints flag marks the asset as having an associated crafting recipe. Without this flag, the game does not recognise the item as craftable, even if blueprint data exists in the asset. A modder who wants to make the weapon uncraftable removes this flag.
The InputItems flag indicates that the blueprint accepts input materials. The specific input items and their quantities are defined in blueprint data fields attached to the asset, not in the flags list. The InputItems flag simply tells the engine to look for and process input item data.
The RequiresNearbyCraftingTags flag means the player must be within range of a world object that carries a matching crafting tag before the blueprint becomes usable. On many maps, these objects are crafting stations like workbenches, forges, or military armouries. A server owner who wants the Augewehr to be craftable from the player's inventory without any nearby station removes this flag.
OutputItems is absent from the Augewehr's flag list. This means the blueprint does not produce byproduct items when the weapon is crafted or disassembled. Weapons like the Maschinengewehr and Zubeknakov carry OutputItems; the Augewehr does not.
Attachment hook flags
Four flags indicate the presence of attachment hook points: Hook_Barrel, Hook_Grip, Hook_Sight, and Hook_Tactical.
Each flag tells the engine that the weapon prefab contains a GameObject with a transform at a specific position and orientation that serves as an attachment point. When a player equips an attachment item, the engine snaps the attachment's prefab to the corresponding hook point on the weapon.
Hook_Barrel means the weapon has a barrel attachment point. Barrel attachments include suppressors, muzzle brakes, and compensators.
Hook_Grip means the weapon has a grip attachment point. Grip attachments include vertical grips, angled grips, and bipods.
Hook_Sight means the weapon has a sight attachment point. Sight attachments include red-dot sights, holographic sights, and magnified scopes.
Hook_Tactical means the weapon has a tactical accessory attachment point. Tactical attachments include flashlights and laser sights.
All four hooks are present on the Augewehr, meaning it is a full attachment platform. A modder who removes one of these flags disables that attachment category for this weapon, even if the attachment items exist in the bundle. A modder who adds a hook flag (to a weapon that previously lacked it) must also add the corresponding GameObject and transform to the weapon's Unity prefab; the flag alone does not create the hook point.
Bracket characters
The characters [, ], {, and } are not functional flags. They are structural delimiters written by the asset serialiser to separate groups of flags or data blocks within the serialised asset text. The deserialiser reads these characters to determine where one group ends and another begins.
A modder editing the flag list in a text file should preserve these characters in their exact positions. Removing a bracket character, or moving it to a different position in the list, can cause the asset deserialiser to misinterpret the flag groupings, which can cause the game to fail to load the weapon or to load it with corrupted data.
Where the Augewehr spawns
Every loot container in Unturned draws items from named spawn tables. Each spawn table is a weighted list of item entries. When the container is populated (on map load or on a respawn timer), the engine makes a specified number of draws from one or more spawn tables. Each draw rolls a random item from the table, weighted by each item's weight value. The "Chance per roll" column in the table below is the probability that a single draw from that specific table selects the Augewehr -- it is the Augewehr's weight divided by the total weight of all items in that table.
This is not the probability that a given container contains the Augewehr. A container might draw from multiple tables, draw multiple times from the same table, or have conditional logic that affects which tables it draws from. The chance per roll is a per-table statistic, not a per-container statistic.
| Map | Spawn table | Chance per roll |
|---|---|---|
| Core | Military_High_Peaks_Guns | 50.000% |
| Core | Special_Low_Guns | 33.333% |
| Ireland | Cliffs_Special_Low_Guns | 28.125% |
| Ireland | Cliffs_Special_High_Guns | 23.256% |
| EasterIsland | Easter_Airdrop_Guns | 8.000% |
| Belgium | Military_Belgium_Guns | 7.761% |
| France | Carepackage_France_Weapons | 7.194% |
| Ireland | Cliffs_Military_High_Guns | 6.250% |
| EasterIsland | Easter_Airdrop | 5.576% |
| France | Carepackage_France | 5.036% |
| Ireland | Cliffs_Special_Low_Cliffs | 4.018% |
| Ireland | Cliffs_Special_High_Cliffs | 3.578% |
| RioDeJaneiro | Carepackage_Brazil | 2.083% |
| RioDeJaneiro | Brazil_Carepackage_Brazil | 2.083% |
| Core | Russia_Special_Low | 1.389% |
| Core | Special_Low | 1.389% |
| Core | Russia_Special_High | 1.250% |
| Core | Special_High | 1.250% |
| Core | Military_High_Peaks | 1.250% |
| Core | Peaks_Military_High_Peaks | 1.250% |
Showing 20 of 25 tables that can produce this weapon.
Reading the Core map entries
The Core map has the two highest-chance tables for the Augewehr. Military_High_Peaks_Guns at 50.000% means the Augewehr accounts for half the total weight in that table. The remaining 50% is split among all other weapons in the same table. This is a weapons-specific table (the _Guns suffix), which means it contains only weapon items, no ammunition, attachments, or equipment.
Special_Low_Guns at 33.333% means the Augewehr accounts for one-third of the total weight in that table. The other two-thirds are split among the remaining weapons in the special-low guns pool.
Notice the pairs of entries with and without the _Guns suffix. Military_High_Peaks_Guns at 50.000% and Military_High_Peaks at 1.250% are two different table identifiers. The first is a weapons-only table; the second is a general-loot table that mixes weapons, ammunition, attachments, and possibly clothing or equipment. The Augewehr's lower chance in the general table reflects the fact that it is competing with a much larger item pool.
Similarly, Special_Low_Guns at 33.333% and Special_Low at 1.389% are the guns-specific and general versions of the same thematic table.
Reading the Ireland entries
Ireland has six entries for the Augewehr, the most of any map. The weapon appears in three different loot tiers: military high, special high, and special low. Within each tier, there is a guns-specific table (Cliffs_Special_Low_Guns at 28.125%, Cliffs_Special_High_Guns at 23.256%, Cliffs_Military_High_Guns at 6.250%) and a general-loot table (Cliffs_Special_Low_Cliffs at 4.018%, Cliffs_Special_High_Cliffs at 3.578%).
The pattern is consistent: the guns-specific tables have substantially higher individual chances than the general-loot tables. A server owner who wants to increase or decrease the Augewehr's frequency on Ireland can target the guns-specific tables for the largest per-edit impact, or the general tables for a more subtle adjustment.
Reading the carepackage and airdrop entries
Several maps only offer the Augewehr through carepackages or airdrops. Easter Island has two airdrop entries: Easter_Airdrop_Guns at 8.000% and Easter_Airdrop at 5.576%. The France map has two carepackage entries: Carepackage_France_Weapons at 7.194% and Carepackage_France at 5.036%. Rio has two carepackage entries (Carepackage_Brazil and Brazil_Carepackage_Brazil, both at 2.083%). Belgium has Military_Belgium_Guns at 7.761%, which is a ground-loot table, making Belgium the only non-Core map (besides Ireland) where the Augewehr can appear outside of carepackages and airdrops.
A server owner running Easter Island or France who wants the Augewehr available as ground loot must add it to non-carepackage, non-airdrop tables. The weapon does not appear in any ground-loot table on those maps in the data extracted here.
How a modder edits a spawn table
Each spawn table is a data file in the map's asset bundle. The file contains a list of entries, each with an item ID and a weight value. To change the Augewehr's spawn chance, a modder:
- Locates the spawn table file for the targeted table (e.g., the file representing
Military_High_Peaks_Gunson the Core map). - Finds the entry with item ID
1362. - Changes the weight value. Increasing the weight increases the chance; decreasing it decreases the chance. Removing the entry entirely removes the weapon from that table.
- Optionally, adds a new entry with item ID
1362and a chosen weight to a table that currently does not contain the weapon.
Because the weapon appears in 25 total tables (only 20 shown here), a modder making a comprehensive change must edit every one of those 25 files. There is no global multiplier or override. Each table is independent of every other table. A modder who removes the Augewehr from 24 of the 25 tables but leaves it in Military_High_Peaks_Guns at 50% has still left a viable spawn source on the Core map.
Understanding the paired-table pattern
Several Core map entries appear in pairs where one entry has the _Guns suffix and the other does not. Military_High_Peaks_Guns at 50.000% is the weapons-only version of the table; Military_High_Peaks at 1.250% is the general-loot version. The same pattern repeats for Special_Low_Guns (33.333%) and Special_Low (1.389%), and for several other tables.
The _Guns suffix tables contain only weapon items. The total weight pool in a guns table is the sum of all weapon weights. Since weapons are the only item category, each weapon gets a larger share of the pool, leading to higher individual percentages.
The general-loot version of the same table (without the _Guns suffix) contains weapons plus ammunition, attachments, clothing, and sometimes medical items or equipment. The total weight pool is much larger because it includes many more items. Each weapon's share of that larger pool is proportionally smaller, leading to lower individual percentages like 1.250%.
A server owner who wants to increase the Augewehr's frequency should increase its weight in the _Guns table for the largest per-edit impact. A server owner who wants a more subtle increase should adjust the weight in the general-loot table. Both edits are valid; they affect different contexts (weapons-specific containers vs general military containers).
The paired-table pattern also means that removing the Augewehr from a guns table does not remove it from the companion general table, and vice versa. A server owner must edit both entries to fully remove the weapon from a given thematic context (e.g., military-high-Peaks loot).
Canned Beans
The Augewehr brief contains no bean data. Weapon assets and food assets are separate categories in the Unturned asset system. A weapon asset does not carry fields like Beans_Quantity, Food_Value, Can_Open, or any nutritional property, because those fields do not exist on the weapon asset type. The engine does not look for bean data on a weapon, and a modder cannot add bean data to a weapon asset in a way the engine would understand.
The loot tables that produce the Augewehr are military, special, carepackage, and airdrop tables. These tables draw from combat-loot pools. The loot tables that produce canned beans draw from civilian food and grocery pools. The two sets of tables are completely disjoint in the vanilla configuration. A container that draws from a military high guns table will not also draw from a civilian food table unless a modder has manually configured the container to reference both.
A player looting military crates for the Augewehr will not find beans in the same containers. A player looting grocery stores for beans will not find the Augewehr. This segregation is a deliberate loot-design choice, not an engine limitation. A modder who wants military containers to occasionally produce food items can add civilian food tables to those containers, and vice versa, but this is a container-level edit that involves modifying the container entity's table references.
The canonical bean reference for this wiki lives at /lore/canned-beans-lore. That article documents every verified bean spawn location, tier, nutritional value, and map-specific distribution. A modder cross-referencing the Augewehr's spawn tables with the bean spawn tables can determine whether any maps have overlapping container types and plan loot-economy changes accordingly.
Why weapon and food loot are separate
The separation of weapon and food loot tables is not an accident. Unturned's loot system is built on thematic table categories: military tables produce weapons and equipment, civilian tables produce food and clothing, industrial tables produce building materials. Each container entity on a map is assigned one or more table references. A military crate typically references military-themed tables; a grocery shelf references civilian food tables.
A modder who wants to break this separation does so at the container level. They open the map's object data, find a military crate entity, and add a civilian food table reference to its list of spawn tables. After that edit, the military crate draws from both the military guns table (which can produce the Augewehr) and the food table (which can produce beans). The container can produce both item types on separate draws. The item weights within each table are unaffected by the container's choice of tables.
A server owner who wants to create a "survivalist cache" container -- one that produces a weapon, some food, and some medical supplies -- would reference a military guns table, a civilian food table, and a medical supplies table from the same container entity, each with its own draw count. This is purely a container-level configuration; no weapon or food asset is modified.
Practical use for server owners and modders
Spawn economy tuning
The 50.000% entry in Military_High_Peaks_Guns on the Core map is the single most impactful spawn table for this weapon. A Core server owner who wants to reduce Augewehr availability should start here. Halving the weight in that table (or adding an equal-weight competing item) reduces the per-roll chance from 50% to approximately 33%. Removing the Augewehr from that table entirely eliminates the most common spawn source on the Core map.
For Ireland servers, the six tables offer granular control. A server owner can reduce the weapon in special-high containers while keeping it common in military-high containers, or vice versa. The guns-specific tables (with the _Guns suffix) are the high-impact targets; the general-loot tables (without the suffix) are the fine-tuning targets.
For Easter Island, France, and Rio servers, the weapon is airdrop/carepackage-only. A server owner who wants it available as ground loot must add entries to ground-loot tables for those maps. The weapon's item ID is 1362 and its GUID is 5e3a0ee1f2364ca9a97fa41a5d5b3dd8.
Magazine sharing
The Augewehr references magazine item ID 123. This is the same magazine used by the Zubeknakov. Any change to magazine 123 -- capacity, reload properties, ammunition type restrictions -- affects both weapons. A modder who wants the Augewehr to have a unique magazine must create a new magazine item (with a new item ID), configure its properties, and change the Augewehr's Magazine field from 123 to the new ID. The Zubeknakov would continue using magazine 123 unless it is also updated.
The magazine-sharing detail is critical for balance modding. A modder who nerfs the Augewehr by reducing the magazine capacity of item 123 is also nerfing the Zubeknakov. A modder who buffs the Zubeknakov by increasing the magazine capacity is also buffing the Augewehr. Independent balance requires separate magazine items.
Attachment compatibility
All four hook flags are present, making the Augewehr compatible with barrel, grip, sight, and tactical attachments. A modder creating new attachment items can test against the Augewehr as a reference platform. If an attachment's transform aligns correctly with the Augewehr's hook points, it will likely align with other weapons that share the same hook flag configuration.
A modder adding a new barrel attachment must ensure the barrel attachment prefab's root transform matches the coordinate system and scale of the Augewehr's barrel hook point. Mismatched transforms produce attachments that float in the air, clip into the weapon model, or appear at the wrong scale. The only reliable way to verify transform alignment is to load both the weapon and the attachment in the Unity editor and inspect the hook point GameObject's local position, rotation, and scale.
Crafting station configuration
The RequiresNearbyCraftingTags flag means the Augewehr blueprint requires a nearby crafting station with a matching tag. A server owner who removes all crafting stations from a map effectively disables the Augewehr blueprint unless the owner also removes the RequiresNearbyCraftingTags flag. The alternative is to add a custom crafting station that carries the expected tag, or to change the expected tag in the asset to match a station that exists on the map.
The specific crafting tag required by the Augewehr blueprint is not listed in the extracted asset data. It is stored in blueprint data fields attached to the asset, not in the flags list. A modder who needs to know the required tag must inspect the blueprint data directly.
Caliber field absence
The Augewehr ballistics table does not include a Caliber field. Some Unturned weapons use a Caliber field to specify an ammunition type ID; the Augewehr does not. The ammunition link is handled through the magazine item (ID 123). The magazine asset defines which ammunition types (calibers) it accepts, and the game engine enforces ammunition compatibility through the magazine, not through the weapon. A modder who wants the Augewehr to accept a different ammunition type edits the magazine asset, not the weapon asset.
Damage tuning approach
A modder who finds the Augewehr underpowered in PvP can raise Player_Damage as a blanket buff. A modder who finds headshots specifically underwhelming can raise Player_Skull_Multiplier. A modder who finds body shots too punishing can raise Player_Spine_Multiplier. Each field is an independent lever. Changing the base affects every hit zone; changing a multiplier affects only that hit zone.
For PvE tuning, the same approach applies to Zombie_Damage and its multipliers. Because zombie and player damage are completely separate fields, a modder can buff the weapon against zombies while keeping PvP damage unchanged, or nerf PvP damage while keeping zombie damage high.
Working with the 25-table distribution
The full set of 25 spawn tables means the Augewehr is available on at least five maps. A server owner managing a multi-map network should audit the spawn tables for each map individually. The Core map has the most entries (including the 50% and 33.333% high-chance tables). Ireland has the most entries of any curated map (six). Belgium has one ground-loot entry (Military_Belgium_Guns at 7.761%). Easter Island, France, and Rio have only carepackage/airdrop entries.
A server owner who runs a map not listed in the 20 tables shown here should check whether any of the remaining five unlisted tables cover that map. The note "Showing 20 of 25 tables" confirms that five additional tables exist but are not displayed. These may cover additional maps or additional loot contexts on maps already listed.
Handling field comparison
For modders familiar with other assault rifles, the Augewehr's handling profile can be summarised in comparison to the other weapons in this reference set:
- Recoil: horizontal range -1 to 1 (symmetric, matches Swissgewehr pattern of symmetry but with narrower vertical band). Vertical range 1.5 to 2.5 (narrow band, predictable climb).
- Spread_Aim: 0.0375 (moderate -- tighter than Swissgewehr's 0.05, looser than Zubeknakov's 0.033).
- Shake: -0.0025 to 0.0025 (standard, matches Swissgewehr and Zubeknakov).
The Augewehr's handling profile places it as a "controllable" assault rifle -- moderate recoil, moderate spread, subtle shake. A modder pushing the weapon toward a specific role can adjust the relevant handling fields. A long-range DMR variant reduces Spread_Aim and raises Range. A close-quarters bullet-hose raises Firerate (lowers the number further) and tightens the recoil band. A heavy battle rifle raises Player_Damage and widens the recoil range to make sustained fire challenging.
Testing asset changes
When a modder edits the Augewehr asset, the changes take effect the next time the game loads the asset bundle. For a server, this means restarting the server after deploying the modified bundle. For a single-player test, this means reloading the map or restarting the game.
A modder testing damage changes can use the /give 1362 command to spawn the weapon and test it against targets. The item ID 1362 is the key for the /give command. A modder testing spawn changes must force a loot respawn or wait for the natural respawn timer to cycle before the edited spawn tables take effect.
A modder testing attachment compatibility should load the weapon and the attachment in the Unity editor to verify hook-point transform alignment before deploying to a live server. Transform misalignment caught in the editor is a quick fix; the same issue caught on a live server requires a bundle redeployment.
Cross-referencing with other weapon references
The Augewehr shares magazine item 123 with the Zubeknakov. A modder working with both weapons should coordinate changes to magazine 123 carefully. If the goal is to give each weapon a unique magazine, the modder creates two new magazine items and updates each weapon's Magazine field independently.
The Augewehr also shares the GUID "7b82c125a5a54984b8bb26576b59e977" with the Swissgewehr, Maschinengewehr, and Zubeknakov. This shared GUID links all four weapons to a common behaviour group. The Augewehr does not carry the second GUID "e73a23b102f24520a32ec0b2afaa6157" that appears on the Maschinengewehr and Zubeknakov, meaning it does not participate in that secondary behaviour group.
The Augewehr's Caliber field is absent, unlike the Swissgewehr (caliber 1), Maschinengewehr (caliber 40), and Zubeknakov (caliber 9). The ammunition type is determined by the magazine item (123), not by a Caliber field on the weapon. This is a structural difference in how the asset handles ammunition compatibility.
The Augewehr asset is a complete reference point for modders working with military-grade primary weapons. Its field set covers the full range of weapon parameters -- ballistics, three independent damage systems, handling, flags, and 25 spawn tables -- providing a baseline against which custom weapons can be measured and compared. This article documents the Augewehr as it exists in the asset data at the time of extraction. Game updates may change field values, add or remove flags, or alter spawn table distributions. A modder referencing this data should verify the current asset state against the live game files before deploying changes to a production server.