#Fixing Jump Inconsistency

1 messages · Page 1 of 1 (latest)

signal rose
#

I've been trying to set up some movement code to get myself back into the swing of things in Unity. The issue is that 1 in every 10 or so jumps is unusually higher than the others. It also seems to differ in the build? The big jumps seem to be default in the editor, but the neutered jumps seem to be the default in the build.
https://hatebin.com/vwllsdmlpr
I think the offender might have something to do with the implemented dynamic jump features. I read online that it has something to do with putting that stuff in Update() but that doesnt seem to apply here. So, idk whats going on.

#

I am sort of convinced that this might be a fixedUpdate/Update function problem

#

but... I havent see anything yet that would cause this inconsistency

solar valley
#

is it a dynamic RB?

signal rose
#

Yes

#

let me know if you need editor screenshots for values and stuff

solar valley
#

right now, you are setting velocity in update

#

that information won’t even get used until the next physics sim

#

for jump input, I recommend logging a timestamp of the last time the jump button was pressed. Then interpret that timestamp only in fixed update

#

ie when jump is pressed, timeLastJumpInput = Time.time;
in fixedUpdate, if timeLastJumpInput + jumpBufferTime > Time.time => register valid jump input

signal rose
#

One time force applications are always weird to me, because I was never sure which Update they needed to be in

solar valley
#

physics simulation ONLY ever happens after fixed update

#

part of why you have it strange here is because you use the old input system, which only detects a button press if you manually check in Update

indigo shale
solar valley
#

because fixed update happens exactly once right before physics sim

signal rose
solar valley
#

while you could have 1-5 Update calls before Physics sim

solar valley
indigo shale
#

0-5 😝

solar valley
#

player movement is always complex. learn it on something simple

#

i don’t recall if Update must also be called on the fixed frame

signal rose
#

The little bit I tried on character movement wasnt too bad, so far I think its just the syntax I need to have figured out

solar valley
#

anyway, that is what I can immediately see here

#

it might not be why you have the big jump, but it is a good starting point

signal rose
#

I was about to ask what about this makes the jump inconsistent

#

It is generally good practice to separate input and physics regardess though

solar valley
#

yes. right now it is a mess and you are not in control

#

and as long as you are not in control of the situation, you will not be fixing anything

signal rose
#

I set up a bool to flag whether or not the player is jumping to bridge between Update() and FixedUpdate()

#

Seems a bit wasteful and weird but well see if it works

#

okay I guess not

#

I would try doing some debug.logs but I dont know where I would put them that would acquire relevant information

indigo shale
#

I guess you can "remove features" until it gets consistent or something like that

#

The friction thing that you're doing might have some effect, and you're not changing it in FixedUpdate.

signal rose
#

Oh you could be right I never bothered to check that

#

Also I cleaned up update() for everyone's convenience and put the groundchecks and other checks into their own function

#

Nope, seems the friction stuff is irrelevant.

#

Would it benefit to have that in FixedUpdate()?

indigo shale
#

Not sure. It is physics related, so seems like a good place

#

Could it be anything like "you're detecting ground while you're still in the air, so sometimes it jumps more (because it hasn't hit the ground yet)?

signal rose
#

Actually I dont think it would, because its a physics property. The consequences of those friction changes are still being enacted in during the physics sim. So it isnt a direct effect to the physics.

indigo shale
#

Do you get the high jump if you give it half a sec between jumps?

signal rose
#

Not only is the jump height difference different from the ground check length but I make sure to land the character fully before jumping

#

The difference in jump height is like 2 units white the protruding ground check is like 0.2 units

indigo shale
#

Yeah, that's a lot of difference

signal rose
#

If that was the issue, the height difference in jumps would only be 0.2 units

#

Part of me thinks its the result of the dynamic jump

#

On the way downward, extra gravity is applied to the character. Also, to sharpen the peak of the jump parabola the Y velocity is dampened when the spacebar is let go.

#

I think one of these could be the culprit.

indigo shale
#

So, remove and see 🙂

