Skip to content

Line Trace vs Projectile vs Overlap Weapon Hits

Weapon hit detection is not one node. First choose the gameplay question: instant ray, moving actor, area trigger, or blocking contact.

The one-minute version

  • Use a line trace for instant hitscan weapons, interactions, line of sight, and crosshair questions.
  • Use a projectile actor when travel time, visible motion, gravity, bounce, homing, dodging, or interception matters.
  • Use an overlap volume when "being inside this shape" matters: pickups, melee windows, hazards, auras, and soft hitboxes.
  • Use a blocking hit when solid contact matters: projectile impacts, physics collisions, and swept movement that should stop on contact.
  • None of these apply damage by themselves. They only detect a target or contact. Your graph filters the result, sends damage, plays feedback, and cleans up.
  • In multiplayer, the authoritative gameplay hit should usually be decided or approved by the server. Local client-only traces and effects are presentation unless the server accepts the result.

The real choice

Start with the player-facing behavior, not the node name:

Weapon behavior Best first tool Why
Rifle, laser pointer, interact ray Line Trace By Channel The result should be instant along a straight ray.
Fireball, rocket, arrow, grenade Projectile actor with Projectile Movement The thing should move through the world over time.
Sword swing, pickup touch, poison cloud Overlap component or shape trace A volume should catch actors during a window.
Bouncing ball, physical impact, projectile wall strike Event Hit / On Component Hit A blocking collision happened during movement or physics.
Shotgun, forgiving melee, large aim assist Sphere/Capsule/Box trace or multi trace A zero-width ray is too precise or you need several hits.

The wrong choice can still "work" in a tiny test and then fail under normal gameplay. A line trace cannot be dodged after it fires. A projectile can miss because it has travel time. An overlap can repeat or fire per component pair. A blocking hit needs blocking collision, not overlap-only trigger settings.

What each one actually does

Line trace

A line trace is a query you call now:

Start = camera or muzzle location
End = Start + forward vector * range
Line Trace By Channel
-> first blocking hit for that trace channel

It returns a Boolean and an FHitResult. The Boolean means the query found a blocking hit. The hit result can give you Hit Actor, Hit Component, Impact Point, Impact Normal, Distance, Bone Name, and Physical Material when the query and asset setup provide those fields.

Use this when the weapon should feel instant or the player is asking "what is under the crosshair?"

Projectile actor

A projectile is an actor you spawn:

Spawn Actor from Class BP_Projectile at muzzle transform
-> Projectile Movement moves its root collision component over time
-> hit/overlap/stop event decides impact

It returns a spawned actor reference from the spawn node, not a hit result at fire time. The hit result arrives later if the projectile's movement and collision produce one.

Use this when the projectile's existence matters: visible travel, leading a target, arcing, bouncing, homing, blocking around corners, or being destroyed before it reaches the target.

Overlap

An overlap is component-pair state:

WeaponHitbox or PickupSphere
-> On Component Begin Overlap
-> Other Actor / Other Comp
-> filter and apply gameplay once

It returns no value because it is an event, not a function. The event gives you the other actor/component and, for swept begin overlaps, a sweep result. It does not inherently know "one attack hit once." You make that rule with sets, windows, cooldowns, or per-swing hit tracking.

Use this when a volume should detect entry or presence instead of stopping on impact.

Blocking hit

A hit event reports solid contact:

Collision component moves or simulates
-> contact resolves as Block
-> Event Hit / On Component Hit
-> Hit result describes the contact

Use this when the world should stop or bounce the moving thing and you need impact data from that movement. Projectile impacts often use On Component Hit or projectile movement's stop/bounce events.

What you get back

Tool Main output Beginner read
Line Trace By Channel Boolean plus one FHitResult Did this ray find the first blocking target?
Sphere/Capsule Trace By Channel Boolean plus one FHitResult Did this swept shape find the first blocking target?
Multi Trace By Channel Boolean plus Out Hits array Which hits did this query encounter up to the first blocker?
Spawn Actor from Class Actor reference or None Did the projectile actor get created?
On Component Begin Overlap Event pins: Other Actor, Other Comp, Sweep Result Which component pair began overlapping?
Event Hit / On Component Hit Event pins plus FHitResult Which blocking contact was reported?

This is why "my bullet hit something" is too vague for debugging. A line trace hit exists immediately in one graph. A projectile hit exists later in the projectile actor. An overlap hit may be multiple component pairs. A blocking hit may repeat while contact continues.

Choosing camera, muzzle, or hitbox source

For a first-person or third-person shooter, decide whether the question comes from the camera or weapon:

Source Use when Trap
Camera trace The crosshair should decide the aim point. The muzzle may be behind cover even if the camera sees the target.
Muzzle trace/projectile The weapon's physical location should decide obstruction. The shot may not match the crosshair at close range.
Camera trace then muzzle trace/projectile toward aim point You want screen aim plus real muzzle obstruction. Requires two-step math and self-ignore setup.
Weapon hitbox / sockets A melee swing or held object should detect during an animation window. Needs per-swing repeated-hit filtering.

Common shooter shape:

Camera trace
-> if hit: AimPoint = Hit.ImpactPoint
-> else: AimPoint = CameraLocation + CameraForward * Range

