UE4 Cube Mesh Not Colliding using SetRelativeLoc

I switched a few of my meshes to UE4 cubes and the collision stopped working. I made several changes during this process. So I wasn’t able to identify the root cause. I decided to create an empty project for debugging. I have a timeline which sets the object location. I have tried the following.

1.) Blueprints directly in the map
2.) Static meshes moving within a blueprint
3.) Child actor components moving within a parent blueprint

Settings

  • Everything is set to blockAllDynamic.
  • The default root scene has physics (“should update physics volume”) checked
  • I tried calling SetRelativeLocation with and without sweep enabled
  • I verified that the collision volume is correct

Is this an issue with driving an actor/mesh with SetRelativeLocation? I expect it is a simple setting, but I haven’t found it after rooting around. I found this related question but there was no answer.

[Collision is not working between static meshes when using set actor location][1]

I have attached the entire basic debugging project (2.5 MB).[Collision Debuging Project UE4.9][2]

Update 1

Please note that the extra timeline in bpPlayer was for testing the blueprint directly within the map instead of as a child.

I forgot to mention that I enabled physics on the top cube and removed the SetRelativeLocation timeline. The top cube drops and correctly collides with the bottom cubes. However, it doesn’t work with either set location or transform. I also tried explicitly enabling collision in the constructor (see below). This didn’t work either.

Update 2

I found the following post in the forums. Zak Middleton (Unreal Engine Developer) responded as follows to a similar question.

[Proper way to move an Actor / Collision Not Working][4]

Zak Middleton (Unreal Engine Developer): The issue here is that the CollisionComponent is not the RootComponent. When you use SetActorLocaiton(…), that sweeps the RootComponent, and teleports attached components, so they don’t get hit events (only overlaps). You need to set the collision component as the root instead.

I found this to be an interesting tid bit about the RootComponent. However, it didn’t help me.

I used the blueprint to test collision. I tried various versions of the SetLocation (Actor etc…) and Transforms as well. I tried it with and without sweep enabled.

I forgot to mention that I enabled physics on the top cube and removed the SetRelativeLocation timeline. The top cube drops and correctly collides with the bottom cubes.

It’s possible that my simple debugging project was corrupted. I tried to delete one of the blueprints to start over and it said that there were 99 references in memory.

I created a new project using the information I found in my Update 2 and the collisions are now working.

Proper way to move an Actor/Collision not Working

Zak Middleton (Unreal Engine Developer): The issue here is that the CollisionComponent is not the RootComponent. When you use SetActorLocaiton(…), that sweeps the RootComponent, and teleports attached components, so they don’t get hit events (only overlaps). You need to set the collision component as the root instead.

I have attached a simple working project with the collision working using SetRelativeLocation. I hope this helps somebody else because I wasted 1/2 a day researching this topic and experimenting.

Bare Bones Project with Collision using SetRelativeLocation (3.9MB)

It’s possible that my simple debugging project was corrupted. I tried to delete one of the blueprints to start over and it said that there were 99 references in memory.

Can you elaborate on this a bit? Are you saying that the “99 references” was a sign that the Blueprint was corrupted, or that the corruption came from deleting the Blueprint? Also, what signs lead you to consider that your Blueprint had been corrupted?

Thanks for sharing this info!

Mike I attempted to delete the blueprints to start from scratch but it claimed that there were still references to the blueprint in memory. The references the editor claimed were attached to the blueprint were long since gone. In fact, I had no references to the blueprint. As you guessed this was an indicator that something might be wrong with the project itself. In C parlance it seemed to think there would be several dangling pointers without the blueprint but I had no instances.
I suspect the cause was when I attempted to scrub proprietary names from objects in an effort to sanitize it for public posting. I may have done a force delete. I’m not sure how it got in that state though.
An additional minor point. There were 4 alleged references to bpPlayer. 99 was a typo.