Input Bug: First results of a computer assisted analysis

[webreg]

I spent the last hour with my notebook and tablet hooked up to my PS3 and so far my test results have been enlightening and surprising. I don't expect you to believe me solely on what I write here so I will record a video this weekend for everyone to see. I also need to test it our more thoroughly but yes, there seems to be what can only be described as a glitch or bug in this game concerning certain inputs.

So far I only tested "down 1" with smoke but this was enough to notice something very interesting. What I did was let my computer run several tests of at least 50 inputs each. Every test run had different settings in the timing between each command. My computer essentially did the following with an accuracy of about 3 milliseconds:

press and hold "down"
wait x milliseconds
press and hold "1"
wait x milliseconds
release "1"
wait x milliseconds
release "down"

The x was what my investigation was about. I will explain everything on more detail once I release the video but lets just say, that only one of those x was relevant. This one here:

press and hold "down"
wait x milliseconds
press and hold "1"

Here is the interesting part. There is an input window of almost exactly 40 milliseconds where the problem occurs. If you press "1" almost exactly 85 to 125 milliseconds after pressing "down" it seems to be completely random if you get a standing or crouching "1". If you hit "1" outside of this window and it doesn't matter if it is earlier or later then the "down 1" is guaranteed.

It's about 2:40 AM here so I won't be able to answer for the next 9 hours because I'm sleeping.

Edit: Video and further explanation can be found here.

 

[GNG Iniquity]

EXPOSED

 

[webreg]

Ok, here are a few additional results from further testing. It was a short run and I wanted to verify some stuff:

- It doesn't depend on the character. Each of them I tested had the same problem. And it doesn't seem to matter which poke is used.
- The problem does seem to be limited to the "down" command. For example Liu Kangs "Back 3" was not affected. Further testing will be required though.

And some stuff about jumping:

- For a diagonal jump you need to keep "up" pressed for at least 35 ms for it to register
- For a neutral jump this window is doubled to about 75 ms or the command will be ignored

Again, even though I'm giving data down to the millisecond please note that these values have a variance of up to 5 ms because of the way my hardware and equipment works. But I know of these inaccuracies and test accordingly to mitigate that.

 

[Prinz]

And some stuff about jumping:

- For a diagonal jump you need to keep "up" pressed for at least 35 ms (one frame) for it to register
- For a neutral jump this window is doubled to about 75 ms (two frames) or the command will be ignored

I think this can be explained by the presence of "up+3" commands in some characters.

Also, can you test "down,up" (teleport) commands, just to see if "up" activates during that timeframe in which the down jab command is randomly ignored?

 

[leek]

Oh wow.

thanks for testing this out man.. that's insane that there is an actual window of about a frame where the input will not register...

why do you think that is? This is groundbreaking..

 

[Somberness]

Nice work (I think? lol) but 1 frame is 16 ms, not 35, unless I am missing something here.

 

[Prinz]

Nice work (I think? lol) but 1 frame is 16 ms, not 35, unless I am missing something here.

1 second = 1000 miliseconds. So, 1 frame (at 60 frames per second) is 16.7 miliseconds. Is this the right math?

 

[webreg]

Frame rate != frame data != input frames

Three different things but all of them related to each other. Sometimes two or even all three are the same but that depends on the game. That's why I don't measure frames but milliseconds because this is the only reliable and perfectly well understandable way to reference such properties. We know, that the frame rate (number of pictures displayed) of MK9 is 60 but that doesn't mean, that the input frames are the same because I think it's either 30 or they have some smoothing and buffering in the code to make it appear to be 30. It is quite common, that a game engine or at least the control threat runs at 30 iterations per second but the actual video is 60 pictures per second because while 30 is more than enough to feel seamless in response to human reflexes 30 pictures is below the perception of the human eye/brain.

***Babble start***
I tested in increments of 5ms and during the tests, the properties of moves always were constant within 5-6 iterations and then changed. So it seems, that button presses are evaluated only every 30 ms. So I concluded, and that's not very scientific I know, that an input frame is 30 ms but I honestly don't know.
***Babble end***

