Different movement logic when playing from different windows

This has me totally baffled:
If I click play being in the character blueprint window, I actually get the correct values which I have specified in the blueprint, but should I pop into the level editor main window and play from there, the character seems to use some other values as apparent from the difference in movement.

This is a bug, because no matter where I click play, it should result in the same logic being executed, correct?

What else than a bug would be a plausible reason for such difference in behaviour, depending on the window where the play in editor window is executed from?

The difference is most apparent in how quick the character stops running. If I click play in the character blueprint window, the movement reacts correctly, but if I click the same play state being in the main editor window, the character doesn’t stop running.

I have imposed a lot of conditions on my axis values for keyboard and mouse controls, somewhere in the middle of that process the problem started.

Hi Polivantage,

Do you have a controller plugged into your PC? If so, please disconnect the controller and see if the same thing happens.

If not, or the same problem occurs without the controller, please reproduce close the project, reopen it, and reproduce the problem. Then, after closing the editor again, get the most recent log from the project’s \Saved\Logs folder, zip it up, and attach it here. Thanks!

link text

Thank you so much for a reply, this difference in behaviour has become my sole interest in the past days and I’m still looking for its origin, any help would be well at hand!

here it is - the most recent log, I think, never done it before, The project itself is 10gig textures but I can share the rest of it, only its really a lot of well documented logic in the blueprints which I doubt is the reason for this.

I notice I get fps lag now as well when playing from the bp window, but playing same state from the main window runs real smooth, (playing from the animation blueprint window also gives same problems as playing from character bp window.)

this low fps when playing from BP windows is probably the reason for the character reacting differently to movement logic: the delta time interpolations return different results because of low frame rate(!could it be?). Anyway I would love to have some consistency in my previews, this thing disrupts the entire on the fly flow thing :slight_smile:

The low fps in the main Viewport during PIE if focus is in another editor window is normal. I don’t expect it would affect any difference in movement because tick is not affected, just fps. Still, I don’t know how your movement is set up and I’m not entirely clear on what specifically is going wrong. Do you have a video of what’s occurring?

It might be helpful to see the project so I can fully grasp your BP setup, but before you send anything along, can you answer whether you have a controller plugged into your PC when this occurs? If you do, and you unplug it, does that resolve the issue (in a fresh PIE session)? Any other input peripherals (wacom tablet, oculus, etc)?

EDIT: if at all possible, can you test this in a template project? See if the same thing occurs in a First Person or Third Person template project and let me know.

If you’d like to share the project, it’d be great to get you to delete the Saved and Intermediate folders from the project, then zip up the whole project folder and upload it someplace like Google Drive. You can send me a link to download it via PM on the forums, if you prefer privacy, or simply post the link here if that doesn’t matter. My forums account is here:


Dear Ben,

I work on a laptop, I guess my only controller is a mouse, I am not using anything else but the keys and the mouse at all times.

I’m afraid it would be a great hassle to reproduce the bug in a new project because of the huge amount of animation and character logic I have built.

I would also like to keep it private, in terms of assets as I have put a lot of time into their creation and plan on using some of them in the final version of the game, mostly stuff that concerns the character. The logic I have put a lot more time into, but that’s free for anyone to learn from :).

Yet I should emphasize that I have reworked the character BP logic sufficiently by now to make this problem almost unnoticeable and I didn’t keep the really buggy version, but the bug is still there! (The stuff I traced the problem to was a rather complex speed and slope dependency on the input axis values, I have simplified it and the problem became less, but not obliterated.) I now presume that while the interpolation speed may remain the same during difference in fps, it might be the axis values from the movement input that differ. Also thank you for clarifying why there is a slight difference in the fps at all when playing from different windows.

I have stripped my project of the saved, intermediate and textures folders and have successfully tested the bug to persist, then uploaded it to google drive and have sent you a private message on the forums with the link.

Hey Polivantage,

I got the project. Just to be clear, is the problem that the character can sometimes continue running forward?

I consider the biggest problem the difference itself, between either continuing to run a short while during “play in new window” clicked from main editor window and almost not continuing to run when I “play in new window” from the character blueprint.

What I wanted to achieve was the kind of stagger you’d experience when trying to stop quickly while running at full speed. I also made that depend on the angle of the slope the character is moving on.

