Wardogs: Fire, Smoke, Throwing and Mine Triggers

Source: the item definitions under data/Wardogs/Plugins/GameFeatures/Items (Molotov, SmokeGrenade, AT_mine, Claymore, C4, IED), the throw curves and smoke assets under data/Wardogs/Content, ge-values.json and explosive-actors.json. Blueprint behaviour comes from the round 8 bytecode listings of the actor Blueprints (kept locally, not in this repository; the explosive actor evidence summarises them). Native addresses are RVAs in the restored CL-516586 executable.

This page covers what an explosive or throwable does apart from its blast: fire that keeps burning, smoke, how things are thrown, how mines and remote charges are placed and triggered. Blast damage, radius and falloff are not repeated here; they are tabulated per explosive on Explosives, with the rules in the Damage Pipeline and the explosive actor evidence. Prices, unlock levels and buy limits are on the Item Shop page (section 4).

Labels: Data is read straight from the export. Bytecode is read from the Blueprint listing of the actor. Native is read from the game executable (RVA given). Derived is worked out from those values. “Not traced” means nobody has followed it yet.

1. Totals

Item definitions scanned: 78 (ID_*.json, audio files excluded).
Throwable items: 13 (ID.Item.SmokeGrenade.Black, ID.Item.SmokeGrenade.Blue, ID.Item.SmokeGrenade.Green, ID.Item.SmokeGrenade.Orange, ID.Item.SmokeGrenade.Purple, ID.Item.SmokeGrenade.Red, ID.Item.SmokeGrenade.White, ID.Item.SmokeGrenade.Yellow, Id.Item.C4Trigger, Id.Item.GoldM67Grenade, Id.Item.IED.Trigger, Id.Item.M67Grenade, Id.Item.Molotov), 26 throw actions.
Placeable explosives: 3 (AT mine, Claymore, placed IED).
Smoke data assets: 9 (DA_SmokeGrenade_* and DA_SmokeScreen).
Molotov post-process rows: 1.

The tables below are generated by _tools/utility_throwable_tables.py (--write). Hand-written text sits between them.

2. Molotov and sustained fire

2.1 How the fire starts

Step	What happens	Label
Item	`Id.Item.Molotov`: 1 x 2 inventory shape, weight 0.99, stackable, thrown actor `B_Molotov`. Throw velocities in section 4.	Data (`ID_Molotov.json`)
Thrown actor	`B_Molotov` lists `B_Molotov_TriggerVolume` as the volume class and `B_Molotov_FireField` as the fire class. It uses the grenade base class `AWDMolotovGrenade` (derived from `AWDGrenade`).	Bytecode (CDO), SDK
Burst	On detonation the Molotov also runs the shared radial blast (`Meta.Damage.Molotov`, base 40, radius 500). Numbers are on the Explosives and damage pages. Thrown contact adds the shared `ImpactDamage` 10.	Data, see round 8 impact
Patch creation	The detonation entry (actor virtual slot 237) is `0x86A15B0`. It creates the trigger volumes and the fire field, then calls the grenade implementation at `0x86A318D`. It reads an integer at actor `+0x678` (class default 15) as a loop count, floats at `+0x670`, `+0x674` (1.5), `+0x680`, `+0x684` (100.0) while placing patches, and copies `+0x684` into a field of the first few spawned patch actors. The values `B_Molotov` sets are in the patch table below; the roles come from the native page.	Native (`0x86A15B0`), Data (Blueprint CDO)
Fuse	`B_Molotov` does not override `BaseFuseTime` (Data (Blueprint CDO), checked in round 17). The grenade base constructor (`0x6CADC90`) sets `BaseFuseTime` (`+0x620`) to 5.0 and `bCanBeCooked` (`+0x624`) to false (store `0x6CADCBB`, a zeroed register; round 18 verified; the Molotov constructor `0x86A0200` runs the grenade base `0x6CADED0`, which stores the same 5.0 at `0x6CADEE4` and zero at `0x6CADEEE`), so the Molotov cannot be cooked and the fuse is 5.0 s. Round 39: the Molotov bursts on its first impact: `B_Molotov` sets the impact-explode bool `AWDExplosive +0x49C` (obfuscated `_aaablepeghlpjblibpkdm`) to true, and the mesh-impact handler `0x6CAB030` then calls the detonation (slot 237, `0x86A15B0`); the 5.0 s fuse is only a backstop. No other dumped throwable sets that bool.	Native (`0x6CADC90`), Data (Blueprint CDO)

2.2 The burning area

Property	Value	Label
Trigger volume accepts	`WDMoverCharacter` (players) and `BHBaseVehiclePawn` (vehicles)	Bytecode (`B_Molotov_TriggerVolume` CDO)
Effect on overlap	`GE_MolotovBurning`, 1 stack; periodic queries off	Bytecode (CDO)
Volume and field life	`InitialLifeSpan` 45 s on both; `bCanBeDamaged` false; replicated, net update 2 Hz (volume)	Bytecode (CDOs)
Damage loop	Looping 0.4 s timer `OnActorsArrayLoop`. Started when the first actor enters the field, and by an overlap scan 1.0 s after the field begins. Cleared when the actor array is empty.	Bytecode (`OnTriggerVolumeUpdated` offsets 238, 445; ubergraph offsets 15, 986)
Player damage	Skips players without `State.Player.Vitality.Alive`. Otherwise one `SimpleDamageActorWithInstigatorController` call of 15 with type `Meta.Damage.DamageType.Enviroment` (the game’s spelling), synthetic hit with no bone. The hit counts only if it returned more than 0.	Bytecode (`TryDamagePlayer`), Native entry `0x6F09210`
Vehicle damage	`DamageModelComponent->ApplyDamage(Attribute.Gameplay.Health, 2)` per tick. The vehicle needs a damage model and a `WDVehicleGameplaySystemsComponent`. Counts only if more than 0 was applied.	Bytecode (`TryDamageVehicle`)
Rates	37.5 player damage and 5 vehicle health per second per actor in the field, before later damage rules	Derived (15 / 0.4, 2 / 0.4)
Instigator	Damage is credited to the fire field’s own instigator controller (set when it spawns; presumably the thrower, not traced)	Bytecode
Team and owner checks	None appear in the field’s loop or in either damage function. Whether later damage rules drop friendly or self damage was not traced.	Bytecode; downstream not traced
Side effects per damaged actor	Camera shake `B_CameraShake_MolotovBurning` (scale 1.0 for a player, 0.175 for a vehicle’s controller) and a hit audio event	Bytecode (`OnActorsArrayLoop`)
Demolition	Ruleset `Molotov` (`Meta.Damage.Molotov`, minimum distance 300) lets fire affect bushes and saplings; see Demolition	Data
Patch geometry	The patch count, spacing and size come from the native spawner `0x86A15B0` reading six `AWDMolotovGrenade` fields; `B_Molotov` sets three of them (count 15 instead of the native 12, offset scale 1.5, copied value 100) and the fire field sets one of four (2000 instead of 250). See the table below this one. Round 39: patches are placed on a golden-angle spiral (helper `0x86A0A70`): patch `i` of 15 sits at radius `250 * sqrt(i / 14)` cm (0, 66, 94, 116, 134, 150, 164, 177, 189, 200, 211, 221, 231, 240, 250) and angle `i * 2.39996` rad around a centre pushed along the throw direction by up to `1.5 * 250` cm; a steep downward hit puts the first 4 patches on a reduced radius of 137 cm (`sqrt(0.3) * 250`). Each patch box is 200 x 200 x 50 cm.	Data (Blueprint CDO), Native (static)

Molotov patch fields (Data (Blueprint CDO) against the Native constructor defaults of AWDMolotovGrenade 0x86A0200 and AWDMolotovFireField 0x86A0140; roles are Derived on the native defaults page; round 17 evidence). A field the Blueprint leaves unset keeps the native value.

2.3 The burning status

| Item | Value | |—|—| | GE_MolotovBurning (Data, assets/data/ge-values.json) | granted tags State.Player.Molotov.Burning; modifiers: none; duration, stacking and requirements not serialized; the native UBHGameplayEffect defaults are recovered (Duration 0.0, MaxStacks 1, refresh policy 0, expiration policy 1; section 2.3 below) | | Character modifier state State.CharacterModifier.Molotov.Burning (Data) | active while State.Player.Molotov.Burning; ignored while State.Player.Vitality.Critical; camera modifier removal blends out over 0.25 s (bBlendedRemoval true) | | Fire-field player damage (Data, explosive-actors.json) | 15 per attempt, damage type Meta.Damage.DamageType.Enviroment, every 0.4 s | | Fire-field vehicle damage (Data, explosive-actors.json) | 2 Attribute.Gameplay.Health per attempt, every 0.4 s | | Per-second rate (Derived) | player 37.5 per second, vehicle 5 per second, before downstream handling |

GE_MolotovBurning itself changes no attribute. Its only job is to grant the tag State.Player.Molotov.Burning; the damage in the table above comes from the fire field, not from the effect. The Blueprint effect GE_MolotovBurning sets only GrantedTags (Data (Blueprint CDO), round 17: no duration, stack limit or refresh policy), so those come from the native UBHGameplayEffect constructor (0x5225C65, Native, round 18; a Blueprint class default object copies the native parent’s defaults): Duration (+0x30) 0.0 (store 0x5225C82), MaxStacks (+0x34) 1, StackDurationRefreshPolicy (+0x36) 0 = RefreshOnSuccessfulApplication, StackExpirationPolicy (+0x37) 1 = RemoveSingleStackAndRefreshDuration (one dword store 0x1000001 at 0x5225C74). So a reapplication cannot add a second stack (MaxStacks 1) and refreshes the duration policy-wise, but the duration is 0.0. What a zero duration does at run time (round 20, evidence level: static-analysis image; virtualized dispatch not removed; the pages read are byte-identical in the analysis and reference images and hold no dispatch stub): the duration pass 0x522D260 loads the effect’s class default Duration (+0x30) and tests it against zero at 0x522D4B3 (ucomiss). When equal it jumps to 0x522D700, which skips the whole timed-expiry block (the end-time comparison at 0x522D4DC and the removal call 0x522D6F1, reached through 0x522D6D5); only a non-zero duration can be removed by this pass. So Duration 0.0 means no timed expiry (a standing effect, not an instant one: it stays on the target and keeps its granted tag until something removes it). That is Derived from the branch structure; the expiry arithmetic for non-zero durations was not decoded. Other cooked effects use the same default for standing tag effects and name their own removal rule instead (for example GE_HeavyHelmet_Passive and GE_Player_Ghilli_Helmet set only a removal requirement ignore State.Player.Vitality.Dead; ge-values.json), which is consistent with that reading.

What ends the burning tag (round 20; Data plus Native): GE_MolotovBurning has no removal or ongoing requirement and no application requirement (ge-values.json: removal_requirements, ongoing_requirements null, so native defaults; the only serialized property is GrantedTags). B_Molotov_TriggerVolume (Blueprint CDO) is a WDMolotovTriggerVolume (WDGameplayTriggerVolume family; EffectsToApply = GE_MolotovBurning x1 stack, bPeriodicQueries false, allow list WDMoverCharacter and BHBaseVehiclePawn, InitialLifeSpan 45). Its Blueprint OnEnterTriggerVolume and OnExitTriggerVolume only call the parent function and broadcast OnTriggerVolumeUpdated, so the application and removal are native, and AWDMolotovTriggerVolume does not override those two virtuals (its vtable at 0xBB222D0 matches WDGameplayTriggerVolume 0xB685790 in slots 237 to 240). The inherited enter handler 0x76FBE80 (vtable slot 237, byte offset +0x768) applies the tag container (+0x910, getter 0x76FBE70) with 0x5239140, then applies each entry of EffectsToApply (+0x930, getter 0x76FBE60) through 0x5227F20 and stores the returned effect handle in a per-actor record in the array at +0x948. The exit handler 0x76FC120 (slot 238, +0x770) looks up that record, takes the actor’s ability-system component through 0x5318480, removes the tag container again (0x5239140 with count -1) and removes every stored effect handle with 0x52355F0 (which calls the same removal routine 0x1452313E0 that the duration pass uses, with stack argument 0x80000001). So the burning effect is removed when the actor leaves the patch’s trigger box (the end-overlap path), not by a timer; since the effect has no timed expiry, leaving the last patch should clear State.Player.Molotov.Burning at once, with no lingering burn. That last step is Inferred: the end-overlap wiring (WDTriggerVolume::OnEndOverlap calling the exit virtual) and the granted-tag release on effect removal were not traced.

2.4 Screen effect

DT_PostProcessEffects_Molotov (row struct WDPostProcessEffect, registered as PostProcessEffectsData) has one row. Duration is 0 and the four parameters are driven by progress curves, so the look is controlled by the effect progress value, not by a fixed time.

| Row | Material | Duration (s) | Progress parameter | Curve keys | Curve time span (s) | Curve value range | |—|—|—:|—|—:|—|—| | PostProcessEffect.Molotov.Burning | MI_PP_Burning | 0 | DamageVignetteProgress | 11 | 0-1 | 0-1 | | PostProcessEffect.Molotov.Burning | MI_PP_Burning | 0 | BlurProgress | 4 | 0-1 | 0-0.75 | | PostProcessEffect.Molotov.Burning | MI_PP_Burning | 0 | DarkenProgress | 4 | 0-1 | 0-0.75 | | PostProcessEffect.Molotov.Burning | MI_PP_Burning | 0 | DesaturationProgress | 2 | 0-0.578 | 1-1 |

The vignette curve rises to 0.75 by 0.25 s, stays near 0.75-0.8 until about 0.39 s and reaches about 1.0 by 0.44 s (Data, key list in the export). The camera modifier B_CameraModifier_MolotovBurning is attached to the character modifier state and is active only while the burning tag is present and the player is not State.Player.Vitality.Critical.

3. Smoke, signal grenades and non-lethal throwables

3.1 What exists

Kind	Items	Notes
Smoke grenade	White and Black (`Utility.Type.Offensive`, tactical slot)	“Emits a cloud of” smoke. Price 100 each (Item Shop).
Signal grenades	Yellow (Alert), Red (Hostile), Blue (Friendly), Green (Supply Request), Orange (Damaged Vehicle), Purple (Landing Zone)	“Emits a Column of” coloured smoke and “Adds a … Marker to the Map” (shop text). Price 50 each. Green and Purple are logistics (`Utility.Type.Building`). How the marker is created is not traced.
Vehicle smoke	`Id.Item.VehicleSmoke` countermeasure	“Sustained discharge trails around the vehicle; settles into a large, lingering screen temporarily providing Infantry cover”. Price 750. Smoke asset in the table below.
Flash and stun	none	No flashbang or stun item exists in the export: no item definition, vendor row or GameplayEffect. Only three audio events (`Audio.Event.Weapon.Throwable.Flashbang.Explosion`, `.Impact`, `.PinPull`) and the Medic skill label `Meta.Role.Medic.StunResistance` (“Reduces the duration of the effects received from flash & stun grenades”) remain. The skill has no effect row in the skill tables.

