Skip to content

Conversation

@ninj1337
Copy link
Contributor

@ninj1337 ninj1337 commented Aug 4, 2025

Changes

Change 1

The slowdown/braking effect that slows you after using air dash was FPS dependent due to being executed in Update(). I moved the code to FixedUpdate() to fix that.

Change 2

I interpreted that the purpose of the Cache.Rigidbody.velocity.magnitude > _originalDashSpeed check was to prevent the slowdown from removing more speed that was added by the air dash. However, this check does not take into account the direction of the dash force, so I added a new field _originalDashDirection to track the direction of the dash, and updated the use of _originalDashSpeed to track the speed only in that direction. Lastly, I added a branch to the code that updates the velocity to correctly avoid removing more speed in the direction of the dash than was added by it.

Misc change

I also did a small change to the Dash and DashVertical methods so that they update _dashTimeLeft after setting State = HumanState.AirDodge. This is to prevent any potential bug in the case that State is ever updated to AirDodge while it is already set to AirDodge, since the State setter clears _dashTimeLeft in that case.

Note

This code should still be optimized and refactored before committing to main, but please test and make sure the functionality is working properly.

@AutumnThyme
Copy link
Collaborator

You're ignoring how timesteps work in order to remove the 1.7 multiplier.

Update (60fps):
Applies every 1/60th second.
Velocity scaled by 1/60.

Fixed update (50 ticks per second)
Applies ever 1/50th second
Velocity scaled by 1/50

However you have to remember that this code changing velocity is called at a different cadence as well. So 1fps velocity change would just be the velocity change and you'd see it after 1s. 50fps would apply 1/50th of the change over 1s. 60 fps would apply 1/60th of the change and so on.

Fixed update is where this code should be but you can't make assumptions like above.

The point of this mechanic should be to slow you down by a fixed amount so that you don't gain speed off of gas burst. What you should do instead is just keep the 1.7 multiplier and clamp speed to the pre burst speed so that you never dip under it.

@ninj1337
Copy link
Contributor Author

ninj1337 commented Aug 5, 2025

Oh, didn't see your comment since I already pushed the corrected code before you posted this. I added the 1.7 factor back to the force calculation, and the point you mention about it not being able to dip under was part of my initial commit so its already addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants