Super Smash Bros. Melee (the doldecomp decompilation, doldecomp/melee)

In the NTSC 1.02 version of Super Smash Bros. Melee, ftColl_80079AB0 computes a hit's knockback as $D\cdot A\cdot r\cdot (0.01g\cdot (c_{11C}\cdot (c_{F8}-\frac{c_{F8}w}{1+w})\cdot (c_{110}d+c_{114}nd)+c_{120})+b)$ capped at c_108. Every c is an unnamed field of p_ftCommonData, which Fighter_LoadCommonData loads from the disc file PlCo.dat, so the constants aren't in the code. Here d is the target's x1830_percent plus x1838_percentTemp, or, while the unnamed flag x2225_b7 is set, c_6D4 (c_6D8 if stamina_dead) plus x1838_percentTemp; n is the hit capsule's unk_count; w is the target's weight attribute times c_F4; g and b are the capsule's unnamed x24 and x2C; r is gm_8016B248(), the match rules' x30, which the VS setup in gm_1601.c sets to 0.1 × the rules' damage_ratio; and A and D are Player_GetAttackRatio for the attacker and Player_GetDefenseRatio for the target. A capsule whose unnamed x28 (k) isn't 0 uses c_118·c_110 + c_114·c_118·k in place of the percent term. The terms sit where Super Smash Bros.'s 0.1, 0.05, 1.4, 18, and its set-knockback 10 and cap 2500 do (ssb64/knockback), and the atlas reads g as the growth and b as the base by that position. Where Super Smash Bros. multiplies by its weight attribute, Melee's weight term equals c_F8 / (1 + w) (computed), so the weight divides. Of the hits a fighter logs in one update, ftColl_8007A06C keeps the largest knockback and writes it to kb_applied; ftCo_Damage_CalcKnockback then multiplies it by kb_squat_mul in ftCo_MS_Squat or ftCo_MS_SquatWait, by kb_ice_mul in ftCo_MS_DamageIce, and by kb_smashcharge_mul while a smash attack charges, rescales it with ftCo_CalcYScaledKnockback when the fighter's vertical scale isn't 1, subtracts the larger of armor0 and armor1 (plus metal_armor for a metal fighter), and raises it to kb_min if it falls below. melee/knockback

About: Super Smash Bros. Melee Knockback

{
 "scalePer": 0.01,
 "weightOne": 1,
 "percent": "PlCo x110",
 "percentTimesDamage": "PlCo x114",
 "weightScale": "PlCo xF4",
 "weightTerm": "PlCo xF8",
 "mul": "PlCo x11C",
 "add": "PlCo x120",
 "setKnockbackAt": "PlCo x118",
 "cap": "PlCo x108"
}

Item hits call the same routine with the item owner's attack ratio (1.0 when the owner isn't a fighter), and environment hits with 1.0 (ftColl_8007A06C cases 2 and 3); ftColl_80079EA8 is a copy with all three ratios at 1. The 0.1 in gm_1601.c is the VS path; gmtoulib.c fills x30 through fn_801653E8. The atlas doesn't fetch PlCo.dat, so no knockback has been worked out for a real hit. That the capsule's unk_count holds the hit's damage, as SSB64's h does, is the atlas's reading by position.

Cited by: Knockback, Super Smash Bros. Melee

In the NTSC 1.02 version of Super Smash Bros. Melee, ftCo_8008DCE0, the routine that puts a hit fighter into a Damage status, sets the unnamed count mv.co.damage.x0 to the knockback (kb_applied) times p_ftCommonData->x154, a value from the disc file PlCo.dat, truncated to a whole number, and to 1 if that comes to 0. It also sets the flag x221C_b6, which ftLib_IsInHitstun returns. Where Super Smash Bros. divides the knockback by 1.875 (ssb64/hitstun), Melee multiplies it by a value the code doesn't hold. The animation routines of the Damage statuses (75 to 86) and the DamageFly statuses (87 to 90) take 1 off the count while it's above 0 (ftCo_8008F744) and clear the flag once it's 0 or below; the status ends when its animation has run out with the flag clear. While the flag is set, their interrupt routines run only doIasa, as the decompilers name it, in place of the wait, fall, or hammer checks, so the fighter can't act, with one exception: after a hit whose angle ftColl_8007AC68 accepts (between unk_kb_angle_min and unk_kb_angle_max), once an unnamed countdown from c_7F0 runs out, an airborne fighter moving down can leave through an air up special (ftCo_800D69C4) or an air jump (ftCo_800CB8E0), which the atlas reads as the meteor cancel. A jump pressed in hitstun otherwise only records the count left. While the flag is set an airborne fighter gets gravity and aerial_friction (ft_80084EEC) in place of fast-fall and drift (ft_80084DB0). A change of motion state clears the flag unless the new state is entered with Ft_MF_SkipHitStun. The DamageFlyRoll status's own routines aren't read here. melee/hitstun

About: Super Smash Bros. Melee Hitstun

{
 "multiplier": "PlCo x154",
 "minimum": 1
}

The count is stored as an int from a float product, so it truncates. The same product picks the damage animation's level against PlCo's x158, x15C, and x160 and the camera shake against x170 and x174. Whether a status's animation routine runs once per displayed frame isn't read here, so the count isn't stated in seconds. Rows 76 to 86 and 88 to 90 of the motion table (ftmotionstates.c) name the same routines as the two cited; 91 is DamageFlyRoll.