3.2 Smoke assets

Smoke is a visual volume; no GameplayEffect is applied by the smoke items (no smoke effect exists in ge-values.json). Durations below are the assets’ Total Duration and describe the smoke visual, not a gameplay timer. A value marked “class default” is the default of PDA_SmokeGrenade_C (Data (Blueprint CDO), round 17: total duration 180, sprite max size 800, fade in 20, fade out 10, diameter 15); “not serialized” means neither the asset nor the class sets it.

Native structure (SDK, SmokeGrenade module): AWDSmokeGrenade derives from AWDGrenade and spawns a grenade actor class (+0x660). The spawned AWDSmokeGrenadeVFXActor keeps an FWDSmokeVolume (a point list, an origin and a bounding box) built from sphere traces (FWDSmokeVolumeParams: trace radius, wall hit offset, trace channel, complex flag) so the cloud stops at walls. It has UpdatePawnsInBoundingBox and UpdatePawnsInSmoke, which keep a pawn list for the cloud. AWDSmokeGrenadeAfterEffect is a separate actor with a gameplay cue and an owner entity tag. What the pawn list is used for (vision, AI, targeting) is not traced. Data (Blueprint CDO), round 17: every smoke and signal grenade (B_SmokeGrenade_*) sets BaseFuseTime 3.0 (the grenade base is 5.0) and lives PostExplodeLifespan 10 s after the burst; the spawned world actor B_WorldSmokeGrenade_White (all colours inherit it) has InitialLifeSpan 175 s; the volume actor BP_SmokeGrenadeVFX uses SphereTraceRadius 65, WallHitPosOffset 100, Density 3 and Height 1.5 (the trace radius equals the native constructor default 0x869C200). Native (static read of the analysis image, round 26): AWDSmokeGrenadeVFXActor fields are Params (FWDSmokeVolumeParams, +0x2B8), SmokeVolume (+0x2E8), NiagaraComponent (+0x350), Pawns (+0x358), one debug bool (+0x368), a start-offset float (+0x36C, set by SetStartOffsetSeconds) and a float at +0x390 (constructor default -1). GetEffectiveSmokeTimings (0x869F010) is plain arithmetic on the three asset timings and the start offset: total = max(total - offset, 0.1), fade in = clamp(fade in - offset, 0, total), fade out = max(fade out, 0); so the 120, 64 and 180 s totals above pass through unchanged when the offset is 0. InitializeSmokeData (0x869F280) builds the SmokeVolume point list (0x869D3FD) and starts two timers that run 0x869DAF0 after the fade-in delay and 0x869E3D0 later. UpdatePawnsInBoundingBox (0x869E420) and UpdatePawnsInSmoke (0x869F600, which uses the point-list overlap test at 0x869D740) maintain Pawns; no native caller was found and the Blueprint BP_SmokeGrenadeVFX does not call either function.

4. Throwing

All throw actions on throwable items, from WDItemExtensionData_Throwable. The M67 frag grenades are listed for comparison. Velocity is in cm/s; when “constant velocity” is yes the velocity curve is not used.

