Open ozguzMete opened 3 years ago
Hi Mete, welcome to the project!
I had noticed this issue too. It's not related to sliding, I think, and doesn't require going up the rock. I will remove the references to that because otherwise it makes it look like old bugs which we have fixed already.
I will update the description with more precise reproduction steps.
@ciro-unity Do restarting Unity solve the issue? I had reported similar problem to this before: https://github.com/UnityTechnologies/open-project-1/issues/127 It somehow occur if you open the project for too long haha
and I think what ozgusMete meant in this issue is: even when the player is stuck, player should be able to change its direction by user input. Is that correct? @ozguzMete
I have the exact same issue with another game I'm working on currently. Still haven't found the cause though. I wonder if this bug persists in a build or if it is something happening only in the editor. Might be worth to check out to get some more information about the cause.
might possibly have to do with loosing focus and input not updating ... for example hold down the down arrow and then use your mouse to click outside the game window (so you loose focus), then click back into the game window, you will notice that even though the key is down the player doesnt move down, you can press left or right arrow and they will work but not the down key you still have pressed.
And this might only happen once due to some weird unity editor thing where the game window looses focus momentarily only on the first time you click play ?
2 quick thoughts on ways to fix it with out any verification:
1) don't only check on input down, up ... pressed should still count
2) force refresh input on regain window focus
Hmm, I don't think a loss of (real) focus of the window is the cause. First because the window doesn't change colour, and second because it regains it automatically after a few seconds.
However, I have to say that in my recent tests I haven't seen this issue anymore, which before would happen every single time (?) But at the same time, nothing really changed in the input configuration, we didn't update Unity or anything... weird. So let's keep an eye on it.
It seems that the source and length of this bug are different for many people and that it also got solved in many different unexplained ways. Updating the input system and reloading the editor for example. Hopefully, it stays gone and doesn't come back. https://forum.unity.com/threads/input-system-freezes-and-stops-registering-input.882754/
I am also not seeing it anymore! Scary though that a bug can appear and disappear like this 😅
I made some tests here and everything goes well.
I was unable to reproduce the error.
I used the latest version of the project.
It worked perfectly here.
Does it still happen to someone?
Would you have any other action to try to reproduce?
Thanks in advanced.
No, same for me... not happening anymore, hopefully it was something that was fixed by Unity (we are updating the editor to the latest LTS). I'll keep it open for another while, but for now I've degraded it to "minor" since the occurrence rate is very low.
I am seeing it again, and consistently... (every time I play, and with exactly the same timing) Aaaaaaahhh what is it?! 😭
I'm not sure if this is related (I don't think so), but I have enocountered unresponsiveness related to the Statemachine. I'm also using the Statemachine for my protagonist movement. I currently have 3 states, Idle (Initial State), Run and Crouch. If I go from Run to Idle state, and then during that transition press the Crouch input button. It takes an additional second before the character goes to the Crouch state. It's super unfortunate that this happens, since I really like everything else about the statemachine. Is there any reason for why it takes such a long time for the Statemachine to transition to another state? It's usually a relatively fast operation.
I am seeing it again, and consistently... (every time I play, and with exactly the same timing) Aaaaaaahhh what is it?! 😭
It was back also when we move to 2019.4.19f1 and it seems gone again now with the last upgrade to 2019.4.20f1! It could be interested to check the release notes for the last 3 LTS version and see if a bugfix related to input system has been done, fallen back and applied back :)
I'm not sure if this is related (I don't think so), but I have enocountered unresponsiveness related to the Statemachine. I'm also using the Statemachine for my protagonist movement. I currently have 3 states, Idle (Initial State), Run and Crouch. If I go from Run to Idle state, and then during that transition press the Crouch input button. It takes an additional second before the character goes to the Crouch state.
Hmm, this sounds like it has something to do with the animation transition. You have an animation clip playing for Idle, right? Is it 3 seconds long? :) Check if the transition from Idle to Crouch in the Animator has "Has Exit Time" checked. If so, uncheck it.
It could be interested to check the release notes for the last 3 LTS version and see if a bugfix related to input system has been done, fallen back and applied back :)
Nah, the issue appears inconsistently and I'm pretty sure I've seen it on and off on the same version. Also I would expect it coming from the Input System (thought that might be not true) and that didn't update every version. So 🤷🏻♂️
Huh... glad I'm not the only one.
I just had this happen on my own game. In particular it happened on "Unity version 2020.3.19f1 Personal
If the bug I encountered is indeed this one talked about here, then it is absolutely tied to the input system :D . I was following this tutorial updating my project from input.getkeydown, when I encountered a disconnect between an instant getkeydown response and the period of unresponsiveness of the bug. I honestly believed I was learning the input system wrong lol.
These bugs are scary when you're learning, but for whatever reason they're great afterwards XD
Short description Character's movement is unresponsive (player perspective) for a few seconds.
Expected behavior Character movement should be always responsive.
To Reproduce Steps to reproduce the behavior:
Notes