This is for the Enemy to move toward the third person character in a beat em up style game. In the Get Unit Direction (Vector) node the From is like Point-A, where as To is Point-B. In this example it is set to fire essentially as fast an Event Tick (actually a hair faster at .001). So my question is…what governs the “speed” in this code? I briefly tried a float to plug in the scale value…but at single digits and around 10 or so I did not see any effect. Maybe it needed insanely high numbers, but I think there is still something else.
Are you trying to move faster or slower? If you want the speed to be slower, you would want to set it to .5, .005 etc. Basically anything below 1 but above 0 will be slower, above 1 will be faster, and below 0 will be reversed. 1 is your baseline, default speed.
Any additional specifics may go a long way in solving your problem.
The movement component on the pawn; Max Walk Speed in case of a character’s Character Movement Component. Floating component if it’s a pawn. It should be Ticked, it accounts for frame-rate.
actually a hair faster at .001
That’s not a hair. Isn’t this 1000 per second? Movement vectors are frame-accumulated and applied as acceleration. By Firing it faster than framerate, you’re doing yourself a disfavour, I think.
Not 100% what the real drawback is, though - best case scenario, it’s just A LOT of wasted performance.
Well, I want to have the normal walk speed yes, but I also want to have running speed so the enemy can dash attack. So if it requires either 1 or 0, I suppose I would have to crank up their max walk speed and run it lower, .5 and less etc etc. Thanks for the tips.
Ahh ok, so add a floating pawn movement component?
But doesn’t an Event Tick fire @ .008? But you can clear an invalidate a timer, I don’t think you stop an event tick (
Haha, well if you need to check something many times a second, where an event tick would be typically used, why not just use a set timer by event and a custom event? Would that not be as efficient as an event tick?
Perhaps then, I need to discover whats the lowest time I can get away with and it still look pretty smooth.
Ahh ok, so add a floating pawn movement component?
We’d need to find out what that Pawn in the pic is and what it’s supposed to do. A floating movement comp is one way to move a Pawn, yes.
No. It fires every frame, depending on the frame rate. And it generates delta seconds, which tells you how frame-time fluctuates. You can either Gate, Stop or slow down Tick.
Do you need to check something 1000 times per second where you can observe the result 60 times per second ony for a 60th of a second? There are reasons for doing something faster than the frame rate. Let’s say you fire a mini gun very fast and want to account for every bullet.
Perhaps then, I need to discover whats the lowest time I can get away with and it still look pretty smooth.
60 times per second? It does not matter, you’ll get an update when the movement component updates. If your game is running at a sluggish 20fps, updating the component 100 per second does nothing good.
Use a timer if that’s more convenient, but 0.001 really does nothing here but eats up cycles.
It is a copied third person character, a typical jobber enemy in a beat em up game is its use.
Ok.
No, I just want it to work right.
Let me ask you then, I just changed from .001 to .25 in that timer, and the enemies stopped moving to the player and just walked in place. Off the top of your head what do you think went on there?
Any reason why you’re not using navmesh and have the AI walk up to where you need it to be. Then you only need to tell it once to start walking and maybe update it twice per second if the player is moving. I think the AI can also move to Actors directly, so there’d be no need to update anything. As in:
Line 2 not much is going on here just checking if they overlap the camera actor so they can move (else every enemy on the map comes to me at begin play).
Line 3 I discovered I had to use a gate else there was many oddities like downed players sliding on the floor toward the tpc and such. Some checks for various things here. Like if the TPC’s capsule is above or below, left or right to the enemy position. For movement experiments I have tried (Macros shown here will be show later). Some nights this was a lot more complicated, I have just condensed it down cause I could really use your help here.
Line 4 is where you have the instant turn left and right for the enemies that is essential to beat em up games in general. And the ability to null it when needed like a downed player for example.
As before, movement needs updating, ideally, as often as every frame, like it says on the node. If the game runs at 60 frames in a second, with a timer .25 you do:
frame 1 - movement
frame 2 - stop
frame 3 - stop
frame 4 - stop
…
frame 15 - movement
frame 16 - stop
frame 17 - stop
frame 18 - stop
…
frame 30 - movement
frame 31 - stop
frame 32 - stop
frame 33 - stop
…
and so on. You will generally mostly stay in place as the movement comp tries to apply acceleration for 1 frame only and then spends 14 frames slowing to a stop. It’s a weird setup, tbh.
With a timer .001, it’s all wasted:
frame 1 - movement
frame 1 - redundant update we can’t see or measure
frame 1 - redundant update we can’t see or measure
frame 1 - redundant update we can’t see or measure
frame 1 - redundant update we can’t see or measure
frame 1 - redundant update we can’t see or measure
…
1000 times per second. So you get what, around 16 wasted updates every frame @ 60 frames. Do note that Timer does fire in between frames, faster than the frame. It has its uses, this is not it.
Well, I’m trying to do their movement myself and not the built in stuff.
You do you.
So my question is…what governs the “speed” in this code?
To bring it back to where it started - the node you’re using does not control movement speed above 100% of what the movement comp can do, afaik. Scale only works in the -1<=>1 range. Think thumb-stick on a controller.
Characters have a movement component where you can set all kinds of variables, dynamically, too. The movement input tells the pawn a direction and scales input and the pawn interprets that input using a component that does the heavy lifting.
See here is the thing, it doesn’t really matter if its 1000 times a second or 5 times a second, I was just looking at it from the view of if it has to have it then it has to. I was under the impression that Event Tick fired at .008. Based on what you have told me here today, then it is a considerable difference, and a very wasteful one. I turned on show FPS in the top left of the view settings and UE5 is reporting it is running @ 120 fps with a lag of 8.33 ms. So then Event Tick would fire 120 times a second. So I will try to use the Event Tick as the main firing source.
It seemed well at first, then I noticed that after the TPC was knocked down the enemy walk speed changed to be slower. I then searched for all “set max walk speed” and though none of them looked to actually be receiving fire, I deleted them all just to be sure. The problem remained.
So I then went and looked for the first branch that checks if the TPC is knocked down. Which is right here in the line 3 of the enemy movement code.
If out of the true there is nothing, they (the enemies) will just stand still indefinitely. So I added a move up macro I had made the other day just for testing purposes. You can see its effect in the video. But why is it moving slower after the branch (TPC knockdown / TPC death check)?
IF that event tick is replaced with the set timer by event firing @ .001, the slow down does not occur after the knockdown. Why does this happen in your estimation? Thanks
Before it was lacking a connection on Z. Granted I do not understand why that matters as Z is not needed here. But it was a mismatch, An Event Tick driven circuit that was seeing X, Y, AND Z, to where it just had X, and Y to work with, resulting in the slowed down enemy movements.
