Rocket Launcher Weapon Reference

Intermediate30-40 minutesCross-platformUnturnedAsset EditorText Editor

The Rocket Launcher -- full asset name Launcher_Rocket -- is an explosive weapon defined in Unturned's asset files. It carries item ID 519, the GUID af47bb9e0ba7443fa69435f1f594a10b, rarity Legendary, and occupies the Primary equipment slot. Its in-game description reads: Russian rocket launcher chambered in Rockets.

This article is a data reference for modders. It catalogues every field the asset file exposes, explains what each field controls, and shows every loot table in which the weapon appears with its exact spawn-chance per roll. It does not provide play advice, projectile-leading tips, or damage maths beyond the values the file literally contains.

Why this reference exists

When a modder opens an Unturned weapon asset file, they see field names and numbers. The file does not explain what Action Rocket means versus Action Trigger, or why Recoil_Min_X is -15 while Spread_Aim is 0.1. This reference answers those questions field by field, using the Rocket Launcher's actual extracted values.

The Rocket Launcher is a useful study asset because it combines three systems that appear across many explosive and crafting weapons: the projectile-based action system (shared with missile launchers, grenade launchers, and any weapon that spawns a physical projectile), the crafting-blueprint system (shared with craftable items that require nearby workstations), and the attachment-hook system (shared with every weapon that accepts scopes, grips, and tactical devices). Understanding how the Rocket Launcher's fields work gives you the mental model for reading any explosive or craftable weapon asset.

The weapon-projectile asset boundary

One of the most important concepts for modders to internalise is that the Rocket Launcher is two assets, not one. The weapon asset (this file, Launcher_Rocket.dat) defines the weapon's handling, its ammo draw, its fire mode, and its attachment support. It does not define what happens when the rocket hits something. That behaviour lives in a separate projectile asset -- a .dat file for the rocket object itself, which defines the explosion damage, blast radius, projectile speed, gravity influence, impact effects, and visual trail.