| Item id | Thrown actor | Throw action | Velocity | Constant velocity | Velocity curve | Owner velocity influence (vertical / horizontal) | Angular velocity Y (min-max) | Spawn offset (X, Z) | Equip blocked after (s) | Consumes | |—|—|—|—:|—|—|—|—|—|—:|—| | Id.Item.M67Grenade | B_FragGrenade | Primary | 2500 | no | CRV_ThrowVelocity_OverarmStrong | 1 / 1 | 200-10000 | 40, 0 | 0.5 | (the item itself) | | Id.Item.M67Grenade | B_FragGrenade | Secondary | 1400 | no | CRV_ThrowVelocity_Underarm | 1 / 1 | 50-200 | 40, -10 | 0.4 | (the item itself) | | Id.Item.M67Grenade | B_FragGrenade | Back | 1800 | yes | - | 1 / 1 | 200-400 | 0, 0 | 0.5 | (the item itself) | | Id.Item.GoldM67Grenade | B_GoldFragGrenade | Primary | 2200 | no | CRV_ThrowVelocity_OverarmStrong | 1 / 1 | 200-400 | 40, 0 | 0.5 | (the item itself) | | Id.Item.GoldM67Grenade | B_GoldFragGrenade | Secondary | 1400 | no | CRV_ThrowVelocity_Underarm | 1 / 1 | 100-200 | 40, -10 | 0.4 | (the item itself) | | Id.Item.GoldM67Grenade | B_GoldFragGrenade | Back | 1800 | yes | - | 1 / 1 | 200-400 | 0, 0 | 0.5 | (the item itself) | | Id.Item.C4Trigger | B_ThrowableC4 | Secondary | 900 | yes | - | 1 / 0.45 | 100-150 | 40, 0 | 0.5 | Id.Item.C4Explosive | | Id.Item.IED.Trigger | B_ThrowableIED | Secondary | 1200 | yes | - | 1 / 0.45 | 100-150 | 40, 0 | 0.5 | Id.Item.IED.Explosive | | Id.Item.Molotov | B_Molotov | Primary | 2000 | no | CRV_ThrowVelocity_OverarmStrong | 1 / 0.45 | 200-400 | 40, 0 | 0.5 | (the item itself) | | Id.Item.Molotov | B_Molotov | Secondary | 1200 | no | CRV_ThrowVelocity_Underarm | 1 / 0.45 | 100-200 | 40, -10 | 0.4 | (the item itself) | | ID.Item.SmokeGrenade.Black | B_SmokeGrenade_Black | Primary | 2000 | no | CRV_ThrowVelocity_OverarmStrong | 1 / 0.45 | 200-400 | 40, 0 | 0.5 | (the item itself) | | ID.Item.SmokeGrenade.Black | B_SmokeGrenade_Black | Secondary | 1200 | no | CRV_ThrowVelocity_Underarm | 1 / 0.45 | 100-200 | 40, -10 | 0.4 | (the item itself) | | ID.Item.SmokeGrenade.Blue | B_SmokeGrenade_Blue | Primary | 2000 | no | CRV_ThrowVelocity_OverarmStrong | 1 / 0.45 | 200-400 | 40, 0 | 0.5 | (the item itself) | | ID.Item.SmokeGrenade.Blue | B_SmokeGrenade_Blue | Secondary | 1200 | no | CRV_ThrowVelocity_Underarm | 1 / 0.45 | 100-200 | 40, -10 | 0.4 | (the item itself) | | ID.Item.SmokeGrenade.Green | B_SmokeGrenade_Green | Primary | 2000 | no | CRV_ThrowVelocity_OverarmStrong | 1 / 0.45 | 200-400 | 40, 0 | 0.5 | (the item itself) | | ID.Item.SmokeGrenade.Green | B_SmokeGrenade_Green | Secondary | 1200 | no | CRV_ThrowVelocity_Underarm | 1 / 0.45 | 100-200 | 40, -10 | 0.4 | (the item itself) | | ID.Item.SmokeGrenade.Orange | B_SmokeGrenade_Orange | Primary | 2000 | no | CRV_ThrowVelocity_OverarmStrong | 1 / 0.45 | 200-400 | 40, 0 | 0.5 | (the item itself) | | ID.Item.SmokeGrenade.Orange | B_SmokeGrenade_Orange | Secondary | 1200 | no | CRV_ThrowVelocity_Underarm | 1 / 0.45 | 100-200 | 40, -10 | 0.4 | (the item itself) | | ID.Item.SmokeGrenade.Purple | B_SmokeGrenade_Purple | Primary | 2000 | no | CRV_ThrowVelocity_OverarmStrong | 1 / 0.45 | 200-400 | 40, 0 | 0.5 | (the item itself) | | ID.Item.SmokeGrenade.Purple | B_SmokeGrenade_Purple | Secondary | 1200 | no | CRV_ThrowVelocity_Underarm | 1 / 0.45 | 100-200 | 40, -10 | 0.4 | (the item itself) | | ID.Item.SmokeGrenade.Red | B_SmokeGrenade_Red | Primary | 2000 | no | CRV_ThrowVelocity_OverarmStrong | 1 / 0.45 | 200-400 | 40, 0 | 0.5 | (the item itself) | | ID.Item.SmokeGrenade.Red | B_SmokeGrenade_Red | Secondary | 1200 | no | CRV_ThrowVelocity_Underarm | 1 / 0.45 | 100-200 | 40, -10 | 0.4 | (the item itself) | | ID.Item.SmokeGrenade.White | B_SmokeGrenade_White | Primary | 2000 | no | CRV_ThrowVelocity_OverarmStrong | 1 / 0.45 | 200-400 | 40, 0 | 0.5 | (the item itself) | | ID.Item.SmokeGrenade.White | B_SmokeGrenade_White | Secondary | 1200 | no | CRV_ThrowVelocity_Underarm | 1 / 0.45 | 100-200 | 40, -10 | 0.4 | (the item itself) | | ID.Item.SmokeGrenade.Yellow | B_SmokeGrenade_Yellow | Primary | 2000 | no | CRV_ThrowVelocity_OverarmStrong | 1 / 0.45 | 200-400 | 40, 0 | 0.5 | (the item itself) | | ID.Item.SmokeGrenade.Yellow | B_SmokeGrenade_Yellow | Secondary | 1200 | no | CRV_ThrowVelocity_Underarm | 1 / 0.45 | 100-200 | 40, -10 | 0.4 | (the item itself) |

Curves used above (Data, Content/Items/Throwable/Curves):

| Curve | Keys (input, value) | |—|—| | CRV_ThrowPitch_Overarm | -90: -90; -37.9: -40; 0: 5; 90: 90 | | CRV_ThrowPitch_OverarmStrong | -90: -75; 0: 5; 15: 27.5; 90: 97.5 | | CRV_ThrowPitch_Underarm | -90: -95; -15: -17.5; -5: 0; 0: 7.5; 20: 30; 30: 42.5; 45: 55; 90: 90 | | CRV_ThrowVelocity_OverarmStrong | 0: 2200; 45: 2750; 90.1: 2200 | | CRV_ThrowVelocity_Underarm | -90: 800; -45: 1000; -15: 1200; -5: 1400 |

Reading the table (Derived):

CRV_ThrowVelocity_OverarmStrong runs 2200 to 2750 (peak at input 45) and CRV_ThrowVelocity_Underarm runs 800 to 1400, so the curve can exceed or undercut the flat ThrowVelocity (2000 or 1200 for Molotov and smoke). How the flat value and the curve combine, and what the curve input is, are not traced.
Primary is the overhand throw, Secondary the underhand throw, Back the M67 back throw. Molotov and all smoke grenades share the same numbers (2000 and 1200 before the curve).
C4 charges and IEDs have only a Secondary action (constant 900 and 1200). The thrown actor is created from the trigger item and consumes one charge item (Id.Item.C4Explosive, Id.Item.IED.Explosive). The placed IED is not thrown; section 5.
The thrower’s velocity adds with a vertical factor of 1 and a horizontal factor of 0.45 (M67: 1 and 1).
The M67 fuse is 4.0 s, it can be cooked and thrown back, MinimumRemainingFuseTime 5.0 (Bytecode, B_FragGrenade CDO). Smoke and Molotov fuses are not in the export (they are native: Molotov 5.0 s, not cookable; see section 2.1).

5. Mines and placed explosives

5.1 Placement limits

Mines, the Claymore and the placed IED use the placeable item extension. Placement takes time while the item is held: GE_UsePlaceable scales Attribute.Gameplay.Movement.MaxSpeedMultiplier by 0.4 (compound multiply, Data in ge-values.json). The progress text for all three is “Deploying Landmine”. A placed item has 1 health from the item definition.

| Item id | Name | Placed actor | Max placement distance | Max placement angle | Collision size (X, Y, Z) | Can sit on another placeable | Health override | Blocked by | Applied effect | Progress text | |—|—|—|—:|—:|—|—|—:|—|—|—| | ID.Item.ATMine | AT Mine | B_AT_Mine_C | 400 | 30 | not serialized | no | 1 | WDMoverPlayerCharacter, WDRotaryVehicle, WDTrackedVehicle, WDWheeledVehiclePawn | GE_UsePlaceable_C | Deploying Landmine | | Id.Item.Claymore | Claymore | B_Claymore_C | 400 | 30 | 0.9, 0.9, 0.8 | no | 1 | WDMoverPlayerCharacter, WDRotaryVehicle, WDTrackedVehicle, WDWheeledVehiclePawn | GE_UsePlaceable_C | Deploying Landmine | | Id.Item.IED.Trigger | Improvised Explosive Device | B_PlaceableIED_C | not set | 180 | 0.5, 0.5, 0.5 | no | 1 | WDMoverPlayerCharacter | GE_UsePlaceable_C | Deploying Landmine |

Derived: the mine and Claymore have a placement distance of 400 units and a maximum placement angle of 30 (degrees assumed, not traced); the IED has no distance value and an angle of 180. None may be placed on another placeable. Vehicles and players block the AT mine and Claymore; only players block the IED. The collision size values are fractions the placement code scales; the unit is not traced. The placement condition Blueprints (B_AT_MinePlacementCondition, B_ClaymorePlacementCondition, also used by B_PlaceableIED) were not exported, so any further placement rule (terrain type, count limit) is not traced.

5.2 Trigger data

Fields the item definition sets on its extension data. “Not serialized” means the class default applies and the default is not in the export.

AT mine vertical numbers. The item data puts the trigger box centre at Z 120 (TriggerLocation) with a half-height of 120. The mine actor Blueprint B_AT_Mine has a separate Z Offset of 20 next to a trace offset of (0, 0, 50) (round 40 evidence, section R40-15). These are different fields of different assets: 120 positions the trigger box, 20 belongs to the actor and its use was not traced. Neither replaces the other.

5.3 How each one triggers

	AT mine	Claymore	C4 charge	IED
Trigger type	Proximity box under the mine (extent 30, 30, 120, located 120 above the mine; Data) plus a repeated upward trace	Proximity box in front (extent 80, 80, 45; Data)	Remote: Remote Detonator item	Remote: IED trigger item
Targets	Vehicles only (`BHBaseVehiclePawn` cast)	Players (tag check on the character) and, if `ShouldDetectVehicle`, vehicles	Not applicable	Not applicable
Speed rule	Vehicle speed must exceed `UniversalVehicleSpeed` 0.1 km/h (Data; the Blueprint default is 5.0), or a per-vehicle-tag speed from `PerVehicleSpeedListDetection` (empty, no Blueprint fills it). The repeated upward trace runs every `TraceCheckTime` 0.1 s (Data (Blueprint CDO))	Vehicle speed must exceed 0 km/h (a vehicle target is accepted because `ShouldDetectVehicle` is true); players have no speed rule	-	-
Arming delay	`ArmingDelay` seconds after placement (timer sets `bIsActive`): 1.0 s (Data (Blueprint CDO), `BH_AT_MineExtensionData`)	`ActivationDelayTimer` seconds after placement (latent delay, then the trigger box turns on): 2.0 s (Data (Blueprint CDO), `BH_ClaymoreExtensionData`)	After the charge sticks, the trigger extension is enabled	Delay after trigger: 3.0 s (`DelayTillExplosion`, Data)
Fuse after trigger	Immediate when a valid vehicle is found	Immediate	`DelayTillExplosion` 0.0 (Blueprint variable default, no Blueprint sets it): immediate. The charge actor has its own `TimerBeforeExplosion` 0.2 s (Data (Blueprint CDO), `B_ThrowableC4`)	3.0 s (Data); the IED actor inherits the charge’s `TimerBeforeExplosion` 0.2 s
Line of sight	Not used	Line trace from the Claymore mesh to the target actor, or to each `DamageQuerySocket*` socket of the target’s static mesh	-	-
Team rule	`DetectFriendlyVehicles` true (Data (Blueprint CDO)): a vehicle of the same faction triggers it. When false it would not	`DetectFriendlyTeammates` true (Data (Blueprint CDO)): a target with the same faction tag as the Claymore is not ignored. `ShouldDetectVehicle` is also true	None in the charge	None in the charge
Owner	Blast ignores the mine actor itself. No owner exemption is read in the trigger	Same	No owner exemption read; the owner’s distance limits the remote range (5.4)	Same as C4
Shot or blast	Any damage except the throwable-impact tag (`Meta.Damage.Kinetic.Impact.Throwable`) makes it explode	An explosion (damage type `Meta.Damage.DamageType.Explosive`) makes it explode at once; other damage reduces its 1 health and destroys it without a blast	A C4 or IED blast (damage type Explosive plus a C4 or IED source tag) detonates it; other damage reduces its 30 health and destroys it	Same as C4 (it is a C4 subclass)
After the blast	Destroy timer 1.0 s	Delayed destroy (`DelayedDestroyActor`)	Not traced	Not traced
Label	Bytecode (`B_AT_Mine`) + Data	Bytecode (`B_Claymore`) + Data	Bytecode (`B_ThrowableC4`) + Data	Bytecode (`B_ThrowableIED`, `B_PlaceableIED`) + Data

Details behind the table:

AT mine (Bytecode): overlap events and the explode decision run on the server only (HasAuthority). The mine ignores everything that is not a vehicle. CheckForVehicle runs a sphere trace (radius 10) from 20 units above the mine to 100 units up and checks the hit actor against the speed rule; a second path (CheckForStationaryOverlap) handles a vehicle already on the mine. Its exact logic is not traced. A mine destroyed by an enemy (BP_OnDisarmed) broadcasts Meta.Progression.Resources.MatchScore.DestroyedDeployable.
Claymore (Bytecode): the trigger box overlap is checked on the server, then the target must pass CheckTargetConditions (player character with a matching gameplay tag, or vehicle above 0 km/h), then the faction check and the line-of-sight trace. From the filtered listing, shooting the Claymore appears to only destroy it (health 1, destroyed-deployable reward), while an explosion nearby sets it off. Which gameplay tag marks a valid player target is not decoded.
C4 charge (Bytecode + Native): the charge sticks to what it hits (bStickOnImpact true, attached to the hit component). It has 30 health. When the trigger fires, OnTriggerExecuted waits DelayTillExplosion seconds when that is above 0, then DelayedDetonate calls Auth_Explode (0x6CACE50, slot 237 0x6CA80E0). A 5.0 s repeating check (CheckOwnerIsAlive) destroys the charge, without an explosion, when its instigator is no longer valid.
IED (Bytecode): the placed IED (B_PlaceableIED) spawns B_ThrowableIED at its own position and releases it as a throw with Action.Throw.Primary.IED; B_ThrowableIED calls the C4 Detonate. The IED inherits the C4 detonation code and has no range limit. The trigger item allows one thrown IED at a time (MaxItemsThatCanBeThrown 1; UI text “IED already placed” / “No IED placed” / “IED empty”).
Explosion entry (Native): explosive actors detonate through 0x6CA8730; the mine and Claymore have their own Blueprint CreateExplosion and do not use it. Both mines initialise the default damage struct in the AWDLandminePlaceable constructor (0x772124F-0x77212F0); see the explosive actor evidence.

5.4 Detonators

