Love the game but have noticed a huge issue with inputs not being registered in the game during certain points of the game.
I tested on stairs to reproduce the issue easier and to show that even though the buttons are pressed, the action does not occur or is queued after pressing as it does other times in the game. Button mash dodge twice fast and the game will still register 2 dodges. In combat, this double press is sometimes not registered and I only dodge once or in the case of attacks the attack never executes.
The issue I have is that this is seemingly not working through-out the entirety of the game correctly. Mostly during combat or low performance areas which makes me believe the performance of the game is hindering the actions of the player. I can’t know this for sure but it does occur more often during high action events like combat or boss fights.
Show below is a video proving that inputs are being pressed but the game does not execute the action OR queue it as it does during button mashing outside of combat or when off stairs.
Due to this issue I am finding it hard to fight certain enemies as my inputs are being deleted completely instead of queued as I would be okay with as it works like that out of combat, just not in or while moving through the worlds design (since it’s not perfectly flat) and thus it could also be tied to the World Design and small things like rocks or other objects might be hindering actions.
Update: More videos of the issue only appearing during rendering, movement or some other actions occurring in the game like stepping over the Crucible door exit causing a missed input.
Input issue entering area for first time.
Issue DOES NOT occur when idle and the area is already loaded or no actions both player and environment are active.
This occurs All The Time during fights with enemies. My first actions are being deleted forcing me to press twice by habit now just to make sure 1 attack Will be registered.
This is the only case where both NohBoard AND the Game did not register input. It felt like my system locked up for a second RIGHT AFTER I chopped the tree the 3rd time and it started to fall.
Hijacking this for a related issue. There are input buffering problems when performing a Rune attack in the bottom slot (“A” button, the button bound to dodge) when using off-hand weapons ie. Bows.
Test case, if you put Cone Shot in the bottom Rune slot on a bow and tap the input you will perform Cone Shot but then also queue a dodge immediately afterwards. This does not happen if you hold the dodge button down when performing the Rune attack, presumably because the buttonup input which triggers a dodge doesn’t go through.
Using Left modifier + Dodge button to try and execute a Rune attack will also buffer a dodge instead of the Rune ability if you use it while in the middle of other animations such as a dodge.
This was another bug I had issues with as well and is why I Do Not use modifiers like Shift in this game and use the Up Arrow for Sprint. Holding SHIFT and using other keys IS causing issues with input. Agreed.
I have since changed from Right Click to Right Arrow and it has seemingly fixed the issue by a lot. I think some areas are still giving me issues but something about using right click as Shift (Logitech G600) and the game using right click for rune attack may be causing a weird overlap with the OS and the game where I am holding the RMB for run as Shift, but the game still uses Right Click for Rune attacks. Not 100% sure how all this ties together.
i noticed this too, but can’t really say when it happens. mostly noticed during crucible runs. sometimes my inputs are not registered but weirdly stored, so when i press the button again, the game does it twice. for example rune attacks.
tried to do the rune attack bound to controller Y button, nothing happened, pressed it again and my character just attacked twice in succession, consuming all my focus.
Yes, so I understand Input Queuing, that I don’t have an issue with. The only issue is pressing multiple times, watching the rune change but the attack never goes off.
I have found this occurs MOSTLY during elevation changes or when near small objects like rocks and railroad sections (like in the Quarry).
Due to the world being curved the way it is I believe we may be falling into an issue where our characters are in a “fall” state during some actions and movements and thus results in the Rune attacks not working the first time and upon the second press, the character is now “grounded” and the attacks can activate. I believe this as you can’t jump off a cliff and do a rune attack, but you can rune attack off a cliff if the rune attack moves you during the attack.
but is queuing really a thing you would want? it becomes gamebreaking when it happens with rolls, and u suddenly and without warning roll of a cliff without pressing anything.
i personally do strongly dislike stored inputs. when i get canceled out of an attack from an enemy etc, it should not just go off on its on “whenever”. An input should either happen when pressed, or get canceled, e.g. by enemy pushing you. but after the push i might want to roll and not attack as “stored”.
i also found it often happens during combat. so i think it might have something to do with an enemy interaction somehow cancelling or storing your input.
Stored inputs aren’t so bad because at least you know the action was acknowledged vs missing a target window or an animation overlap or cancel causing the inaction at the moment of input.
No Rest isn’t as fast as most think it is or should be as I find myself in a new flow of combat with my weapons that feeds off that delay or queue of input. When a boss goes down or I know they are stalling I can drink a potion and immediately press for a rune attack without having to wait for the perfect window when the animation ends and I can begin the new input.
Now with input cancelling you get away with anything you want and I do like it to an extent. Anything that involves the player leaving the ground or losing contact with their weapon should result in a stored input scenario whereas an animation like Reap (3-hit attack) that can’t be cancelled should be allowed as just like in Baseball, a Batter doesn’t always have to swing all the way JUST BECAUSE they started to swing. I believe in input canceling but also think No Rest is aiming to be more methodical than reactive. I believe after a few more tweaks to combat and performance the game will settle nicely into itself. I’ve found many new avenues trying new weapon and rune synergies. What seems weak might be super safe, what is strong could be preventing damage overall. Still lots to learn.
Input queuing is important because the character spends a lot of their time in hte middle of committed animations where you are unable to perform a different input until the animation is fully recovered. If you have no input queue at all then pressing a button even one frame before the end of your previous animation will result in nothing happening and the player feeling like their input was eaten. An input queue which is too long is also bad because that can cause an action to come out after the player has already changed their mind about the input they pressed.
The correct way to handle this is to have an input buffer which lasts no longer than average reaction time so that the gap between pressing a button and the input being executed is never longer than it takes the player to change their mind. So you want an input buffer of about 150-250ms.
I’d agree to a shorter buffer than what we have now but make very slight adjustments here with every patch so as not to go too far. I just want to get rid of having to press twice to activate things in the game which I believe is tied to performance and world design causing the player to be stuck on short instances of “falling” as the player is on a curved world and due to inputs being cancelled during falling I feel like this is a possible avenue to test as just walking over a piece of wood or rock in the game completely disables Rune attacks. No queue at all when “in the air”.
So in the end this may be an issue that encompasses more than we think and not just Input queue timing.