Cited by: Hitstun, Super Smash Bros. Melee

In the NTSC 1.02 version of Super Smash Bros. Melee, a fighter's shield_health is a float that starts at x260_startShieldHealth. Each time Fighter_procCollResolve runs for a fighter that isn't asleep (is_sleeping), a fighter whose unnamed flag x221A_b7 is clear regains c_27C, up to the start value. That flag is set when the guard statuses switch on the shield's collision (ftColl_8007B1B8), and the atlas reads it as "shield up". While it's set, the fighter instead loses c_284 × s × (1 − (l·(c_2E0 − c_2DC) + c_2DC)) + c_288, where s is x19A0_shieldDamageTaken, each shield hit's damage plus its unnamed x34 (a fighter's hit counts only while the flag x221C_b2, set on entering ftCo_MS_GuardReflect, is clear), and l is lightshield_amount. Below 0, the health is set to x280_unkShieldHealth, and on the hit path the shield break (ftCo_80098B20, which enters ftCo_MS_ShieldBreakFly) starts only in the branch taken when the fighter has no knockback to apply (kb_applied is 0), the unnamed x18a0 is 0, and a shield hit is recorded (x19A4). While the fighter holds the shield, the animation routines of ftCo_MS_GuardOn and ftCo_MS_Guard call ftCo_800925A4, which, while x221B_b0 is set, sets l from the analog trigger past its deadzone, (trigger − deadzone) / (1 − deadzone), keeping the old value when that's negative, and takes c_278 × (l·(c_2F0 − c_2EC) + c_2EC) off the health; below 0 it sets the health to 0 and starts the shield break. Every c is a field of p_ftCommonData, from the disc file PlCo.dat, so the numbers aren't in the code. Where Super Smash Bros. counts whole points from a fixed 55 and resets to 30, with no say for how hard the button is pressed (ssb64/shield), Melee's wear while held and its damage from hits both depend on l. melee/shield

About: Super Smash Bros. Melee Blocking

{
 "start": "PlCo x260",
 "afterBreak": "PlCo x280",
 "regenPerUpdate": "PlCo x27C",
 "heldWear": "PlCo x278, x2EC, x2F0",
 "hitScale": "PlCo x284, x288, x2DC, x2E0"
}

Fighter_ChangeMotionState clears x221A_b7 (fighter.c L1050), so the shield counts as down in any status that doesn't set it again. The shield's drawn size scales with shield_health / x260_startShieldHealth (ftCo_Guard.c L183). A digital L or R press sets the trigger to 1.0 (fighter.c L1887-L1889), so l is 1 at a full press. Yoshi's guard (ftyoshiguard.c) is its own code and isn't read here. The decompilers' comment on PlCo's powershield_input_window names the reflect status's input as "a powershield".

Cited by: Blocking, Super Smash Bros. Melee

In the NTSC 1.02 version of Super Smash Bros. Melee, an aerial attack (statuses ftCo_MS_AttackAirN to ftCo_MS_AttackAirLw) that touches down calls ftCo_LandingAir_EnterWithLag from its collision routine ftCo_AttackAir_Coll, through ft_80082C74, which calls it when the unnamed ft_80081D0C returns true. If the move's command script has set cmd_vars[0], which entering the aerial clears, the fighter enters that aerial's LandingAir status with the fighter's landing-lag attribute for it (landingairn_lag and the four like it), and the animation plays at a rate of (ftAnim_8006F484 + 0.1) / lag, where ftAnim_8006F484 returns the animation's end frame. If the unnamed count x67F is below c_E4 at that moment, the lag is first divided by c_E8, truncated to a whole number, and raised to 1 if that's 0; c_E4 and c_E8 are p_ftCommonData fields from PlCo.dat, so the window and divisor aren't in the code. Fighter_procInput sets x67F to 0 on an update where the HSD_PAD_LR bit is newly pressed and otherwise adds 1, up to 255. That bit is on while L or R is held, while the analog trigger is past its deadzone, or while Z is held unless gm_GetDbPauseFlag(0) is true, and it's off while the unnamed gm_8016B0FC is true. Without cmd_vars[0], the fighter takes the basic landing (ftCo_Landing_Enter_Basic). Super Smash Bros. reads the same moment differently (ftCommonAttackAirProcMap): when the aerial's flag1 is clear or Z was pressed no more than 10 counts before (tics_since_last_z ≤ 10), it skips the aerial's landing lag outright, landing in Wait if the air speed is above −20 and in Landing otherwise, where Melee divides the lag. melee/l-cancel

About: Super Smash Bros. Melee Landing lag

{
 "window": "PlCo xE4",
 "divisor": "PlCo xE8",
 "minimum": 1,
 "rateAdd": 0.1,
 "counterMax": 255,
 "ssb64ZWindow": 10,
 "ssb64SkipVelY": -20
}

Peach's float attacks call the same routine (ftpeachfloatattack.c). Which aerials set cmd_vars[0], and when, is in each fighter's move scripts, which are disc data; the community name for landing without it is an auto-cancel, and the reduced landing is the L-cancel. In Super Smash Bros., an aerial whose LandingAir animation is missing uses ftCommonLandingAirNullSetStatus with flag1 as a percentage.

Cited by: Landing lag, Super Smash Bros. Melee