Download

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:

It should work, see this example thread, so its most likely your setup. You may need to show a screenshot of your component hierarchy list to start…

But if you want to do this just using physics for now anyway (which I recommend as collision is more reliable as the linked above thread shows). Then, you can use one sequence to apply the turn such as Set Physics Angular Velocity, and then another to check the actual rotation: Get World Rotation, etc. So you can tell ‘are you there yet’ or when to actually switch the Blueprint turning circuit off etc.

Non-physics work is generally easier as Kinematic / Translated / Interp’d movement just applies a specific angle (or increments to the angle using RInterpTo to smoothly get there). Whereas Physics nodes apply a turn force. While you need your cylinder to turn around and face the player, its the same system as correcting a jet fighters roll etc (to make it easy to fly so it doesn’t roll out of control).

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?

Interesting… Some things to look at: 1. Reparent everything UNDER the collision box. 2. Reparent everything under the static mesh and set that to Simulate Physics. The latter is how I’d normally go about it. But then again I’d normally use a child collision box as a detection box rather than the main source of collision.

But they shouldn’t be fighting each other, as there’s no physics action being applied anywhere (in the screenshot anyway). But one other thing to try is to use a Set World Rotation node instead, and assign the most top level component to that.

The only other thing is the Timeline. That’s essentially a tick here. But I’m trying to predict how often that’s called, but I’ve no idea basically. Not a huge fan of Timelines anyway. You can’t copy them, and you cant debug them in a case like this without a float or vector output to look at etc. :stuck_out_tongue:

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.

Great question! I can throw example posts at you that may offer clues (1 / 2). But I’m not the best placed to answer this tbh. What you’re after are deep insights. I’ve struggled to get any useful depth when learning UE4. There is best practice for everything… However the docs / wikis aren’t that helpful, and video tutorials rarely go into that level of detail. I usually just assemble snippets from working examples, and build more complex things off that. But it would be better to have in-depth knowledge.

You do see the same patterns or approaches come up for similar problems all the time though. But is that just copying or actual best practice or it works for now - IDK… We need a level of deeper explanation in Unreal. The movement and collision issues / glitches alone are immense. With few practical resources, deep insight usually comes from delving into source or befriending someone who has. But there’s so much lacking in the UE4 learning space, especially best practice examples from Epic.

TLDR;
Dissect every BP example project you can find & make your own notes / observations… Dive into the deep end and get stuck into C++ / Engine Source.

Yes its definitely possible as hinted above, so its worth looking at other BP projects to see how they’ve done it… But my gut feeling is something else is a factor here…

There are a bunch of worthwhile Tick vs Timeline threads that you can search on. Even after reading them I don’t feel Timelines are worth it tho. The hassle just from not being able to duplicate or clone them between BP’s makes them worthless imho. Tick comes with a customizable update interval and an off switch at both component and actor level, (which you’ll most likely need anyway for performance / profiling / troubleshooting etc)… Plus there’s always Timers too…

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: