ProjectBorealis / PBCharacterMovement

HL2-style, classic FPS movement for Unreal Engine implemented in C++
https://www.projectborealis.com/movement
MIT License
1.27k stars 163 forks source link

Strange 'step up' behavior when jumping onto high enough platforms #21

Closed smt923 closed 2 years ago

smt923 commented 4 years ago

Video: https://streamable.com/dqi9vr

I'm just wondering if this is intended, or if its a bug? I've tried messing with all sorts of settings, the min/max step height, I've tried turning the MID_AIR_STEP stuff on and off, but this still happens regardless, is there a way to stop it happening? stepping up stairs would be and does work fine, but this seems to 'warp' the character up almost 40 units (you can see on the showpos text, normal jumping is fine but onto platforms it 'warps' up from 140 to 170) and just feels and looks really unnatural to me

mastercoms commented 3 years ago

I think we've fixed this internally but it will be a while until we can get an update out.

Ratchet7x5 commented 3 years ago

Hello! I know this issue has been open for a while. I did a small change when the default object for the PBPlayerMovement is constructed. I set this flag to false and it seems to resolve the issue. I cannot confirm if this can cause issues for the movement, but feel free to let me know. I've tried debugging this issue, but I'm new to Unreal Engine C++, so let me know if this isn't an ideal fix. Could be a good temp fix maybe?

Video Here: https://youtu.be/RuLlOod540E

Flag to set false: bUseFlatBaseForFloorChecks = false;

mastercoms commented 2 years ago

I can't tell if this is fixed in the partial update I have done here: 74791cb2b465c5b1e0b3bd9beb91ac1d6accf570

Didn't include all changes yet

Ratchet7x5 commented 2 years ago

Hi mastercoms, Thanks for the update! I appreciate it a lot.

I got a few errors here and there. I did manage to fix them though, I'm able to build my game (including the plugin) and play it just fine though I still see the strange step-up behavior occurring. I ran this on a source build of 4.27.2.

PBPlayerMovement.cpp(773): error C2065: 'Delta': undeclared identifier
PBPlayerMovement.cpp(776): error C2065: 'Delta': undeclared identifier
PBPlayerMovement.cpp(781): error C2065: 'Delta': undeclared identifier
PBPlayerMovement.cpp(1317): error C3861: 'GetCrouchedHalfHeight': identifier not found
PBPlayerMovement.cpp(1341): error C3861: 'GetCrouchedHalfHeight': identifier not found
PBPlayerMovement.cpp(1341): error C2737: 'FullCrouchDiff': const object must be initialized
PBPlayerMovement.cpp(1345): error C3861: 'GetCrouchedHalfHeight': identifier not found
PBPlayerMovement.cpp(1439): error C3861: 'GetCrouchedHalfHeight': identifier not found
PBPlayerMovement.cpp(1439): error C2737: 'FullCrouchDiff': const object must be initialized

The 'Delta' error is located in the function TwoWallAdjust(). In the header file, there's a FVector& Delta while in the cpp file the variable's name is different: FVector& OutDelta. Renaming this parameter to Delta in the cpp file fixes the error.

The GetCrouchedHalfheight() identifier not found is a missing getter function for the CrouchedHalfHeight variable, so I fixed it by implementing a simple getter in PBPlayerMovement.h.

float GetCrouchedHalfHeight()
{
    return CrouchedHalfHeight;
}

Here's a video: https://youtu.be/bAO06KUiM7s

mastercoms commented 2 years ago

Merely the crouching issue where i provided a solution was fixed.

because they apparently do not want us to let have what they have in their perfect trunk....

Hey azradric, mind if you cool it off a little bit? This is an open source project with different integration requirements vs. our private code. We would like to share everything, as much as we can, but releasing code requires very careful work to basically re-integrate it without extra dependencies. It's not a matter of us not wanting to share, it's the time needed to integrate code properly. Eventually we will release as much as is needed, don't worry, and I hope you see that the gesture of me coming into this issue to figure out if this issue is solved as us wanting to solve it. We just have to make minimal changes, enough to resolve issues, to minimize the work required to re-integrate changes. Plus, with such limited time vs. our priorities, I cannot commit too much time into open source releases myself, and rely on the community for guidance/testing.

mastercoms commented 2 years ago

@Ratchet7x5 Hi, it's not exactly clear what your inputs are to get some of these issues. Could you record a video with ShowDebug INPUT in console?

mastercoms commented 2 years ago

I understand that frustration, it isn't meant that we only drop that one fix and go, we are trying to make sure that we add enough to fix each issue. Thank you for understanding.

mastercoms commented 2 years ago

@Ratchet7x5 I think this issue is solved in 83a71bd74e8a4a351c7849ec6f3e986c28c2643a

mastercoms commented 2 years ago

I didn't move over some surface/slope handling code, but this should be good enough for now.

mastercoms commented 2 years ago

@Ratchet7x5 We have ported over most if not all of the latest movement behavior, and I can confirm that the other issues presented in your video are solved.

Ratchet7x5 commented 2 years ago

Thank you for being proactive in solving these issues. I really want to thank you for it.