Half Circle not registering when it should [Video Evidence]

[Wafer]

Bug found on date:17/11/2020
BuildID: BETA E6E763848
Game mode: Training

Steps to replicate bug: With the Keyboard attempt to do Half circles at various speeds. Can happen when done fast or slowly. More specifically when the time between a key release and a press is close to a frame in time.

Occurance rate: ~10%

Details of bug: Usually when attempting sequential inputs with the keyboard one of the required directions will be skipped. Usually during half circles or commands longer than 3 directional inputs.

Apparently when an input is missing it may be due to a directional being active in its state for a frame or less time and only during an specific time of the frame.

The issue happens between the short timeframe between a key release and a press, therefore it can happen if the command is done slowly.

I recorded at 120fps with a keyboard overlay to study the issue and the results showed that I performed the command correctly but wasn't registered by the game. The following half circle test had the commands performed by hand at a lower speed than I'm used to.

https://youtu.be/lZnl00QwsGE
Seemingly the input interpreter is tied to the framerate and can only receive a single directional per frame, though ideally it should prioritize the first direction of the frame over the latest one.

Also it may be that there may be a few miliseconds of the game loop where the game cannot gather input data.

Ideally inputs should register one direction per frame for the game, but the first direction pressed should take priority (or the second input from the previous frame) and the input interpreter should have a higher polling rate than the framerate (120hz or more).

Many Arc System Works games have the same issue of eating directional inputs but it is most noticeable with GGACR.

Issue happens with and without V-Sync.

It is possible to test this issue with a Macro so the inputs are identical everytime, even if given a 17ms window between inputs sometimes the result is different and the command will not come out. (16.66~ms is the time of a frame).

This issue should theoretically happen with hitboxes, some gamepads and other input devices.

PC Specs:
- CPU i7 4790
- GPU GTX 1060 6GB
- RAM 16GB
- Windows 10 build 19042.630 (20H2)
- Desktop
- LAN

[sat0ri]

Thank you for reporting.

Correct me if I'm wrong, from the video you provided, the [2] was held no more that 1 frame at 120 fps?

What software did you use for macro playback, input display, 120fps recording? So we can reproduce this by ourselves.

[Wafer]

Originally posted by tfc sat0ri:

Thank you for reporting.

Correct me if I'm wrong, from the video you provided, the [2] was held no more that 1 frame at 120 fps?

What software did you use for macro playback, input display, 120fps recording? So we can reproduce this by ourselves.

From what was captured it could've been almost two 120fps frames (roughly ~11ms). More than half a frame in ACR (16.66~ms) but less than one. Since the frames visible in the video do not capture the time between the frames (I pressed the key near the middle of the previous frame (f48) and continued almost until the end of the visible frame (f49).

Macro used in other tests was with a Software called Razer Synapse 3. Though it may require you to own a Razer Keyboard or Mouse, and the Macro Module needs to be installed.

So I recomend you to use this program
https://www.autohotkey.com/

And download this code wrote by myself to test this issue.
https://www.dropbox.com/s/4mnv7cnpl2to7h3/CommandTesterGGACR-yar0th3ungg0y.ahk?dl=0

Once Autohotkey is installed, open the .ahk file I gave you with administrative privileges. Instructions are commented in the .ahk file when opened with the notepad.

While on the video I reproduced the issue by hand. There are two Macros to reproduce this with one using SOCD where the [2] input is a result of left+down+right being pressed at the same time. And a sequential half circle which is what I did in the video, holding down+right,releasing right while holding down, and pressing left while still holding down, this means I held [2] alone by 8 or 9ms.

A Macro with commands spaced 17ms can still trigger the issue. More than a frame and a half is required for the issue not to trigger on a single input, though sometimes even at times longer than a frame commands will not come out if two or more buttons are near simultaneously pressed/released (which may happen during command normals).

I added an additional macro to test input interpreter failures on command Normals. This issue is very difficult to humanly reproduce but it can be used to test the input interpreter as well.

As for the recording software and the overlays.

OBS Studio
https://obsproject.com/

I still need to make an overlay that also shows the attack buttons and is functional at 120 fps also so it will be pending for now...

EDIT: Gather this plugin for the input overlay... However none of the presets are approppiate for testing fighting games on the keyboard. I'm making one for that.

https://obsproject.com/forum/resources/input-overlay.552/

[sat0ri]

Thanks for the info. Appreciated.

[Wafer]

Originally posted by tfc sat0ri:

Thanks for the info. Appreciated.

Here's an Overlay appropiate for GGACR controls, default buttons work, UP should be set as Spacebar ingame for it testing.

Can be installed alongside the other Input Overlay presets, more instructions in the compressed folder.

https://www.dropbox.com/s/8vazfi15uypkqkj/WaferKB.zip?dl=0

To record in 120fps in OBS go to File>Settings>Video>Click Common FPS Values and change it to Integer FPS Value and set it to 120 FPS.

[Lux]

I just want to chime in that I'm having the same issue with my Hitbox, too. Same as OP, a down direction input frequently get skipped if I attempted to do half circle fast (the training room's input display showed that a direction was missed). I'm happy that it's not just me. No issue if I inputted half circle motion slowly.

Would be wonderful if it is fixable.

[Wafer]

Issue can still be reproduced in build BETA C4A10542A