Property	Value	Label
C4 detonator	`Id.Item.C4Trigger` “Remote Detonator”, chamber `Item.Attachment.Chamber` accepts only `Id.Item.C4Explosive` and starts with one; charge stack size 3	Data
C4 range	`MaxDetonationDistance` 200 in the detonator’s extension data, times `DetonationDistanceMultiplier`, times 100. Code compares the distance from the owner to the charge against this value and cancels the blast when the charge is farther away. -1 disables the check.	Data + Bytecode (`DelayedDetonate`, offsets 4487-4851)
C4 range value	200 x 100 = 20,000 units at multiplier 1	Derived
C4 range, other value seen	The thrown charge Blueprint `B_ThrowableC4` also lists a “max detonation distance” of 100 (round 40 evidence, section R40-15). The item data and the `DelayedDetonate` bytecode use the detonator’s 200, so 200 (20,000 units) is the range used here and the 100 is not applied as a limit; whether the charge-side field is read anywhere was not traced.	Data, conflict settled in favour of the item data (verification, round 39-40)
Range skill	Support skill `Meta.Role.Support.IncreadedDetonatorRange` multiplies `Attribute.Gameplay.Weapon.DetonatorRangeMultiplier` (default 1) by the curve 1, 1.2, 1.4 (levels 0, 2, 4), so 20,000, 24,000 and 28,000 units. See Progression.	Data + Derived
IED range	`MaxDetonationDistance` -1: no range limit	Data
IED detonator	`Id.Item.IED.Trigger`, Specialist slot item. Primary use is the place action `Action.Placeable.PrimaryUse.IED` (consumes `Id.Item.IED.Explosive`); it also binds `Input.NamedActions.Appliable.SecondaryUse`. An action class `B_Action_IED_Trigger` exists; its logic was not read.	Data
Trigger enable	`UWDItemExtension_Trigger.bCanTrigger` is set true on the charge when it deploys; `OnExploded` and `HandleTriggerAction` handle the press	SDK, Bytecode
Detonation against owner death	Charges stay until the 5 s check finds no valid instigator	Bytecode

6. Friendly fire and ownership

The blast ignore list of the AT mine and Claymore contains the mine itself (evidence). Nothing in the placed items grants or denies damage to the owner or teammates beyond the Detect... flags above; whether the radial rules drop friendly damage is handled in the Damage Pipeline. Team kills are tracked in Teamkill Tracking.
Mine and Claymore factions come from their WDFactionComponent; the Claymore also listens to faction changes (OnFactionChanged_Event). Target factions are read from the target pawn’s player state faction component (Bytecode).

7. Open items

Settled in round 17 (round 17 evidence): the mine, Claymore and C4 class defaults (ArmingDelay 1.0, TraceCheckTime 0.1, DetectFriendlyVehicles true, PerVehicleSpeedListDetection empty, ActivationDelayTimer 2.0, ShouldDetectVehicle true, DetectFriendlyTeammates true, DelayTillExplosion 0.0), the smoke grenade fuse (3.0 s), the smoke asset defaults and the Molotov Blueprint patch values.
Molotov: the patch radius (the exact use of each patch field in 0x86A15B0), and what ends the fire at 45 s versus the later one-shot timer in the field’s ubergraph.
Burning after leaving the fire (round 20): Duration 0.0 is a standing effect (no timed expiry, branch 0x522D4B3 to 0x522D700), and the effect is removed by handle when the actor exits the patch trigger volume (0x76FC120 via 0x52355F0). Still open: (a) the end-overlap to exit-virtual wiring and the granted-tag release on removal were not traced; (b) with MaxStacks 1 and several overlapping patch volumes, whether a second application shares one effect (so leaving one patch could remove it while still inside another) or yields a separate handle is not decoded; (c) what happens on target death or when a patch actor is destroyed while the target is inside (45 s InitialLifeSpan) relies on the engine’s end-overlap behaviour and is untraced; (d) the removal pass for StackExpirationPolicy 1 is moot for a zero duration.
Whether downstream damage rules reduce Molotov, mine, Claymore or C4 damage to the owner or teammates.
Placement condition Blueprints and any placement count limit.
What the smoke volume’s pawn list is used for, and the smoke fuse.
Any flash or stun grenade: not present in this build’s export.

7. Round 36 additions

Evidence: round 36 combat evidence, sections 7 and 8.

Fire patch size (Data, Blueprint dump). B_Molotov_TriggerVolume’s BoxComponent has BoxExtent 100 x 100 x 25 (half extents, cm), so each patch trigger box is 200 x 200 x 50 cm and overlaps Pawn only. The total spread of the 15 patches is native and not decoded.
Impact or fuse (Native). B_Molotov only plays a flight sound. CollisionExplodeImpactThreshold (AWDExplosive +0x498) is 0.0 in the constructor and no Blueprint sets it; the float is read by the mesh-impact handler 0x6CAB030 (as a1[294]), which first tests the bool at +0x49C. Round 39: B_Molotov sets that bool true, so the Molotov explodes on its first impact; the 5.0 s fuse (and depletion of the 50 starting health) are backstops.
Armor against fire (Derived from the damage tables). The fire tick is Meta.Damage.DamageType.Enviroment; no row in DT_GlobalDamage_ArmorData, _InfantryData or _VehicleData matches that source, so armor rows do not apply to it. The burst (Meta.Damage.Explosive.Utility.Molotov) matches the Explosive armor rows (-85%) and gets -30% against Armor.SuperHeavy in _InfantryData.
Teammates (Derived). AlignmentRequired = Friendly entries exist in DT_GlobalDamage_InfantryData for Bullet (-50%) and Large Hammer (-70%) only; none for the Molotov burst or fire tick, and the fire loop has no team check. Whether the mode disables friendly damage elsewhere is not in these tables.
What smoke blocks (Native, static). The only caller of the sight-blocker query (0x6F4E2D0) is the aim-assist target manager (0x6D821E1). No spotting, lock-on, minimap or damage code calls it, and no smoke effect or tag exists. Whether AI sight traces ignore the smoke is not determined.