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 Hitevent 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
IsInsideBoolean/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:
- Target is
None. Blueprint reports an invalid-reference diagnostic in editor/development play and skips the call. The pure getter can leave its defaultfalse, which does not prove a valid component's flag is off. - Wrong Primitive Component. You enabled a visual mesh while the capsule, trigger box, projectile sphere, or physics body owns the collision.
- The other overlap side is off. Your getter returns true and Begin still never fires because the exact other component returns false.
- Collision mode/response is incompatible. Notifications are requested, but the pair cannot form the required Overlap or Block interaction.
- No registered collision shape/body exists. A flag can be stored without any live query or physics contact to report.
- Physics simulation notification is confused with a sweep. You toggle the rigid-body flag while the real failure is Sweep off—or vice versa.
- Multi-body selection is wrong. The root Body Instance is configured but the contacted skeletal body is not.
- Another setup step overwrites/rebuilds collision. Profile, registration, simulation, welding, or component recreation changes the live body after your call.
- 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, andEndComponentOverlapinEngine/Source/Runtime/Engine/Private/Components/PrimitiveComponent.cpp;SetNotifyRigidBodyCollisionandOnComponentCollisionSettingsChangedinEngine/Source/Runtime/Engine/Private/PrimitiveComponentPhysics.cpp; notification flags/delegates and multi-body overlap declarations in the matchingClasses/Components/PrimitiveComponent.h; Body Instance contact filter state underEngine/Source/Runtime/Engine/Private/PhysicsEngine; and skeletal per-body variants inPrivate/SkeletalMeshComponentPhysics.cppwith declarations inClasses/Components/SkeletalMeshComponent.h.