Input Bug: First results of a computer assisted analysis

[Shadowfire]

Very scientific, you've made a believer out of me. Now NRS can be notified with something concrete and reproducible, not just people blaming losses on some mysterious glitch that changes symptoms from day to day.

This is also useful because it defines the window it happens in, and as such the problem can be circumvented for the time being by trying to avoid that window whenever possible.

I thought NRS was aiming to make this a relevant fighter. If thats the case, this game should work like one.

I really don't feel that adequate testing was put into this game, clearly, but now that we're finding bugs THIS big...it's a problem.

Look at the bug that was found in SSF4AE recently, a game which has already had 3 retail releases on basically the same codebase. People have found a way to make a corner crossunder temporarily disable your opponent's controls.

Input glitches are not unique to MK, nor are they more severe in MK.

 

[webreg]

I will test the "down poke inconsistency" with the release version of the game (without any patches) to see if there is any difference. So far I have neither seen any evidence nor can I imagine a scenario where negative edge could have any impact because at the time where this becomes a factor (releasing the poke button), the problem has already occurred. So it shouldn't matter if the "button release command" has now to be closer in time to the directional commands of a special move or not. But we'll see.

 

[GGA soonk]

Its more of a curiosity thing for those of us discussing it here at SB. Bug isn't getting fixed anyways so guess it doesn't matter too much, just wondering if it was being covered up.

 

[Panque]

Look at the bug that was found in SSF4AE recently, a game which has already had 3 retail releases on basically the same codebase. People have found a way to make a corner crossunder temporarily disable your opponent's controls.

Input glitches are not unique to MK, nor are they more severe in MK.

Never said it was unique or more severe, just that NRS should have done this right since their aim was for a tournament worthy fighter.
SFIV:AE not being perfect (I have no love for that game, really) is no excuse for this bug. I hope they don't stop patching this game anytime soon. Tournament players are pretty unhappy with this bug + dash nerf. These factors are hurting the game a lot.

 

[Shadowfire]

Never said it was unique or more severe, just that NRS should have done this right since their aim was for a tournament worthy fighter.
SFIV:AE not being perfect (I have no love for that game, really) is no excuse for this bug. I hope they don't stop patching this game anytime soon. Tournament players are pretty unhappy with this bug + dash nerf. These factors are hurting the game a lot.

It's no excuse, certainly, but the fact it's less severe than SSF4:AE's problems I think is a good argument for the game still being very tournament worthy.

I haven't seen much evidence that the majority of tournament players are unhappy about the dash nerf, to the point of thinking it's causing the community to dwindle. It's still too early to say how it's going to affect the game in the long term anyway.

All the game really needs to keep going for a long time is a new character now and then. Again I must refer to TF2 being an excellent model.

 

[funkdoc]

there are a lot of complaints from good players re: dash nerf, but that's just bc of kabal. i've been arguing from day 1 that the dash change is fine and kabal just needs cooldown time on air fireballs

 

[GGA soonk]

i dont think im always getting input bugs on clones... i KNOW it. i just watched 99999 MKDC matches of mine. GL's db+1 is his green hand.. out of 999999 green hands know how many 1's or b1s i got? ZEROOOOOOO....

out of 99999999 green hands i missed 5... FIVE!!! and it was because i was early after the breaker. in MK9 i miss clones at least 30% of the time, i KNOW how to hit db+1. im going to say that 99% of the time that i get a B+1 that its the bug.

I don't disagree with you, I think I've had it happen, but I wish there was a way to reproduce it in training mode. I wonder if the window is smaller or if there is another variable.

 

[arydious]

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.

This made me laugh

 

[Panque]

It's no excuse, certainly, but the fact it's less severe than SSF4:AE's problems I think is a good argument for the game still being very tournament worthy.

I haven't seen much evidence that the majority of tournament players are unhappy about the dash nerf, to the point of thinking it's causing the community to dwindle. It's still too early to say how it's going to affect the game in the long term anyway.

All the game really needs to keep going for a long time is a new character now and then. Again I must refer to TF2 being an excellent model.

Actually, I see the input bug happening every tournament, while I have never seen the SSFIV:AE bug in a tournament, so unless I missed it (Don't really enjoy SFIV so I don't watch it a lot), the SFIV bug isn't as severe as this input bug.

The dash nerf isn't as harmful as the input bug. Remember our actual EVO champ blames this among other stuff for his decision to stop playing this game. If that doesn't look in the eyes of a capcom fan (Most of the fighting games fans really) a big "Screw this game, too buggy to compete in", I don't see what it does look like.

The dash system worked great and I didn't see people complaining about it (Doesn't means there wasn't, i'm not that well informed). I don't see a reason to turn something that was good into "fine".

I do agree that this game is still tournament worthy and I love it, don't mean to bash it, but it's so far away from what it could be.

---

Boon said "No more DLC", so no more chars for us (MAYBE a Halloween surprise, but I still think thats unlikely) =/

---

 

[GUTTY333]

Interviewee- NRS what are your thoughts on the input bug?

NRS- Whats that?

 

[Sasuga]

Nice job man. Looks like u used sixemu. I wanted to do the same kind of tests but I'm too lazy I guess

I think I can explain the inconsistency however. A flaw in a test like this is the input that is not synched with the game frames. A frame has a certain time-span and if you input at intervals that do not equal the frame-rate exactly, your input might span over more frames at certain points. If you press down for example at the start of a frame, the 1 command might fall in the same or in the next frame, counting as standing. But if you press down at the end of a frame, the 1 might register 2 frames later, where the character is already in the crouch position. If the game animation runs at 30 frames (33,34 ms/frame) I can imagine that a 40 millisecond gap between button presses would yield said inconsistency.

[EDIT] On 60 frames, output may look like this. I can't verify it right now. Input down at time = 0. Input 2 with certain delay.

Frame	start(ms)	end(ms)	output
1	0	16.67	iUC
2	16,68	33,34	iUC
3	33,35	50	st2
4	50,01	66,67	st2
5	66,68	83,34	st2
6	83,35	100	st2
7	100,01	116,67	UC
8	116,68	133,34	UC

iUC = instant uppercut
st2 = standing 2
UC = uppercut

I think the game only renders ~30 discriminate frames though, maybe input is also registered in 30 frames.

 

[webreg]

I have acquired quite a good understanding of how inputs are processed during the last few days and yes you are absolutely correct and I have incorporated this flaw into my testing process. Your assumption of roughly 30 ms per input frame is correct. However, MK9 and other fighting games I have tested have a failsave in place for the scenario you describe (might be PS3 native). The order of the commands is also processed. It doesn't matter if you press a directional command ("up" excluded) together with a button in the same input frame as long as they are in the correct order. Inputs work with 0ms between them. The only rule that must be folled is, that a command should be pressed for at least 30ms because otherwise "button down" and "button up" might fall into the same input frame and the system doesn't know that something happened but as I said earlier, a human and a normal controller is not capable of doing that anyway.

So while your point is valid, it's not adequate to explain the problem itself because it happens between 90ms and 120ms after the "down" input. Multiple input frames after the "down", not within the next two. What you explain however is something I have discovered myself yesterday and let me write this a bit more prominent for the other people who skip over my tech-rant here:

The "input bug" is not random. I can reproduce it with 100% accuracy every time. The fourth input frame after the "down" seems to completely ignore, that you are ducking. The randomness where sometimes it did work was due to an slight inaccuracy in my methodology and for that I apologize. See Sasuga's post for an explanation on what I did wrong at that time.

[MENTION=6085]Sasuga[/MENTION]
I would very much welcome you to challenge my findings because as long as only one person is testing it, there will always be errors and everyone who confirms or refutes it helps to paint a more accurate picture.

 

[Tremloc]

first, great job by web.

