Normalizing Frame Data And Other Research Methods

[SamuraiPanda]

Given that we are making "official" data for everyone to be able to read and understand, we cannot have everyone using different methods of finding the data we use. So we need to normalize one to two methods of finding frame data that yield the same results. The purpose of this thread is to discuss your method of finding frame data, whether or not you believe that should become the norm, and why.

Also, there are other numbers we will be using, like distance. For distance, I assume the best course of action would be to make the distances in a unit of measurement where 1 unit = the length of 1 small block from the stage builder. Scotu has relayed to me that he'd like to use actual distance, convert it to distance in blocks, and have both side by side, which I am not opposed to. What else do we need to normalize before we begin intensive research?

 

[SCOTU]

I've made a list of stuff and how to collect the data in a standardized way for a lot of the stuff (http://www.smashboards.com/showthread.php?t=210625)

I'm not sure exactly what we need distance for yet, but i beleive we should use the actual numbers the game gives us, since it's FAR more precise. We could always just measure the length of a SB block and give a user friendly reading too, like you said, but I'd go with precision over friendly, especially when precision can easily be converted to friendly



Input
Directions are "Forward", "Up", "Down", "Back", and "Neutral"
Attacks to combine with a direction are "Tilt", "Smash", "Special" or "B", "Throw", "Air", "Dash" (doesn't take a direction)
"Jab" refers to a standing neutral A
From the edge there is a "Slow Edge Getup" (>=100%) and a "Fast Edge Getup" (<100%)
From a fallen position there is a "Front Wakeup" (lying on front side) and a "Back Wakeup" (lying on back)
Names involving a direction can be abbreviated by taking the first letter of the direction and adding it to the attack type.


List of All attacks with proper names:
Jab
2nd Jab
3rd Jab
Rapid Jab
Forward Tilt
Up Tilt
Down Tilt
Forward Smash
Up Smash
Down Smash
Neutral Air
Forward Air
Back Air
Up Air
Down Air
Z Air (some character's tethers have a hitbox)
Dash Attack
Neutral B
Forward B
Up B
Down B
Forward Throw
Back Throw
Up Throw
Down Throw
Front Wakeup Attack
Back Wakeup Attack
Fast Edge Getup Attack
Slow Edge Getup Attack


Hits On
This is the first frame the attack starts to hit on. Frame 1 is the first frame of the animation of the attack.

Duration
This is the total number of frames the attack lasts. You can buffer a Shield in most cases to see when an attack ends. When the shield is first visible is 2 frames after the end of the attack.

Hitlag
This is the number of frames of freezeframe animation when an attack connects. The first frame of hitlag is the frame that the attack connects, the last frame is the frame before the attack animation resumes. Hitlag affects both the attacker and the attackee.

BlockHitStun
This is the number of frames of freezeframe on the animation of a shield when an attack hits it. The shielder does not slide during this time. The first frame is when the attack hits the shield, the last is the frame before the shield starts sliding.

Blockstun
This is the number of frames after shield hitlag that the shielder cannot unshield in. Simply release the shield button as soon as your shield is hit and count the number of frames from when shield hitlag is done until you can start dropping your shield.

Base Damage
In VS mode (NOT TRAINING) hit someone when they're at 0% (so there's no hidden decimal error that's not built into the attack). The percent they end at is the Base Damage.

Knockback Angle
in training mode, set cpu = jiggs (pretty floaty so gravity has very little effect in the first frame after hitlag)
set the jiggs to 999%. set her standing on the edge of a platform and hit her while capturing video. In frame by frame, find the frame after hitlag. From that frame you can find the angle at which the opponent is sent. These angles are measured in degrees above forward, which means that if you draw a line from the hitter straight in front of him, that's 0 deg, straight up is 90, straight down is -90, and directly behind (for say, a bair) is 180. If the character turns around in the attack, "forward" refers to the direction prior to the attack. Pro Tip: DON'T have the jiggs DI.

Knockback Base & Growth

Growth is found using this equation:

g = (f - m) / e

where g is the growth, m is the knockback mario takes at 0% (before the hit), e is any percent, and f is the knockback taken by mario at e% before the attack.

in a new VS game, hit a mario at 0% with a non-stale attack. End the game. In the mario's stats screen find "Mas Launch Speed" this is m

start a new VS game, shoot mario with a fox laser until he is at some % (this % is e). Hit him with the non-stale attack. End the game, check his launch speed, this is f.

subtract m from f, and then divide by e to get the growth.

now that you have the growth,

Base Knockback is found by taking m and subtracting d * g from it, where d is the damage the non-stale attack does.

aka

base knockback = m - d * g

FOR FIXED KNOCKBACK ATTACKS

Base Knockback is just how much knockback Mario takes

and Variance is
V = (K - B) / R1
where V is variance, K is the knockback that character takes, and R1 is that character's Knockback Resistance 1

So find the knockback the move does on Mario, then find it on some other character, subtract the Mario one from the other character one, and then divide by the other character's Knockback Resistance 1


Element
I'm not entirely sure what all the elements are, nor who has weaknesses/ resistances to what elements, but I do know that Ivysaur has a weakness to element "fire" and squirtle has a resistance to it. If an attack has a 1.1 multiplier to the expected knockback on either of these (1/1.1 in case of a resistance) then that attack has the element that the attackee is weak/strong against.[/QUOTE]

 

[Vyse]

Also to expand on the technical side of things, here is some info I dug up on how Magus420 collected Frame data -

http://www.smashboards.com/showpost.php?p=5463438&postcount=18

The best way is to capture the game in normal speed and be able to get the raw unaltered and still interlaced (this is important) 29.97 frames per second capture onto your computer. Most 'user friendly' capture programs try to deinterlace this source capture for you since interlaced video does not display well on a progressive display like your computer, and you need to avoid this being done.

When done properly, this method will always be 100% correct, so it's the next best thing to a debug mode for finding frame data. It's also pretty quick once you know the process. I did very thorough and detailed frame data for Luigi for Brawl in like 4-6 hours including all IASAs, hitbox windows, autocancels, hitlag/stun/advantages disadvantages (lol Brawl), etc.
http://www.smashboards.com/showthread.php?t=175652

An important thing to mention is that the invincibility 'flashing' isn't actually a true representation of when you're invincible like in Melee. I noticed this when I did Luigi's stuff. The only way to find it is to test it directly to see the frames where they begin not getting hit for the start of the window and begin getting hit again for the end. I never bothered to redo this for Luigi since I've played the game maybe twice or something since then back in June, lol.



In NTSC the game runs at 59.94 frames/game images per sec, and when you capture through composite (the basic yellow video cable) or S-Video the signal that is carried is 29.97 interlaced frames per sec, which is actually 59.94 fields per sec with each field representing 1 game 'frame' and there are 2 of these fields in each interlaced frame.

So in reality every game frame you need is actually there in a basic normal speed capture, but 99% of the time when programs deinterlace the video they scrap 1 of those fields for viewing on a computer and you are left with a 29.97 progressive video (1 image per frame) and so half of the game frames are lost.

To get around this you need to do the deinterlacing yourself, and instead of scrapping half the fields you want to separate the fields into separate frames creating a 59.94 frames per sec progressive video. You could also capture through component to get 59.94 progressive, but I believe capture cards that have these particular inputs are extremely expensive/aren't readily available for consumers. With this all you need is any basic capture card/gamebridge/whatever.



I use VirtualDub (to do the capture and to view it) along with AviSynth which can do the proper deinterlacing method for this purpose. I begin to go over how I do it here and in my next 2-3 posts or so in that thread:
http://smashboards.com/showthread.php?t=163775&p=4338287

I also explain some things about the video signal that is captured, interlaced video, deinterlacing, and how it applies when wanting to get all 59.94 (aka 60) game images/frames per second from the captured video signal here:
http://smashboards.com/showthread.php?t=162023&p=4308928



Also, like I mentioned in that first thread explaining it, you should be sure to record the move being done at least twice just in case a field happens to be added/dropped at the same time you used the move which could cause the data to be off by 1 'frame' on occasion. Having that to double check, and also having the in-game timer on will make sure the numbers you get are exact.

If you happen to have an S-Video connection for input and a cable that has an S-Video out from the game you should use that. The signal is basically the same as the normal composite (yellow), just that the image you get is a bit clearer which helps with reading things like Brawl's tiny game clock numbers.

When capturing, I recommend using a lossless codec or at least a very very high bitrate with a codec like XviD/Divx or something if you don't have adequate hard drive space for a lossless capture. The reason being that you don't want to get compression artifacts across the interlaced fields, which would distort fine details in the image that after you deinterlace it will make things like the game clock difficult or impossible to read.

I myself use the Lagarith Lossless video codec if you want a suggestion for one:
http://lags.leetcode.net/codec.html

 

[Steel]

I use a 60 FPS camera and just record the animations right off the screen. I got the exact same data Ankoku got on various attacks when he used his own recording device.

Also will the official frame data consist of frame advantages/disadvantages on block?

guessing that's a given

 

[SamuraiPanda]

Also will the official frame data consist of frame advantages/disadvantages on block?

There is another thread for discussing what we should include in the official frame data and research on characters.

But personally, I think that including advantages.disadvantages on block is absolutely necessary.

 

[Zankoku]

Frame advantage formula is as follows:

(Hits on frame #) + (Blockhitlag + Blockstun) - (Duration + Hitlag)

Most (probably all) attacks in Brawl have negative frame advantage.

Here's how to use frame advantage.
7 [unshieldlag] + (Hits on frame #) + (frame advantage)
OR
(Grabs on frame # [usually 6]) + (frame advantage)
If the number is +2 or more, you can shield it. If the number is greater than the (hits on frame #) of one of your attacks, you can poke before the opponent does something (and this is the most useful way to punish shieldgrabs). Keep in mind that negative frame advantage does not necessarily mean you are at a complete disadvantage, it simply means you can't string it into another attack before the opponent can do something. Whether that something actually works or not will be determined by the above formula.

So for example, if Sheik's nair has a frame advantage of -3 (just a random number, not the actual value), and the opponent tries to shieldgrab, then you get
(grab [6]) + (frame advantage [-3]) = 3
and Sheik's jab hits on frame 2. This means that Sheik can jab before the opponent's grab reaches, and it will interrupt the opponent's grab.

As another example, if Marth's dtilt has a frame advantage of -10 (I think? Don't remember), and the opponent tries to unshield and do an fsmash that hits on frame 5, you get
(unshield [7]) + (hits on frame [5]) + (frame advantage [-10]) = 2
This means you have 2 frames to do something. You can successfully powershield the fsmash, OR you can use Marth's Up+B, Dolphin Slash, because while it hits on frame 5, it has full invulnerability on frames 1-4, so it will completely avoid the opponent's fsmash.

 

[Pierce7d]

I have more to contribute than just this brief post, but at this exact moment, I merely want to remind you all that you need to also test knockback properties and frame data of angled ftilts, so you will need to add side up, and side down to your possible directions, and add ftilt up, ftilt down, smash up, and smash down as possible moves. I believe these attacks have different trajectories, and angled up has more knockback (in general). There are also quirky things such as Luigi's IASA frames on Angled Up Fsmash.

 

[Levitas]

I think the only angled moves are ftilts and fsmashes, aside from some b moves. We should normalize (imo ideally abbrieviate and popularize) a notation for angled tilts.

 

[SCOTU]

I don't know why i didn't notice this before

A camera is insufficient for frame data collection because it does not signal lock to the video source (i.e. its frames don't line up with the game's frames, and you're likely to get small errors).

 

[Steel]

Not sure what you're getting at there scotu, my camera seems to work fine when I do frame data. My data lined up with others' data perfectly.

 

[SCOTU]

that doesn't ensure that it does. You just got lucky. If you use a capture card, Frame X is guaranteed to be frame X, if you use a camera, frame X could be Frame x-1,X, or X+1 because it doesn't lock onto the signal.

 

[ColinJF]

I'd like to emphasise that at least three values are required to determine launch speed for each move, namely g (growth), b (base), and c (mysterious constant). You can easily get all three from three data points using this script http://colin.shoddybattle.com:81/gbc.php

If my hypothesis about c is right then

θ = arccos((kg + q - c)/q)

where θ is the launch angle, k and q are global constants, g is growth rate, and c is... c.

If this hypothesis is right then a lot of time can be saved since launch angles can be found knowing just c and g, requiring no video equipment.

 

[SCOTU]

well, thanks for that.

 

[leafgreen386]

I'd like to note that handicap is superior to fox's lasers for setting percent for testing. Fox's lasers do decimal damage (not that normal attacks don't, so perhaps this is a moot point), and just in general take more time to get to the exact percent you want to test, while handicap allows you to set your percent to any multiple of 10.

BlockHitStun
This is the number of frames of freezeframe on the animation of a shield when an attack hits it. The shielder does not slide during this time. The first frame is when the attack hits the shield, the last is the frame before the shield starts sliding.

Don't you mean shield hitlag?

I'm not sure exactly what we need distance for yet, but i beleive we should use the actual numbers the game gives us, since it's FAR more precise. We could always just measure the length of a SB block and give a user friendly reading too, like you said, but I'd go with precision over friendly, especially when precision can easily be converted to friendly

Completely agreed. In fact, I'm working right now on figuring out the game's units. If my current knockback theory is correct, then a stage builder block is 10,000 units tall, although seeing as I lack a recording device I've sorta been stopped cold in my research, and have no way of verifying this.

 

[SCOTU]

not sure how i typo'd the blockhitlag. In either case, that's being covered in the other thread. The fox laser testing method is now quite obsolete, so it doesn't matter anyways.

 

[Amazing Ampharos]

An error that could greatly corrupt the data is that you are reversed on base damage. You do base damage in training mode and 1.05x base damage unstale in versus mode. It's pretty easy to tell since you do decimal damage in versus mode pretty much always while in training mode you do integer damage (hit with the same move over and over again, and unless you are using Lucario or certain special moves, the displayed damage will continue to go up by the same integer value, indicating that it is indeed integer damage).

It's possible to model versus mode as base damage, but it requires you to say that every move does non-integer base damage and makes stale move multipliers really ugly.

About elements, the only four elements that matter are fire, water, grass, and electric. Fire, water, and electric have special effects with Olimar's pikmin, and fire, water, and grass have special effects with the Pokemon Trainer. The sticker system in Subspace leads me to believe that there is actually a very general "element" system and that things like "punch" and "slash" are stored internally as elements which are called for things like sound and hit effects, but in terms of practical battle effects, we only need to worry about the first four I mentioned.

 

[infomon]

^^ Brawl's elemental type system is full of fail, lol.

Before you write it off the impact of the types....... there are a few hitbox interactions that may merit their own Lab thread. AFAICT, Snake's mortar (as it rises and falls) has quirky priority behaviour. It can be destroyed by some aerials, like Ness' Bair and Nair, but not others, like Ness' Fair, or any of MK's aerials. I experimented a bunch, but so far I don't know of any comprehensive rule that explains which aerials work and which don't. It may very well have to do with the type system, but it's possible that it altogether does not. I'm pretty sure it isn't based on the relative damage of the hitboxes.

 

[Amazing Ampharos]

I think Ness's forward aerial is a laser (which may be new information; I wonder if his dash attack is a laser too), and I know that all of Meta Knight's aerials are lasers. Lasers pass through other hitboxes without clanking; they get their name from the most obvious case in the blasters of Fox and Falco. I believe Snake's mortar, when entering a "clank" (and it will clank with almost everything since it does 10% damage as base damage), explodes. It's a bit odd that an exploding attack like the mortar wouldn't have a hurtbox (Snake's grenades definitely have hurtboxes and can be detonated by lasers), but this seems to be a consistent explanation based on my limited testing. It would be too weird for it to be elements; how could Ness's forward aerial and Meta Knight's aerials not work while Marth's and Mr. Game & Watch's aerials do work otherwise (that's all I tested personally)?

Also, for the record, this isn't the only reason I suspect Ness's forward aerial is a laser. It also can go through the Mach Tornado, and given how that move works, it's very strange that a multi-hit move with such weak individual hits that seemingly hits slower than the Mach Tornado would do as such. Incidentally, indicating attacks as lasers is probably important for listing move properties so this may not be a silly tangent.

A second for the record, I find it plausible that the element system isn't new to brawl but that brawl is just the first smash game in which it did anything. How else do you explain Roy's fire but an element system?

 

[infomon]

Hmmmmm. At first I was simply going to say that the "laser"-type priority mechanism you mention is something I've seen gone by the name of "transcendent priority"; I think that originates from some allisbrawl thread where someone tried to categorize all the projectiles of the game based on their priority properties. I should look that up.

You say that "Lasers pass through other hitboxes without clanking".... all aerials pass through other aerials without clanking. However, typical aerials will clash against the tornado..... interesting, if Ness' Fair clashes with nothing, then that makes me happy, because it means Snake's mortar isn't as much of an exception as I'd thought.

Now we have the task of determining which aerials fall in what priority category, for each character; and making sure we've got a clear understanding of the different categories. Eventually it would be good to compile a comprehensive "priority guide" that covers all the different types of hitbox interactions in Brawl. It's something I've wanted to do for a long time.

This discussion should prolly continue in a different thread.

 

[Steel]

It's called transcendent priority, yeah. Marth's dancing blade for example is transcendent, it goes right through MK's tornado.

 

[Levitas]

We should add another category to the data template then, because there are some weird moves that are both transcendant and not, like ROB's Fsmash. From what I can tell, the lazer in front of ROB's face has a transcendant hitbox, but there's one that can clank on ROB's eyes.

 

[3GOD]

One thing that MUST be considered...should we use fresh moves in VS mode or should we use training mode when obtaining frame data?

Things like BlockHitlag, BlockStun, and Hitlag vary depending on whether a move is fresh (in VS mode)...also there is a difference between training mode and fresh moves in VS mode.

My suggestion is that frame data should be gathered using fresh moves in VS mode since that is the mode that is actually played in tournaments.

 

[ColinJF]

It should be collected in training mode because that's the only place the stale moves multiplier is 1. Then we should find the way to derive the quantities for an arbitrary stale moves multiplier. If the latter task proves too difficult, it could be collected in versus mode... but if we can accomplish a formula for those things that is based on the stale moves multiplier, then training mode data is more useful.

 

[ColinJF]

(accidental post)

 

[3GOD]

It should be collected in training mode because that's the only place the stale moves multiplier is 1. Then we should find the way to derive the quantities for an arbitrary stale moves multiplier. If the latter task proves too difficult, it could be collected in versus mode... but if we can accomplish a formula for those things that is based on the stale moves multiplier, then training mode data is more useful.

Upon investigating your work with the stale moves multiplier, I agree. From here on out, I'll be finding all frame data from Training Mode to ensure a stale moves multiplier of 1 unless it's decided that information from VS mode is also desired.

This will actually make collecting frame data a little quicker too since accidental hits won't require a self-destruct to reset the stale moves queue.

 

[infomon]

Frame advantage formula is as follows:

(Hits on frame #) + (Blockhitlag + Blockstun) - (Duration + Hitlag)

Most (probably all) attacks in Brawl have negative frame advantage.

Here's how to use frame advantage.
7 [unshieldlag] + (Hits on frame #) + (frame advantage)
OR
(Grabs on frame # [usually 6]) + (frame advantage)
If the number is +2 or more, you can shield it. If the number is greater than the (hits on frame #) of one of your attacks, you can poke before the opponent does something (and this is the most useful way to punish shieldgrabs). Keep in mind that negative frame advantage does not necessarily mean you are at a complete disadvantage, it simply means you can't string it into another attack before the opponent can do something. Whether that something actually works or not will be determined by the above formula.

So for example, if Sheik's nair has a frame advantage of -3 (just a random number, not the actual value), and the opponent tries to shieldgrab, then you get
(grab [6]) + (frame advantage [-3]) = 3
and Sheik's jab hits on frame 2. This means that Sheik can jab before the opponent's grab reaches, and it will interrupt the opponent's grab.

As another example, if Marth's dtilt has a frame advantage of -10 (I think? Don't remember), and the opponent tries to unshield and do an fsmash that hits on frame 5, you get
(unshield [7]) + (hits on frame [5]) + (frame advantage [-10]) = 2
This means you have 2 frames to do something. You can successfully powershield the fsmash, OR you can use Marth's Up+B, Dolphin Slash, because while it hits on frame 5, it has full invulnerability on frames 1-4, so it will completely avoid the opponent's fsmash.

Hmmmm... for moves with hitboxes that stay out for a while, I suppose "frame advantage" should be an interval, along with the Hits-on-frame-#; we care about what frame it's blocked at. So the timing of your block (which usually correlates with your spacing) can make or break the advantage in many cases.

This is kinda obvious but I thought I'd point it out. Do we want to specify advantage as an interval, or do we use the earliest possible frame it can hit, or what?

On that note, what's a good systematic way to determine when a hitbox goes away? Do we have any good code for this, or are we sticking with repetition and metal characters?

 

[leafgreen386]

If we ever get a code that removes the "has this move hit this character" check, then it should be very very easy to test. Otherwise, whatever other method we figure out will be very very tedious.