Super Turbo HUD

Cool. Are not these values different for SSF2 characters? I recall VF4 would use O.Boxer and grab as much as he could because that character got even more headbutts by default, without mashing.

There is at least one last “meter” that is to be identified, which is the one that determines when the homo loses the claw.

BTW, now that the distances can be measured, it should be easy to get accurate distances for all the stages. I will do this when I am done with frame data and damage/stun (which, have I ever said, are quite annoying to obtain).

I didn’t think claw’s, “claw meter” really mattered. Do people really care to see this? I mean I could find it quickly…lol

Don’t think I’ve implemented old characters.

:tup:

so you got the address from the mame-cheat you linked?

do you think you can figure out what triggers the `hyper’ hold?

I didn’t get any address from anything.

I found the grab flag and values myself. I just updated the training cheat with the new one from d9x.

Learn to read fagasi.

Shame on me if I implied anything like stealing-- however I think our efforts are fairly open but yes, by all means, better to confirm to be sure.

Interesting-- I’ll take another look when I can then. I use ASCII characters for the input display in my (stolen) scripts (toggle with hotkey 5), however this could be easily modified to use images as some scripts already use images. I have it set up now to display images on a range of frames you specify (eg Standing 720 script, or Special Moves Fireball script). It might seem kinda buried in the rest of the code so if you want to try a similar approach let me know and I’ll direct you to the specific line numbers.

There is a counter at FF8AFF that goes up by 2 every time an opponent is dizzied, and this counter is offset into a table at 7F1C6, which stores the values for when an opponent is dizzied. The first number is 30, followed by 34, followed by 14 35s. If you dizzy someone 16 times, it resets the counter to 2, so they can be dizzied with 34 again. These numbers are from the world version.

Just so you don’t have to search for these things yourself, there is a reason I documented all the memory addresses when I did the research in that other thread. There might still be some useful stuff in there, if you sift through it.

No fancy interface would be necessary. But if I could find attacks that can remove his claw faster, that could help. He can usually get it back easily, but when he can not, at least his dives get a bit more fair, if I can find a way to turtle at the other side of the stage.

Cool. So the maximum value for the dizzy counter is 35, which I doubt many of us have ever seen considering it’s pretty fucken hard to get 2 dizzies in a row. Which means its probably impossible to even dizzy 3 times in a match anyways, meaning 34 is the realistic number anyways. I’ll just leave the script as is, no point adding numbers that aren’t realistically used.

However:

I just reversed how the game determines the dizzy type you will recieve (birds, angels, stars, reapers etc…). It is completely random (well, as far as CPU randomization goes).
[list]
[*]The game first makes a LEA (load effect address) to store a value into register A0 @ 07A646, this value is random.
07A646: lea (A0,D0.w), A0

[*]The game then moves a value into register D0 from the location of register A5 + 0x2D1 @ 002EB4, this value is also random.
002EB4: move.b ($2d1,A5), D0

[*]The value inside of register D0 then has a bitwise AND calculation done to it against 0x3E @ 07A64E
07A64E: andi.w #$3e, D0

[*]Finally the dizzy value administered is retrieved from the location of A0 + D0.w, this always points to a table inside the rom that contain values for 60/90(angels), 90/120 (stars), 150/180 (birds), and the dreaded 150/210 (reapers) and written to the dizzy timer (the amount you of time you stay dizzy), these are max values, I think there are alternate values for the different types of dizzies (I believe stars can start at 120 or 90 etc…).
07A652: move.w (A0,D0.w), ($60,A6)
[/list]

For those who want laymans terms:
[LIST]
[]The game first grabs random value 1
[
]Game then grabs random value 2
[]Game adds random value 1 + random value 2
[
]Game then takes the sum of these 2 values, this sum points to a random location inside of a table that contains the dizzy values.
[/LIST]

**
[LIST]
[]Reapers: 150 or 210
[
]Ducks: 150 or 180
[]Stars: 90 or 120
[
]Angels: 60 or 90
[/LIST]
**

For those interested: A screenshot of the table for dizzy addresses located in the actual ROM, they are hex values (obviously), so 0x3C = 60, 0x5A = 90, 0x78 = 120, 0x96 = 150, 0xB4 = 180, 0xD2 = 210.

http://img535.imageshack.us/img535/2129/tablesjc.th.png

The dizzy table begins at (ROM address): 7A69E and ends at 7A79C

So the dizzy type you receive in the game is completely random. I’ll be adding a dizzy meter when the char becomes dizzied.

Miscellaneous/useless but fun information =]:

Address Locations of what dizzy icon is being used (only 3 are used at a time):

[LIST]
[]FFC4C2
[
]FFC582
[]FFC942
[
]FFC702
[]FFC882
[
]FFD482
[/LIST]

Icon values for each dizzy type:
[list]
[]Reapers: 0x6A03
[
]Ducks: 0x6A02
[]Stars: 0x6A01
[
]Angels: 0x6A00
[/list]

Did some digging on claw’s “claw drop” feature, it was pretty fun gathering all this information because it wasn’t a simple meter. It’s actually semi-random if he will drop his claw or not.

First thing that happens is there is a counter that goes from (Player 1) 0 to 8 @ 0xff85B0 (player 2 side = 0xff89B0). This will increment by 0-2 (it’s random whether it is +1 or +2, throws do not always increment it) each time he is hit, if he blocks, or is thrown/grabbed. Once this counter reaches 8, a check is performed at 07AEB0:

7AEB0: btst D0, D1 (bit test bit # in D0, against register D1)
07AEB2: bne $7af38 (branch if not equal, tests the CPU Z flag)

If the bit test returns false, the CPU’s Z flag is set and the BNE is executed, dropping his claw. Otherwise, he doesn’t drop his claw and the counter remains 8 so another check is performed when he is hit.

The reason this is random is because the value inside of D0 is always random from previous bitshifts and ANDI instructions set to it before the check. The value inside of D1 will always be 0x5555DFDF by time the check is performed.

Randomization performed to D0 before the check is made:

002E96: move.w ($2d0,A5), D0 (the value at A5 + 2D0 is almost always different each time)
002E9A: andi.w #$202, D0 (AND d0 against 0x202)
002EA0: lsr.w #8, D0 (logical bit shift right)

D0 will always have a number from 0 to 16 (0-F), this is the bit that will be checked inside of D1.
0 = 1st Least significant bit
16 = 17th least significant bit

D1 will contain a datatype ‘long’ number that is always equal to 0x5555DFDF

**Example (No claw drop): ***
D0 = 00000006 D1 = 5555DFDF

Since D0 is 6, we check the 7th bit inside of D1, since 0 = bit 1, so 6 = bit 7.

D1 (5555DFDF) in binary is: 1010101010101011101111111011111

Starting from the least significant byte in big endian (right side), we need to move 7 places from the right. This puts us at ‘1’.

1010101010101011101111111011111

The check returns true, the CPU’s Z-flag is not set. Vega/Balrog will not drop his claw.*

Example (Claw drop):*

D0 = 0000000D
D1 = 5555DFDF

Check the 14th bit inside of D1.

D1 (555DFDF) in binary is: 1010101010101011101111111011111

Starting from the least significant byte in big endian (right side), we need to move 14 places from the right. This puts us at ‘0’.

1010101010101011101111111011111

The check returns false, the CPU’s Z flag is set. Vega/Balrog drops his claw.*

So, now for the layman’s explanation:
[LIST]
[]Every time claw is hit, claw blocks, or is thrown there is a counter that will increment by 0-2 (random, throws can sometimes do 0) until it reaches a maximum value of 8
[
]Once the counter reaches 8, a check is performed every time claw is hit, blocks, or is thrown (this includes grabs such as the knee bash).
[]There is a 2/17 (11.76%) chance he will drop his claw every time he is hit, he blocks, or is thrown/grabbed.
[
]When Vega/Balrog picks his claw backup, the counter is reset back to 0.
[/LIST]

So there you have it, another mystery solved. Claw has a 11.76% chance to drop his claw once the the counter reaches 8.

I’m awesome.

oh no, not yet. hyper knee bash? =p

[media=youtube]XV-1y_72SXY&hd=1[/media]

ORLY?

Holy shit @ Gief!

LoL @ T.hawks…that or he uses a different address…haven’t checked.

^^^ is that really you, son ?

those are pretty fast holds, but I’m not sure if they are the hyper version… see the hyper version will go at a crazy rate even before you start to mash, and the rate won’t slow down even if the opponent tries to mash it out (although they can reduce the duration of the hold).

since you’re playing a dummy p2, you didn’t simulate the situation where the p2 tries to shake it off.

anyway, appreciate your new addition with that hold meter. i’ll play around with it when i have time. thx.

No, I’m only 7.

I’ve been testing the game and I have yet to see a grab EVER go faster than the default motion without a button/direction being pressed, also, the opponent mashing has no effect on any grabs speed. Try it yourself. You got it wrong. What you’re probably seeing is you double tapping the throw button or moving a directional. The “hyper hold” value appears to be a value that effects the amount of times the game checks to see if any input was given to increase the damage, “hyper hold” = checks frequently, normal throw = checks infrequently. I may be incorrect because I haven’t gotten around to checking what is going on.

The reason the holds in the video look “CPU fast”, is because I set the value beyond what the game gives you for a hyper grab, this is probably the rate the CPU uses vs players.

I’m unsure if p2 mashes the grab if it will effect the animation, I doubt it does.

I’ll look into what triggers it later, I found the address this morning.

Is there any reason for the red hitboxes on gief’s throws?

Great resource; I’ve already been practicing better throw mashing technique. Thank you! FYI, the newest version of the sf2-hitboxes.lua has throw box options.

EDIT: Remember how the roundhouse version of Zangief’s Siberian Suplex (360+K up close) has better range than the other two strengths for some reason? That version alone has (mistakenly?) the same grab box as the running grab; you can see the gross difference in the full “command throw” size versus the two smaller ones on the other strengths before the run box comes out. Neat!

Oh FML, you tell me this after I’ve captured all those character throw ranges screenshots?

Everyone go click on that link and read all of those, so many good info there! Dammit should post on this forum!

[ punch air throw grab high and kick air throw grab low? why fei’s airthrow suck? how guile can airthrow on his way up? why djpancakes could do that 720 on blanka when hawk’s not facing blanka?]

Haha ouch, but thanks for all of the hard work you’ve put in yourself, paps. At least with this amazing new throw information, we finally have a definitive source for how the game calculates the ranges and values. EVERYONE who is serious about ST should be using this and learning from it.

To summarize, each character has a static “throwable box” that also displays throwable states (by way of color changes during emulation). In addition, throw moves toss out their own “active throw attempt” box that activates the throw when it intersects the throwable box. All of the standard throw ranges for a character seem to be the same, though they, like the static throwable box, differ per character. It explains things like how Honda is relatively more difficult to tick throw, for example. Characters may have varying sizes of active throw boxes if they also possess command throws.

Again, this is EPIC news, and is readily verifiable by using the scripts in the emulator. MAJOR THANKS to dammit for discovering this.

Updated. New hotkey for toggling the throw hit boxes.

Additions:
[LIST]
[]Added the throw hitboxes
[
]Dizzy bar is shown when the char is dizzied.
[]Removed the ability to move the dummies by 1 pixel since throw boxes are now visible.
[/LIST]
Fixes:
[LIST]
[
]Fixed the stun counter, it’s actually a word, not a byte, so it’s displayed correctly (0-65535)
[*]Fixed the grab break, ken seems to have a maximum value of 63, far beyond what I thought the threshold was (52). I believe sim can get 57, didn’t test this much. So I left it at 63 until I reverse what determines that value and find the table and…the max value :p.
[/LIST]

Let me know if I broke anything, don’t think I did.

I’ll add an accurate stun gauge (although I don’t see the practical uses) that keeps the stun counter in mind (the one Cauldrath mentioned increments after each stun) just didn’t feel like doing it tonight.

how to control p2 to do reversal? answer me fagsky!

Updated the video on SRK thread and the google code, shit was out dated lol.