Low FPS values shorten jump height, but lengthen timers?


While messing around with editor scalability settings (in a hope to stop my fans from running like crazy 24/7) I stumbled upon the command to limit FPS; t.MaxFPS #. Shortly after, I noticed that my jump height and timers were not the same depending on framerate.

I don’t do anything special; no adding velocity without taking deltaseconds into account which is what i’d expect to cause this phenomenon. I have a simple jump, with a jump hold time set via the Character variables in the ThirdPersonCharacter panel:


My jump looks like this:


But when jumping, this is the result I get depending on framerate:

The jump gets lower along with the framerate. Strangely, I have noticed the opposite with timers. I have a simple test function (it was originally a diveroll ability), where on button press, a timer is started (the length of the roll), the player’s deceleration and friction are set to 0, and their velocity is set to a value once. When the timer fires, the roll stops, and the player’s velocity is set back to 0. Here’s what came of that (capsule started from the LEFT, resting against stairs):

And the function itself, triggered ONCE from button press:

What am I doing wrong? Messing with physics substepping, max delta time values, etc didn’t change anything. Any feedback would be very helpful.

I fixed the jump height issue (as far as I can tell) by unchecking this flag:

It does the opposite of what it claims to do when ticked: makes the jump height frame-rate dependent. Perhaps this is something EPIC needs to update? I’ll report back if I fix my other problem.

I fixed the timer issue.

The solution was to increment my own timer on tick, adding delta time to it, then checking it immediately after to see if it has exceeded “stoproll” time. The order here is very important: if the check for the timer is moved before incrementing, the roll inconsistencies come back. This leads me to believe that UE4 timers don’t tick until after the player blueprint does, leaving them to be a tick behind when firing their function.

That said, is there a way to change this? Some setting somewhere I missed? Or will I need to make a bunch of my own timers in tick? (not ideal needing a bunch of branches evaluated every tick)


Is this at all related to the Timer usually executing on the next frame???
What engine are you using versus the way the Timer node looks here?


Is this at all related to a default Timer executing on the next frame maybe???
What version of the engine are you on, versus the way the Timer looks here?


This was indeed because of the timer executing on the next frame. It was a frame late on calling the “stop roll” function, and a single frame at high deltatime caused the inconsistency. I didn’t know it did this. I am using UE4 4.25. I use set timer by function instead of event.

Is there a way to change it to check before the player blueprint runs?

How do you mean ‘change it to check before the player blueprint runs’… Check what exactly? :confused:

Check that it has finished, and call its function. A way to change the tick order. If it is a frame late on calling its function, i’d instead like it to increment and immediately check if it exceeds the time limit, like what happens in the first image. The second image seems to be what happens currently.

is there no way to eliminate this frame of delay from timers? If I was confusing before, I’m sorry. I’d just like the timer to instantly call its function when it ends, similar to the way a manual timer on EventTick would work.

The answer is in the thread I linked dude… Look closely at the screenshots. Specifically how the negative **Initial Start Delay **offsets the positive Time value. Why were things done this way? Well previously with the old node, entering zero into the Time param would just cancel the timer outright. So this is the fix apparently…Note, I haven’t tried it personally, as I 'm still stuck on 4.18. But its supposed to fix this issue iirc. :wink:

Thank you, I will look into this.

thank you for directing me to that thread; I learned a useful trick with timers. That didn’t actually fix my problem, though. The issue is not that **the timer starts late. The issue is that, after the timer finishes, there appears to be a frame delay before it calls its function, or perhaps a frame delay before it tells the player it has finished. This delay is allowing my roll to have one more frame’s worth of delta time influence it when it shouldn’t be, so instead of stopping at the right position, it ends up with variance in the end position. **I tried setting start delay to -1 frame at target framerate, but this made no difference on the outcome. Please keep in mind that my roll is started by button press, and only stops moving when the timer runs out, so I don’t want the “roll stop” timer to fire its function immediately after the roll is entered. I think we both misunderstood each other earlier XD. I posted pictures and perhaps a better example in that thread you linked me!

Since it seems like there isn’t a way to fix this, I will be going with my own EventTick() timers, despite that being a huge inconvenience. I was told by a user on r/unrealengine that I could use timelines also, but needing essentially a new component every time I want to set a timer is ultimately much worse on performance and memory than if I just made my own. Timelines are further inconvenient because they can’t be called from functions, and require custom events instead if I want to cut down on blueprint graph clutter.

If I had few timers, this wouldn’t be an issue, but I have many things such as cooldowns, buffer windows, counters, etc all using timers at the moment, and I can’t afford to have any of these frame-rate dependent. Very unfortunate, because I want to use UE4’s timers! :frowning:

EDIT: Here is a reproduce-able example of what I mean: