This has me totally baffled:
If I click play being in character blueprint window, I actually get correct values which I have specified in blueprint, but should I pop into level editor main window and play from there, character seems to use some other values as apparent from difference in movement.
This is a bug, because no matter where I click play, it should result in same logic being executed, correct?
What else than a bug would be a plausible reason for such difference in behaviour, depending on window where play in editor window is executed from?
P.S
difference is most apparent in how quick character stops running. If I click play in character blueprint window, movement reacts correctly, but if I click same play state being in main editor window, character doesn’t stop running.
I have imposed a lot of conditions on my axis values for keyboard and mouse controls, somewhere in middle of that process problem started.
Do you have a controller plugged into your PC? If so, please disconnect controller and see if same thing happens.
If not, or same problem occurs without controller, please reproduce close project, reopen it, and reproduce problem. Then, after closing editor again, get most recent log from project’s \Saved\Logs folder, it up, and attach it here. Thanks!
Thank you so much for a reply, this difference in behaviour has become my sole interest in past days and I’m still looking for its origin, any help would be well at hand!
here it is - most recent log, I think, never done it before, project itself is 10gig textures but I can share rest of it, only its really a lot of well documented logic in blueprints which I doubt is reason for this.
I notice I get fps lag now as well when playing from bp window, but playing same state from main window runs real smooth, (playing from animation blueprint window also gives same problems as playing from character bp window.)
this low fps when playing from BP windows is probably reason for character reacting differently to movement logic: 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 entire on fly flow thing
low fps in 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 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 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 same thing occurs in a First Person or Third Person template project and let me know.
If you’d like to share project, it’d be great to get you to delete Saved and Intermediate folders from project, then up whole project folder and upload it someplace like Google Drive. You can send me a link to download it via PM on forums, if you prefer privacy, or simply post link here if that doesn’t matter. My forums account is here:
I work on a laptop, I guess my only controller is a mouse, I am not using anything else but keys and mouse at all times.
I’m afraid it would be a great hassle to reproduce bug in a new project because of 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 final version of game, mostly stuff that concerns character. 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 character BP logic sufficiently by now to make this problem almost unnoticeable and I didn’t keep really buggy version, but bug is still there! (stuff I traced problem to was a rather complex speed and slope dependency on input axis values, I have simplified it and problem became less, but not obliterated.) I now presume that while interpolation speed may remain same during difference in fps, it might be axis values from movement input that differ. Also thank you for clarifying why there is a slight difference in fps at all when playing from different windows.
Update:
I have stripped my project of saved, intermediate and textures folders and have successfully tested bug to persist, then uploaded it to google drive and have sent you a private message on forums with link.
I consider biggest problem 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 character blueprint.
What I wanted to achieve was kind of stagger you’d experience when trying to stop quickly while running at full speed. I also made that depend on angle of slope character is moving on.
I had an issue where slope multiplier would revert to its base value during standing still on a slope, fixing that had no influence on problem of having different behaviour.
Okay, it does appear to only happen if BP editor isn’t open, even if Editor Viewport has focus. I’m guessing it has something to do with using World Delta Seconds in your calculations for Add Movement nodes, which must be different in those circumstances. I’ll investigate that a bit further and enter a bug report if necessary.
moving forward thing seems to be more of a project bug, so I’ll set that aside unless something jumps out at me as cause. key thing here is that debugging issue is problematic because of this difference between when 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.
I just found out that delta time given out by event tick in my character BP does indeed vary, depending on my frame rate. 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 technical department on 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 current problem clamps would only give me either maximum, or just 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 screen, or sharing screen through Skype, frame rate naturally drops a little, but unexpectedly also drastically affects my calculations. As you can tell from log, my machine is pretty powerful for today’s standards so I dare to exclude 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 render won’t appear before entire tick is complete, or something that would put a hard limit on whole thing, so variation in behaviour due to frame rate which I experience now would be minimized, without changing my current blueprint?
P.S.
Just uploaded is latest version of project, problem is very noticeable in this one. Sending link to your forum account .
Change quality settings to minimum from dedicated chain in character BP and 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 case, but maybe 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 undesired result. If you don’t see problem with this stripped version, I can try to upload whole 10gig project, because this thing is really getting in way of me building on top of current blueprint base.
Found a solution to mitigate problem which is described in posts above in detail.
solution is basically to take out 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 same with different frame rates.
I spoke with developers about 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 editor is doing more things.
So a couple things:
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.
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 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.
thank you very much for your help,
I have indeed been able to resolve 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
P.S.
I recently discovered that static value I used (0.0167) is very close to maximum time allowed per frame for physics calculations, which was set to 0.016, don’t exactly remember where, somewhere in project settings. Makes all sense now.
