Oh, I’m not delving that far into it, I’d have to find the tables for the characters and have no idea where they are in ROM.
Very cool Pasky
Stepping back from picking and working on individual “features” to be added to the Pasky HUD, is there a way just to list out the universe of “possible features” in a list?
That way we can then:
- add a box next to each and check that box if it is in the Pasky HUD (this gives the HUD current feature set)
- see what all is possible with the Pasky HUD
(with crude approximate time requirements to add if its handy)
That way we can indicate/voice/debate/lobby/beg what features would be neat to add next. AND we can also get a sense of the scope and scale that the Pasky HUD covers as a tech.
What’s the point of this?
Seriously? You gotta ask?
Did you not read the posts? It’s for frame advancing, figuring out exactly when a move is charged/ready. Figuring out exact throw distances for each character, when a move can truly be cancelled. This isn’t a stupid training mode, this is for people who frame advance the game and want to figure out exact mechanics…
EPIC face palm bro!
Stun meter added:
I suppose it requires some explanation for the feeble minded:
What you normally saw as a stun meter…was only half of it. What that half is…is a counter. While that number is positive, the stun won’t decrease.
The REAL stun meter only increments up to 30, if it is equal to or greater than 30, the character goes dizzy and both counters reset. So as long as the first value stays positive(The counter), the 2nd value (The stun meter)will not decrease.
Cauldrath figured out those stun mechanics in the “Things you just don’t understand about ST” thread.
I was being flippant in how tersely I phrased my question, but my question could be better phrased as: to what practical uses can this be put? So for example, if you give this to Mattsun or Taira, how will it help them? It seems to me that knowing the ‘exact mechanics’ (as you put it) does not have much practical application. Pixel differences or microsecond differences are changes at the margin.
But I am happy to be proven wrong… we’ll see.
Knowing exact values gives you comparisons and benchmarks when performing moves, if you know giefs max throw range, you can then compare against it when ticking normals during push back to discover maximum length blockstrings with different normals before he can spd for instance. Knowing how many steps it takes to get back in range after an spd. If you can see the difference in number, you can see how far that distance is visually.
Also, this is nowhere near microseconds, well I guess its 16667 microseconds, but if you can’t time 1 frame links, I don’t think you’ll get places in fighting games anyways. Why is frame data useful? Well this is the same shit, except its showing you the frames for charges and execution moves and how long they remain, by the frame…not by the microsecond.
Do you how know charges are handled when you cross someone up? You can find out now. You can also see if the charge is maintained if the charge character switches directions as the opponent goes to the other side.
It’s like saying “Whats the point in knowing the exact hitbox for a move? I know how far I gotta be to hit them.”
Like seriously man…I can’t believe you can’t see the usefulness.
Good for him!
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.
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.
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.