[petran79]

I am also having an issue with doing Jam's DP Kick motion while on air with a gamepad. It registers at DF Kick instead. If anyone else manages it and could me inform if it is feasible. I can do it with keyboard fine and move is not that hard to pull through, so there must be an issue with the game and that specific motion on a pad

[rednecked_crake]

Originally posted by Lux:

I just want to chime in that I'm having the same issue with my Hitbox, too. Same as OP, a down direction input frequently get skipped if I attempted to do half circle fast (the training room's input display showed that a direction was missed). I'm happy that it's not just me. No issue if I inputted half circle motion slowly.

Would be wonderful if it is fixable.

I'd double check you actually are getting a proper half-circle, they are notoriously difficult on hitbox and some newer games let you skip a down-direction and will just accept down-left or down-right instead. If you can get some other game that accepts background inputs, you can see what input the other game is seeing as well.

Doing 63214 + 6 HS in AC+R for Sol's super, the two common ways hitbox messes it up is skipping 2 and skipping 4.

https://i.imgur.com/wWepDqm.jpg

https://i.imgur.com/XTwv0Qi.jpg

[sat0ri]

This should be fixed in publictest branch, we're awaiting your feedback.

Input parser was modified to simulate updating at 120 FPS, while keeping the amount of frames required to input a move the same as before. Only half-circles (HC+back, HC+forward as well) are affected. Changes allow skipping a direction if it looks like it was pressed, but for less than a frame.

As for feedback, we're most interested in any examples of game registering unintended moves due to changes in input parser, or game's behavior in general changing in any way aside from making it easier for keyboard and hitbox players to input the moves.

In depth:
- Any direction other than the first or last can be skipped (i.e. 4123 is not a valid HCF, but 4136 can be, same for 63214 vs 63216 for HCB+F)
- Incorrect direction is not allowed to be in place of the skipped one. For example, if expected input is 63214, 63514 is not valid. Alternatively, the "sum" of previous and next directions must result in the skipped one. For example, if expected input is 632146, then 632176 (1+7=4) will be considered valid.
- Even if (for example) 6314 is accepted as HCB, the whole input must still be at least 5 frames long like before (i.e. some direction should be held for at least 2 frames)

How to switch to publictest: https://store.steampowered.com/news/app/348550/view/2961640281611459954

[Mateus]

I'm not a fan of this change, I was able to do half circle inputs while deliberately skipping diagonals and that's not how the game behaves on other platforms.

On a persnal note I liked the input strictness.

[Medusa]

Hi there. Sorry for my english.

Not a fan of the input changes too.
I'm a new player, and one of the reasons i picked up the game (specifically I-No), because i was very enthusiastic about challenging execution.
I understand the issue with the not registering inputs, but i wish that could be solved without allowing players to actually skip inputs.
Seeing half circles be done just by inputing 624 is kinda unsettling to be honest.

[Amphyvxena]

Originally posted by tfc sat0ri:

This should be fixed in publictest branch, we're awaiting your feedback.

As for feedback, we're most interested in any examples of game registering unintended moves due to changes in input parser, or game's behavior in general changing in any way aside from making it easier for keyboard and hitbox players to input the moves.

This is an amazing fix!
I did test it on several characters like Potemking, I-no and bunch of others - this is like day and night - you can focus on gameplay and combos/defence - instead of a mashing buttons and raging about the inputs with half circules not beeing registred.

I did ask some other keyboard players, they all was so happy about it that no one could really belive how GOOD +R with this fix is now.

I dont get about some "i didnt like it" lol???
Most of the negative comes from a random hype people, like 5-10 hours spent in +R
Tell or show me please like 5 veterans +R players who are against it.

You can't.
Beacuse thing it's a god sent.

PS
I did investigate 1st post in this topic closely and yeah..this fix shoud be happened years ago.

If you dont agree with me - be my guest. (but please like 200+Hours on +R spent before you even start saying anything bad)

[Baf0]

Just reporting to say that this change made XX I-no playable for me. Not saying she was dysfunctional or anything, but Chemical Love inputs would sometimes not be parsed correctly especially when playing online. It's a lot more consistent now.

All my combos from before work the same (i.e 6P > 5H > sj.IAD j.K) if not better.

I feel for people who play on both console and PC, and I hope this change doesn't get rolled back because of it. I'd rather we ask for a genuine re-release on PS4/PS5 from ArcSys since the game is seeing a resurgence now.

[Aligari]

Discussed it in the discord, just bringing it up again here. The change I'm not necessarily opposed to, but it does break parity with PC and every other console, and running PC standard tournaments (as someone who has both done that and helped other tournaments that have done that) is an absolute nightmare, so the parity issue sits bad with me. If there were a way to practice on the offline input parser (onlne or off), or a way to port this to a console that we could then use for tournaments, I would be a lot more ok with it. I think its a great feature and I'm glad to see people enjoying the game because of it, I'm just concerned for people that learn over netplay then come out to tournament and none of their inputs work

[Mech]

I think the most important part is parity with other systems. The most preferably is if every other system got updated too but who knows if that is going to happen. A toggle for it so people don't get screwed when they need to play on other systems is something to consider.
People will always want to gatekeep for execution stuff yes, I'm not the biggest fan of that argument.