Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Godmode affects unrelated player movement #381

Open
Cosine256 opened this issue May 1, 2024 · 1 comment
Open

Godmode affects unrelated player movement #381

Cosine256 opened this issue May 1, 2024 · 1 comment

Comments

@Cosine256
Copy link
Contributor

Godmode affects player movement mechanics that are unrelated to taking damage or debuffs. I've found two cases where this happens, both caused by godmode forcing lock_input_timer to 0.

  • Godmode lets you start moving after using a layer door one frame earlier than you would be able to otherwise. lock_input_timer is normally set to 1 for the duration of a layer door usage and takes one extra frame to expire after finishing the door usage.
  • Godmode clears the 10 frames of locked input after firing a weapon with recoil, which affects the behavior of things like shotgun jumps if the player is holding inputs during that recoil period.

What was the intended purpose of setting lock_input_timer to 0? Was it to clear the input lockout that happens if you touch an enemy while airborne? If you can't get hit anyways in godmode, then that would only matter if a user took a hit without godmode and then tried to switch to godmode immediately to clear the input lockout.

@Dregu
Copy link
Collaborator

Dregu commented May 9, 2024

Was it to clear the input lockout that happens if you touch an enemy while airborne? If you can't get hit anyways in godmode, then that would only matter if a user took a hit without godmode and then tried to switch to godmode immediately to clear the input lockout.

I believe it was something like that, i.e. to recover from every negative status effect and all kinds of stuns immediately when switching it on, but the approach was bit of a crapshoot with no testing, just forcing more things until the game stopped bugging me.

The aim was also to keep the gameplay otherwise normal though, so yeah making that one only set the value once when toggled on would probably fix the problems while keeping the intended behavior.

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

No branches or pull requests

2 participants