I had an issue where the slope multiplier would revert to its base value during standing still on a slope, fixing that had no influence on the problem of having different behaviour.

Okay, it does appear to only happen if the BP editor isn’t open, even if the Editor Viewport has focus. I’m guessing it has something to do with using World Delta Seconds in your calculations for the Add Movement nodes, which must be different in those circumstances. I’ll investigate that a bit further and enter a bug report if necessary.

The moving forward thing seems to be more of a project bug, so I’ll set that aside unless something jumps out at me as the cause. The key thing here is that debugging the issue is problematic because of this difference between when the BP Editor is open and closed during PIE. I’ll also check to see if I can find any suitable workarounds and let you know.

Thank you so much for your help,

I just found out that the delta time given out by the event tick in my character BP does indeed vary, depending on my frame rate. The difference is just a few decimals, but it has a significant impact on my movement with my current setup. I understand that event tick is not supposed to change because of frame rate changes. Hence I think it should be considered a bug after all.

Before any action is taken from the technical department on the Unreal’s side, is there anything I could do to mitigate this difference, since all interpolation require delta time, how could I keep values constant without relying on clamps, since with the current problem clamps would only give me either the maximum, or just the minimum, depending on my frame rate, thus depending on a lot of things which must have no impact on my gameplay mechanics.

For example, I found out that setting my reflections and shadow quality to maximum also effectively has impact on my character’s deceleration rate, through frame rate drop I presume. When I’m recording the screen, or sharing screen through Skype, the frame rate naturally drops a little, but unexpectedly also drastically affects my calculations. As you can tell from the log, my machine is pretty powerful for today’s standards so I dare to exclude the hardware performance issues. Still, even for an old computer, I would consider this a bug.

Is there some way to force my tick calculations into a predefined time frame? So that the render won’t appear before the entire tick is complete, or something that would put a hard limit on the whole thing, so the variation in behaviour due to frame rate which I experience now would be minimized, without changing my current blueprint?

Just uploaded is the latest version of the project, the problem is very noticeable in this one. Sending the link to your forum account Ben.

Change the quality settings to minimum from the dedicated chain in the character BP and the character won’t stop running. (deceleration interpolation speed too low), but change them to maximum and he halts much too quick even for my taste of things. I presume quality settings to affect frame rate, at least when running with textures it is the case, but maybe the stripped version I’m giving you is just too light (without textures) to exhibit this behaviour, I tried to record a video, but every time I try to record screen, my frame rate drops sufficiently to totally disrupt my movement logic, so I couldn’t record anything, but the undesired result. If you don’t see the problem with this stripped version, I can try to upload the whole 10gig project, because this thing is really getting in the way of me building on top of the current blueprint base.

Found a solution to mitigate the problem which is described in the posts above in detail.

the solution is basically to take out the real delta time from all interpolations which have to do with my axis inputs and replace them with a static number. Although it doesn’t give accurate results (that’s what delta time is for) It works much, much more the same with different frame rates.

Heya Polivantage,

I spoke with the developers about the difference, and they said this is pretty expected. World Delta Seconds is going to be different depending on Frame Rate, and a higher FR is going to happen in PIE if more of the editor is doing more things.

So a couple things:

  1. Generally, relying on frame rate for game mechanics is dangerous. This will make your game function differently on different machines. It looks like you’ve already discovered this based on your notes above.
  2. If you DO need to use frame rate dependent values for mechanics, you might consider using Project Settings > General Settings > Use Fixed Frame Rate. I tried it in your project, however, and it did some surprising things and did not really resolve the issue, so I think there’s more going on in your project that makes this setting an invalid option for you.

Please let me know if you have any other questions.

I’ve been struggling with something similar… on this thread

and the solution for me was changing the component tick group from “During Physics” to “Pre or Post Physics”… I don’t know if it helps in your case

thank you very much for your help,
I have indeed been able to resolve the issue by not relying on delta time and just using a static value in some of my interps, it had me for quite a while though trying to get a grip on this :slight_smile:
I recently discovered that the static value I used (0.0167) is very close to the maximum time allowed per frame for physics calculations, which was set to 0.016, don’t exactly remember where, somewhere in the project settings. Makes all the sense now.