The problem I’m encountering is that a trigger volume (Box Component) is receiving OnComponentBeginOverlap and OnComponentEndOverlap events for the same component, continuously (one begin overlap and one end overlap event each frame).
Background:
I am working on building an interactible system for PlayerActors to detect and interact with objects in the world.
The PlayerActor has a trigger volume component for detecting interactible objects nearby. The trigger volume is setup to “Generate Overlap Events”, “Query Only”, and is setup to overlap with associated collision types.
I’ve also created an Interactible Component with an InstancedMeshComponent parent (since that’s the first available parent component with collision I could find). It has “generate overlap events” enabled, Query Only", and is setup to overlap with associated collision types.
I’ve successfully used this setup to build some simple interactibles objects that use the Interactible Component. The trigger on the PlayerActor detects the interactible component’s just fine, and everything works as expected.
Now onto my problem:
I’m trying to add my Interactible Component to a custom actor derived from the Wheeled Vehicle. As stated above, when I move the PlayeActor nearby the vehicle, I see an OnComponentBeginOverlap event fire for my Interactible Component attached to the vehicle (as expected) and then immediately receive an OnComponentEndOverlap event for the same Interactible Component. This continues, with both events firing every frame while I stand such that the Trigger and Interactible Components overlap.
Both objects are stationary (once they move into the initial overlapping position)
I’ve begun expirmenting with the “Should Update Physics Volume” flag on the Interactible Component and it’s parent components, with no noticeable effect.
I suspect the Wheeled Vehicle is the key to the issue I’m seeing, but I’m out of ideas for why
I have the same problem. I have a sphere collision attached to my pawn and whenever it overlaps something it will fire constantly both the begin and end overlap functions until I move away.
I managed to track down this issue to the InstancedMeshComponent I was using as the parent for my Interactible Component, after stepping through the debugger.
The flow goes like this:
UPrimitiveComponent::UpdateOverlaps() gets called for the ‘trigger volume’ component and detects the overlap with the InstancedMeshComponent.
This is a new overlap event, so UPrimitiveComponent::BeginComponentOverlap() is called
Inside BeginComponentOverlap() the new overlap event is broadcast to the InstancedMeshComponent
At this point, both components have recorded the overlap and everything is as expected
UPrimitiveComponent::UpdateOverlaps() is now called for the InstancedMeshComponent
Detecting overlaps internally eventually calls UPrimitiveComponent::ComponentOverlapMultiImpl() on the InstancedMeshComponent, which is where the bug occurs.
InstancedMeshComponent does not store it’s collision information in UPrimitiveComponent::BodyInstance. Instead it uses it’s own separate container so it can have multiple body instances. However, it does not override the virtual function UPrimitiveComponent::ComponentOverlapMultiImpl() to correctly use the BodyInstances it is maintaining.
Since UPrimitiveCoimponent::BodyInstance is invalid, there is no overlap, and an OnComponentOverlapEnd event is generated.
1-8 now repeat again the following frame.
This seems like an UE4 bug to me with how InstancedMeshComponent is currently implemented.
My Solution:
My solution to avoid this problem is to not used the InstancedMeshComponent as the parent of my Interactible Component in the first place. It never really made sense anyways, but I was trying to avoid making a custom C++ component. But alas, I created a C++ component that derives from the box component and is Blueprintable, and now everything works as expected.
Final Thoughts
There really should be Blueprintable components that derive from UPrimitive much further up the chain than UInstancedMesh (mesh, box, etc.). I can see many common scenarios where making a custom Blueprint Component that has collision information would be extremely useful/required. Is there some potential danger with exposing some of those base components to Blueprint, or is this maybe just an oversight?
I posted an update with my solution, which hopefully helps. If it doesn’t apply to your situation, post some more details and I or someone else may be able to help.
I had the same problem using the Advanced Vehicle Template. I simply put a collision box around the Static Mesh I wanted to have the Begin & End Overlaps with and now everything is working perfectly fine. All in Blueprints.
Yeah I actually ‘fixed’ it by subclassing UInstanceMeshComponent and overriding ComponentOverlapComponentImpl to check the instance bodies. Overlap seems to work (more) correctly now.
@AJQuick I “fixed” it too by implementing that function. I’m now getting overlaps, but they aren’t correct all the time. They come in and out when I move, so it’s quite easy to stop moving and have the number of overlapping actors print “0”. I also implemented “OverlapComponent” and “ComponentOverlapMultiImpl” to no avail, though I’m pretty sure those are needed too. (Copying SkeletalMesh).
I’m a bit stumped this big of a bug exists… Any other ideas I should try? I’m about to debug it further…
I’m still having a similar issue in 5.2. Begin overlap and end overlap events fire every single tick for some actors when they are moving through a collision volume. Not sure what is going on.
In case this helps anyone else: I ran into the same problem with begin and end overlaps occurring immediately after each other, and in my case the problem seems to have been caused by a custom movement component I was using.
Basically I have a component which I attach to various actors, which moves them at a consistent pace during gameplay (it “scrolls” them basically), and then they each do whatever additional movement they want on top of that. My custom movement component would apply a world offset during tick. In the call to apply the world offset, I left the default of the bSweep parameter to false. I suspected that this may have had something to do with it, so I set this true and voila! It works now! So I guess think about whether you might need to enable sweep on any of your movement commands.
