How to record frame data

...

so BB is either GD -6, -12, or -18. anything larger (-24 and up) is illogical.

now find the slowest move that can punish BB - hildes 6A+K will work. her 6A+K is a very fast move, but definitely not the fastest (takis 2bA is significantly faster), so its a fair assumption that BB is GD -12.

...

no camera necessary, ever, and theres NO room for error (unless you just suck at pressing buttons)

There's really no point arguing this. Seriously. I don't understand why you would want to.
 
*sigh*

how i did it with raph:
after a blocked B, B will trade with 3A
after a blocked B, 3A will trade with 8K
after a blocked B, 8K will trade with 8B
after a blocked BB, B will trade with 8B
BB on block then must be some multiple of 3
(B on block * 3 = BB on block)

I'm not quite understanding this. Don't take this as me being a dick or anything as I'm a math major and I'm actually very interested in deciphering this method. Currently though, something hasn't *clicked* in my head yet as to how this works.
 
There's really no point arguing this. Seriously. I don't understand why you would want to.
because your opening post is full of bad information, which i have a strong dislike for. afaik nobody in this community uses a camera to record impact data, so your post does nothing more than provide misinformation to people who come here to learn.

I'm not quite understanding this. Don't take this as me being a dick or anything as I'm a math major and I'm actually very interested in deciphering this method. Currently though, something hasn't *clicked* in my head yet as to how this works.
np. im not sure where youre at w/ this, so i guess ill start with the basics.

all moves have +/- frames on NH (normal hit) CH (counter hit) and GD (guard/block). if a move is GD -4, then that means it leaves you at a disadvantage of 4 frames if the attack is blocked.

if youre left at a disadvantage of 4 frames, then you must use a move thats 4 frames faster than your opponents to have both moves impact at the same time. we use the reverse of this when calculating frame data - if 2 moves impact at the same time when one player is at -4, then that players attack is 4 frames faster.

in short, everything from here is all simultaneous equations. im going to be lazy and just c+p another post of mine that explains a similar situation in a different way. (ive been arguing with people about whether throws are i16 or i17, whether K is i12 or i13, whether sophs A is i11 or i12, etc... since release so ive got like 10 or so long-winded posts explaining exactly how to figure this stuff out)

oh yeah, and when i say "after a blocked B, B trades with 3A" this means:
go into training
record B, B
play it back
block the first B
immediately use 3A
your 3A will trade with the second B



Kolhell said:
you can get exact frame data by solving simultaneous equations and using a bit of logic.



ok first im going to define some variables to represent unknown frame data for some of raphs moves:

bB = frame advantage for B on block
b6B = frame advantage for 6B on block
bBB = frame advantage for BB on block
iB = impact on B
i3A = impact on 3A
i8K = impact on 8K
i8B = impact on 8B

after a blocked B, B will trade with 3A.
-bB + iB = i3A
(its a minus sign bc this the standards for frame advantage notation are stupid)

after a blocked B, 3A will trade with 8K
-bB + i3A = i8K

after a blocked B, 8K will trade with 8B
-bB + i8K = i8B

after a blocked 6B, B will trade with 8K
-b6B + iB = i8K

after a blocked 6B, 3A will trade with 8B
-b6B + i3A = i8B

after a blocked BB, B will trade with 8B
-bBB + iB = i8B

im gonna add some crap here bc this is whats relevant to your question.

1) -bB + iB = i3A
2) -bB + i3A = i8K
3) -bB + i8K = i8B
4) -bBB + iB = i8B

from 1 & 2 you get:
5) -bB + -bB + iB = i8K

from 5 & 3 you get:
6) -bB + -bB + -bB + iB = i8B

from 6 & 4 you get:
-bB*3 + iB = -bBB + iB


with this you can show that:
2*bB = b6B
3*bB = bBB


we know that these variables MUST be integers (no decimals/fractions in frame data) so if bB must be = -1, -2, -3, -4, -5, etc... then bBB must be = -3, -6, -9, -12, -15, etc...

now, if you take ALL of raphs moves and mark down which ones are equal to each other on impact and then rank them from fastest to slowest, youll see that there are at least 11 "steps" between B and 8B:
iB < i1B < i8A+B < i6B+K < i3A < i22B < i4B < i1K < i8K < i22A < i8A < i8B
so according to -bBB + iB = i8B, bBB cannot be -3, -6, or -9 as that simply would not leave enough steps in between B and 8B for all of these moves to be ranked in this order. this narrows BB on block to -12, -15, -18, etc...

according to tiamats data sophs A is i11 and cass' A is 1 frame slower at i12. sophs A can punish a blocked BB while cass' A cannot, which means that the impact frame sophs A = raphs disadvantage on a blocked BB, which makes sophs A = i12, i15, i18, etc...