solar valley
solar valley
# 
private const float JUMP_BUFFER_TIME = 0.1f;
private bool JumpInputActive => timeLastJumpInput + JUMP_BUFFER_TIME > Time.time;```
#

this works for both new and old input systems

indigo shale
#

That's a cool additional feature, but unrelated to the issue at hand

solar valley
#

it is related because setting a bool flag makes it harder to manage, and make sure it is being set correctly

indigo shale
#

It can't be simpler than a bool flag, really

signal rose
#

I was gonna say the same thing.

solar valley
#

because there are frames where you are not pressing jump, but also should not be setting Jump from true to false

solar valley
#

because you only write data when you observe input.

indigo shale
#

Okay, that's a fair point, still not related to the problem though

solar valley
#

a bool flag requires you to also set it back off to prevent double jump commands, and turning it off with other misc doodads

signal rose
#

For now

solar valley
#

in general, when you press jump, i expect rb y velocity to be set, and this should be the only thing needed

signal rose
#

I just want to fix the problem. Optimizations and other things are an afterthought at the moment

solar valley
#

and this velocity set should be done late in the frame, so few other thing can fuck with it

signal rose
#

Maybe put it on lateupdate?

solar valley
solar valley
#

also, since it is a dynamic rb, any collisions it has during the physics sim step can change that velocity

#

so if i set y vel to 5 in fixed update, physics sim might set it to 10, so the fixed frame ends with y vel of 10

#

and this is because it is a physics-affected object

indigo shale
#

You're holding space throughout the whole jump, right?

signal rose
#

Yea, I'm measuring the full jump.

solar valley
#

also, turn off all your slope logic rn

#

you are not in control enough to do any slope logic. that needs to come AFTER you have basic jumping

indigo shale
#

And show latest code after 😋

solar valley
#

for releasing jump, I would also do the same timestamp thing, btw

signal rose
#

What does the slope stuff have to do with the jump?

indigo shale
#

It adds force, which on slope may affect y

solar valley
#

actually, i think your slope logic is already off

#

your speed control method also modifies Y velocity

#

we want to minimize the number of points where your variables get changed. period

#

my player movement script is like 1200 lines of code. I directly write velocity 5 times, once at the end of each of 4 mutually exclusive types of jumps, and once at the end to enforce terminal velocity

#

if you constantly modify velocity, you don’t know wtf is going on, because you lose control over what functions changed that number at what point in time

signal rose
#

Okay I went and neutered everything relevant, and it seems we've got consistency now

#

10/10 full jumps were good

#

tested it on the build

#

Gonna add stuff back slowly to locate it one sec

solar valley
#

in general, your methods should have more variable arguments in and out, instead of private void Function()

signal rose
#

Its the speed control

solar valley
#

called it

signal rose
#

LOL

#

Let me double check to see if it isnt both

solar valley
#

it isn’t

signal rose
solar valley
#

you need to be using documentation btw. your code is totally undocumented, and that will be a big problem

signal rose
#

Figured a couple seconds of testing is worth more than a couple potential hours agonizing about it in visual studio lol

#

Elaborate on "documentation" because Im not sure I know what that means fully

indigo shale
#

Good code doesn't need documentation i say 😋

solar valley
#

///<summary>Set the player’s rigidbody velocity to be no greater than the given terminal velocity.</summary>
private void EnforceTerminalVel(Vector2 velocityLimits) {

signal rose
#

What do the summary tags do?

solar valley
#

in visual studio, when you mouseover the name of the function (wherever you use it), the tooltip will show whatever text is in the summary

indigo shale
#

Is already obvious by the name, come on

solar valley
#

without the summary tags, that will not happen

signal rose
#

Ohhh thats pretty neat

#

Ill make note of that

solar valley
signal rose
#

Only having a comment at the top of a function is okay on a teeny script like mine, but a pain in the ass later on when it gets big

indigo shale
#

When you type /// in VS it'll automatically create the tags for summary, return type and params

solar valley
#

it should be clear what your code does by just looking at it, with as few comments as possible.

#

but i still expect almost every function to have a docstring like that to explain wtf it does. And some variables might need them if they are a bit more complex

indigo shale
solar valley
#

It needs documentation if it's a library and others need to use it (many others!)
fixed that for you

signal rose
#

A comment is apt for when you're looking at the function itself
A summary is good when you're looking at where it's being called but dont know why

solar valley
#

the most likely person to need to read and understand your code is yourself 1 month to 3 years in the future, looking back to understand wtf you did

signal rose
#

100%, I've been trying to comment more

#

my old stuff was wayyyy messier and was completely without comments

indigo shale
#

I guess if it helps you - cool.. 90% of the time it's a pointless struggle to keep the docs updated for pretty much no one to read because small personal project that you'll abandon in a month 😅

#

At least that's been my experience 🤷‍♂️

signal rose
#

Idk, a summary seems like just as much effort as a comment tbh

solar valley
#

the documentation for a function should not be changing very much

signal rose
#

anyways, speed control is fucked up

solar valley
#

documentation tells you what a variable/method is SUPPOSED to do. and how it is SUPPOSED to be used.

#

if this is changing a lot when you find bugs, then your docstring is bad

signal rose
#

I don't know why SpeedControl() is messing things up though. I purposefully left out velocity.y

solar valley
#

well idk what speed control does. in part due to a lack of documentation

#

and I’m not going to sift through a function to follow all the shit it does just to try to figure out the intention

signal rose
#

Basically, if the horizontal speed is too much, we try to constrict it within the bounds of the set runSpeed

#

The drag part is irrelevant afaik

indigo shale
#

Might be an issue that you're mixing forces and setting velocity. I can't remember if one of those canceled the other in some way. 🤔

signal rose
#

Is there a cleaner way to restrict the horizontal speed without writing to the rb.vellocity?

solar valley
#

the simulation will automatically calculate: velocity += force * deltaTime / mass, right before it simulates

solar valley
signal rose
#

so this is an appropriate time for it?

solar valley
#

these need to be very carefully managed, and writing velocity is risky when multiple different methods compete to do it

#

dashes are also a good time, because dashes usually override all other behaviour to a fixed path

signal rose
#

I dont understand though, I used the rb.velocity.y for the Y value when writing it

#

so it should be unaffected

indigo shale
#

I think it cancels some downward force you're adding with addforce

#

Maybe 🤷‍♂️

signal rose
#

Okay so the big jumps are normal in the editor

#

and when things are working in the build, ALL jumps are big jumps
as intended

#

when its not working, 90% of the jumps are smaller

#

So it seems like the upward force is being canceled

solar valley
#

remember physics sim does vel += force * deltaT / mass

#

if you set velocity, but still have force, the force gets applied on top of that

#

(at least for 2D, it is not instant)

signal rose
#

Im gonna try to not mess with the velocity like that, and just control the speed by not allowing more running forces if the speed is too high

#

that way im not meddling with it directly

#

Regular movement seems normal, but the jumping is still inconsistent

#

is the speed dampening not the problem?

#

I used the same speedcheck as the one in SpeedControl()
I also disabled everything but the drag stuff in SpeedControl()

image.png
indigo shale
#

wasn't speed control the problem?

#

am confused... did solve the issue with speedcontrol, and if not - what's the code there currently?

signal rose
#

Yes but I took away the thing from speed control that caused the issue(Supposedly)

#

SpeedControl would restrict the speed by setting the velocity directly
I disabled that and made it so that the movement just wouldnt apply new forces if the character was too fast

indigo shale
#

and jump is still inconsistent?

signal rose
#

Somehow

#

Which is baffling, considering we honed it down to that specific part of the SpeedControl() function

indigo shale
#

show code

signal rose
#

I was just thinking that

#

one moment

#

Line 126 is where it checks if the player is going too fast

#

I think I'll be taking a break. Partially because I have chores to do, partially because I've been racking my brain against this for a bit too long.

#

Thanks for your collective patience. I'll probably be back on this issue later tonight.

#

🫡

indigo shale
#

I'd remove the part about slopes and check again

signal rose
signal rose
#

I'm so confused, I tested it and the speed control was the problem

#

why does the problem still persist?

signal rose
#

What sucks about this the most is I cant even have my friends playtest the movement because the jump doesnt work ;-;

signal rose
#

most recent code

swift mountain
#

...just a suggestion, unrelated

#

you show a video of you 'testing' it against an obstacle.. where, your physics / ground check code might be getting twerked wrongly, thereby causing you issues...

now im not going to doubt your logic that heavily... But i would advise you test it properly away from objects that will allow you to 'jump twice'

#

..also id make a a kind of 'debug output' that tells you the height, of your character when the direction of it's vertical velocity changes...
..in world-position-number format so you don't have to be looking at the screen lol...

signal rose
#

The jump is the exact same whether or not contact is made with a wall

signal rose
swift mountain
#

sure thing pal, its your time to waste

#

it makes it easier to have it printed out and to know the difference.. youd also get a figure, so if it was a pattern, like its always 10% more.. that would clue you in maybe.. its more evidence for such minimal investment

swift mountain
#

good luck

signal rose
#

I dont need to know the difference in jump sizes. That information is irrelevant, because the problem is the fact that the jumps ARE different sizes.

swift mountain
#

..i mean your problems are numerous

#

you shouldnt be affecting velocity directly at all

#

and you shouldnt be doing it in the update, you should be doing it in fixed update.

#

but this stuff is covered in the most basic of basic tutorials... so, yea... carry on!

signal rose
#

You could've said that straight from the beginning without the condescending tone and everything.

swift mountain
#

sure

#

but i didnt

#

You'll also note, i started out by saying:
" ...just a suggestion, unrelated "

which suggests, i know what im telling you.. wont fix your issue.. its just a helpful hint to make testing easier and more 'emperical'

#

as opposed to 'sumtimes i fink the jump is biggerer cus look at the way he clips onto this higher up obstacle (trust me its not related to any other physics interactions just take my word on that) '

#

now thats condescending.

#

😉

signal rose
#

And certainly not helpful

swift mountain
#

Im just trying ot save you from chasing your tail

#

if you've never ran into a bug that you thought was caused by one thing.. but was infact caused by another.... kudos to you, you must be a very successful software engineer / tester

signal rose
#

You don't need to be so rude to someone that's just trying to iron out a bug they're dealing with. You're acting like I'm some cockroach because I don't code the exact way you do.

swift mountain
#

idk, cockroach is projection

#

ive not directly insulted you yet.

signal rose
#

The tone from beforehand is just unnecessary

swift mountain
#

would you like me to?

signal rose
#

I would like for you to find something better to do than waste my time and patience

swift mountain
#

well you seemed like you were asking for help and then you started saying that i was being 'offtopic' when i wasnt.

#

so either you didnt understand its relevance... or.... idk really...

#

you need to step back maybe and view the larger picture lol

#

im trying very hard to be polite now

#

again, good luck to you...

#

i will leave you be now lol

signal rose
#

Well at this point I dont want your help since you've proven to be more of a nuisance with your rude tones and unhelpful messages

swift mountain
solar valley
signal rose
#

Dont worry Loup your tone wasnt nearly as bad lol

#

you're just trying to give me an objective analysis without any extra unneeded sass

swift mountain
#

what can i say im sassy. xD

dusky ember
swift mountain
#

LOOK MAW IM INTERNET FAMOUS

signal rose
#

I completely commented out the "Sharpen and define jump peak" part alongside the friction stuff in Checks()

#

stilll some weird jump behavior

#

Is there anything other than those two things that could be affecting physics in Update()?

#

Like I mentioned before, I think the friction stuff is actually PROBABLY fine, because its a physics property and not an actual direct manipulation of the rigidbody

indigo shale
#

Last version you showed does the jump in Update

signal rose
#

Unless thats the one you're talking about.

indigo shale
#

It is, yes

signal rose
#

...one moment lol

indigo shale
#

🙂

signal rose
#

No, a flag is set and then the jumping is handed off to fixed update

indigo shale
#

yeah, I remember you said that

signal rose
#

Does that not work?

indigo shale
#

Ah, I misread a bit

#

You're doing the key-up handling in Update, which does set velocity

#

and it shouldn't

#

but that's probably not the issue

signal rose
#

I commented that out for the time being

indigo shale
#

👍

#

I'd say - go with the same approach as yesterday

#

remove things until it starts working or in the other direction

signal rose
#

Yeah, been slowly picking away at things

#

I'd be lying if I didnt say I wasn't a little embarassed that this bug is taking me so long to deal with

indigo shale
#

honestly, there isn't anything that screams "problems!!!" to me... and I've done a reasonable amount of physics stuff...

#

I'd recommend you move drag and physics material changes to fixed update as well

#

just go by the sometimes annoying rule that physics stuff must be in fixed update... I know that not everything needs to be, buuut it's the safer option

signal rose
#

Considering I can just slap the friction stuff with the drag handling in SpeedControl() its probably worth it lol

dusky ember
signal rose
#

Oh definitely, but I mean in the context of my own standards. I've done good character controllers before, this one is just taking longer I suppose!

indigo shale
#

I did a CharacterController once (that I still want to put in the store at some point), and I made a debugger that allows you to log and see per-frame values and what changed what in the past 500 frames, because every now and then it misbehaves and debugging that is just so annoying! 😄

signal rose
#

You could attach a separate diagnostics script to avoid cluttering the original movement scripts

indigo shale
#

kinda-sorta... mine is "modular" so has like 30 components 😄

#

supports 2D and 3D (theoretically)... that was fun! 😄

signal rose
#

LOL yeah I've been there- obsessed with modularity and whatnot.
My controls for the current project is inspired by the movement in Overgrowth

indigo shale
#

Modularity is awesome 😛 But... only sometimes 😄

signal rose
#

Also, I moved all the potentially bad physics stuff to fixed update

#

not sure why I thought it'd be a pain

#

Still, the stunted jumping remains ;-;

indigo shale
#

Oof 😄 kill more code then! 😅

signal rose
#

What killed the performance in that project was the disgusting use of Invoking functions. That was responsible for like 80% of my optimization efforts.

indigo shale
#

I would say it's great for anything that you wanna... compose. So, if you want a large variety of things that you can easily make once you have the low-level pieces - it's great

#

"invoking functions"?

signal rose
#

yeah, it was my way around the annoying ienumerators

indigo shale
#

oi oi oi 😄

signal rose
#

I dont like em! There I said it

signal rose
#

With that in mind, I try to use it sparingly from now on

#

You make a normal function, but just call it in a different way.

indigo shale
#

I highly dislike it, tbh

#

Uses strings, that's enough for me to not use it ever 😄

#

I'd rather coroutine or async

#

And you can make a single coroutine method that is like... public IEnumerator InvokeDelayed(float delay, Action action) that does the delay and invokes your custom action... and you can make another one that wraps it and does StartCoroutine and whatnot, to make it even easier

#

It's gonna be 10 times more performant, and not use strings

#

(Of course, if one cares about performance, one must measure it first and then measure other options and all that... )

signal rose
#

I used the easy option

indigo shale
#

I... just have a problem with strings being used that way 😄

signal rose
#

So I've weeded out all the physics stuff being done in update

#

and the only two instances of me writing to the velocity are the jump and the velocity dampening

#

What if I did something silly like this in order to cancel the Y velocity before jumping. Instead of writing over it.

#

Still the same.

#

I guess that means writing to the velocity isnt the problem.

#

Okay something notable happened, I messed with the last value in this line. That affected the jump height

image.png
#

I still dont know why though

#

it was .05, I changed it to .03 and now the jump is shorter

#

Wait... nevermind???? I messed with it some more and nothing happened

indigo shale
#

show latest code 🙂

signal rose
#

Sure thing

#

hatebin isnt giving me a link to paste in here

#

one moment

solar valley
#

don’t do any of that coroutine nonsense in playermovement. just use the timestamp method

#

coroutines will make everything much more complex, and that is the opposite of what you need right now

signal rose
#

Agreed, we were just talking about our preferences between coroutines and invoking though.

solar valley
#

point being, there is a lot to do here, and yet you keep coming back without changes.

signal rose
#

That's sort of the point, we're just taking things away one at a time to see what is or isnt working. We are hitting the limit of things to do that with though.

solar valley
#

I expect before you next return to see docstrings and no physics in Update. Because it seems to me like you are looking for a “quick fix” that solves your current problem, without being interested in doing a proper long-term solution, an approach which I cannot endorse.

signal rose
#

We already figured out that the writing velocity thing in Update() isnt doing anything wrong.

solar valley
#

ok. that’s great. don’t do it

indigo shale
#

👆

#

It's probably fine, still - don't do it 🙂

signal rose
#

not what I meant one sec

solar valley
#

you are trying to make it work because you see nothing wrong, despite knowing that this is not how it should be done. And this approach is why you continue to fail

#

Nothing will change until you decide to change it.

#

Because I know once you get it to work while having the rb vel change in update, I guarantee you will plan to leave that change in Update.

#

Which, and I can’t stress this enough, is wrong

signal rose
#

I've kept it in MyInput() for right now because it was behaving differently in any of the FixedUpdate() functions

indigo shale
#

ah... you need a thing... yeah...

signal rose
#

so instead of going on a tangent to fix that I wrote something down and decided to push ahead

indigo shale
#

you need a bool for it

#

no, no, that's not a tangent, it's physics-related

#

and you've been having physics-related problems for a while 😛

solar valley
#

do the timestamp method

#

just log timestamps in Update, and don’t do anything with them.

signal rose
#

Well I guess I have no other avenues to explore right now

solar valley
#

Then in fixedupdate, you use the timestamp info to know what to do

signal rose
#

I guess I've been trying to go about this the subtractive way. Try to take away the problem as opposed to adding something to circumvent it.

indigo shale
#

You shouldn't try to add something to circumvent it, before you know what's causing it

solar valley
#

you need to be willing to destroy parts of your work which are wrong, or you will never succeed as a programmer

indigo shale
#

honestly, destroying broken parts and replacing them with working ones is the best! 😄

#

well, no, deleting code is the best 😄

signal rose
#

LOL its not that I want to keep the bad code, it that I wasnt sure if that was the bad code that was causing the root issue.

indigo shale
#

well it should've been the first thing to fix 😛 because it shouldn't be there and there's no reason for you to try to keep it there

solar valley
#

over the past day, we have explained all of the issues with your code. You understood what we meant. You left, you came back feeling like you hit a dead end. Your code has none of what we discussed.

#

The code is not unchanged because you tried and failed to change it. The code is unchanged because you were unwilling to change it.

signal rose
indigo shale
#

To be fair, sometimes it is best to not touch unrelated parts and focus on one problem at a time... but this is just way too close to said one problem 🙂

#

So, yeah, lets see if that helps 😄

signal rose
#

Right, I kinda wanted to focus on one thing at a time. Not to mention that I'm being urged to implement the timestamp thing. Which I dont understand just yet.

solar valley
#

stop trying to salvage, and just change it

signal rose
solar valley
#

ok. then i’ll see you in several hours to a day then lmao

indigo shale
#

I'd say just kill that feature

#

until your jump works well

signal rose
#

I actually had it commented out for a little bit.

indigo shale
#

until. your. jump. works. 😠 😄

signal rose
#

I know! It just means I'll be commenting it out until then!

#

Not recycling it for later I mean

#

just storing the idea

indigo shale
#

yeah, yeah, that was my fake extra-serious face

signal rose
solar valley
#

whenever you see GetKeyDown true for the jump input, then you set timeLastJumpInput = Time.time;

signal rose
#

Ohhh I remember doing something like this in a processing4 project to handle inputs

indigo shale
#

shouldn't it be >?

signal rose
#

Yea I think so

solar valley
#

yes it should

#

jump input should count for any time up until (time you pressed jump) + (buffer)

signal rose
#

You could do the same with GetKeyUp for the jump arc sharpening thing couldnt you?

solar valley
#

for letting go of jump, we will also use a timestamp, but the property will be different

#

letting go should only count if the last jump release timestamp is further forward in time than the last jump input (ie we released jump more recently than we pressed it).

AND we only want to actually do anything with it if the last time we were actually grounded was also BEFORE the last time we released the jump key.

#

Meaning we also need a timestamp of the last time we were grounded, which is a timestamp we were going to need anyway for coyote time (among other things).

signal rose
#

which I think I did plan to add

solar valley
#

Update should not worry about any of this. Update just logs timestamps for jump press, and jump release.

#

FixedUpdate (or collision callback) can log timestamp for the time last grounded.

#

The property that tells you if you need to do a controlled jump (ie you let go of jump in the middle of your jump) needs to compare these 3 timestamps to check that the player releasing the jump button is the most recent event of all 3.

signal rose
#

I am sorry I doubted you, it seems to work after using the timestamp method

solar valley
#

,UnityChanThumbsUp

signal rose
#

Now I just have to work from here and patch up the feeling of the jump again

#

Removing the arc sharpening has made the jump feel different

#

Oh yeah, I think theres a karma system thing

#

Thank you @solar valley and @indigo shale

#

Sorry for the mention, I know some coding help server do a karma type thing when you say thanks

dusky ember
indigo shale
#

pf, GDL! 😛

signal rose