Programmable inputs / Esoteric frame data Q&A

with guard.

 

you mean like how soon after exiting flamingo can you guard? This should be pretty straightforward to figure out with a local friend, just enter flamingo then guard, while they do progressively slower moves.

Or did you mean something else?

 

no that's what I mean, being able to exit flamingo and then guard. I'm just curious to how fast Sarah can get out.

 

We were curious about canceling flamingo and throwing, I think. But just the simple speed it takes to exit FL and block should give us what we want.

 

Awesome research and post KOD! I just saw it today and thought I'd give props.

 

I'm relatively new to the game and don't know too much about frames yet, but is the frame data for shun's drinking animations known?

 

KoD, can you find out in what specific frames Sarah is jumping (and thus will avoid lows) during her Side Hide Kick ( /forums/images/%%GRAEMLIN_URL%%/p.gif + /forums/images/%%GRAEMLIN_URL%%/k.gif)?

 

KoD do you have your Arduino wired directly to you controller PCB ?
Or do you have an Optocoupler per button ...

 

There are no optocouplers / solid state relays or anything of that sort. The arduino is wired directly to the controller pcb, very straightforward. If you're interested in making one you should.

I've updated the first post to hopefully make it clearer on how to obtain programmable inputs, including a consumer device 001 has been playing with.

 

I hope I am putting this in the right place.

After some matches, Feck and I got into a discussion about Akira's SDE (666p)being beaten out by my P in a +4 situation, and initially we chalked it up to online lag. The more I thought about it and looked at it, the more questions I had.

Here's the situation: he lands a PK leaving him at +4. his SDE is 14 frames and my P is 10, leaving them dead even and executing at exactly the same time. Therefore, the SDE would win with more damage. However, inputs are 1 frame each at best, and the buffer plays out frame by frame for each player equally. Therefore, in my mind, this picture shows the buffer and why (maybe) my move was landing first, all things being equal:


They both have an EXE of 2 frames, so I cancelled that out of the equation ahead of time.

My question is: Is this a correct expectation of how the buffer plays out? does it tick off a frame (or more) for each input entered when putting these moves against each other? If so, my P should have at least a 2-frame advantage over his 666P, given the 66 that gets counted before the 6P.

OR, does the system see that the 666P in the buffer is really just 1 14-frame move, and start it there, putting it dead even with my P, thus beating it?

Otherwise I had lag in my favor? I always thought lag affected us equally leaving us still in the same spot, but I don't really know.

 

With commands that involve a dash command (44, 66, 33) you can pretty much add 1 frame to the execution, meaning most of the time an SDE will come out in 15 frames.

It IS possible to get it out in 14 frames, but you'll have to buffer it extremely early. Say if you want to do PK to SDE, you should buffer the 666 command almost at the same time as you're inputting PK.

If you're playing online none of this will matter though, it's random and there's no equality.

 

Ok, but assuming I am mashing P into the buffer during my stunned frames, and he does a perfect 666p into the buffer during his extra frames, will his 66 waste frames within the buffer? I am hearing from some people that in the buffer, the 666p gets recognized and executed immediately upon buffer dump.

EDIT--
OK, I RTFM'd and the wiki says:
Fastest Timing (no 1 Frame Kill) When inputting moves normally that include a dash (or crouch dash) motion such as /forums/images/%%GRAEMLIN_URL%%/f.gif/forums/images/%%GRAEMLIN_URL%%/f.gif/forums/images/%%GRAEMLIN_URL%%/p.gif, before the move executes there will be at least 1 frame of dash motion wasted while the engine determines whether or not you're trying to dash. However, if you input the joystick motions before the input buffer, and input the buttons during the input buffer, then the move will execute in the fastest timing, and there will be no 1 frame penalty.

So what, then, do "before the buffer" and "during the buffer" mean?
This? \/

 

Frame-wise, this is pretty much the exact same situation as doing jab (blocked) 666p in order to beat opponent's lowpunch.

The initial jab takes 26 total frames to finish animation. The last 10 of those (17-26) are buffer for what comes out after the jab. So my understanding is, in order to do SDE and have it beat the lowpunch, you need to input 666 during frames 1-16 ("before the buffer"), and the final P during frames 17-26 ("during the buffer").

My guess is that 66 during 1-16 and 6p during 17-26 would also work. You should be able to play around with this scenario pretty easily in dojo - just set the cpu to block and lowpunch, then do jab ~ sde with different timings.

 

OK I didn't see that part. Thanks. That leaves the only 2 possible explanations for my P winning out being online lag or Feck's input. I trust Feck's input, especially over several consistant examples of my P winning.

So, lag wins. Sorry Feck.

Thanks to Myke, KoD, Jeneric, and TSF (on shoutbox) for your input.

 

I'd just like to throw in; Propz to KoD!

Very useful thread.

 

Just a heads up - it looks like some stuff got changed around in the 0012 release of the arduino development environment. I wrote this code on 0010, and haven't gotten around to updating it, so if you're making one of these, download & use the 0010 release of the arduino software.

 

I think that is simply wrong, referring to the wiki article about input buffer anyway. What it should read was input joystick motions before recovery. If you input something before input buffer IT DOESNT REGISTER.

Anyways, from my experience, if you input the WHOLE move during the 10f input buffer you get it at fastest timing.

 

You certain about that?
<div class="ubbcode-block"><div class="ubbcode-header">Warning, Spoiler: <input type="button" class="form-button" value="Show" onclick="if (this.parentNode.parentNode.getElementsByTagName('div').getElementsByTagName('div')[0].style.display != '') { this.parentNode.parentNode.getElementsByTagName('div').getElementsByTagName('div')[0].style.display = '';this.innerText = ''; this.value = 'Hide'; } else { this.parentNode.parentNode.getElementsByTagName('div').getElementsByTagName('div')[0].style.display = 'none'; this.innerText = ''; this.value = 'Show'; }" /></div><div class="ubbcode-body"><div style="display: none;">


CPU set to guard and lowpunch . . .
</div></div></div>

 

Yes, after blocked P I get a stagger off DE and float off SDE. DE is about 50 times easier than getting SDE to hit but I can do it. I never said buffering these was easy. Want a vid?