4.5 preview: character movement regression

  1. The “Event Hit” event no longer gets triggered continuously while hitting the wall while falling (worked in 4.4). This does not seem expected behavior since it gets triggered continuously while hitting a wall if you are running on the ground too.

  2. The following change was made in 4.4:

Characters that are falling and impact geometry with an unwalkable normal can check for a valid landing spot and land if possible. Running and jumping up on ledges is more fluid. Previously the character would “float” for a bit before landing, which would lose velocity.

This change was really awesome but it seems like it does no longer work in 4.5.

EDIT2: I have uploaded a video showing the issue comparing 4.4 with 4.5 preview: https://www.youtube.com/watch?v=HQUaE88pAfI

It would be great if this could be fixed for 4.5.

Hi ,

I’ve tried to create the bug you are reporting in the 4.5.0 Preview. Using a static mesh for reference, the character continuously triggers Event Hits as shown in the attached image. Note that the “hits” were generated while the character slid down the wall until the character landed on the ledge. (The static mesh was a converted BSP box with “Add 26DOP Simplified Collision” applied, in case the issue you’re experiencing is related to your collision settings.)
If adjusting your collision (if applicable) does not resolve the issue, please provide more information on how we can better simulate your project in order to reproduce the issue on our end.

][1]
Thanks

Hey ,
thanks for your reply. It does indeed work with slopes but “Event Hit” event no longer gets triggered continuously with perfectly vertical walls while holding forward move button. This however happened before 4.5 and still happens on the ground while holding forward move button. PS: I am testing this on a first person setup but it should make no difference.

Hi ,

After your clarification I was able to recreate the issue in the latest build and have submitted a bug report.

If I hear back from the developers I will post their response here.

Thank you for your input.

Thanks , sorry for not being clear earlier. Please tell me if you need more feedback regarding 2) the step-up/edge-landing regression.

Hi ,

In regards to your second issue, I’ve created a scene with a small ledge to jump up on to in both the 4.4.3 and latest build and in both instances there seems to be an equal amount of “hang time.”

However, I may not be reproducing your exact scenerio… If you could provide some steps to reproduce and perhaps even a screen shot I might be able to reproduce the issue more accurately on this end.

Thanks

Thanks again . It looks like this was an issue on my side due to the games climbing code not working as expected because of the first issue. It looks like the step-up/edge-landing part is indeed exactly how it used to be. Sorry for the trouble.
EDIT: After testing it out some more I actually again believe that there is an issue with step-up. See my comment below.

Actually I have to redact my last statement. There is indeed an issue regarding step-up and I am now able to reproduce it.

Please see this video: https://www.youtube.com/watch?v=HQUaE88pAfI

On the first two jumps (at 4.4) the character smoothly steps up the ledge. On the last two jumps (at 4.5 preview) the character does not make the step up as smooth. This happens when you jump up a vertical wall and still have enough upward momentum to be able to step up a bit after the first hit. I believe that it is an extended issue of issue #1 since it seems that it doesn’t check being able to step up every frame anymore on vertical walls similar to how event hit isn’t being called every frame anymore.

Hi ,

Thanks for taking the time to create the video depicting the glitch. I was indeed able to reproduce the issue and agree it is related to the “hit” not being continuously triggered on a vertical surface. I have entered this information (reference TTP349200) in our bug database so that it may be fixed in a future release. If any further information is needed, please let me know.

Thanks.

I’m looking in to issue 1.

As for issue 2, it may be related, but I don’t think so initially. The change for 4.4 was to change the movement mode from falling to walking earlier, if we could potentially walk at the given location. The character used to deflect upwards a bit and continue falling, then only land when moving downward, but after the change it was allowed to land as long as a vertical floor check succeeded on any impact. It’s possible the Velocity is getting affected upon landing though, there were some related changes to how Velocity is computed during falling movement, and that could be something I can fix.

Issue 1:

It does indeed work with slopes but “Event Hit” event no longer gets triggered continuously with perfectly vertical walls while holding forward move button. This however happened before 4.5 and still happens on the ground while holding forward move button.

There was a bug in 4.4 that allowed air control (input acceleration while falling) onto unwalkable slopes, that was fixed for 4.5. The bug fix was important because it would allow you to push your way up unwalkable slopes if the AirControl was set high enough. Because of this, we don’t let you push forward into unwalkable surfaces. When you slide down, we kill your air control but gravity causes you to continuously hit the slope so you still get hit events.

There are a couple side effects that need improvement: you’ll notice that if you stand next to a vertical wall and jump straight up and push toward the wall, you don’t move at all laterally. This is something I hope to address. However 4.5 exposes some new C++ virtual functions to make it easier to override this behavior to your liking (the code used to all be within PhysFalling): GetFallingLateralAcceleration, GetAirControl, FindAirControlImpact, LimitAirControl.

Those last two are probably of interest to you if you want to tweak the behavior.

Hey Zak, thanks so much this was a very interesting read. I have now overridden GetAirControl to not limit air control anymore (commented out the whole block) which interestingly fixes both issue #1 and issue #2. I am very keen to see how you plan to improve this behavior. Thanks a lot and let me know if you need any more feedback.

Hey there, just wanted to update you and let you know that I’ve made improvements to the code so that it now allows air control toward unwalkable surfaces, but with some extra safety checks to make sure you can’t wall climb or climb up unwalkable slopes. This will be included in the next release.