Skip to content

Get / Set Generate Overlap Events and Set Notify Rigid Body Collision

At a glance

Lives on: one Primitive Component · Get Generate Overlap Events returns: Boolean, the target's local notification flag—not whether it overlaps anything · Setters return: no success value · Overlap requirement: both components' Generate Overlap Events flags plus query-enabled collision and a pair response that resolves to Overlap · Physics-hit requirement: the component that wants solver-generated hit events enables Notify Rigid Body Collision, shown in Details as Simulation Generates Hit Events · Official pages: Get Generate Overlap Events, Set Notify Rigid Body Collision, On Component Begin Overlap, and UPrimitiveComponent

These flags do not decide whether two objects block, overlap, or ignore each other. Collision Enabled, object type, and channel responses decide the interaction. These flags decide whether a qualifying interaction should also produce a particular family of notifications.

The one-minute version

  • Get Generate Overlap Events answers only “is this Primitive Component's overlap-notification flag on?” True does not prove a current overlap or a correct collision pair.
  • Set Generate Overlap Events changes that flag on this exact component. It does not change the other component, enable collision, or set any channel to Overlap.
  • Both components need Generate Overlap Events enabled before component Begin/End Overlap notifications can occur.
  • Set Notify Rigid Body Collision changes the physics contact-notification flag also labeled Simulation Generates Hit Events in the component Details panel.
  • Physics-simulated blocking contacts need that flag on the component whose On Component Hit event you expect. The other component does not need the same flag merely to remain a blocker.
  • Movement sweeps—Character Movement, Projectile Movement, or Set Location with Sweep—can report blocking hit events through the movement path without relying on physics-simulation contact notification.
  • Changing Generate Overlap Events on a live registered component refreshes overlap bookkeeping. Existing contacts can produce Begin when enabled or End when disabled; do not assume the flag waits quietly for the next move.
  • Changing Notify Rigid Body Collision does not synthesize a past Hit or an End Hit. It changes which future physics contacts are reported.
  • None of these nodes changes Collision Enabled, object type, responses, Simulate Physics, gravity, visibility, or transform.
  • The flags and events are local to the machine/world. Authoritative overlap, damage, and physics-hit gameplay should be decided on the server.

Three separate collision decisions

Treat collision setup as three layers:

1. Participation
   Collision Enabled = No Collision / Query Only / Physics Only / Query and Physics

2. Pair response
   my Object Type + both response tables -> Ignore / Overlap / Block

3. Notification request
   Generate Overlap Events?       -> Begin/End Overlap family
   Notify Rigid Body Collision?   -> physics-simulation Hit family

The notification flags cannot repair an earlier layer. A Sphere with Generate Overlap Events true but Collision Enabled set to No Collision is not a trigger. A physics body with Notify Rigid Body Collision true whose pair resolves to Overlap does not become a blocking impact.

Setting Controls Does not control
Collision Enabled Whether query collision, physics collision, both, or neither participates. Per-channel Block/Overlap/Ignore choice or event request by itself.
Object Type Which object channel this component represents. How every other component responds to it.
Responses Pairwise Ignore/Overlap/Block resolution. Whether qualifying overlap/physics contact is dispatched to Blueprint.
Generate Overlap Events Whether this component participates in overlap event/tracking notifications. Collision participation, responses, blocking, or physics simulation.
Notify Rigid Body Collision Whether this component requests rigid-body contact hit notification. Simulation, blocking responses, sweep behavior, or overlap events.

Get and Set Generate Overlap Events

What the getter returns

Get Generate Overlap Events returns one Boolean copied from the target Primitive Component.

true  = this component permits overlap notifications/tracking
false = this component does not

It does not mean:

  • the component is currently overlapping something;
  • the other component has its flag enabled;
  • query collision is enabled;
  • the pair resolves to Overlap;
  • a Begin event was already delivered; or
  • your own cached IsInside Boolean/Set is correct.

Use Is Overlapping Actor/Component or Get Overlapping... for current state. Use the getter to diagnose one prerequisite.

Why both sides need the flag

For a trigger and player capsule:

TriggerBox.GenerateOverlapEvents = true
PlayerCapsule.GenerateOverlapEvents = true

TriggerBox is Query Only
TriggerBox responds Overlap to Pawn
PlayerCapsule does not Ignore TriggerBox's object type