I think the game only renders ~30 discriminate frames though, maybe input is also registered in 30 frames.

It's running at 30fps, but the input processor on the 360/ps3 runs at 120Hz. That doesnt mean mk is capturing input at 30 or 120 and it's difficult to venture a guess because all games do it differently.

Input bugs are actually very common in video games and they're tough nuts to crack.

 

[webreg]

All you need to do is test the "liu kang b+3,1,2 punish" test. And you''ll get standing 1s and 3s for NO REASON! And it DOES happen randomly. This was tested in training mode with two human players.

I haven't made a video because I wasn't able to reproduce it and let me explain to you how I tested so you can see I was quite thorough. Now, let us take a look at the input script:

KEYDOWN BACK
DELAY 45 //checkpoint alpha

KEYDOWN 3
DELAY 45
KEYUP 3
DELAY 45 //checkpoint beta

KEYDOWN 1
DELAY 45
KEYUP 1
DELAY 45

KEYDOWN 2
DELAY 45
KEYUP 2
DELAY 45

KEYUP BACK

A bit of info about the delays first. The game collects the state of all buttons and directions roughly every 30ms and compares this to the state of the previous collection to see what buttons have been pressed or released. This means, that in order to make an input count you have to press it for at least 0.03 seconds. In order to do a reliable test I have to go multiple times through all collection intervals to see if there is one that behaves different from what it should.

This means I tested the two delays with iterations of 0/15/45/75/105/135/165 ms in every combination and made runs of at least 20 inputs each. Yeah, that's a lot of inputs and Sub Zero hates Liu Kang now. Anyway, iterations of 15 ms is the way to go because this is the most reliable way to hit the input frame. The third input frame is 60ms to 90ms after the last input and 75 is right in the middle. Due to technical constraints I can't rule out shifts in synchronicity and that's why I did it 20 times for each test.

Not one of those 980 inputs failed. Because I have no live I did some additional tests to see what circumstances could actually lead to "standing 1s and 3s". And only four of them are somewhat realistic:

• If you hit "3" earlier than "back" and yes, even 1ms earlier, then you get a standing "3". Other games might do it differently and apply more leeway but MK9 does not.
• "Back" was released earlier than "3" was hit. Standing "3". Unlikely with players that know what they are doing.
• "3" wasn't hit properly, didn't register and "back" is already released. You get a standing 1.
• "3" was hit so fast a cat on crack would be envious. Pressing "3" for less that 30ms and doing so at the beginning of an input frame won't register the button and yes, I say it again 0.03 seconds. Most unlikely in my opinion.

 

[MKK hanzo]

i dont think im always getting input bugs on clones... i KNOW it. i just watched 99999 MKDC matches of mine. GL's db+1 is his green hand.. out of 999999 green hands know how many 1's or b1s i got? ZEROOOOOOO....

out of 99999999 green hands i missed 5... FIVE!!! and it was because i was early after the breaker. in MK9 i miss clones at least 30% of the time, i KNOW how to hit db+1. im going to say that 99% of the time that i get a B+1 that its the bug.

I was thinking on MKDC too, AFAIK there werent that many controller problems with that game aside from the huge buffer between directions to make specials easier...

Hmmmm I want to play that game again XD

 

[GGA soonk]

...

I already posted, that's not what he meant. The B312 comes out fine, it's the opponent trying to down poke out that sometime gets a standing attack.

 

[webreg]

Here the proof, that this error is reproducible with an accuracy of 100%, no randomness involved. Look at the inputs and in addition you can see, that after each hit Scorpion goes back to crouch (only a splitsecond because I have chosen a close interval for repeating the inputs).

 

[webreg]

Oh I forgot to mention, that it also affects uppercuts in the exactly same way.
Actually no surprise there regarding what is known now.

Next test will be about combos that involve "down + button". For example Smoke and his "3,d1,2". Would be a huge disadvantage to such characters and Smoke especially since that is his "go to" move in most situations.

 

