[Bug] UFPS: Jump ability cancelled early on high frame rates

Justy

New member
1. Character controller variant: UFPS
2. Unity version: 2022.3.29f1
3. Bug description:
- Discussion thread: https://discord.com/channels/476506682382483456/478012956899147797/1250499421465219173
- Jumping ability is cancelled early in a build, but not in the player. It appears to be frame-rate dependent from my perspective.
- The jump would work when moving, but most of the time not when jumping stationary
- Changed the value in this line to * 100 and the bug no longer occurred. I am guessing that with a high enough framerate the character does not get high up enough for the grounded raycast checks to consider it ungrounded, and then the jump is cancelled
1718229991684.png
1718230058097.png

This might not actually be that important since once more things are added the framerate will drop and then it should work - but it does mean that certain combinations of jump force and raycasting distance for ground detection would be problematic - so other use cases involving slow jumps (maybe like in space) could potentially run into this.

Video example: https://streamable.com/ew78ti

4. Steps to reproduce from a fresh project:
- Have an empty world to maximise FPS
- Create a new character from the wizard - you might need to use the most stripped down character model possible. I could not reproduce this when using the Atlas demo character
- Create build
- Jump!
5. The full error message (if any): n/a
 
Thanks for the repro steps. This is interesting, that 10 in their is a magic number and has worked for years. I do think that your inclination is correct. I wonder if we can make it a little smarter. Instead of just checking the grounded state try changing the if condition within EnsureAirborne to:

Code:
            if (!m_CharacterLocomotion.Grounded || m_CharacterLocomotion.LocalDesiredMovement.y > m_CharacterLocomotion.ColliderSpacing) {

I have a framerate of ~150fps with an empty character and haven't been able to reproduce it so the code is more of an educated guess but I like this solution better than changing the magic number.
 
Thanks for the reply and the idea!

I tested the above line on a build and it did not fix it - about 20-30% of the jumps worked.

A fix for this isn't needed for me right now since I can just tweak the number and hope it doesn't affect anything else - but if you want me to test any other potential solutions just let me know
 
Hmm, what is the value of m_CharacterLocomotion.LocalDesiredMovement.y when it doesn't work? Also, are you jumping with a collider directly overhead so there's not any space to jump or is it completely clear?
 
There is no collider overhead; completely clear.

Failed jump:
(Filename: .../Assets/Opsive/UltimateCharacterController/Scripts/Character/Abilities/Jump.cs Line: 340)
m_CharacterLocomotion.LocalDesiredMovement.y: 0
m_CharacterLocomotion.ColliderSpacing: 0.01

Successful jump:
m_CharacterLocomotion.LocalDesiredMovement.y: 0
m_CharacterLocomotion.ColliderSpacing: 0.01

Code implementation:
1718391332512.png
 
Well that wasn't helpful :D

What is the framerate that you're seeing when it doesn't occur? I'm thinking that we could change the scheduler so EnsureAirborne gets called based off of the framerate rather than a constant.
 
I tried again now and have made too many changes that I cannot reproduce it now :s (which is a good thing I guess, but also not for fixing it!)

based on the above graph it looks like around 600fps or so is the area, but can't be 100% certain, sorry
 
Back
Top