I wasn’t trolling; believe it or not. I hope that people publish their findings to this thread which they have identified using this tool. Until then, I remain skeptical as to the practical application.
Edit to add: to repeat my earlier point, pixel and microsecond differences only matter at the margin.
This can be useful for more easily finding a setup to be the exact range to be slightly outside someone else’s throw range.
T.akiba has already compiled the throw ranges, and someone messing with the setups should use it as a reference.
It’s interesting to note that you get pushed farther from your opponent if you land a jump-in attack really deep rather than if you land it slightly higher.
If you wanted to improve this tool pasky, you could try adding another hud display for “throw range” which would be the distance between the nearest sides of the collision/push box between the two characters. Right now, the range just calculates the distance between the center of the pushbox.
I prefer the center of the of the characters axis in the middle of the hitbox (pushbox). It makes no difference if the calculation is done between the two characters hitboxes, because the distance is just a number, it would only change the number but the two dummy distances would still remain the same, as long as the calculations all use the same method to get that number…what difference would it make?
Also, I’ve come close to finding the base values for damage on, or at least how damage is calculated. I set a breakpoint when the dummies life is written to, and the value is gained 2 or 3 lines above the sub.w ASM (it subtracts the value in register D6 from the value at the address of the dummies life) and is stored in register D6.
However, I can’t backtrack any further due to limitations of the MAME debugger and any addresses above that address are not executed when damage is taken so setting breakpoints above it does no good since it’s probably a branch jumping to it. I’d have to disassemble the ROM and I don’t know how to disassemble an encrypted cps2 rom, but I’d be willing to take a look if someone has a decrypted SSFT2 ROM.
I have however been able to view further back using cheat engine, however 68000 is a big endian cpu so the addresses are backwards in cheat engine and x86 doesnt translate well from 68000 so i can’t debug it through cheat engine.
But the cheat engine inside mame is limited and has no access to the decrypted CPU instruction memory and its a pain in the ass accessing the mame decrypted cpu memory section using cheat engine and inputting everything backwards to test.
EDIT:
Ah cool nevermind, I can run trace to log the cpu functions and just backtrack the log (which is essentially the ROM decrypted and being executed).
Also, messing around, I found out exactly why sometimes I would not get moves even though I swore I input it correctly.
As can obviously be seen by using pasky’s hud display, ST’s input system works by just incrementing a counter for a certain move every time you input the next expected direction for that move. You have to input the next direction within a variable timeframe. The first input needs to be input within probably around 7-15 frames. The other input windows after the first seem to be ~6 and more. Each type of special move keeps track of its own window separately. Super input windows are much larger. However, if you don’t input the move within the time frame, the counter will reset to 0 for a frame and will wait for the first directional input again.
This has repercussions. If you input the second part of a move exactly on the frame it gets reset to 0, it will not count towards inputting that current move! For example, if you hold toward, then input down then down-toward on the frame that the counter resets to 0, you will not get a dp input. With ryu you will just get a normal attack. If we assume a uniform distribution of the variable input window for the first directional input of a move to be between 7-15f, then there’s an ~8.8% chance your move will just not come out if you’ve been holding down that direction. This applies to every single special move in the game.
If you try to do a walk-up spd and you hold toward for longer than 7f, there’s just a random chance you won’t get it. If you’re holding down to punish an enemy’s recovery in anticipation of just easily closing out the match with rekkas, your rekkas will just randomly not come out. If you’re holding back OR down-back for a while and then input cammy hooligan or fei chicken wing, it will just randomly not come out. If you’re holding back with fei to block a jump-in attack and then input reverse dp, the game will just randomly not recognize that you even input the correct directions in the first place.
The only way to avoid this situation is to make sure that the countdown for your move is completely timed out which can be accomplished by just holding any other direction than the first or neutral for at least 15f. If the countdown timer hasn’t reset to 0, then you are still susceptible to your move just randomly not coming out. In fact, for a dp, if you tap toward, neutral, then toward within 6f you have a much higher chance of your dp not coming out.
This system explains why you can’t easily do qcfx3 to input super moves. It explains why if you do a 360/720 input with the correct timing but had input a few directions beforehand, you won’t get the 360/720. ST uses a counter system per move and it doesn’t actually keep track of a buffer of past input moves. If st just looked at a string of inputs, inputs like those should easily work.
Note that for 360s/720s, the counter starts counting down for a possible 360 whenever you input or hold either 2468. This means if you’re doing a tick setup, DO NOT HOLD one of those directions at the start or you will randomly not get your spd. Also, if you input something like 8426+p (needed by gief in the corner) off of crouching jabs while holding down-back, brushing “down” or “back” on your way to “up” will start the countdown and drastically narrow your input window for spd.
Pasky, characters have different sized collision/push boxes. This means that while a throw range will be the same distance between the nearest sides of two push boxes regardless of the characters, the distance between centers of these boxes will be different for different characters.
I see, in that case I’ll add it when I get some time.
EDIT:
So wait…so you’ve confirmed throws go by pushboxes and not character position? Did you check against their hitbox (blue)?
Distance between center when ryu & ken push against each other: 32
Max distance between center for ryu to throw ken: 77
Throw distance and distance between sides of pushbox: 77-32=45
Distance between center when ryu & sim push against each other: 38
Max distance between center for ryu to throw sim: 83
Throw distance and distance between sides of pushbox: 83-38=45
Actually wait I guess you’re right it might not be pushbox distance and there’s some other factor.
Distance between center when ryu & honda push against each other: 46
Max distance between center for ryu to throw honda: 76
Throw distance and distance between sides of pushbox: 76-46=30
Blue hitboxes wouldn’t explain this wierdness either.
Okay, then I’ll add it when I have time.
I don’t know what explains this. Ryu is aligned so his pixels match. All at max throw range for ryu in frame advance:
That’s strange how Honda is closer hitbox wise yet that is still max throw distance…hrmmmm, I don’t have time right now, I’m in class, maybe this evening if I’m not tired I’ll check that out more.
Also, found when D6 is written to for the damage value:
0BEDA4: move.b (A1,D0.w), D6
Anyways I got class.
ComedyBlissOption, pasky & all, you guys combined are even better than NKI at his prime 
I’m still digesting your post regarding input counter reset to 0.
I understand the 8.8% chance your move won’t come out if you hold the first direction down.
This sucks cause I do walking dp all the time and now I know I have a chance of screwing up even I input the motion perfectly.
But why would it still fails if I go back to neutral and input the dp immediately?
Also, now that I think about it, this doesn’t seem to be “fair” to all charge characters. So you always have a 8.8% chance of failing sonic boom if you hold back?
That’s exactly what t akiba found too. That’s why the “average” throw range I calculated on my website doesn’t make sense to Born2SPD. It’s all relative. (i.e. ehonda has the best normal throw range against the rest of the cast, yet his “average” throw range is not the largest)
BTW, ComedyBlissOption, don’t know if it’s too much to ask, it would be awesome if we can have image captures of each character max throw distances.
That could be a lot (at least 16x16, plus some characters have more than one throws with different ranges, plus command throws and gief/hawk super), but that would be really helpful to get familiar with all those distances for your main.
:tup: :tup: :tup:
CBO can you post up images of max range 360/720’s for Hawk and Gief please ?
Born2SPD has identified patterns in the max throw distances so that one could obtain them from the distances in relation to Ryu and certain values which are character-dependent. You can not get the values against Ryu and think they apply to different characters. He tried to explain, but failed miserably. Anyway, T. Akiba does have a table for all throws, all characters and all SF2 versions.
Such selfish request!
ComedyBlissOption, if you were to do them, do gief/hawk last!
The table is good for determining who beats who. But it’s useless to learning the actual distance for your main.
An image capture of the max distance OTOH is very useful.
Exactly, that’s why I said it will be a matrix of at least 16x16.
Edit: looking at the pictures, I think the throw distance is calculated from ass to ass. ehonda certainly has the largest range.
lo0l
Thanks, I’m going to post even more 
10% of walk up DP’s won’t come out? Uhm, no.
Try it. Hold toward for > 6f or just hold it for a couple seconds. Then finish the dp input quickly. You will randomly and bizarrely not get the dp input. You can test this in frame advance where the dp will simply not come out if you’ve been walking forward and you move to down on the frame the counter gets reset to 0. If you finish a quick dp input on any other frame, you will get the dp.
You can test this easily with a paused save state. Frame advance to see how many frames before the counter gets reset to 0. Then reload the state paused and frame advance so that you input down when the counter hits 0. Account for input delay. Finish the dp and you won’t get it.
Also there’s absolutely no way I’d compile data manually for anything that’s 16x16 cases.
You shouldn’t compare me to NKI he knows way more about this game than I do. I’m just messing around w/ tools other people have created.
The counter window is still going on even after you go back to neutral. The counter needs to be reset to 0 before you will get the dp 100% of the time. If you go back to toward after neutral but before the counter resets to 0, there’s a chance when you go to down you will go down exactly when the counter hits 0 which will prevent you from being able to dp.
Charge moves don’t have this problem and work differently. I guess I shouldn’t have said every move.