[GNG Iniquity]

it also affects uppercuts

Would you mind testing D4? Reptile, for instance, uses D4 as an AA and from what I've read that often drops as well - D3 may be exempt from this but I doubt it.

 

[GGA soonk]

Would you mind testing D4? Reptile, for instance, uses D4 as an AA and from what I've read that often drops as well - D3 may be exempt from this but I doubt it.

Happens with all down attacks, 1 2 3 and 4

 

[GNG Iniquity]

Happens with all down attacks, 1 2 3 and 4

Thanks, I had assumed as much, but I wasn't sure!

 

[Sasuga]

So while your point is valid, it's not adequate to explain the problem itself because it happens between 90ms and 120ms after the "down" input. Multiple input frames after the "down", not within the next two. What you explain however is something I have discovered myself yesterday and let me write this a bit more prominent for the other people who skip over my tech-rant here:

The "input bug" is not random. I can reproduce it with 100% accuracy every time. The fourth input frame after the "down" seems to completely ignore, that you are ducking. The randomness where sometimes it did work was due to an slight inaccuracy in my methodology and for that I apologize. See Sasuga's post for an explanation on what I did wrong at that time.

Ok, but then it's pretty much solved, right...? If you input attack-button after down within the next 3 game-frames, you get an instant poke/uppercut. 1 frame after counts as still standing while you are on your way to enter crouch state. So if you were to do input within this particular frame, you would get the standing poke. After that, you are in crouch state, you can poke/uppercut all you want and make sub-zero's face the same color as his costume XD

If they were to speed up the crouch animation by 1 frame this would pretty much be solved...? To eliminate that gap.

 

[GGA soonk]

Ok, but then it's pretty much solved, right...? If you input attack-button after down within the next 3 game-frames, you get an instant poke/uppercut. 1 frame after counts as still standing while you are on your way to enter crouch state. So if you were to do input within this particular frame, you would get the standing poke. After that, you are in crouch state, you can poke/uppercut all you want and make sub-zero's face the same color as his costume XD

If they were to speed up the crouch animation by 1 frame this would pretty much be solved...? To eliminate that gap.

Then explain why you can do instant D1s.

 

[webreg]

If they were to speed up the crouch animation by 1 frame this would pretty much be solved...? To eliminate that gap.

Your inference does make sense but so would other explanations (I have a couple of them). There is no way to narrow it down to the very end without access to the source code or debugging the PS3 and I think we don't need to. The behavior is there, can be reproduced and absolutely makes no sense in the context of the game mechanics. Now it's in the hands of the developer. All we can do if NRS doesn't react is trying to figure out if the problem is truly limited to "down+button" or if other moves might be affected as well. So far there is no real proof of that only anecdotal evidence.

 

[Sasuga]

@soonk : It seems to me that the crouch animation is 6 frames. If a player would have to wait 6 frames to do uppercuts or low pokes or footsies, they would not nearly be as usefull. So NRS allowed instant versions of chrouch-moves. As it seems now the window for these instant moves is 4 frames, very lenient actually. The fifth frame of the crouch animation, you count as still standing, which you would have been without the instant-leniency. If this all is true, it could be fixed by removing this frame from the crouch animation or, even better, make it lenient for one more frame.

This seems like the most logical explanation. Concerning the crouch-moves at least.

About what Tom says about ice clones: Maybe he executes the iceclone during a similar "black hole frame". It might also be there in there in standing-up animation as well as other recovery animation. In that case it would be more like an actual bug, because you would be able to do an iceclone while standing. I may be able to do some testing with this tonight. It would render my previous theorie obsolete.

I am just thinking out loud by the way. What do you think @webreg?

[EDIT] On the other hand; you're right about one thing Webreg. NRS should have enough insight in the matter and the properties of the exposed frame. It is in their hands now. I just hope they will fix it

[EDIT2] Crouch animation would be 6 frames, i wrote 5 earlier. My bad.