Menu
By:
Filters
What's new

Input Bug: First results of a computer assisted analysis

Status
Not open for further replies.
webreg

webreg

Noob
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.
 
webreg

webreg

Noob
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

Prinz

watch?v=a8PEVV6tt14
webreg said:
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
Click to expand...
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

leek

Noob
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..
 
Prinz

Prinz

watch?v=a8PEVV6tt14
XXZ said:
Nice work (I think? lol) but 1 frame is 16 ms, not 35, unless I am missing something here.
Click to expand...
1 second = 1000 miliseconds. So, 1 frame (at 60 frames per second) is 16.7 miliseconds. Is this the right math?
 
webreg

webreg

Noob
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

webreg

Noob
Prinzmetal said:
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?
Click to expand...
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

webreg

Noob
Couch Tomato said:
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..
Click to expand...
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

aj1701

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

webreg

Noob
aj1701 said:
[MENTION=4121]webreg[/MENTION], very nicely done. I can only assume you also build software for a living?
Click to expand...
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

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

aj1701

Noob
webreg said:
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. ;)
Click to expand...
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.
 
GGA soonk

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

Panque

Random foreign guy
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!
 
E

eskuAdradit0

"Thanks" button abuser.
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.
 
Status
Not open for further replies.