SetActorRotation no longer works after SimulatePhysics is enabled

Hi all,

Fairly noddy issue I’m having some problems with.

I have a very basic cylinder with a sphere collision component to detect if a player gets close to it. When it does, it rotates around to face the player. This was all working well.

Whilst testing I start blasting the destructible floor and thought I’d see what happens if I took the floor out from under it. As it happens, nothing, that was when I realised I’d need to SimulatePhysics.

Having enabled that, the nodes which handled the rotation no longer seem to function. Turning off SimulatePhysics enables the rotation functionality again!

I’m assuming this is down to the actor no longer being kinematic, and is under the control of physics but there must be a way to rotate it still surely? I saw there was something about adding torque, but I don’t think that’s what I want, I want the rotation to end when its looking directly at the player.

I spotted one article from a couple of years ago which talked about having a “dummy rotation” component (scene component), having all of the other components under that, which then allow them to rotate those components. I didn’t find this approach worked for myself, as if I remove the staticmesh component from under its parent box collision component, you can see in the scene that the box collision component ends up led on its side, yet the mesh remains standing vertically, and not falling.

Any thoughts would be most welcome, and, as I’m fairly new to Blueprint, should you have time for a screenshot, that would be wonderful :slight_smile:

Hi @ClavosTech, thank you for the reply.

As it happened I did see your other response when searching through the forums, but, perhaps being new to Blueprint, I didn’t really understand.

This is what I currently have, it works, as long as the Collision component (*EnemyDetection) *doesn’t have Simulate Physics enabled;

BlueprintComponents.jpg

As soon as the Simulate Physics is enabled on the EnemyDetection component (Box Collision), it no longer rotates. I suspect this is due to conflicts between kinematic movement and physics, with the latter winning.

Any thoughts/advice?

Hi @ClavosTech, thanks for the reply and the info.

I will give the ideas you have presented here a go and see what happens.

Regarding the hierarchy of components, is there any “best practice” or just general advice on the structure for that? As an example, when I created the Blueprint, based on an Actor class, I added a Box Collision component and a Static Mesh component. Initially I added the static mesh as a child of the box collision, it kinda made sense to me that the boundary of collision detection was on the “outside” so to speak of the mesh. Later I noticed that the mesh itself had a collision section under details, I wondered then what the upshot of having collision detection on both the mesh and the separate component was, I think in the end I turned it off on the mesh and just left it enabled on the more primitive shaped collision component.

Perhaps part of my problem is that I am not parenting/childing the components in a way that is suitable for the kinematic rotation AND the physics to work together nicely.

I am implementing a Timeline in order to rotate this, my only current grumble is that I dont seem to be able to place it within a component, so it has to sit “outside” within the main Blueprint and then communicate back and forth with the component. I assumed “under the hood” a Timeline (which I seem to keep seeing recommended over Tick) is just running a Tick for all intents and purposes… there has to be something creating the loop etc.

Hey @ClavosTech, thanks for the reply and insights and of course the links, I’ll be sure to check them out, my apologies for the delay in responding. :slight_smile: