Hello everyone!
I have just started using Unreal Engine 5 recently and have been tampering with the Third Person template Unreal provides when either creating a new project or by adding a content pack manually after the fact. I am unsure if this is a bug or me not understanding the new Enhanced Inputs but I am seeing weird behavior when setting Jump Max Count higher than the default (1) on the BP_ThirdPersonCharacter.
When inspecting the BP_ThirdPersonCharacter class and selecting the BP_ThirdPersonCharacter (Self) Class Defaults, I am only changing the Jump Max Count value to 2. When I click play to test double jump, holding the jump key with each jump results in infinite jump height until released for the first jump. The second jump after is normal and will not result in infinite jump height while being held.
Note
- This is with version 5.1.1.
- No other settings aside from the Jump Max Count are being touched.
- This is reproduceable with any number greater than the default with infinite jump height on all jumps up until the last.
Blueprint Screenshot
Issue Video
If I switch the Enhance Input to standard input action node, it works with no issue.
Blueprint Screenshot
Deprecated Input Action Video
Is this a bug with the Enhanced Inputs or is this a beginner misunderstanding to how this new feature works?
Thanks to all in advance!
1 Like
Hey there @TheEt3rnalL1ght! Welcome back to the community! This is intentional! When there are multiple jumps, you need to have some form of delimiter, until StopJumping() is called, the jump will continue forever! However, you can limit the length the player can hold jump by this value:
This automatically calls stop jumping after that time has elapsed. However if you’re still holding jump and haven’t modified the default input action, it will continue running that timer for every jump count. So if I have 3 jumps, and Jump Max Hold Time is 1 second, the player will continue jumping for 3 seconds then fall unable to jump again.
2 Likes
Thank you so much for your reply!
So if I am understanding things correctly, the Jump Max Hold Time is a time that is shared between all allowed jumps. In the example you provide, 1 second per jump with 3 jumps gives them 3 seconds total of potential jump time depending on how one jumps. Here are some sample scenarios I’ve been running to attempt to understand how these values work:
- If the player only jumps once, then they have the full 3 seconds they can jump for if holding down the button.
- If the player jumps and releases, then jumps again while in air, one jump is consumed so they now have only 2 seconds remaining
- Same scenario where the player jumps and releases, jumps and releases again, they now only have one jump left meaning only 1 second.
- Any variation of hold times in the mix of reaching the max time results in no more jumping meaning if they hold the input during any one of the jumps, they are allowed up until the hold time per jumps remaining is met or reach the Jump Max Count
Is this a correct understanding?
If so, how do I replicate the behavior seen with the deprecated input action jumping? Basically allowing a max jump time per jump that isn’t shared across the whole jump action sequence. So in our above scenario, if I jump with a max jump hold time of 1 second with 3 total jumps, I can only hold for the 1 sec and it stop me at that second not cutting into my ability to jump 2 more times for a total of 1 second each.
Is this possible with the enhanced input action pins? Or is this custom behavior that will be needed to be written?
Reason I ask is because I modified the hold time to .2 as shown in your screenshot suggestion, even lower such as .01 to get a jump velocity applied similar to using the deprecated input actions but using values that low results in the player unable to jump more than 1 time when set to more than one jump since the hold time is reached immediately.
Pins referring to:
Any guidance and suggestions would be much appreciated for understanding the other pins as well.
Thanks again in advance to all!
1 Like
UPDATE
Immediately after posting this last reply, I had thought to start printing strings out of the Started pin instead of the Triggered pin. This led me to change the Jump call to be from Started pin which results in the exact behavior I described as the desired end result.
(Spent about an hour writing that previous reply and testing what I thought was everything I could with the other pins and reading the documentation before posting. Tunnel vision got me good. lol)
Follow-up
Confirming the previous initial question of whether or not I have a correct understanding of the Jump call from the Triggered pin would be wonderful.
Any pointers to understanding why the difference in behavior between which pin is used to call this simple action would also be wonderful. Documentation isn’t the clearest to my beginner status on what these different pins will result in and why so figuring out their correct usage is where I’m struggling at this point.
Thanks so much!
1 Like
No worries! You’ve got it right. Though depending on how your input action is setup, you get a couple of interactions. By default (tap and release):
Triggered: Context sensitive in that it can change, by default (tap and release) it will be continuous, so it results in the 3 jump in a sequence issue.
Started: Only fires when the event is fired (in tap and release this would be on tap) (what I’d recommend using over triggered but you figured that out)
Ongoing: for most contexts it just means it’s still happening.
Canceled: Is when the criteria for the input were not met, like press and hold not making it to the hold time.
Completed: if the input event is done being evaluated
Did swapping it to started work out?
3 Likes
Evening!
This is great insight! This helps confirm my understandings so far of how these new enhanced input actions are designed to work. Much more to learn as I dive into other actions desired in my testing and projects.
Yes switching to using the Started pin instead of the Triggered pin on the Enhanced Input Action node for my Jump action resulted in the desired behavior:
- Behavior the same as the now deprecated Input Action nodes with a character class Jump Max Count set to 2 with no other modifications prior to the introduction of Enhanced Input Actions in 5.1
or more detailed
- A double jump where each jump could be tapped and released, held and released, or any combination of the two for the Jump Max Hold Time without jump lockout or a shared cumulative time between the jumps.
Thank you so much for your quick responses, nurturing suggestions, and helpful guidance. Look forward to chatting again with any and all!
2 Likes
Another option, if you want to stick to using just the Character Movement component, is creating a ‘Kill Jump’ function that sets the Character Movement Z velocity to 0 when the player lets go of the Jump button. Out of the Completed node, you check if the character has a positive Z velocity (ensures character is jumping upward, not falling downward), and if that is true you run the Kill Jump function.
Cheers if this helps anyone 