-> the pair can be tracked and dispatch Begin/End Overlap

If either Generate Overlap Events flag is false, the official component event contract is not satisfied. Setting only the trigger is a common mistake because the other Actor can have several Primitive Components with different values. Query the exact Other Comp, not just Other Actor.

The pair still needs a response that resolves to Overlap. When one side says Ignore, Ignore wins. When both sides truly Block, the interaction is a blocking hit rather than a trigger overlap.

What happens to an overlap that already exists?

Set Generate Overlap Events is not a raw bit write. On a live initialized component, changing the value enters the component's overlap-change handling and reconciles tracked pairs.

Change during an existing geometric contact Possible notification result
false -> true A qualifying current pair can be discovered and send Begin Overlap.
true -> false Tracked pairs can be cleared and send End Overlap.
Set to the value it already has No meaningful flag transition; do not use it as a “re-fire Begin” button.

“Can” matters because registration, collision participation, responses, the other side's flag, and valid shapes must still agree. The setter has no Boolean that says how many pairs changed.

The refresh can happen inside the setter's call path. Code that disables the flag from a Begin handler should be prepared for End/cleanup logic to run as the tracked pair is cleared; do not assume End must wait until a later Tick. Likewise, dynamically binding a handler after enabling an already-overlapping component can miss the Begin that the enable produced. Bind first or query the starting overlap state explicitly.

When an explicit overlap update matters

For a normal registered Primitive Component, toggling Generate Overlap Events already invokes the flag-change path; calling a full overlap query every Tick is unnecessary and can be expensive.

An explicit refresh is relevant when a different operation intentionally batches or defers collision changes:

  • Set Collision Profile Name exposes an Update Overlaps input; enable it when the new profile's responses/participation must immediately reconcile current pairs.
  • Runtime component registration creates its first live collision state; bind handlers before registration/enable when initial overlaps matter.
  • C++ systems that perform low-level/batched setup can call UpdateOverlaps() once after the final shape/response/attachment state, rather than after every intermediate edit.
  • After a deliberate deferred movement/collision workflow, query the final overlap set if gameplay cannot depend on event ordering.

Blueprint does not need a blanket “Update Overlaps every frame” workaround. Keep your own arrays, Sets, counters, and booleans at parity too: an engine End event cannot repair custom state that your graph forgot to remove.

Set Notify Rigid Body Collision

The node's C++-style name maps to a friendlier Details checkbox:

Set Notify Rigid Body Collision(true)
    == request rigid-body collision notifications
    == Simulation Generates Hit Events enabled for that body/component setup

This is for the physics solver contact route. A typical single-body setup is:

PhysicsMesh:
    Collision Enabled = Query and Physics
    response to WorldStatic = Block
    Simulate Physics = true
    Set Notify Rigid Body Collision = true

PhysicsMesh.OnComponentHit
-> handle future simulated impacts

The component whose On Component Hit listener should receive solver contacts needs notification enabled. The wall can remain a normal blocker without also requesting its own Blueprint hit callback.

Enabling the flag updates contact-notification/filter state for future physics processing. It does not manufacture an impact for a body already resting on a floor, replay a collision that happened before the call, or produce a matching “End Hit” when disabled. Hit is an impact/contact report, not a maintained Begin/End pair like overlap.

There is no matching general Blueprint getter in this grouped family. The setter is void. Verify the intended component/body setup in Details and prove the actual On Component Hit event with the live component name and Hit Result.

Physics hits versus swept movement hits

On Component Hit can be reached by two different routes:

Route Example Needs Notify Rigid Body Collision? Typical Normal Impulse
Swept movement Character Movement, Projectile Movement, Set Location with Sweep Not as the reason the movement code reports its blocking hit. Usually zero.
Physics simulation contact A simulating crate falls onto a floor or two rigid bodies collide Yes on the component that wants the solver-generated event. Filled for simulating bodies when available.

Both routes still need blocking collision. Teleporting a transform with Sweep off does not become a swept hit because the notification flag is true.

This distinction explains two common observations:

  • “My projectile hit event works even though Simulation Generates Hit Events is off.” Projectile Movement swept its collision component.
  • “My dropped physics mesh blocks the floor but On Component Hit is silent.” The solver resolved contact, but the component did not request notification.

Multi-body components

A Static Mesh Component is commonly one body containing one or more shapes. A Skeletal Mesh Component can have many bodies from its Physics Asset. One component-level setter or flag may not express the body selection you intend.

For skeletal physics, current Blueprint families include:

  • Set Body Notify Rigid Body Collision for one named body;
  • Set All Bodies Notify Rigid Body Collision for the body set; and
  • Set Notify Rigid Body Collision Below for a named bone/body subtree.

Choose one deliberately. Enabling only the component's main Body Instance and then expecting every ragdoll limb to report contact is not a safe assumption. Check the Hit Bone Name, My Comp, and Other Comp from the event.

Overlap tracking has its own Multi Body Overlap option. When enabled, a multi-body component can report individual body pairs, so one Actor pair may produce several component/body overlap notifications. Generate Overlap Events does not deduplicate those into “one event per Actor.” Filter body/component identity or maintain an Actor Set/counter when that is the gameplay meaning.

Welding can also move child shapes into a parent rigid body. After welding, the visually obvious child may not own the independent Body Instance or contact notification you expected. Diagnose the actual body owner.

What the setters return and how they fail

Node Return/output contract
Get Generate Overlap Events Boolean flag value. No success Boolean separate from the value.
Set Generate Overlap Events Execution continues; no success or changed-pair count.
Set Notify Rigid Body Collision Execution continues; no success or generated-hit count.

Common failure shapes:

  1. Target is None. Blueprint reports an invalid-reference diagnostic in editor/development play and skips the call. The pure getter can leave its default false, which does not prove a valid component's flag is off.
  2. Wrong Primitive Component. You enabled a visual mesh while the capsule, trigger box, projectile sphere, or physics body owns the collision.
  3. The other overlap side is off. Your getter returns true and Begin still never fires because the exact other component returns false.
  4. Collision mode/response is incompatible. Notifications are requested, but the pair cannot form the required Overlap or Block interaction.
  5. No registered collision shape/body exists. A flag can be stored without any live query or physics contact to report.
  6. Physics simulation notification is confused with a sweep. You toggle the rigid-body flag while the real failure is Sweep off—or vice versa.
  7. Multi-body selection is wrong. The root Body Instance is configured but the contacted skeletal body is not.
  8. Another setup step overwrites/rebuilds collision. Profile, registration, simulation, welding, or component recreation changes the live body after your call.
  9. Wrong machine. A client changes or observes only its local component, while authoritative contact happened on the server.

Failure is normally silence. The setters do not turn on collision, create a shape, start simulation, move the components apart/together, or retry.

The patterns everyone actually uses

Enable a pickup trigger at runtime

PickupSphere:
    Set Collision Enabled(Query Only)
    Set Collision Response to Pawn(Overlap)
    Set Generate Overlap Events(true)

PlayerCapsule:
    Get Generate Overlap Events -> confirm true while debugging

PickupSphere.OnComponentBeginOverlap
-> validate Other Comp / Other Actor
-> authoritative pickup logic

If the player is already inside when the pickup trigger is enabled, Begin can arrive during the refresh. Bind/implement the event before enabling, and query current overlaps if initial occupancy must be handled deterministically.

Enable impact feedback for a dropped physics prop

PropMesh:
    Set Collision Profile Name(PhysicsActor, Update Overlaps true as needed)
    Set Simulate Physics(true)
    Set Notify Rigid Body Collision(true)

PropMesh.OnComponentHit
-> inspect Normal Impulse
-> if impulse exceeds threshold:
       spawn local sound/VFX with cooldown

Threshold and cooldown prevent resting/jitter contacts from spamming feedback. Gameplay damage remains an explicit, authoritative decision.

The C++ twins, for the curious (our own example code):

Trigger->SetGenerateOverlapEvents(true);

PhysicsMesh->SetNotifyRigidBodyCollision(true);
PhysicsMesh->OnComponentHit.AddDynamic(
    this, &APhysicsProp::HandlePhysicsHit);

Bind dynamic delegates before a state change that can immediately discover an existing overlap.

Multiplayer boundary

Overlap lists, sweeps, and physics scenes exist per world. These setter calls change the local component copy. The flags are not Remote Procedure Calls (RPCs), and their private/body configuration is not a general replicated gameplay state.

For authoritative interactions:

server collision world detects qualifying overlap/hit
-> server validates actor/component and applies gameplay result
-> replicated state / RPC presents result to clients

Clients can enable local notifications for cosmetic prediction, sounds, or debugging, but they must not award pickups, damage, score, or ownership solely from an untrusted local contact. Physics correction, relevancy, different collision settings, and timing can make server/client events differ.

If a replicated state transition changes collision—Held to Dropped, for example—apply the corresponding local collision/notification setup from that state on each required machine. Do not assume calling the setter once on the client or server magically invokes it on the other copies.

What these flags do not do

  • They do not enable query or physics collision.
  • They do not change object type or any channel response.
  • They do not turn Overlap into Block or Block into Overlap.
  • They do not enable Simulate Physics, gravity, Continuous Collision Detection, or movement sweep.
  • They do not filter events by Actor, component, body, class, tag, team, or impulse strength.
  • They do not guarantee exactly one event per Actor or per contact.
  • They do not replay events that happened before a listener/flag existed.
  • They do not clear your own cached references, arrays, Sets, or counters.
  • They do not replicate the setter call or the gameplay consequence.

These are notification gates, not complete collision presets.

Lookalikes - which one do I want?

Node / setting Use when Important difference
Get Generate Overlap Events Diagnose this component's overlap-event flag. Does not query current overlaps or the other side.
Set Generate Overlap Events Start/stop overlap notifications/tracking for this component. Does not enable collision or choose Overlap responses.
Set Notify Rigid Body Collision This body/component should report future physics-simulation blocking contacts. Details label is Simulation Generates Hit Events; no past-event replay.
Set Body / All Bodies / Below Notify Rigid Body Collision A Skeletal Mesh needs explicit per-body/body-set selection. Multi-body scope rather than the component's simple body assumption.
Set Collision Enabled Choose Query, Physics, both, or neither. Participation, not notification request.
Set Collision Response / Profile Name Choose Block/Overlap/Ignore behavior. Pair policy; profile can refresh overlaps but does not replace event filtering.
On Component Begin / End Overlap React when a tracked overlap pair starts/stops. Event, not a setup setter or current-state query.
On Component Hit / Event Hit React to a blocking sweep or physics contact. Event source can be movement sweep or simulation.
Get / Is Overlapping Actors or Components Ask who is overlapping right now. Current-state query, not a transition notification.

Rule of thumb: responses decide what contact means; Generate Overlap Events requests pair Begin/End notifications on both sides; Notify Rigid Body Collision requests physics-hit notification on the listener's body.

Going deeper

  • Collision presets, channels, and responses - participation, object types, and pair response resolution.
  • On Component Begin / End Overlap - event pins, component-pair duplicates, filtering, and End cleanup.
  • Get Overlapping Actors / Components / Is Overlapping Actor - query current state after setup or refresh.
  • Event Hit - swept versus physics hits, Hit Result fields, Normal Impulse, repetition, and filtering.
  • Set Collision Enabled / Response / Profile Name - the separate participation and response layer, including Update Overlaps.
  • Set Simulate Physics / Is Simulating Physics / Set Enable Gravity - body ownership, skeletal body names, welding, and authority.
  • Replicate Movement vs replicated variables - why local physics/contact state is not the same as durable shared gameplay.
  • Official docs: On Component Hit and UPrimitiveComponent.
  • Engine source (requires engine access - we do not reproduce it here): UPrimitiveComponent::SetGenerateOverlapEvents, GetGenerateOverlapEvents, OnGenerateOverlapEventsChanged, UpdateOverlapsImpl, BeginComponentOverlap, and EndComponentOverlap in Engine/Source/Runtime/Engine/Private/Components/PrimitiveComponent.cpp; SetNotifyRigidBodyCollision and OnComponentCollisionSettingsChanged in Engine/Source/Runtime/Engine/Private/PrimitiveComponentPhysics.cpp; notification flags/delegates and multi-body overlap declarations in the matching Classes/Components/PrimitiveComponent.h; Body Instance contact filter state under Engine/Source/Runtime/Engine/Private/PhysicsEngine; and skeletal per-body variants in Private/SkeletalMeshComponentPhysics.cpp with declarations in Classes/Components/SkeletalMeshComponent.h.