Muzzle source
-> direction = AimPoint - MuzzleLocation
-> line trace or projectile from muzzle toward that direction

That keeps the shot aligned with the player's view while still respecting walls, railings, or cover near the weapon.

Failure and repeated-hit behavior

Every method fails differently:

Symptom Likely cause
Trace returns false Nothing blocked the trace channel, wrong start/end, wrong channel, self-hit, ignored target, query collision missing.
Projectile spawns but does not move No useful velocity, wrong updated component, simulation disabled, physics took over, or movement component not set up.
Projectile flies sideways Actor/component local X+ or spawn rotation does not match the visual muzzle direction.
Projectile passes through Collision pair ignores/overlaps instead of blocks, movement is too fast without useful sweep/substep settings, or wrong component owns collision.
Overlap never fires Generate Overlap Events or query collision is missing on one side, or the pair does not resolve to overlap.
Overlap fires multiple times More than one component pair overlapped, or your attack window allows the same actor repeatedly.
Hit event repeats Blocking contact can be reported across movement/physics frames, bounces, or resting contact.

None of these failures automatically print a useful warning. Add debug drawing, print the actor/component names, and inspect the collision pair.

Damage and feedback are separate

Detection gives you evidence. Damage is the gameplay message you choose to send. Feedback is local presentation you choose to play.

Detection
-> filter target, team, owner, validity, already-hit state
-> Apply Damage / Apply Point Damage / Apply Radial Damage
-> Spawn Niagara / decal / sound / camera shake
-> cleanup projectile or hit window state

For a bullet trace, Apply Point Damage is useful because the hit result already has impact location, normal, component, and bone data. For a generic pickup touch, generic damage may be irrelevant. For an explosion, radial damage is usually the right later page because the effect is area-based, not one impact.

What weapon hit detection does not do

  • It does not apply damage. Detection only tells you what was hit or overlapped.
  • It does not decide teams, ownership, friendly fire, invulnerability, or already-hit filtering.
  • It does not guarantee one event per attack. Overlaps, multi traces, and blocking hits can all produce several usable records.
  • It does not play impact feedback. Niagara, decals, sounds, camera shake, and material changes are separate local presentation work.
  • It does not clean up projectile actors or hit windows. Use lifespan, destroy paths, notify-state end logic, or explicit state resets.
  • It does not solve multiplayer authority. Client-local detection is not trusted gameplay unless the server validates or owns it.

Multiplayer authority

For single-player, the graph that detects the hit can usually apply the result directly. For multiplayer, ask "which machine is allowed to decide this?"

Common first patterns:

Pattern Shape
Server-authoritative hitscan Client presses Fire -> Server RPC -> server traces -> server applies damage -> replicated state/impact reaches clients.
Server projectile Client presses Fire -> Server RPC -> server spawns replicated projectile -> projectile hit on server applies damage.
Local cosmetics Client immediately plays muzzle flash, sound, and recoil while waiting for server-approved state.
Melee overlap Server owns the damage window or validates the client request; replicated state tells clients what happened.

The quick path is trusting a client-only hit result because it feels responsive. The concrete cost is that any client can claim hits the server never saw. Use local prediction for feel; use the server for trusted gameplay.

The pattern everyone actually uses

For a hitscan rifle:

Input Fire
-> check ammo/cooldown
-> Camera trace to choose aim point
-> Muzzle trace toward aim point
-> Branch Return Value
-> Break Hit Result
-> filter Hit Actor
-> Apply Point Damage
-> spawn impact feedback at Impact Point / Impact Normal

For a projectile:

Input Fire
-> check ammo/cooldown
-> Spawn Actor from Class BP_Projectile at muzzle transform
-> projectile movement handles travel
-> projectile OnComponentHit / OnProjectileStop
-> filter Other Actor
-> Apply Point Damage or Apply Damage
-> impact feedback
-> Destroy Actor

For a melee swing:

Animation Notify State begins
-> clear HitActorsThisSwing set
-> enable weapon hitbox or run repeated sphere/capsule traces

During hit window
-> for each overlap/trace hit actor
-> if not already in HitActorsThisSwing
-> add actor to set
-> apply damage / reaction

Notify State ends
-> disable hitbox or stop tracing

Lookalikes - which one do I want?

Tool Use when Watch out
Line Trace By Channel Instant one-ray weapon or interaction. Too precise for broad melee or shotgun patterns.
Sphere/Capsule Trace The trace needs forgiving thickness. Shape radius can hit earlier than a line.
Multi Trace Several hits matter, such as a shotgun pellet list or melee sweep. Filter and de-duplicate deliberately.
Projectile Movement Component A spawned actor should travel and collide over time. Spawn, collision, damage, and cleanup are still separate.
On Component Begin Overlap A volume detects entry/presence. Repeated-hit filtering is your job.
Event Hit / On Component Hit Blocking contact from movement or physics is the signal. Blocking contact can repeat.
Apply Damage family A validated target should receive damage. Detection is not damage; damage is a separate call.

Rule of thumb: trace for instant questions, projectile for travel time, overlap for area presence, hit event for solid contact.

Going deeper