well get back to that stuff later, but for now we need to relate a couple more moves to each other:

after hitting with raphs A, 3A will trade with B. this means that raphs A on hit gives the same number of frames advantage as B gives disadvantage on block.

after hitting with raphs A, B will trade with soph's A.



ok, so now were going to make a couple assumptions.

first: well suppose raphs BB is -12 on block. this would make sophs A i12, raphs B i16, and raphs 8B i28 (connects .467 seconds after input.)

second: well suppose raphs BB is -15 in block. this would makee sophs A i15, raphs B i20, and raphs 8B i35 (connects .583 seconds after input.)

this is easily checked with a stopwatch - 8B takes just under a half second to hit after input, so BB on block is -12 and sophs A is i12. i could give a more elaborate proof of this, but i dont think anyone here wants to read more of that.



alternately we could just use occams razor (in short: the simplest solution is correct) and say that since tiamats impact data is -very- close to accurate, it logically follows that his system is correct and only 1 frame off rather than that the whole thing is flawed.



kosher?
hope that helps rico. if youve got any questions then please ask, as i love this stuff.
 
because your opening post is full of bad information, which i have a strong dislike for. afaik nobody in this community uses a camera to record impact data, so your post does nothing more than provide misinformation to people who come here to learn.
Your logic is somewhat flawed. You assume that because no one else uses this method, the method is wrong. There's a strong disconnect between cause and effect there.

Just curious, what do you think is more accurate, a stop watch or a high speed camera where you can advance time 1/60th of a second at a time?

Anyway, as basically everyone in this thread but you have agreed that you need a starting point, and someone already did that to find some impact data, I find it pointless debating this topic any further.
 
Your logic is somewhat flawed. You assume that because no one else uses this method, the method is wrong. There's a strong disconnect between cause and effect there.
the method is "wrong" because theres too much room for error. counting frames, determining the delay between input and the beginning of the move, inconsistent frame rate on the tv (sc4 on the ps3 is notorious for slowdown), the fact that you cant press and release a button within 1/60th of a second - all of this creates a very high probability that data gathered in this way will be a frame off.

Just curious, what do you think is more accurate, a stop watch or a high speed camera where you can advance time 1/60th of a second at a time?
and whether hildes 6A+K is i12 or i24 can be checked with a freaking stopwatch.
ill trust a person to time .2 seconds on a stopwatch LONG before ill trust them to pick out the exact frame when a button is pushed on a 60 FPS recording. .2 seconds isnt fast by any means, and the difference between .2 seconds and .4 seconds (12 and 24 frames) is well within the limits that are detectable by a human.

hell if you WANT to use a high speed camera for this part then by all means, but its hardly necessary. a stopwatch isnt even necessary - there are other ways to prove this w/o ever guessing at whether a move is i12 or i24, but i cba to teach them to people who have trouble grasping the preliminary steps.

Anyway, as basically everyone in this thread but you have agreed that you need a starting point
fine, then basically everyone in this thread is an idiot. im here trying to teach you a better way to find that starting point yourself, but if you want to wallow in ignorance then i cant be faulted for it.

and someone already did that to find some impact data
oh yeah thanks for the reminder - that was ME.

bottom of page 1 i encounter problems with the previous system where throws were i16
http://www.caliburforum.com/forums/showthread.php?s=&threadid=34318

second post on page 2 is the first record (afaik) of anyone showing proof for throws being i17
http://www.caliburforum.com/forums/showthread.php?s=&threadid=34318&perpage=25&pagenumber=2

I find it pointless debating this topic any further.
if you find it pointless to debate this further then youre more than welcome to stop. i dont, so im going to continue posting in hopes of educating you.
 
hope that helps rico. if youve got any questions then please ask, as i love this stuff.

Yeah, all I needed was the red stuff. I just wasn't associating the block frames as quantifiable terms in an equation. Your logic is quite solid and I find it to be a simply ingenious method of determining a starting point for frame data.

Oh, and I was the one who said a starting point has to be found, and yes, SOME people have used the 60fps camera method to find a starting point for frames in fighting games where no other method seemed possible. When done appropriately, the margin of error is generally around a single frame. It's not all that rare to see entire sets of data based off of this method actually.

I'm always blown away by what can be discovered using math in scenarios where there seems to be no possible way around inexact means.

You've got my vote and I will trust any data you post.
 
I'm surprised nobody (here or at CF) has posted the frame data of Sophitia moveset, so I guess I can try to do it.

EDIT : I will be using your (Kolhell) Raphael data, if you don't mind.
 
Back