Skip to content

Changelogging

Askew edited this page Aug 20, 2024 · 6 revisions

HDR is a massive project, and as such it is vitally important to keep track of everything that changes, both for developmental and referential purposes

PLEASE MAKE NOTE OF ALL VALUE CHANGES

It cannot be overstated how essential this is and how much time and energy is wasted having to chase after and verify missing or incorrect data

How to Measure Certain Data

Basic value changes are pretty cut-and-dry, but there are a few key pieces of data not so easily obtained just from looking

Hitbox Durations

  • You will need a visualizer active for this, but it's the most straightforward. Simply document the starting and ending frames for each part of the move
  • Please make sure to separate any distinct parts into their own durations such as early/mid/late, hit 1/hit 2, multihits/launcher, etc

FAF

  • For grounded moves, start an attack in frame-by-frame, hold shield, and count how many frames it takes for the character to enter shield. Note that the shield bubble appears frame 2 of being actionable, so please remember to account for this
  • For aerial moves, start the move and hold jump when advancing every OTHER frame. This needs to be done every other frame since holding jump throughout the move will not automatically buffer it when becoming actionable. The FAF will be the frame the character enters their jump animation, signified by the air jump ripple vfx

Autocancels

  • Autocancel windows cannot be measured directly without additional visual affirmation. To accurately measure them, you will need to find the frames that the ENABLE_LANDING flag is being set on and off and add some visual indicator on that same frame. The go-to methods are printlns, incrementing the character's percent using AttackModule::add_damage, or even spawning a hitbox
  • Autocancels have an early and late portion. For the early portion, the autocancel always starts on frame 1 and ends the frame before the flag gets set (for instance, if the flag is set on frame 4 then the autocancel is F1-3). The late autocancel lasts until the end of the move, so just noting the frame it starts is fine

Kill Percents

  • Inkling is the median for both weight and fallspeed in HDR and is used for testing pretty much anything related to knockback
  • The standard is to use Inkling on Final Destination. For vertical kill moves, default spawn position is fine, whereas Inkling should be at normal getup distance from ledge for horizontal kill moves
  • For angles above 60, use DI away. For angles below 45, use DI up and in. For angles between 45 and 60, use DI down

Frame Advantage

  • You will either need two controllers or the training modpack with the opponent set to mash shield and jump
  • Count how many frames the character is airborne from a shorthop before landing, then perform the move so that the opponent gets hit the frame before the character lands (as an example, if a character's nair is frame 8 and their shorthop is airborne for 30 frames, then input the nair on frame 21)
  • Hold shield with the character and advance frames until one of the two enters shield (or the opponent jumps). From there, count how many frames it takes for the other to enter shield. The frame advantage will be one less than the difference (for instance, if the attacker enters shield and then the opponent shields 4 frames later, then the move is +3)
  • Unless the move uses FKB, this should be documented at both 0% and 100%

IMPORTANT NOTE

  • Changing hitbox durations, FAF, or autocancels virtually always has a direct effect on one or both of the other two. When altering any of these three, PLEASE account for this and verify the data for the others, making note of them if they are changed

How to Order a Changelog

The standard order for moves is as follows:

General (character physics)
Unique Mechanics (float, meter, etc)
Jab 1
Jab 2
Jab 3
Rapid Jab
Rapid Jab Finisher
Forward Tilt
Up Tilt
Down Tilt
Dash Attack
Forward Smash
Up Smash
Down Smash
Neutral Air
Forward Air
Back Air
Up Air
Down Air
Zair
Neutral Special
Side Special
Up Special
Down Special
Unique Moves (Power Geyser, Hellsweep, etc)
Standing Grab
Dash Grab
Pivot Grab
Forward Throw
Back Throw
Up Throw
Down Throw
Up Taunt
Side Taunt
Down Taunt

The recommended order of data is as follows:

Overall Changes (new/adjusted animation)
Properties (cancels, adding a late hit, etc)
Special Properties (projectile lifetime, travel speed, etc)
Hitbox Duration
Hurtbox State Duration (armor/intangibility)
Hurtbox State Threshold (used for armor)
Damage
Angle
BKB (not needed if 0 and using FKB)
FKB (not needed if 0 and using BKB)
KBG
Hitlag Multiplier
SDI Multiplier
Shieldstun Multiplier
Shield Damage
Additional Hitstun
Hitbox Size
FAF
Autocancel
Landing Lag

Changelog Formatting and Tagging

Move Parts and Subsections

Data from each part of the move should be separated into its own subsection if there is at least one change pertaining to that move part alone, or combine them into one line and distinguish which values pertain to which parts

Both examples below are acceptable:


Back Air

  • [+] Damage (early/late): 10.0/9.0% -> 11.0/10.0%
  • [+] KBG: 80 -> 90

Back Air

  • Early
    • [+] Damage: 10.0% -> 11.0%
    • [+] KBG: 80 -> 90
  • Late
    • [+] Damage: 9.0% -> 10.0%
    • [+] KBG: 80 -> 90


However, if more than a couple parenthesis are being used, the data should be separated into subsections like the lower example

Subsections should be ordered either by order of appearance (early/mid/late), by sweetspot to sourspot (ie Mewtwo's tail moves are base/mid/tip), or by distance outward from the character (shoulder/arm/hand)

This can be pretty case-by-case, feel free to ask about any particulars

Tagging

Tagging is not required but is appreciated for visibility

  • (!) New property (cancels, mechanics, new animation, changing from a multihit to a single hit, etc)
  • (*) Bugfix
  • [$] Aesthetic (vfx, sfx, animation timing)
  • [+] Buff
  • [-] Nerf
  • [/] Sidegrade (a buff/nerf depending on context)
  • [=] Compensation (usually only used when changing the damage of a move but keeping its knockback the same)

Tagging is not used if the move changes completely or is a brand-new move or move part