The connection between the two assets is indirect. The weapon declares Action Rocket, which tells the game engine to spawn a projectile of the Rocket archetype at the muzzle transform on fire. The game then looks up which projectile asset to instantiate using either a direct GUID reference in the weapon file (if present) or a calibre-based lookup (matching the weapon's Caliber to a projectile asset registered for that calibre). The exact lookup mechanism varies by Unturned version and by how the projectile asset is registered in the game's asset bundle.

This two-file architecture has a practical consequence for modders: every time you edit the Rocket Launcher's weapon asset, ask yourself whether the change belongs in the weapon file or in the projectile file. A change to Player_Damage on the weapon may or may not be read by the projectile -- it depends on whether the projectile asset uses the weapon's damage field as a base value or defines its own independent damage. Until you inspect the projectile asset, you do not know which file controls the explosion's lethality. This reference covers the weapon asset; a companion reference for the projectile asset would cover the explosion parameters.

Asset identity

Every item in Unturned is identified by three values that appear together in the asset file: the asset name, the item ID, and the GUID. The asset name is the internal identifier the game engine uses to load the file from the Bundles directory. The item ID is a numeric key used by commands, save files, and the item-spawning system. The GUID is a 32-character hex string that uniquely identifies the item across all assets in the game.

For the Rocket Launcher these identifiers are:

Attribute	Value
Asset name	`Launcher_Rocket`
Item ID	`519`
GUID	`af47bb9e0ba7443fa69435f1f594a10b`
Rarity	`Legendary`
Slot	`Primary`

The Rarity field controls which colour the item's name displays in the inventory UI. Legendary items appear in gold. The game uses the rarity string to look up a colour entry in the UI theme; changing this field to Epic would display the name in purple. The rarity string is also used by some server plugins and loot-filtering systems to gate item availability by tier, so changing it can affect which loot tables the item qualifies for if the server uses rarity-gated spawning logic.

The Slot field determines which equipment slot the weapon occupies. Primary means it competes with rifles, shotguns, and other large weapons. A player can carry one Primary weapon and one Secondary weapon at a time. If a player picks up the Rocket Launcher while already holding a Primary weapon, the existing weapon is dropped or swapped depending on server settings. Slot assignment also determines which hotbar key the weapon binds to (typically key 1 for Primary, key 2 for Secondary) and which animation set the game uses for equipping, firing, and reloading.

The asset name Launcher_Rocket follows a simple naming convention: the category (Launcher) followed by the subtype (Rocket). This distinguishes it from other launcher-type assets such as the missile launcher or grenade launcher. When browsing bundle files, the Launcher_ prefix groups all launcher-class weapons together alphabetically. The naming convention is not enforced by the engine -- you could rename the asset to anything -- but following the Category_Subtype pattern helps other modders find and identify your custom weapons when browsing extracted assets.

How the game loads and registers the Rocket Launcher

When Unturned starts (or when a server loads a map that references the Rocket Launcher), the game runs an asset-loading pipeline that reads the weapon from its bundle file into a runtime data structure. Understanding this pipeline helps modders debug asset-loading failures, GUID conflicts, and model-disappearance issues.

The pipeline has four stages:

Stage one: bundle discovery. The game scans its Bundles directory (and any mod-directory bundles if workshop content or server mods are active) for .dat asset files. Each .dat file is a serialised key-value format that defines one item, vehicle, structure, or object. The Rocket Launcher's weapon asset is one such .dat file. The game does not care about the filename -- it reads the ID field inside the file to determine the item ID. A file named WrongName.dat that contains ID 519 is still loaded as the Rocket Launcher.

Stage two: GUID registration. The game reads the GUID field from each .dat file and registers it in a global GUID-to-item-ID lookup table. This table is used for cross-referencing: when a blueprint or loot table references a GUID, the game resolves it to an item ID through this table. If two .dat files claim the same GUID, the last-loaded one wins (overwriting the previous registration), and the overwritten item's GUID-based references silently break. This is why modders must never copy an existing item's GUID into a custom asset -- the GUID collision will break one or both items.

Stage three: item-ID table construction. The game builds a sparse lookup table mapping numeric item IDs to the parsed asset data. Item ID 519 maps to the Rocket Launcher's parsed fields. This table is used for inventory operations, save-file loading, and in-game spawn commands (/give 519). If two .dat files claim the same item ID, the game's behaviour depends on the Unturned version -- some versions reject the duplicate, others silently overwrite, and some log a warning and use the first-loaded asset.

Stage four: model binding. After the .dat asset is loaded and registered, the game loads the weapon's 3D model from a .unity3d bundle file. The model file is referenced by the asset's model-path field (or resolved by convention, matching the asset name to a known bundle filename). The model provides the mesh (visible geometry), the bone hierarchy (for attachment transforms and muzzle position), and the animations (equip, fire, reload). If the .unity3d bundle is missing, the weapon still exists as an item in the game's registry -- it can be spawned, held in inventory, and referenced by commands -- but it has no visible model and cannot be fired because there is no muzzle transform from which to spawn the projectile.

For modders who encounter a "weapon appears in inventory but is invisible or unfireable" issue, the problem is usually at stage four: the .unity3d bundle is missing, corrupt, or named differently than the asset expects. Check the asset's model-path field (if present) and verify the corresponding .unity3d file exists in the Bundles directory.

How GUID cross-referencing works

The GUID system is Unturned's internal linking mechanism. Unlike item IDs (which are simple integers that can collide if two mods pick the same number), GUIDs are 32-character hex strings that are effectively guaranteed unique if generated properly. The game uses GUIDs for three types of cross-references:

Weapon-to-projectile linking. The game may use a GUID field on the weapon asset to point directly to the projectile asset. If such a field exists, the game resolves it through the GUID registry (stage two above). If no direct GUID link exists, the game falls back to calibre-based lookup (finding a projectile asset registered for Caliber 20).
Blueprint-to-item linking. The blueprint assets for crafting recipes use GUIDs to specify input items and output items. The Rocket Launcher's two GUID-format flags ("7b82c125a5a54984b8bb26576b59e977" and "e73a23b102f24520a32ec0b2afaa6157") are pointer-flags that connect the weapon to its crafting blueprints. The GUIDs on the weapon point to the blueprints; the blueprints in turn use the weapon's GUID (af47bb9e0ba7443fa69435f1f594a10b) to reference the weapon as an ingredient or product.
Loot-table-to-item linking. Spawn tables list items by their GUIDs, not by item IDs. When a loot table entry says "spawn item at 0.159% chance," the game resolves the GUID to an item ID through the registry. This system means that moving an item to a different item ID does not break loot tables as long as the GUID remains unchanged.

The GUID af47bb9e0ba7443fa69435f1f594a10b is the Rocket Launcher's identity key across all referencing systems. If you change this GUID on a custom variant, every system that references the original GUID continues to reference the original Rocket Launcher -- your variant is invisible to those systems. This is the correct behaviour for a variant. If you change this GUID on the original Rocket Launcher asset (overwriting the official asset), every loot table, blueprint, and cross-reference that uses af47bb9e0ba7443fa69435f1f594a10b breaks because the GUID no longer resolves to the Rocket Launcher.

How projectile weapons differ from hitscan weapons

The Rocket Launcher's Action field is Rocket, which makes it a projectile weapon. Understanding the difference between projectile and hitscan weapons is fundamental to editing any launcher-type asset.

In a hitscan weapon (Action Trigger), the game does not spawn a visible projectile. On the frame the weapon fires, the engine draws an instantaneous line from the muzzle to the first collision point and applies damage there. There is no travel time, no bullet drop, and no physics interaction. The server validates the hit by raycasting from the shooter's camera along the aim direction; if the ray intersects a hitbox, damage is applied immediately. The entire process -- fire, trace, hit, damage -- completes in a single frame.

In a projectile weapon (Action Rocket), the game spawns a physical game object at the muzzle position. This projectile travels through the world governed by its own asset file -- a separate .dat file that defines the projectile's speed, mass, gravity influence, blast radius, explosion damage, blast force, and visual effects. The projectile asset is referenced by the weapon, typically through the weapon's GUID or through a calibre-lookup system. When the projectile collides with a surface or entity, it triggers its explosion effect and applies damage in a radius.

This separation means that editing the Rocket Launcher's damage or blast behaviour requires editing the projectile asset, not the weapon asset. The weapon asset's job is to define how the weapon handles (recoil, spread, fire rate), what it draws ammo from (calibre, magazine), and which projectile to spawn (action type). The projectile asset's job is to define what happens after the projectile leaves the barrel. Modders who only edit the weapon asset and expect the explosion to change will be confused -- the changes must happen in the projectile file.

The projectile lifecycle

When a Rocket Launcher fires, the projectile goes through four distinct phases, each governed by different game systems:

Phase one: spawn. The game instantiates the projectile prefab at the weapon's muzzle transform position and rotation. The muzzle transform is a named bone on the weapon model; its position relative to the player's camera determines where the projectile appears. If the muzzle transform is offset incorrectly in the model file, the projectile spawns from the wrong location -- sometimes behind the player, sometimes to the side. The initial velocity vector is computed from the crosshair direction plus the random offset defined by Spread_Aim (0.1 for the Rocket Launcher). The projectile receives its initial speed from the projectile asset's speed field.

Phase two: flight. Each frame, the game moves the projectile along its velocity vector, applies gravity (if the projectile asset has a non-zero gravity multiplier), and checks for collisions with world geometry, vehicles, NPCs, and players. The collision check uses the projectile asset's collision radius -- a sphere cast along the travel direction each frame. If the collision check returns a hit, the projectile enters phase three. If no hit occurs and the projectile's total travel distance exceeds Range (12), the projectile despawns silently. For the Rocket Launcher, Range 12 means the projectile travels at most 12 game metres from its spawn point before the game removes it.

Phase three: detonation. On collision, the game runs the projectile asset's explosion definition. This typically applies damage in a radius around the impact point, spawns a visual explosion effect (particles, decals, sounds), and applies a physics impulse to nearby rigidbodies (pushing vehicles, ragdolls, and loose objects away from the blast centre). The damage falloff from the blast epicentre is defined by the projectile asset's blast curve -- an inner radius where full damage is applied and an outer radius where damage decays linearly to zero.

Phase four: cleanup. After the detonation effects play, the game destroys the projectile game object. Any lingering particles or decals remain in the world as independent objects with their own lifetimes. The weapon asset's Firerate delay begins counting down from this point, and once the delay expires (and a reload has completed if the magazine is empty), the weapon is ready to fire again.

Understanding these four phases helps modders debug projectile issues. If the rocket does not explode on impact, the problem is in phase three (the projectile asset's collision or explosion definition). If the rocket vanishes mid-flight without hitting anything, the problem is in phase two (the Range value is too low for the distance being travelled). If the rocket spawns from the wrong position, the problem is in phase one (the muzzle transform on the weapon model).

Ballistics fields

The ballistics block controls how the weapon fires, what ammunition it draws from, and how the projectile behaves after leaving the barrel.

Field	Value
Range	12
Firerate	50
Action	Rocket
Caliber	20
Magazine	520
Ammo_Min	1
Ammo_Max	1

Range (12) determines the maximum distance the projectile travels before the game despawns it. The unit is game metres. A value of 12 is markedly lower than hitscan firearms, which commonly have Range values of 150 to 500. This is normal for projectile weapons: the projectile is a physical object that the game must simulate each frame (position, velocity, collision detection), and a shorter Range keeps the simulation cost bounded. A rocket that travels 12 metres then vanishes is cheaper to simulate than one that travels 300 metres.

For modders, Range on a projectile weapon has a different meaning than Range on a hitscan weapon. On a hitscan, Range is the maximum hit-registration distance. On a projectile, Range is the projectile's maximum lifetime expressed as distance; the projectile despawns when its travel distance exceeds this value, not when it reaches a specific map coordinate. If you increase Range, the projectile will travel farther before disappearing, but it will also consume more server resources per shot. For explosive weapons, a longer Range also means the projectile can reach areas the designer did not intend, which may have balance implications.

The Range of 12 is unusually low compared to most launcher-type weapons, which typically carry Range values between 20 and 100. A range of 12 means the Rocket Launcher is a close-to-medium-range weapon in practice. The rocket will despawn after travelling only a modest distance, which limits the weapon's effective reach regardless of how fast the projectile asset says the rocket moves. For server owners tuning weapon balance, Range is one of the most effective dials: lowering it forces close-quarters use, raising it extends reach without touching any other stat. Because Range is in the weapon asset rather than the projectile asset, it is one of the few projectile-behaviour controls accessible from the weapon file.

Firerate (50) is the internal tick count between shots. This is a raw engine value -- it is not a rounds-per-minute figure and it does not convert cleanly to wall-clock time. For the Rocket Launcher, Firerate is largely academic because the weapon holds only one round (Ammo_Min 1, Ammo_Max 1) and fires in semi-automatic mode (Semi flag). The Firerate effectively becomes the minimum delay between a shot and the moment the reload begins.

When editing Firerate on a launcher-type weapon, the practical effect is the refire delay. A lower Firerate value means the weapon cycles faster after a shot, allowing the player to fire again sooner (assuming the weapon has been reloaded). On a single-shot weapon, the reload time usually dominates the total time between shots, so Firerate has a minimal impact on practical fire rate. However, Firerate still gates the earliest moment at which the reload animation can begin -- the game will not start reloading until the Firerate delay has elapsed since the last shot. An extremely high Firerate value can therefore create a perceptible pause between firing and the start of the reload animation, even on a single-shot weapon.

For modders creating a multi-shot rocket launcher variant (by increasing the magazine item's capacity and updating Ammo_Min/Ammo_Max), Firerate becomes much more relevant because it controls the delay between successive shots without a reload. In that scenario, tuning Firerate directly controls the burst fire rate. The stock value of 50 provides a baseline for comparison when designing variants.

Action (Rocket) is an enum that determines the projectile type and firing mechanic. Rocket tells the game to spawn a physical projectile object at the muzzle transform. The projectile is governed by a separate asset file that defines its behaviour. Key characteristics of the Rocket action type:

The projectile has travel time -- it moves from the muzzle to the target at a speed defined in the projectile asset, not instantaneously.
The projectile is affected by gravity -- it drops over distance unless the projectile asset specifies zero gravity influence.
The projectile collides with world geometry, vehicles, and NPCs. On collision, it triggers its explosion effect.
The projectile can be shot down in flight if the game's projectile-interception system is active.
The projectile's damage, blast radius, and effects are defined in the projectile asset, not the weapon asset.

The Action field is one of the most structurally significant fields on any weapon asset. Changing it does not merely tweak a number -- it changes which game system handles the firing process. The valid Action enum values include Trigger (hitscan), Rocket (physical projectile with explosion), String (bow-type charging weapon), Pump (shotgun with pump cycle), Break (break-action reload), and several others. Each Action value activates a different firing pipeline in the engine, with its own state machine for chambering, cycling, and reloading. Swapping Rocket for a different action type fundamentally changes how the weapon operates -- it is not a cosmetic change.

If a modder changes the Action from Rocket to Trigger, the weapon becomes hitscan and will no longer spawn a projectile. The weapon's stats (damage, range, handling) would then apply directly rather than being delegated to a projectile. This is a foundational change that alters how every other field on the weapon is interpreted.

Caliber (20) is the ammunition-calibre identifier. Every ammo item in the game carries its own Caliber number; the weapon can only reload from items whose Caliber matches exactly. The Rocket Launcher's calibre of 20 links it to rocket-type ammunition. To find which ammo items the Rocket Launcher accepts, search the item database for every ammo asset with Caliber 20.

The calibre system in Unturned is a simple integer match -- there is no calibre family, no compatibility range, no "this calibre is also compatible with calibres 19 and 21". If the ammo item says Caliber 20, the weapon can use it. If the ammo item says Caliber 19, it cannot. This strictness means that changing a weapon's Caliber is an all-or-nothing switch: the weapon immediately loses access to all ammo of the old calibre and gains access to all ammo of the new calibre.

Caliber also plays a role in ammunition stacking and UI display. The game groups ammo items by calibre in the inventory, and the ammunition counter on the HUD uses the calibre to look up the appropriate icon and text colour. When you change a weapon's Caliber, you must ensure that ammo items with the matching calibre exist in the loot economy. A weapon with Caliber 99 and no ammo items carrying calibre 99 is unfireable after its initial spawn rounds are expended.

Additionally, calibre can affect compatibility with magazine attachments. Some magazine-attachment items filter by calibre: a drum magazine designed for a specific calibre will only attach to weapons of that calibre. If you change the Rocket Launcher's Caliber from 20 to another value, any magazine items that filter on calibre 20 will stop attaching to it, and magazine items for the new calibre may become attachable.

Magazine (520) is the item ID of the magazine or feeding device attached to the weapon. The game's reload system uses this value to look up the magazine item asset. For the Rocket Launcher, magazine ID 520 refers to the weapon's internal feed -- there is no detachable box magazine in the conventional sense. The magazine item asset at ID 520 defines the weapon's reload behaviour and ammo capacity.

When a weapon is dropped or disassembled, the game spawns a magazine item in the world. The magazine's model, name, and capacity come from item 520's asset file. If you change the Magazine field to a different item ID, the dropped item and reload behaviour will change accordingly.

The magazine item is a full asset in its own right, with its own item ID, name, description, model, and capacity field. This means you can modify the Rocket Launcher's capacity by editing the magazine item at ID 520 (or by pointing the Magazine field to a custom magazine item you create). If the magazine item at ID 520 specifies a capacity of 1, reloading always fills to exactly 1 round. If you create a variant magazine item with capacity 5 and point the weapon's Magazine field to it, the weapon becomes a five-shot launcher -- provided you also update the projectile asset if you want each rocket to behave differently, and provided you update Ammo_Min and Ammo_Max to reflect the new spawn behaviour.

Ammo_Min (1) and Ammo_Max (1) set the random range for the number of rounds the weapon carries when it first spawns. Because both values are exactly 1, the Rocket Launcher always spawns with one round loaded -- no variance, no chance of a partial or full magazine.

For a single-shot weapon, this is the expected configuration. The weapon fires its one round, then must be reloaded. If a modder wants the weapon to spawn with more than one round, raise Ammo_Max above 1. For example, setting Ammo_Min to 1 and Ammo_Max to 3 means the weapon spawns with 1, 2, or 3 rounds (uniform random). Setting both to 3 means it always spawns with exactly 3 rounds.

These fields only affect the initial spawn state. They do not change how many rounds fit in the magazine after a reload. The post-reload capacity comes from the magazine item ID 520. If the magazine item says capacity 1, reloading always fills to 1 regardless of Ammo_Min and Ammo_Max.

An often-overlooked detail is that Ammo_Min and Ammo_Max do not affect weapons spawned through crafting. When a blueprint produces the Rocket Launcher as its output, the game spawns the weapon in its default state, which may or may not respect the Ammo_Min/Ammo_Max range. The crafting system's spawn behaviour is separate from the loot-spawn behaviour; some versions of Unturned default to the Ammo_Min value for crafted items, while others default to full magazine capacity. Server owners who rely on the single-round spawn as a balance mechanism should verify whether crafted launchers also spawn with one round or whether they spawn with a full magazine.

Player damage fields

The player damage block defines how much damage the Rocket Launcher deals to other players. Unlike hitscan weapons with per-zone multipliers, the Rocket Launcher has a single base value with no limb-multiplier fields.

Field	Value
Player_Damage	200

Player_Damage (200) is the base damage value applied to any player within the blast radius -- subject to armour and other server-side damage-reduction layers. The absence of multiplier fields (Player_Leg_Multiplier, Player_Arm_Multiplier, Player_Spine_Multiplier, Player_Skull_Multiplier) means the damage is uniform: a hit to the foot deals the same damage as a hit to the head.

This is standard for explosive weapons. Explosions apply area damage using a proximity check -- the game measures the distance from each entity to the blast centre and scales damage based on distance (controlled by the projectile asset). Because the damage is area-based rather than raycast-based, there is no hit-zone bone lookup. The full base value of 200 is delivered to every player entity within the blast's inner radius, with damage falloff at larger distances defined by the projectile's blast curve.

For modders, the implication is that editing the Rocket Launcher's damage requires editing the projectile asset, not the weapon asset. The weapon's Player_Damage of 200 is a reference value that the projectile may or may not use as its base. Some projectile assets read the weapon's damage field; others define their own independent damage values. Until you inspect the projectile asset, you do not know whether changing Player_Damage on the weapon will affect the explosion damage or will be ignored.

One practical check a modder can perform: change Player_Damage on the weapon to an extreme value (like 1 or 9999), load the game, fire the weapon at a test target, and observe the result. If the damage changes, the projectile is reading the weapon's damage field. If the damage remains at 200, the projectile is using its own independent damage value and you must locate and edit the projectile asset to change explosion lethality. This test is safe to perform on a local server with cheats enabled; do not perform it on a production server.

Zombie damage fields

Zombie damage follows the same single-value pattern as player damage.

Field	Value
Zombie_Damage	200

Zombie_Damage (200) matches the player damage value exactly. The weapon does not differentiate between PvP and PvE damage at the asset level. A zombie standing in the blast radius receives the same 200 base damage as a player standing in the same position.

This parity is common for launcher-type weapons. Because the blast is area-based and the damage is high relative to most firearms, the designer did not need to tune PvE damage separately -- the base value is already sufficient to be lethal against NPCs. Weapons with separate PvP and PvE bases typically do so because they want the weapon to feel powerful against NPCs without feeling oppressive against players. For a rocket launcher, the base is already high enough that further differentiation is unnecessary.

The absence of zombie-specific multiplier fields mirrors the player damage block: no Zombie_Leg_Multiplier, no Zombie_Skull_Multiplier, no per-limb variance. Every zombie caught in the blast receives the same damage. This uniformity across player and zombie targets is a design signal: the Rocket Launcher was built as a general-purpose explosive weapon, not a specialised anti-personnel or anti-zombie tool. The uniform 200-value across both tables means the designer did not consider PvE a meaningfully different use case from PvP for this weapon.

Animal damage fields

Animal damage follows the same single-value model.

Field	Value
Animal_Damage	200

Animal_Damage (200) matches both the player and zombie base values. Every target class receives the same damage from the explosion. This three-way parity is rare among Unturned weapons, most of which tune damage differently for each target class. The rocket launcher's uniform 200 across all three classes tells you that the designer considered the blast lethal regardless of target type.

Hunting animals with a rocket launcher is a fringe use case, but the uniform damage means the weapon behaves predictably regardless of what the player points it at. For modders building custom game modes where animal-type entities serve as bosses or objectives, the Animal_Damage field is the one to tune if you want the launcher to behave differently against animal-class entities than against players or zombies. The default uniform-200 configuration is the simplest possible setup; any deviation from uniformity across the three damage fields requires a deliberate design choice about target-class balance.

Handling and recoil

The handling fields control how the weapon moves the camera and where the projectile spawns relative to the aiming direction. The Rocket Launcher has a full set of recoil and screen-shake fields.

Field	Value
Recoil_Min_X	-15
Recoil_Min_Y	25
Recoil_Max_X	15
Recoil_Max_Y	30
Spread_Aim	0.1
Shake_Min_X	-0.0025
Shake_Max_X	0.0025

Recoil_Min_X (-15) and Recoil_Max_X (15) define the horizontal camera-kick range. On each shot the game picks a uniform random value between the inclusive min and max and applies it as a horizontal view-angle offset. The range from -15 to 15 means the crosshair can kick left (negative values) or right (positive values) with equal probability and equal magnitude. The total horizontal range is 30 units (from -15 to 15), which is a wide spread -- the weapon will visibly jerk the player's aim sideways on each shot.

Recoil_Min_Y (25) and Recoil_Max_Y (30) define the vertical camera-kick range. Both values are positive, so the crosshair always kicks upward. The range from 25 to 30 means the upward kick is between 25 and 30 units, with a narrow 5-unit band of variation. The upward kick is always stronger than the maximum possible horizontal kick (30 vs 15 at the extremes), which means the dominant recoil direction is upward -- as expected for a shoulder-fired launcher.

The ratio of vertical to horizontal recoil is a deliberate tuning choice. The designer made the upward kick dominant (25-30) while allowing modest horizontal drift (-15 to 15). This gives the weapon a predictable overall recoil direction (up and slightly left or right) without making it feel like a perfectly vertical laser.

For modders adjusting recoil, the key insight is that Recoil_Min and Recoil_Max define a range, not a fixed offset. A weapon with Recoil_Min_X of -15 and Recoil_Max_X of 15 will sometimes kick hard left (-15), sometimes kick hard right (15), and sometimes barely move horizontally (values near 0). The range width controls consistency: a narrow range like 8 to 12 produces a predictable kick every time, while a wide range like -15 to 15 produces erratic, variable kick direction. The Rocket Launcher's wide horizontal range and narrow vertical range means it kicks reliably upward but wanders unpredictably left-right.

Spread_Aim (0.1) is the angular deviation applied to the projectile spawn direction when the player is aiming down sights. The game takes the crosshair direction, generates a random angular offset within a cone defined by 0.1 angular units, and launches the projectile on that offset vector. A value of 0.1 is a noticeable spread -- the projectile will not always fly exactly where the crosshair points.

Compared to precision weapons (which carry Spread_Aim of 0.001 to 0.01), 0.1 is a wide cone. This is intentional for a rocket launcher: the projectile is area-effect, so pinpoint accuracy is less important, and the spread ensures the rocket does not always hit the exact pixel the crosshair is on. For a modder who wants a more accurate launcher, reduce Spread_Aim -- a value of 0.05 halves the cone width.

Spread interacts with the projectile's travel distance: the farther the rocket travels, the larger the absolute deviation from the crosshair. At short range (within the 12-metre Range limit of the Rocket Launcher), a Spread_Aim of 0.1 produces a modest deviation. At longer ranges (if you increase Range), the deviation grows proportionally and the rocket may miss even large targets. When increasing Range on a projectile weapon, consider reducing Spread_Aim to keep the weapon usable at the new maximum distance.

Shake_Min_X (-0.0025) and Shake_Max_X (0.0025) are the screen-shake parameters. These values define a subtle horizontal camera oscillation on fire. The symmetry around zero means the shake alternates equally left and right. The magnitude of 0.0025 is small -- it creates a fine tremor rather than a violent camera lurch.

The absence of Shake_Min_Y and Shake_Max_Y fields means vertical screen shake is zero. The screen shakes left-right but not up-down. This is a common configuration: the recoil fields handle the coarse camera movement (the aim kick), while the shake fields add a fine vibration on top. Separating the two lets the designer make the gun feel heavy (through recoil) without making the screen unreadable (by keeping shake subtle).

For modders, adding vertical shake is a matter of adding Shake_Min_Y and Shake_Max_Y fields to the weapon asset with symmetric values (e.g., -0.0025 and 0.0025 for parity with the horizontal shake). Adding shake increases the weapon's sensory weight -- the screen will rattle more aggressively on fire, making follow-up shots harder to place. This is an aesthetic tuning dial: players feel the weapon through the camera movement, and increasing shake is the simplest way to make a weapon feel more powerful without changing its numerical damage or recoil.

Flags

Flags are boolean or tag-like properties that modify weapon behaviour. The Rocket Launcher has an extensive flags list, much of which relates to the crafting and attachment systems. Understanding each flag's role is essential for editing the weapon.

Flags present:

"7b82c125a5a54984b8bb26576b59e977"
"e73a23b102f24520a32ec0b2afaa6157"
Blueprints
Hook_Grip
Hook_Sight
Hook_Tactical
InputItems
OutputItems
RequiresNearbyCraftingTags
Safety
Semi
[
]
{
}

GUID-reference flags. The first two entries in the flag list are 32-character GUID strings, not named keywords. These are not flags in the behavioural sense -- they are identifiers that cross-reference other assets, typically blueprint or recipe files. When a weapon has GUID-format flags, it means the weapon participates in one or more crafting recipes, and the GUID points to the specific blueprint asset that defines the recipe.

To trace what these GUIDs reference, search the asset database for blueprint files whose GUID matches one of the two strings. The blueprint asset will list input items, output items, required crafting stations, and any additional conditions (tool requirements, skill level requirements). These are standard Unturned blueprint GUIDs, not proprietary or encrypted values.

The presence of two GUIDs suggests the Rocket Launcher may be involved in two separate crafting recipes: one as an input ingredient (combined with other items to craft something else), and one as an output (crafted from component parts). The GUID reference is the most reliable way to identify the recipe, since the flag name itself carries no semantic meaning.

Blueprints enables the weapon to participate in the crafting-blueprint system. This flag is a prerequisite for any asset to appear in a blueprint recipe. Without Blueprints, the asset cannot be used as an input or output in any crafting operation, even if a blueprint references its item ID.

InputItems marks the weapon as capable of serving as an input in a crafting recipe. When the player interacts with a crafting station and selects a recipe that requires this weapon as an ingredient, the InputItems flag tells the crafting system that the weapon is eligible for consumption. If this flag were absent, the weapon could not be used as a crafting ingredient even if a blueprint listed it.

OutputItems marks the weapon as a valid output of a crafting recipe. When a blueprint produces this weapon as its result, the OutputItems flag tells the crafting system to spawn the weapon in the player's inventory or at the crafting station's output slot. The flag confirms the weapon is spawnable through crafting and allows the crafting UI to display it as a result.

RequiresNearbyCraftingTags enforces a proximity requirement during crafting. The player must be near a world object (such as a workbench, forge, or specialised crafting station) whose tags match the requirements specified in the blueprint. This prevents players from crafting the Rocket Launcher from their inventory alone -- they must be at the correct workstation.

The specific tags are defined in the blueprint asset, not in the weapon asset. To find which workstation is required, read the blueprint asset referenced by one of the GUID flags and locate its required-tags field. Common tags for launcher-class weapons include military workbench tags, explosives-lab tags, or high-tier crafting station tags.

How the crafting flags interact

The five crafting-related flags -- Blueprints, InputItems, OutputItems, RequiresNearbyCraftingTags, and the two GUID-reference flags -- form a coordinated system. They do not operate independently; they work in sequence:

The GUID-reference flags ("7b82c125a5a54984b8bb26576b59e977" and "e73a23b102f24520a32ec0b2afaa6157") tell the game which blueprint asset to load when a crafting recipe involving the Rocket Launcher is requested.
Blueprints tells the game that the Rocket Launcher asset participates in the blueprint system at all. Without this flag, the GUID references are ignored.
InputItems tells the crafting system that this weapon can appear on the left side of a recipe equation (consumed in crafting).
OutputItems tells the crafting system that this weapon can appear on the right side (produced by crafting).
RequiresNearbyCraftingTags tells the crafting system to check for a nearby workstation with matching tags before allowing the recipe to execute.

Removing any one of these flags breaks the crafting chain. Removing Blueprints disables all recipe participation. Removing InputItems prevents the weapon from being consumed in a recipe but still allows it to be crafted as an output (if a blueprint produces it). Removing OutputItems prevents crafting the weapon but still allows using existing ones as ingredients. Removing RequiresNearbyCraftingTags allows the recipe to execute anywhere, removing the workstation proximity requirement. Removing a GUID-reference flag severs the link to a specific blueprint, which silently removes the associated recipe from the game's crafting registry.

For modders who want to disable the Rocket Launcher's crafting system entirely, removing all five crafting flags and both GUIDs is the clean approach. For modders who want to keep crafting but change the workstation requirement, leave the flags in place and edit the blueprint asset's required-tags field instead. For modders who want to add a new crafting recipe for the Rocket Launcher (e.g., a repair recipe that combines a damaged launcher with scrap metal to produce a fresh one), create a new blueprint asset with a new GUID and add that GUID to the weapon's flag list.

Hook_Grip, Hook_Sight, and Hook_Tactical are attachment-hook flags. Each flag enables one attachment slot on the weapon model:

Hook_Sight: Enables the optic/scope attachment slot. Players can attach scopes, red-dot sights, holographic sights, and other aiming devices to the weapon.
Hook_Grip: Enables the foregrip/bipod attachment slot. Players can attach vertical grips, angled grips, or bipods.
Hook_Tactical: Enables the tactical-device slot. Players can attach rangefinders, laser sights, or flashlights.

The presence of these three hooks means the Rocket Launcher supports a full attachment loadout. The absence of Hook_Barrel means muzzle devices (suppressors, muzzle brakes, compensators) are not supported. This makes sense for a rocket launcher: the barrel is a large-diameter tube designed to launch rockets, not a threaded firearm barrel that accepts muzzle attachments.

Each hook flag requires a corresponding attachment transform on the weapon model. The model's bone hierarchy must include a transform at the index the attachment system expects for that hook type. If the flag is present but the transform is missing, the attached item will be invisible or will appear at the model's root position, which is usually at the player's feet.

Attachment hook mechanics in depth

Each attachment hook flag communicates with two separate systems: the inventory system (which validates whether an attachment item can be slotted onto the weapon) and the rendering system (which positions the attached item's model relative to the weapon model). A thorough understanding of both systems is necessary for modders who want to add, remove, or modify attachment support on a weapon.

The inventory attachment filter. When a player attempts to attach an item to a weapon, the inventory system checks the weapon's hook flags against the attachment item's hook-type field. A red-dot sight carries Hook_Sight as its attachment type; the weapon must also carry Hook_Sight for the attachment to be accepted. The match is a simple string equality check -- there is no partial matching, no fallback, no compatibility matrix. If the attachment says Hook_Sight and the weapon does not have Hook_Sight, the game rejects the attachment and plays a deny sound. The same goes for grip attachments (Hook_Grip) and tactical attachments (Hook_Tactical).

The model transform. When the attachment is accepted, the rendering system must place the attachment's 3D model on the weapon. It does this by searching the weapon's model bone hierarchy for a transform node at a specific index assigned to each hook type. If the weapon model was authored in Unity with a bone named Sight (or whatever convention the model exporter uses) at the correct hierarchy position, the attached sight appears on top of the weapon's receiver. If the bone is missing or at the wrong hierarchy index, the sight appears at the weapon model's root transform (typically the origin, or 0,0,0 relative to the weapon). An attachment at the root transform looks wrong -- the sight floats at the weapon's centre of mass rather than on the rail.

For modders working with the stock Rocket Launcher model, the attachment transforms are already present for Hook_Sight, Hook_Grip, and Hook_Tactical (since the flags are present and the weapon ships with functional attachment support). Adding a new hook type -- such as Hook_Barrel for muzzle attachments -- requires both adding the flag to the weapon asset and adding the corresponding bone transform to the weapon's Unity model file. The model edit is the harder of the two changes: it requires exporting the Unity asset bundle, opening the prefab in Unity, adding a child transform at the correct position on the barrel, and re-exporting. The .dat asset edit (adding Hook_Barrel to the flags) takes seconds; the model edit can take hours.

Attachment validation and mod compatibility. Server-side mods that validate attachment legality check the same hook-flag match that the client checks. If a modder creates a custom attachment that declares Hook_Sight as its hook type and the weapon has Hook_Sight, the attachment is legal. If the modder creates a custom weapon that accepts Hook_Sight but does not declare the flag, the client rejects the attachment (the game plays a deny sound) and the server may eject the attachment from the weapon's attachment array if a validation pass runs.

This enforcement means that modders who want unusual attachment combinations -- such as a rocket launcher with a suppressor -- cannot simply tell the server to ignore the hook check. They must add Hook_Barrel to the weapon's flags list and ensure the model has a barrel transform. Attempting to bypass the hook system through server plugins or inventory manipulation will result in attachments that appear slotted but are invisible (the rendering system has nowhere to place them) or that disappear when the server runs an attachment-validation tick.

Safety enforces a safety-fire-selector mechanism. When present, the weapon has a safety toggle that the player must cycle through. The default state is safe (weapon will not fire). The player presses the fire-mode switch key to cycle to fire mode (weapon can fire). This prevents accidental discharge -- the player must consciously switch off the safety before the weapon will respond to the fire key.

The Safety flag is independent of fire-mode flags. A weapon can have both Safety and Semi -- the player must first switch off safety, then the semi-automatic fire mode is active. The safety is an additional input gate before the fire-mode logic runs.

Semi is the semi-automatic fire flag. The weapon fires one round per trigger pull. Holding the fire key down does not produce additional shots -- the player must release the key and press it again for each subsequent shot. This is the expected fire mode for a single-shot rocket launcher.

If a modder removes Semi and adds Auto, the weapon would fire continuously while the fire key is held. However, with Ammo_Min 1 and Ammo_Max 1, the weapon only has one round before requiring a reload, so full-auto would stop after the first shot. For full-auto fire to be meaningful, the magazine item ID 520 would need a capacity greater than 1, and the Ammo_Min/Ammo_Max fields would need to be adjusted accordingly.

Bracket characters. [, ], {, } are not functional flags. These characters appear as separators or delimiters in the asset's serialised data format and are captured by the data-extraction tool as entries in the flags list. They have no effect on weapon behaviour and can be ignored when editing the asset. A modder who sees bracket characters in a flags list should not try to add, remove, or modify them -- they are structural markers from the serialisation format, not gameplay flags.

Loot table presence

The Rocket Launcher appears in multiple loot tables across several official maps. Each entry specifies the map domain, the named spawn table, and the percentage chance the Rocket Launcher is selected in a single roll of that table.

Map	Spawn table	Chance per roll
France	Milita_Super_France_Guns	11.765%
RioDeJaneiro	Exterminators_High_Guns	11.765%
Core	Militia_Special	9.091%
Core	Militia_Russia_Special	9.091%
Core	Syndicate_Special	9.091%
RioDeJaneiro	Exterminators_High	0.882%
RioDeJaneiro	High_Exterminators_High	0.882%
France	Milita_Super_France	0.619%
France	France_Milita_Super_France	0.619%
Core	Syndicate	0.216%
Core	Peaks_Syndicate	0.216%
Belgium	Militia_Belgium	0.159%
Core	PEI_Militia	0.159%
Core	Militia	0.159%
Core	Washington_Militia	0.159%
Core	Russia_Militia_Russia	0.159%
Core	Militia_Russia	0.159%

Reading the loot table. Each row represents an independent spawn-table entry. When the game rolls the named table -- for example, Militia_Super_France_Guns on the France map -- the Rocket Launcher has an 11.765% chance of being the item the table produces for that roll. This is the chance per roll, not per container. A container may roll its spawn table multiple times (once for each item slot), producing several items from the same table. If a container rolls a table twice, the probability of the weapon appearing at least once is higher than 11.765%.

The percentages are not hand-entered values. They are computed by dividing the Rocket Launcher's weight in the table by the total weight of all items in the table. The weight is the raw integer the modder enters; the percentage is the result. If you add items to a table, the Rocket Launcher's percentage drops because the total weight increases. If you remove items, the percentage rises. When editing loot tables, work with weight values, not percentages. Use the percentage column here as a snapshot of the current distribution.

How loot table rolling works

When the game determines that a container or spawn point should generate loot, it follows a multi-step process:

The container definition specifies which spawn table to use (e.g., Militia_Special).
The game resolves the table name to the map-specific variant. If a map-prefixed variant exists (e.g., France_Milita_Super_France), that variant is used on the matching map. If no map variant exists, the base table is used.
The game sums the weight values of all items in the resolved table to produce a total weight.
For each item slot in the container, the game generates a random number between 0 and the total weight, then walks the item list until the cumulative weight exceeds the random number. The item at that position is spawned.

This is a weighted random selection with replacement -- each item slot rolls independently, and the same item can be selected for multiple slots. A container with three item slots that all draw from Militia_Special could, in theory, spawn three Rocket Launchers.

Entry-by-entry analysis

Each of the 17 loot table entries tells a different story about where and how the Rocket Launcher is distributed across the game world.

Milita_Super_France_Guns (France, 11.765%). This table is the Rocket Launcher's most likely spawn point on the France map. The Super qualifier suggests a top-tier loot pool within the Militia faction, and the Guns suffix confirms the table is filtered to weapon items only. At 11.765%, the weapon appears in roughly one out of every eight or nine rolls of this table. France-map players who farm Militia Super locations have a reliable path to acquiring the Rocket Launcher.

Exterminators_High_Guns (RioDeJaneiro, 11.765%). This is the mirrored high-tier entry for the Rio de Janeiro map's Exterminators faction. The identical 11.765% suggests the weapon's weight is the same fraction of both tables' total weights. The Exterminators faction is a Rio-specific NPC group; players on the Rio map must engage Exterminator enemies to access this loot pool, making the Rocket Launcher faction-gated on this map.

Militia_Special (Core, 9.091%). A Core-domain special-tier Militia table. The Special qualifier indicates a curated loot pool, typically reserved for rare or high-power items. At 9.091%, the Rocket Launcher appears in roughly one out of every eleven rolls. This is the highest-chance Core-table entry and the primary acquisition path for base-game-map players.

Militia_Russia_Special (Core, 9.091%). The Russia-map variant of the Militia Special table. The identical 9.091% confirms the Rocket Launcher holds the same weight proportion in both the base Militia Special and the Russia-specific variant. Russia-map players have the same per-roll chance as players on other Core maps.

Syndicate_Special (Core, 9.091%). The Syndicate faction's special-tier table. At 9.091%, this matches the Militia Special entries. The Syndicate faction is a separate NPC group from the Militia, which means the Rocket Launcher is distributed across two distinct faction loot pools at the same per-roll chance. Players who farm both Militia and Syndicate locations have double the effective acquisition rate compared to players who farm only one faction.

Exterminators_High (RioDeJaneiro, 0.882%). A general high-tier Exterminators table rather than a guns-filtered one. The drop from 11.765% to 0.882% -- roughly a 13x reduction -- reflects the difference between a filtered Guns table (fewer total items, higher per-item share) and a general High table (more items, lower per-item share). The Exterminators faction has two tiers of Rocket Launcher availability: common in the Guns pool, rare in the general High pool.

High_Exterminators_High (RioDeJaneiro, 0.882%). A further-specialised high-tier table within the Exterminators faction. The High_ prefix may indicate an even tighter loot filter or a specific boss-level table. The 0.882% matches the general Exterminators_High entry, so the Rocket Launcher's weight proportion is the same across both variants.

Milita_Super_France (France, 0.619%). The general (non-Guns-filtered) Super-tier France Militia table. The drop from 11.765% (Guns) to 0.619% (general) mirrors the pattern seen in the Rio De Janeiro Exterminators tables. The Guns-filtered table concentrates weapon spawns into fewer item options, giving the Rocket Launcher a much larger share.

France_Milita_Super_France (France, 0.619%). The map-prefixed variant of the France Militia Super table. The identical 0.619% suggests this is a map-specific override that replicates the base table's item distribution exactly. The duplication between Milita_Super_France and France_Milita_Super_France may be a quirk of the loot-table authoring process; only one of the two activates on the France map (whichever the map configuration references), while the other serves as a fallback or base definition.

Syndicate (Core, 0.216%). The baseline Syndicate faction loot table, without any Special or High qualifier. This is the widest Syndicate pool, containing the full range of possible faction-dropped items. At 0.216%, the Rocket Launcher appears in roughly one out of every 463 rolls -- a rare drop from general Syndicate enemies. Compare this to the Syndicate_Special table at 9.091%, roughly a 42x increase, to see how dramatically a filtered loot table concentrates item availability.

Peaks_Syndicate (Core, 0.216%). A Syndicate faction table variant associated with the Peaks map region within the Core domain. The identical 0.216% matches the base Syndicate table, confirming the Rocket Launcher's weight proportion is unchanged in the Peaks variant.

Militia_Belgium (Belgium, 0.159%). The Belgium-map variant of the Militia faction table. At 0.159%, the Rocket Launcher is marginally rarer in Belgium than in Core Syndicate tables (0.216%). The Belgium map hosts geographically specific Militia spawn points, and players on that map are restricted to the Belgium-tagged versions of faction tables.

PEI_Militia (Core, 0.159%). The PEI (Prince Edward Island) map variant of the Militia table. PEI is one of the original official maps; its Militia spawn table is map-specific. The 0.159% means PEI players have a low but nonzero chance of finding the Rocket Launcher from Militia enemies.

Militia (Core, 0.159%). The base Militia faction table without any map qualification. This table serves as the fallback for any Core-domain map that does not have a map-specific Militia override. At 0.159%, it is the broadest possible Militia pool -- every Militia spawn point that does not use a Special or map-specific table draws from this pool.

Washington_Militia (Core, 0.159%). The Washington-map variant of the Militia table. Washington is another original official map. The 0.159% matches the base Militia table and the other map-specific variants, confirming uniform weight distribution across all Militia faction tables regardless of map.

Russia_Militia_Russia (Core, 0.159%). A doubly-qualified Militia table: both the map (Russia) and a _Russia suffix that may indicate a further region or sub-faction filter within the Russia map. The 0.159% is consistent with every other Militia table entry.

Militia_Russia (Core, 0.159%). A second Russia-specific Militia table variant. The distinction between Russia_Militia_Russia and Militia_Russia is likely a data-entry artefact -- two table definitions that resolve to slightly different spawn-point configurations on the Russia map but carry identical item weight distributions for the Rocket Launcher.

Map coverage synthesis. The 17 entries span five map domains (Core, France, RioDeJaneiro, Belgium, and Core map variants). The Core domain dominates with 13 of the 17 entries across eight distinct table names: Militia_Special, Militia_Russia_Special, Syndicate_Special, Syndicate, Peaks_Syndicate, Militia, PEI_Militia, Washington_Militia, Russia_Militia_Russia, and Militia_Russia. The France domain contributes three entries (Milita_Super_France_Guns, Milita_Super_France, France_Milita_Super_France). RioDeJaneiro contributes three entries (Exterminators_High_Guns, Exterminators_High, High_Exterminators_High). Belgium contributes one entry (Militia_Belgium).

The faction breakdown is similarly lopsided: Militia tables account for 12 of the 17 entries, Syndicate for 3, and Exterminators for 3. The Rocket Launcher is overwhelmingly a Militia-faction item in terms of table count. However, the Syndicate and Exterminators entries include high-chance tables (9.091% and 11.765% respectively), so per-roll availability is comparable across all three factions despite the Militia having more total entries.

Server-owner loot-table tuning strategies

The 17-entry distribution gives server owners multiple tuning points for controlling Rocket Launcher availability. The strategies below use only the data present in the tables above; they do not require external tools or additional data sources.

Strategy one: remove all high-chance entries. Remove the Rocket Launcher from the five tables above 1%: Milita_Super_France_Guns (11.765%), Exterminators_High_Guns (11.765%), Militia_Special (9.091%), Militia_Russia_Special (9.091%), and Syndicate_Special (9.091%). This eliminates the primary acquisition paths while preserving the weapon as an extremely rare find (0.159% to 0.882%) from general faction loot. The result is a Rocket Launcher that appears roughly once per server wipe cycle rather than once per faction-stronghold farming session.

Strategy two: increase low-chance entries to medium. If the server's intended feel is "rare but findable with effort," raise the Rocket Launcher's weight in the five 0.159% Militia tables (Militia, PEI_Militia, Washington_Militia, Militia_Russia, Russia_Militia_Russia, Militia_Belgium) to produce a 1% to 2% per-roll chance. Use the weight formula: new weight = desired percentage / (100 - desired percentage) * existing total weight. Keep the high-chance entries at their current values to preserve the faction-reward feel for players who push into Special-tier loot pools.

Strategy three: faction-gate the weapon entirely. Remove all Syndicate and Exterminators entries, leaving only the Militia tables (12 entries). The weapon becomes a Militia-exclusive item. Players who primarily engage Syndicate or Exterminator content will never find it. This is appropriate for servers with distinct faction identities where each faction has exclusive gear.

Strategy four: map-gate the weapon. Remove all Core entries (13 tables), leaving only the France (3 entries) and RioDeJaneiro (3 entries) and Belgium (1 entry) tables. The weapon becomes unavailable on base-game Core maps and only appears on the named DLC or custom maps. For servers running only Core maps, this is equivalent to removing the weapon entirely.

Strategy five: equalise across all tables. Adjust the Rocket Launcher's weight so every table produces the same per-roll chance (for example, 2%). This requires increasing the weight in the low-chance tables and decreasing it in the high-chance tables. The result is a weapon that is equally likely from any faction encounter, removing the current bias toward Special-tier tables. This equalises acquisition across player skill levels -- new players looting general Militia spawns have the same per-roll chance as experienced players farming Special-tier spawns.

A note on testing loot-table changes. Loot-table edits are probabilistic, which makes them difficult to test by playing the game normally. A 0.159% chance means the item appears once every 629 rolls on average; a player looting 20 containers per session might go several sessions without seeing the item. To verify a loot-table change, use console commands to trigger table rolls in bulk (spawn 100 containers and count how many times the item appears) or use a server plugin that logs loot-table outputs. Spot-checking by looting a few containers and concluding "the item is there" or "the item is gone" is unreliable for any chance below roughly 5%.

Canned Beans

There are no Canned Beans associated with the Rocket Launcher's loot tables in the extracted data. The weapon appears exclusively in militia, syndicate, and exterminator spawn tables -- factional combat-loot pools. Beans are civilian consumables and appear in grocery-store, food-crate, and kitchen-spawn tables. These table categories do not overlap with the faction-gun tables the Rocket Launcher appears in.

The absence is structural, not coincidental. The loot system separates items by category: food items populate food tables, weapon items populate weapon tables, and the two rarely intersect. A weapon appearing in 17 faction-loot tables and zero food tables is exactly what the category separation predicts.

For the broader context of beans in Unturned lore, see Canned Beans Lore.

Practical use for server owners and modders

Server owners should pay attention to the loot-table distribution when deciding whether the Rocket Launcher is appropriate for their server. With entries in 17 tables across multiple maps, the weapon is broadly accessible. The high-chance tables -- particularly Militia_Special at 9.091% and Syndicate_Special at 9.091% -- mean that players who frequently loot faction strongholds will encounter the weapon regularly.

If explosive weapons cause balance issues on your server, the most effective intervention is to remove the Rocket Launcher from the high-chance tables while keeping it in the sub-1% tables. This preserves the weapon as a rare trophy item without flooding the server with rocket launchers. Removing the five high-chance entries eliminates roughly 97% of the weapon's total appearance probability (the combined chance across the high-chance tables is far larger than the combined chance across the low-chance tables).

Alternatively, server owners who want the Rocket Launcher to be more common can increase the weapon's weight in the low-chance tables. Doubling the weight in Militia from whatever produces 0.159% to a value that produces roughly 0.3% is a proportional increase that raises availability without making the weapon ubiquitous.

The single-round spawn (Ammo_Min 1, Ammo_Max 1) is an important limiting factor. Every Rocket Launcher found in the world has exactly one shot. This means that even if the weapon itself is common, sustained use requires a supply of rocket ammunition (Caliber 20 ammo items). Server owners should check the loot-table distribution of the matching ammo items to understand whether players can reliably find reloads. If the ammo is rare, the Rocket Launcher is effectively a one-shot-per-find item regardless of how common the weapon itself is.

The crafting system adds another acquisition path. The presence of Blueprints, InputItems, OutputItems, and two GUID flags means the Rocket Launcher can be crafted at a specific workstation. Server owners who want to control crafting availability should locate the blueprint assets referenced by the GUID flags and check their workstation-tag requirements. If the workstation is easily accessible, crafting may be a more reliable source of Rocket Launchers than looting. If the workstation is gated behind progression, crafting serves as a late-game acquisition path that does not compete with early-game looting.

Ammo economy considerations. The Rocket Launcher's ammunition situation is unusual. With Magazine 520 and Ammo_Min/Ammo_Max both at 1, every launcher found in the world contains exactly one shot. After that shot is fired, the player must reload from a Caliber 20 ammo item in their inventory. Server owners who stock Caliber 20 ammo generously in loot tables effectively make the Rocket Launcher a sustained-use weapon. Server owners who make Caliber 20 ammo scarce turn it into a one-shot emergency tool that players hoard for critical moments. The ammo distribution is as important a tuning dial as the weapon distribution.

Crafting accessibility. Server owners can control crafting availability by editing the blueprint asset's workstation-tag requirements or the required input items. If the blueprint demands a rare component (e.g., an item that only drops from a specific boss or event), crafting becomes a progression gate rather than an alternative loot path. If the blueprint requires common components and an easily accessible workstation, crafting undercuts the loot economy by providing a deterministic acquisition path that bypasses random chance entirely. Most servers aim for a middle ground: crafting is available but requires effort comparable to farming the equivalent faction-loot table.

Modders editing the Rocket Launcher asset should focus on the fields described in this reference. Each edit should be made in isolation and tested before combining with other changes. The key edits a modder is likely to make are:

Edit the projectile, not the weapon: The Rocket Launcher's blast damage, explosion radius, projectile speed, and impact effects are defined in the projectile asset (the .dat file for the rocket itself). To change how the explosion behaves, find the projectile asset. Trace it by searching for assets that reference the Rocket Launcher's GUID as their parent weapon, or by searching for projectile assets with a matching calibre (20). The weapon asset is the wrong file for explosion tuning.
Change the fire mode: Remove the Semi flag and add Auto to allow continuous fire. This only makes sense if the magazine supports multiple rounds. To make the weapon fire bursts, add the Burst flag and a Bursts field set to the number of rounds per burst. As with full-auto, the magazine must have enough capacity for the burst fire to complete.
Increase magazine capacity: The magazine item at ID 520 defines the capacity. If you change that item's capacity to 5, the player can reload to 5 rounds. Update Ammo_Min and Ammo_Max on the weapon to set the spawn-round range. A weapon that can hold 5 rounds but spawns with 1 (Ammo_Max 1) will confuse players -- match the spawn range to the intended starting ammo count.
Add barrel attachments: Add the Hook_Barrel flag to enable muzzle-device support. The weapon model must have a barrel attachment transform at the correct index. If the model does not have this transform, the muzzle device will appear at the model's root position. Adding the transform requires editing the weapon's .unity3d model file in Unity, which is a more involved process than editing the .dat asset file.
Modify loot-table weights: When editing weights, compare against the existing total weight for the table. A table with total weight 500 and a desired 5% chance for the Rocket Launcher needs a weight value that makes the weapon's share 5% of (500 + new weight). The formula is: weight = desired_percent / (100 - desired_percent) * existing_total. For a 5% chance in a 500-weight table, add roughly 26.3. Since weights are integers, use 26 or 27 and verify the resulting percentage.
Explore the crafting recipe: Locate the blueprint asset matching GUID "7b82c125a5a54984b8bb26576b59e977" or "e73a23b102f24520a32ec0b2afaa6157". Read the blueprint's input items, output items, tool requirements, skill requirements, and workstation tags. This gives you the complete crafting recipe, which you can then modify by editing the blueprint asset -- changing the required items, the workstation tag, or the number of outputs.
Adjust the handling profile: Reduce Spread_Aim from 0.1 to 0.05 for a more accurate launcher. Increase recoil values for a heavier-feeling weapon. Add Shake_Min_Y and Shake_Max_Y to introduce vertical screen shake. Each handling field is independent -- you can tune spread without touching recoil, and vice versa. Test the feel by equipping the weapon in-game rather than judging by the numbers alone.
Create a low-tier variant: Copy the Rocket Launcher asset, change the GUID to a new 32-character hex string (generate a fresh GUID; never reuse an existing one), assign a new item ID that does not collide with any existing item, change the rarity to Rare or Uncommon, and reduce the damage values to create a lower-tier explosive weapon. Place the variant in different loot tables with higher spawn chances. This preserves the original Rocket Launcher as a rare high-tier item while giving lower-level players access to an explosive weapon with reduced stats.
Create a guided variant: Add a guidance system flag (if your version of Unturned supports projectile guidance through flags or projectile-asset configuration) to make the rocket steer toward the crosshair in flight. This requires editing both the weapon asset (to add the guidance flag) and the projectile asset (to enable guidance behaviour and define turn rate, acceleration, and lock-on parameters). This is an advanced modification that touches both files and requires testing across different network conditions to ensure the guided flight looks smooth on both client and server.
Disable crafting unconditionally: Remove the Blueprints, InputItems, OutputItems, RequiresNearbyCraftingTags flags and both GUID-reference flags ("7b82c125a5a54984b8bb26576b59e977" and "e73a23b102f24520a32ec0b2afaa6157"). This strips all crafting participation from the weapon. The weapon can still be found in loot tables; it simply cannot be crafted, deconstructed, or used as a crafting component.

How loot tables store weapon entries

Behind every loot table entry in the list above, there is a data file on disk. Understanding the file structure helps modders find and edit the right entries without hunting through raw game files.

A typical spawn-table entry for the Rocket Launcher in the Militia_Special table looks like this conceptually:

The table is defined in a file (or a section of a larger spawn-configuration file) with a header that names the table and optionally scopes it to a map.
Each row in the table has three fields: a GUID (or item ID), a weight value, and optionally a spawn-condition flag (e.g., "only spawn during rain" or "only spawn if player level > 10").
The weight value is an integer. The sum of all weight values in the table is the total weight. The Rocket Launcher's percentage chance is its weight divided by the total weight.
The percentages shown in this reference (11.765%, 9.091%, 0.882%, etc.) are derived from the weights; the actual file contains the weight integers, not the percentages.

When a modder opens a spawn-table file, they see a list of GUIDs with weight numbers. The Rocket Launcher's entry might look like:

GUID af47bb9e0ba7443fa69435f1f594a10b Weight 3

ID 519 Weight 3

The weight value -- 3 in this example -- is the number the modder edits. Changing it to 6 doubles the weapon's share of the table's items (assuming no other weights change). Changing it to 0 removes the weapon from the table (though some game versions treat a weight of 0 as "do not spawn" and others treat it as "spawn with zero probability," which is functionally the same).

For the high-chance tables (11.765%), the weight is a substantial fraction of the total table weight -- the table contains relatively few items, so each weight contributes a large percentage. For the low-chance tables (0.159%), the weight is a tiny fraction of a much larger total -- the table contains many items, diluting each one's chance.

Knowing this structure, a server owner who dislikes editing raw weight files can use the percentages in this reference to set targets. "I want the Rocket Launcher at roughly 2% in the Militia table." Find the current percentage (0.159%), compute the weight multiplier (2.0 / 0.159 = roughly 12.6), and multiply the existing weight by that factor. Then round to the nearest integer and verify the resulting percentage.

Additional modding scenarios

Beyond the standard modifications listed above, several advanced scenarios are worth documenting for modders who want to push the Rocket Launcher asset further:

Scenario: create a faction-specific reskin. Copy the Rocket Launcher asset, give it a new GUID and item ID, change the model-path field to point to a custom .unity3d bundle with a recoloured or redesigned rocket launcher model, and place the variant exclusively in a specific faction's loot tables (e.g., only in Syndicate tables). Change the item name and description to match the faction theme. Players who farm that faction now have a visually distinct launcher to chase.

Scenario: split the weapon into tiered variants. Create three copies of the Rocket Launcher with progressively higher damage values (edit the projectile assets, not the weapon assets) and progressively rarer loot-table placement. Name them "Rustbucket RPG" (low damage, 5% spawn chance in general militia tables), "Rocket Launcher" (stock stats, current spawn distribution), and "Precision Launcher" (higher damage, tighter Spread_Aim, only in Special-tier tables). This creates a progression ladder within the explosive-weapon category without introducing entirely new weapon types.

Scenario: make the weapon a quest reward instead of a loot drop. Remove all 17 loot-table entries by zeroing the Rocket Launcher's weight in each table. Create a quest-definition file (if the server uses a quest plugin or the game's built-in quest system) that awards the Rocket Launcher on completion. The quest can require killing a number of Militia enemies, collecting a rare component, and visiting a specific workstation. The acquisition path shifts from probabilistic (random loot) to deterministic (complete the quest, get the weapon).

Scenario: add ammo-type variants. The Rocket Launcher's Caliber is 20. By creating a new projectile asset that reads Caliber 20 but has different explosion behaviour (e.g., a fragmentation warhead with wider blast radius but lower direct damage, or an incendiary warhead that applies a fire effect), and by creating a matching ammo item also set to Caliber 20, the same Rocket Launcher weapon can fire different ammunition types. The player loads the ammo type they want, and the calibre match allows any Caliber 20 projectile to spawn. The weapon asset does not change; the projectile and ammo assets provide the variety.

Scenario: conditional loot-table spawning. Some server mods support conditional spawn-table entries -- the weapon only appears if a certain game-world condition is met (time of day, server population, world-event status). Rather than removing the Rocket Launcher entirely, a server owner can gate it behind a full-moon condition or a blood-moon event. The weapon still has its 17 entries, but each entry carries a condition flag that only activates during the designated event window. This concentrates Rocket Launcher appearances into high-intensity moments rather than dispersing them evenly across all play sessions.

When editing the asset, always keep a backup of the original values. The Rocket Launcher's stat profile -- uniform 200 damage across all target classes, the Rocket action type, single-round spawn capacity, broad 17-table loot distribution, full attachment support, and a crafting blueprint -- is a carefully balanced combination that serves both the high-rarity loot role and the crafted-late-game role. Any single-field edit can cascade into unintended balance results, so test each change in isolation before combining edits.

Common pitfalls when editing the Rocket Launcher asset

Several editing mistakes appear repeatedly in modder forums and workshop submissions. Being aware of them before you start editing saves debugging time.

Pitfall one: editing the wrong asset. The most common mistake is opening the weapon asset, changing Player_Damage to 500, loading the game, and seeing that the explosion still deals 200 damage. The modder then changes it to 10, tests again, and still sees 200. The problem is not that the change failed to save; it is that the projectile asset uses its own independent damage value and ignores the weapon's Player_Damage field entirely. Always test whether the projectile reads the weapon's damage field before committing to weapon-asset damage edits.

Pitfall two: removing a GUID flag without removing the blueprint. If you remove GUID "7b82c125a5a54984b8bb26576b59e977" from the weapon's flag list but the blueprint asset still references the Rocket Launcher's item ID as an input or output, the game may produce null-reference errors when the crafting UI tries to resolve the recipe. The blueprint still exists and still points to the weapon, but the weapon no longer declares the blueprint GUID. Remove the blueprint asset first, then remove the GUID flag from the weapon.

Pitfall three: changing the item ID without updating references. The item ID 519 appears in save files, server databases, loot-table definitions, and blueprint input/output lists. If you change the Rocket Launcher's item ID to a custom value, every reference to 519 in other files becomes a dangling pointer. The old item ID 519 will no longer resolve to this asset. If you are creating a variant, use a new item ID and leave the original 519 intact. If you are replacing the original, update every file that references 519.

Pitfall four: adding attachment hooks without model transforms. Adding Hook_Barrel to the flags list takes seconds. Getting the barrel attachment to render correctly on the model requires adding a bone transform to the Unity prefab and re-exporting the asset bundle. Modders who add hook flags without touching the model file discover that attachments are accepted by the inventory system (the hook check passes) but are invisible in the world (the render system has no transform to parent the attachment to). The attachment exists in the weapon's data array but the player cannot see it.

Pitfall five: tuning recoil without testing across framerates. Recoil values interact with the game's frame-dependent update loop. A recoil configuration that feels good at 60 FPS may feel different at 30 FPS or 144 FPS because the per-frame camera correction applies at different rates. Test recoil changes at the minimum and maximum framerates your target player base uses. If the weapon feels dramatically different across framerates, the recoil values may need adjustment.

Pitfall six: setting Ammo_Min higher than magazine capacity. If the magazine item at ID 520 defines a capacity of 1 and you set Ammo_Min to 3, the weapon will attempt to spawn with 3 rounds in a 1-round magazine. The game typically clamps the value to the magazine capacity (the weapon spawns with 1 round), but this behaviour is not guaranteed across all Unturned versions. Always keep Ammo_Min and Ammo_Max at or below the magazine item's capacity.

Pitfall seven: using the wrong weight formula for loot-table edits. The percentage column in this reference shows the current percentage distribution, not the weight value. If you double the weight value, the percentage does not double because the total weight increases. For example, if the current weight is 10 and the total table weight is 100, the chance is 10%. Doubling the weight to 20 makes the total weight 110, and the chance becomes 20/110 = 18.2% -- not the 20% you might expect. Always recalculate the percentage after changing a weight; do not assume linear scaling.

These pitfalls are all avoided by following a simple rule: change one field at a time, test the result in-game, and only move to the next field after confirming the previous change behaves as expected. The Rocket Launcher's asset is interconnected enough that even experienced modders benefit from single-change testing.

Testing asset edits efficiently

Testing a weapon-asset edit traditionally involves loading Unturned, joining a server or single-player world, spawning the weapon via console commands, and firing it at a target. This cycle takes minutes per edit. Several techniques reduce the iteration time:

Use the /give command. The console command /give 519 spawns the Rocket Launcher directly into your inventory. No need to find one in the world or craft it. Combine with /give <ammo_item_id> to spawn matching Caliber 20 ammunition. This eliminates the loot-table and crafting variables during testing -- you always have the weapon and ammo available.

Test on a local server. Hosting a local single-player world or a local dedicated server eliminates network latency as a variable. Recoil feel, projectile travel, and explosion timing are all affected by server tick rate and client-server latency. Testing locally ensures the numbers you see in the asset file are the numbers the game is applying, without network jitter adding variation.

Test one field category at a time. Group edits into categories and test each category independently. Category one: handling (recoil, spread, shake). Category two: damage (player, zombie, animal). Category three: attachments (add or remove hook flags). Category four: loot tables (adjust weights). Category five: crafting (edit blueprint assets). Testing an entire category in one session is efficient; testing fields across categories simultaneously makes it impossible to know which edit caused an observed behaviour change.

Use a second client for PvP testing. If you are testing player damage or projectile behaviour against player targets, run a second Unturned client on the same machine (or a second machine on the local network) and join your local server. Have the second client stand at known distances and note the damage values, projectile behaviour, and visual effects from the receiving end. Damage numbers that look correct on the shooter's screen may differ on the target's screen due to server-side damage calculation differences.

Validate GUID uniqueness after creating variants. When you create a custom Rocket Launcher variant with a new GUID, verify that the GUID does not collide with any existing asset's GUID. A GUID collision produces unpredictable behaviour -- typically one of the two items silently disappears from the registry. Tools exist for scanning the game's asset database for GUID conflicts; run a scan after creating any new asset before distributing it to players.

Inspect the server console during testing. The Unturned server console outputs asset-loading warnings and errors. A malformed .dat file, a missing model bundle, a GUID collision, or a calibre mismatch will often produce a console warning that the client-side game does not display. Keep the server console visible during testing and watch for any yellow (warning) or red (error) lines that mention the Rocket Launcher, item ID 519, or GUID af47bb9e0ba7443fa69435f1f594a10b.

With a systematic testing approach -- local server, /give spawns, one field category per test session, and server-console monitoring -- the edit-test cycle for the Rocket Launcher drops from minutes to tens of seconds per iteration.

Rocket Launcher Weapon Reference ​

Why this reference exists ​

The weapon-projectile asset boundary ​

Asset identity ​

How the game loads and registers the Rocket Launcher ​

How GUID cross-referencing works ​

How projectile weapons differ from hitscan weapons ​

The projectile lifecycle ​

Ballistics fields ​

Player damage fields ​

Zombie damage fields ​

Animal damage fields ​

Handling and recoil ​

Flags ​

How the crafting flags interact ​

Attachment hook mechanics in depth ​

Loot table presence ​

How loot table rolling works ​

Entry-by-entry analysis ​

Server-owner loot-table tuning strategies ​

Canned Beans ​

Practical use for server owners and modders ​

How loot tables store weapon entries ​

Additional modding scenarios ​

Common pitfalls when editing the Rocket Launcher asset ​

Testing asset edits efficiently ​