NRS.. PLEASE fix the input drop bug!!!

[Tremloc]

Whether its the engine or the game dropping the input, it's clearly deciding that the player should stand. It may not even be an input drop but what else do we call it?

Also, interesting about the negative edge correction theory. I wonder if this is why NRS refuses to remove negative edge from the game...

I'm using engine and game interchangeably and I should stop, it is confusing. What I'm saying is the engine isn't screwing up, the game is.

I don't think it's a true input drop, I think the D+ issue is just a bug in the game, and the jump issue is deliberate game code that is wrong. This is all based on the great detective work you and others have done and assumptions i'm making are based on my game development past. I'll state that all of this is speculation since we don't have access to the actual game code.

Again, hopefully [MENTION=446]colt[/MENTION] or whoever can give us an actual word on this.

 

[webreg]

I think you might be misunderstanding when and how this bug occurs. The engine isn't missing the down, the character is already crouched, then stands up and does the move, then goes back to crouch.

That's just semantics. "Swallowed" can be interchanged with anything from "misinterpret" over "state machine confusion" to "ignored". It doesn't really matter and doesn't change anything about my previous assumptions. It could also be, that the engine plays the duck animation even though the command processor thinks the player is still standing. If the engine is confused (two different sections of the code have conflicting data about the state of the game) then there can be all kind of kinky stuff happening. The input display in training is not reliable and neither are the animations on the screen. There can be no conclusive assessment if you rely on any kind of measurements from the target you wish to debug.

About game vs engine. I'm kind of certain there is no clear cut between the two. I'd say that only the audiovisual aspects are from the unreal engine and everything else is heavily modified if not completely new so game and engine can pretty much be used interchangeable. A fighting game has very specific needs when it comes to input, timing and similar stuff so I highly doubt that's original engine code.

 

[Shadowfire]

You can hold down and mash 1 all day with no issue. The issue is that coming out of blockstrings the game will reevaluate inputs/position/whatever and if you happen to hit a button during the 1 frame window I demonstrated(which is not at the beginning of the 'down' input, it's in the middle, hence the complaint) you will get a standing attack. I will make more videos when I get to Columbus and have another player.

ETA
In fact, I've already shown, and will show more later, that deliberate presses mean fuck all in this game.

Why do you need another player if this works as you describe? How is what you describe not explained by non-instant crouches? You're never crouching in a blockstring, so you need time to duck regardless of if you're already holding down. Ducking is essentially a stance with startup frames. You wouldn't expect to be able to instantly Military Stance out of a block string.

And that last statement is pretty goofy.

If that's true then it's an epic failure of design. You never, ever, make assumptions about what the player was trying to do.

Input systems in any game of any genre are fundamentally an attempt to translate a player's intentions into actions. Short of reading neural patterns, the system you describe that makes no assumptions about player intention does not, and cannot, exist.

 

[superbn0va]

the critical edge and input delay already were reasons why i messed up my game @high level. i hate it when my characters does something else instead of doing what i actually pressed/wanted. and now there is also an input bug?! this makes sense why lots of pp keep making mistakes. im not sure if it's an input drop or something similar to it, but all this sh*t needs 2get fixed next MK.

next MK NO,

* input delay
* critical edge
* input bug (something like that)

 

[GGA soonk]

I was talking about crouch blocking a string then poking out, which I need 2 people for. They did it on digital dojo the other night, but didn't explore it much.

I understand that there are crouching frames, but you can push down and 1 together for an instant d1. Crouching frames are not the issue here. 1 frame of dropped input is:

Idk about military stance, never played sonya, but I can instantly leg lift from crouch so stance frames should be a nonissue.

My last statement is neither goofy nor incorrect. In my vid I am not mashing 1 after pushing and holding down. I am executing one button press during an assumed 1 frame window(could be more, who knows) and I still get the standing 1. Thus, deliberate unmashed button presses mean fuck all.

 

[Tremloc]

That's just semantics. "Swallowed" can be interchanged with anything from "misinterpret" over "state machine confusion" to "ignored". It doesn't really matter and doesn't change anything about my previous assumptions. It could also be, that the engine plays the duck animation even though the command processor thinks the player is still standing. If the engine is confused (two different sections of the code have conflicting data about the state of the game) then there can be all kind of kinky stuff happening.

haha you said kinky.

The input display in training is not reliable and neither are the animations on the screen. There can be no conclusive assessment if you rely on any kind of measurements from the target you wish to debug.

We're debugging with the tools we have available to us, we don't have access to source code, so of course we can't be making any conclusive assessments.

About game vs engine. I'm kind of certain there is no clear cut between the two. I'd say that only the audiovisual aspects are from the unreal engine and everything else is heavily modified if not completely new so game and engine can pretty much be used interchangeable. A fighting game has very specific needs when it comes to input, timing and similar stuff so I highly doubt that's original engine code.

There is a clear cut distinction between the two. The unreal engine gives you an API to work with. They do provide the source code if you've purchased that license, but you typically don't need to go modifying it unless the engine can't do something you want, or isn't doing it in a fashion that's necessary for your title. As far as the input in concerned, I highly doubt they went ahead and rewrote the I/O portion of unreal.

 

[Tremloc]

Input systems in any game of any genre are fundamentally an attempt to translate a player's intentions into actions. Short of reading neural patterns, the system you describe that makes no assumptions about player intention does not, and cannot, exist.

You're missing my point and I should clarify. When someone pushes up on the joystick, it gets translated into a jump command. That's not an assumption. The assumption comes in where the game is saying "well he didn't push up on the joystick for more than 3 frames, so I'm going to assume that he didn't really want to jump". That sentence should be "Well he didn't push another button that equates to a ground command (like so many U+3 moves) in the 3 frame window so I'm going to jump, because that's what the player input". That's where the problem lies. It's possible they put this system in place because testing uncovered that players were getting errant jumps when using a crappy dpad, like the one on the 360.

 

[Shadowfire]

You're missing my point and I should clarify. When someone pushes up on the joystick, it gets translated into a jump command. That's not an assumption. The assumption comes in where the game is saying "well he didn't push up on the joystick for more than 3 frames, so I'm going to assume that he didn't really want to jump". That sentence should be "Well he didn't push another button that equates to a ground command (like so many U+3 moves) in the 3 frame window so I'm going to jump, because that's what the player input". That's where the problem lies. It's possible they put this system in place because testing uncovered that players were getting errant jumps when using a crappy dpad, like the one on the 360.

But that's just the assumption that players who tap up extremely briefly always do want a jump. What you're really saying is that you think the input system makes the wrong assumption.

the critical edge and input delay already were reasons why i messed up my game @high level. i hate it when my characters does something else instead of doing what i actually pressed/wanted. and now there is also an input bug?! this makes sense why lots of pp keep making mistakes. im not sure if it's an input drop or something similar to it, but all this sh*t needs 2get fixed next MK.

next MK NO,

* input delay
* critical edge
* input bug (something like that)

It's so simple... no lag and no bugs. Why didn't they think of that! You should be rich.

 

[Tremloc]

But that's just the assumption that players who tap up extremely briefly always do want a jump. What you're really saying is that you think the input system makes the wrong assumption.

I would argue that it's not an assumption when the player inputs up the character jumps. You're following the players orders.

It's so simple... no lag and no bugs. Why did they think of that! You should be rich.

Step 4. Profit! hehe!

 

[Shadowfire]

I would argue that it's not an assumption when the player inputs up the character jumps. You're following the players orders.

You can very easily accidentally get a brief up input on any kind of controller though. Sticks with short throws or small deadzones very commonly get momentary "up"s during sudden left/right motions. This is often due to the tension of the springs, without actually being the player's fault. Going from down to neutral can cause the same problem, I got this all the time on my old MASS stick.

It also happens on HitBoxes and pads, because the thumb button on a HitBox triggers in a strong breeze, and because pads are awful.

 

[Tremloc]

You can very easily accidentally get a brief up input on any kind of controller though. Sticks with short throws or small deadzones very commonly get momentary "up"s during sudden left/right motions. This is often due to the tension of the springs, without actually being the player's fault. Going from down to neutral can cause the same problem, I got this all the time on my old MASS stick.

It also happens on HitBoxes and pads, because the thumb button on a HitBox triggers in a strong breeze, and because pads are awful.

I just mentioned this exact scenario a few posts ago as a possible reason for the decisions we think they've made.

I think the window for errant inputs is too large in MK. If you really get one, it's going to be shorter than 10ms.

 

[Shadowfire]

Oops, my bad.

I did often get accidental jumps in SF4 even though I don't in MK9 for what that's worth, I mean aside from me jumping and then immediately realizing it was a bad idea.

 

[GGA soonk]

Sorry this took so long, the net here at Red Roof is trash. We recorded for a bit until I got the timing down on this input bug. 3 times in a row, and an extra one for good measure. I was holding down the entire time, so you'll never see an arrow on the input section. Please don't say this bug doesn't exist anymore, this is all the proof we need.

 

[Shadowfire]

Sorry this took so long, the net here at Red Roof is trash. We recorded for a bit until I got the timing down on this input bug. 3 times in a row, and an extra one for good measure. I was holding down the entire time, so you'll never see an arrow on the input section. Please don't say this bug doesn't exist anymore, this is all the proof we need.

It's not all the proof we need, but thank you for providing some of the first actually compelling evidence.

This proves that there is in fact a way to cause a standing normal while holding down. Also it's important to note that instant crouch normals are a red herring and appear to have nothing to do with this.

What I'd be interested in finding/getting more video evidence from you on is:

1. Whether it can be reproduced for all buttons.
2. Whether you have to be crouch blocking (will it happen when recovering from another move, or from hitstun?)
3. Whether it matters what properties the moves in the opponent's blockstring have, particularly on the first/last hit, and whether it only happens on advantage/disadvantage.

This might rule out or narrow down causes. For example, it's possible that crouch block stun itself is bugged so that you very briefly count as standing before you finish recovering.

Thank you for manning up and posting this. I'm still going to laugh at most people blaming totally unrelated losses on this though.

(Also why is your friend hitting like 8 buttons every string?)

 

[Slips]

How the hell is the debate of its existence even still going on? I thought this glitch was well known? If you haven't noticed this bug then you haven't been playin the game enough. There have been COUNTLESS times of me losing whole rounds and matches because of this glitch. What REALLY doesn't make sense, is that this glitch wasn't in the demo version, it only appeared in the final cut...which makes no sense at all.

The garbage after Liu Kang's string is just one example. 16 Bit got knocked into losers at Evo because of that exact same scenario.

Blocking KL's 1121 string, I'll hit d1 afer, the bug kicks in making me get hit by a whole new set of 112 spin, making me losr rounds.

Doing Smoke's 3,d1,2 on block and hitting d1 after the string the bug kicks in, I get a standing 11, get blown up, and lose the round.

Raiden's will do b321 shocker and I'll be hitting d1 after the string, the bug kicks in standing me up to get hit by the shocker. Lose the round.

Punishing Mileena's EX TK I block the 2nd hit crouching, then try and d1 TP, but get a standing 1 instead that gets blocked into a blocked TP. Peace out to that round.

Really, the scenarios are endless. If NRS fixes this bug, it will make a world of difference.

Hell, check out this tourney footage at FighterxShooter at 52.22. The glitch kicks in as I try and do a d1 for anti-air, but get a standing 1 instead and lose MY WHOLE BAR.

http://www.twitch.tv/focusfirefighters/b/294267961

The bug exists, it needs to be fixed, end of story.

 

[Prinz]

Sorry this took so long, the net here at Red Roof is trash. We recorded for a bit until I got the timing down on this input bug. 3 times in a row, and an extra one for good measure. I was holding down the entire time, so you'll never see an arrow on the input section. Please don't say this bug doesn't exist anymore, this is all the proof we need.

If a bug has to have timing, is it still a bug? I thought it was supposed to be random.

 

[webreg]

Read here

 

[Prinz]

Also, I see people saying "the bug" is happening more often after the patch. Ca this be related to the so called 3-frame-nerfed negative edge?

 

[aj1701]

If a bug has to have timing, is it still a bug? I thought it was supposed to be random.

Excluding faulty hardware, bugs are never random, they are always the result of a specific set of circumstannces. That means that they can be rare, but never random

 

[Trini_Bwoi]

Can someone test if holding DF or DB prevents this?

 

[Carefoot]

You can hold down and mash 1 all day with no issue. The issue is that coming out of blockstrings the game will reevaluate inputs/position/whatever and if you happen to hit a button during the 1 frame window I demonstrated(which is not at the beginning of the 'down' input, it's in the middle, hence the complaint) you will get a standing attack. I will make more videos when I get to Columbus and have another player.

ETA
In fact, I've already shown, and will show more later, that deliberate presses mean fuck all in this game.

My only claim was that if you deny this game is dropping inputs (something you can confirm by splitting the USB from your controller to PC to console) than your a fucking moron.

Its a fact.

We're trying to help find the root of the problem, symptoms and conditions.

I am starting to suspect that the unreal engine (an engine which has its roots in FPS) may not be the best at hitbox engine where as with the projectile part of the game (mid-max screen) I see no strife but up close there seems to be a lot of chaos and the specific place where I experience dropped inputs the most.

I feel bad for the professional community who plays this game because at the higher level it sounds like its really frustrating. The match between CDJ and M2Dave I could hear them groaning and between matches Tom just got flooded by trolls denying the input bug.

I mean I don't understand a gaming community that doesn't keep competitive play at the pedestal and instead just accuses them of being part of a witch hunt. The bug is real the question is it even fixable?

It could very well be an artifact of the Engine that may never be fixed in this iteration of MK.

 

[Shadowfire]

Read here

This is the most definitive proof. I recommend the discussion migrate to this thread.

And I also recommend that people stop being morons that don't actually read the OP and thus talking about the non-instant jumps like they're related to this.

 

[Durango]

Getting to the point where I may quit this game. I just barely squeezed out a win against a Scorpion because my Ice Clones and Ice Balls weren't coming out.

 

[aj1701]

Getting to the point where I may quit this game. I just barely squeezed out a win against a Scorpion because my Ice Clones and Ice Balls weren't coming out.

A few posts up is a link to someone that did some computer aided testing of the input bug. Short story is that it does exist, but it doesn't appear to impact specials. So if your specials aren't coming out, its likely an execution error. The input bug is limited to down pokes AFAWK right now.

 

[GUTTY333]

My thoughts on the input bug.

http://s1.static.gotsmile.net/images/2010/10/07/fish_face.jpg_1286400088.jpg