I apologize. I shouldn't have used the word "frame" because it's not specific enough and people will confuse this with frame data and draw the wrong conclusions. I should now better being a scientist after all. From here on out I'll stick to milliseconds because that's what my computer tells me and that is what I will tell you. I have removed my reference to frames in the previous post.

I started yesterday night with my tests and only wanted to at least tell the people, that there is no doubt about a glitch/bug/inconsistency involving down pokes. This much is clear and I can prove that. However, I don't have enough data yet to draw any specific conclusions as to why it happens I only have the evidence that it does happen.

 

[webreg]

Also, can you test "down,up" (teleport) commands, just to see if "up" activates during that timeframe in which the down jab command is randomly ignored?

What interests me is if all "up" commands have the same properties. For example is the input timeframe for Raidens teleport the same as for Ermacs overhead? I'll look into that and your question should be answered along the way.

 

[webreg]

Oh wow.
thanks for testing this out man.. that's insane that there is an actual window of about a frame where the input will not register...
why do you think that is? This is groundbreaking..

The thing is, it's not consistent. During this very specific amount of time it seems to be somewhat random what happens. I have an idea why this might happen but I won't say anything until I have data to support my claim but let me just say, that the next thing I'll test is standing up from crouching and try to get a standing "1". An "instant up poke" if you will.

 

[aj1701]

[MENTION=4121]webreg[/MENTION], very nicely done. I can only assume you also build software for a living?

 

[1man3letters]

good work man

 

[webreg]

[MENTION=4121]webreg[/MENTION], very nicely done. I can only assume you also build software for a living?

No, I actually do the opposite. I pick software apart for a living. But yes, I'm able to write me some tools and stuff if need be.

 

[GGA soonk]

So there really is a 1 or 2 frame window for the input? I knew the only concern was how long down was being held before the button press. I'm glad your software was able to confirm my suspicions. I wonder if the window is the same when caught blocking a string, since the same thing occurs trying to down poke out of strings.

 

[aj1701]

No, I actually do the opposite. I pick software apart for a living. But yes, I'm able to write me some tools and stuff if need be.

Oh, so you're my nemesis then. I was close though, you're in the software industry. Anyway, your findings are great stuff, by far the most indisputable evidence that we have an issue. My timing seems to be perfect for this bug, it happens almost once a round for me.

 

[GNG Iniquity]

This specific thread needs to be sent to Paulo, this is indisputable proof that it exists.

 

[GGA soonk]

Can you do us a favor? Test this on a prepatch version. Negative edge was just reduced, so if prepatch input drop window is smaller, that means negative edge has been covering this up the whole time.

 

[Panque]

Best thread ever. Hopefully this ends the discussion between people who acknowledge the bug and people who say it doesn't exists. The community needed this bug to be clarified. Great job!

 

[REYTHEGREAT]

I vote for main page. Good stuff bro.

 

[Lt. Boxy Angelman]

This specific thread needs to be sent to Paulo, this is indisputable proof that it exists.

Seconded. Fantastic work, man. THIS is where the fixing focus needs to be...

Somewhere in Kombatland, Tom Brady is brewing the biggest bowl of "I told you so" ever stirred.

 

[Z-911-Z]

Webreg Wins. Flawless Victory. Babality.

 

[aj1701]

Thirdededed.. er something. So [MENTION=1]STORMS[/MENTION], what do you say??

 

[STORMS]

Thirdededed.. er something. So @STORMS , what do you say??

Sent it to Hec and Paulo

 

[NRF CharlieMurphy]

Can you do us a favor? Test this on a prepatch version. Negative edge was just reduced, so if prepatch input drop window is smaller, that means negative edge has been covering this up the whole time.

This... all day long.

 

[eskuAdradit0]

This shows that there exists inconsistency for the referred problem, which seemingly no one can doubt it's existence now.

Now, the big question is, is it a bug?Or was it thought that way by NRS for any reason whatsoever? <--- That's the interesting part.