Project Thread I: Frame/Hitbox data and Advantage analysis

[Veril]

This project is intertwined with anything else the smashlab can hope to accomplish. Here we will compile "in-depth" and "simplified" frame and hitbox data, and the results of any analysis.

Goals:

I. Data for us:
1. All data that can be derived from PSA and Brawlbox, codified and organized.

2. The advantage permutations for all moves.

3. A reliable formula for hitstun.

4. A reliable formula for the point at which moves induce tumble (I'll dump enough examples that we should be able to extrapolate something, I already am really good at estimating these points but don't have an easy formula).

5. Quantifying the "human" element when testing frame perfect: we need to decide exactly how much SDI is reasonable, what is reasonable to expect from people in the way of DI and when, what should our baseline for "choice reaction time" be. This is not exactly what Bowyer or Adumbrodeus have been talking about, but it is necessary for each of their respective projects.
a. ex. I assume that people are able to input Quarter Circle SDI reliably on any move telegraphed by over their Choice Reaction time.
b. "" with all options that the players will both be aware of and able to execute the options available. Technical difficulty is only considered in very rare circumstances.
c. "" players aware of their options will always punish something with a -20 advantage or greater on reaction.
d. when a single dominant option is guaranteed to work, ie, it is a frame trap, players will overwhelmingly choose this option, and when they don't it falls into the nebulous realm of "mindgames" which the "option select" project will pursue.


II. Data for the masses:

1. Use a universal format that includes what players will want to know.
a. The hit-frames and first actionable frame.
b. Cancelable frames
c. Part Qualitiative hitbox data: ex. strong hitbubble, weak, etc
d. Damage by hitbubble
e. KO% by hitbubble with and without DI, center FD for any move which can KO under 250%.
f. The frame advantage "on-hit" and "on-block" for all moves
g. The % at which moves induce tumble, by character weight class (there is overlap so testing of all is unnecessary).
h. Hitbox/hurtbox images for all moves.

2. The best options characters possess to break strings and combos, based on positioning.

3. Frame traps pointed out, categorized and explained.



Sorry I was gone for so long, I'm gonna look over all these messages now...

Spoiler

Late as balls, thanks to a combination of my computer breaking, my laptop hdd usb adapter thing taking forever to ship, and laziness, but it's finally here. The Solo DThrow Chaingrab Percentage List.

The laptop's in the shop, I can access my old files again; things are looking up! For now it's just an initial list of percentages and ways to escape, but over time I'll evolve this into something special, starting with the walking chaingrab percentages (<3 Hylian). Maybe even a general chaingrabbing guide, but I don't want to get too ambitious at the moment. xP



CHAINGRABBING

These figures assume you start the Chaingrab at 0% with DThrow fresh (not in the stale move queue at all). Obviously enough, the higher damage the character has when you start the Chaingrab fresh, the less you can Chaingrab them (higher start + fresh throw = more knockback = escaping lower).

The percentages look all out of whack, but it makes sense when you consider each character has a different weight, fall speed, size, shape and animation, among other attributes.

Bowser - 95% [30T]
Captain Falcon - 98% [31T]
Charizard - 92% [29T]
Diddy Kong - 62% [18T]
Donkey Kong - 65% [19T]
Falco - 87% [27T]
Fox - 87% [27T]
Ganondorf - 81% [25T]
Ice Climbers - 65% [19T]
Ike - 65% [19T]
Ivysaur - 62% [18T]
Jigglypuff - 16% [3T]
King Dedede - 103% [33T]
Kirby - 34% [8T]
Link - 70% [21T]
Lucario - 31% [7T]
Lucas - 76% [23T]
Luigi - 59% [17T]
Mario - 65% [19T]
Marth - 31% [7T]
Meta Knight - 65% [19T]
Mr. Game & Watch - 57% [16T]
Ness - 54% [15T]
Olimar - 37% [9T]
Peach - 24% [5T]
Pikachu - 70% [21T]
Pit - 59% [17T]
R.O.B. - 48% [13T]
Samus - 31% [7T]
Sheik - 90% [28T]
Snake - 84% [26T]
Sonic - 57% [16T]
Squirtle - 68% [20T]
Toon Link - 48% [13T]
Wario - 73% [22T]
Wolf - 98% [31T]
Yoshi - 81% [25T]
Zelda - 40% [10T]
Zero Suit Samus - 59% [17T]

I'm not sure about Mr. Game & Watch, not because he's tricky or anything, but because while compiling this list I didn't have my original document on hand. All I know is that he was one throw less than either Ice Climbers or Zero Suit Samus. Of course, I'll update with the correct value when I've had a chance to look over the old document.



ESCAPING

As a general rule, characters should DI Up-Away to escape the DThrow Chaingrab faster (though a few exceptions exist; can't remember who they are, don't have it on hand etc, but DIing as above is still good). The moves listed here also help escape MUCH earlier than simply jumping out, usually because of invincibility.

Some moves aren't as useful to escape as you'd think. Generally a move has to either have invincibility starting at frame 1 (preferably with a hitbox at the end, ala Fox's or Wolf's Shines), or move you completely out of the way really fast (within a few frames).

Fox - Shine (DSpecial)
Jigglypuff - Rest (DSpecial) or Double Jump, DJ preferred
Lucas - Double Jump DAir
Marth - Dolphin Slash (USpecial) or Double Jump, DJ preferred
Ness - Double Jump DAir
Peach - Float (Hold Jump)
Snake - Grenade (NSpecial), won't get you out immediately though.
Wolf - Shine (DSpecial)
Yoshi - Reverse Double Jump (Hold Away)
Zero Suit Samus - Flip Jump (DSpecial)

If a character is not listed here, all they can do to escape is DI well and jump out.



TODO

1a. Walking chaingrab percentages.
1b. Regrab knockback ranges.
1c. Complete frame data.
2a. Video supplement.
2b. In-depth data for each character.



TL;DR

- Yes, these are correct.
- Yes, I double-checked them.
- Yes, I accounted for DI.
- Yes, I checked for moves to escape with. (I actually did a LOT of impromptu frame data for other characters because of this, gotta love having no immediate access to the internet.)
- Yes, sometimes you have to be dang-near frame perfect to pull off a regrab on some characters at higher percentages.



... I think that's everything. :/

Brawl Weight Modifiers

Spoiler

1.20 Bowser
1.16 Donkey Kong
1.13 Snake
1.12 King Dedede
1.10 Charizard
1.09 Ganondorf
1.08 Samus
1.07 Wario / Yoshi
1.06 R.O.B.
1.05 Ike
1.04 Captain Falcon / Link
1.02 Wolf
1.00 Ivysaur / Lucario
0.98 Mario
0.97 Luigi
0.95 Sonic
0.94 Lucas / Ness / Pit
0.93 Diddy Kong
0.92 Ice Climbers / Toon Link
0.90 Peach
0.87 Marth
0.85 Sheik / Zelda
0.82 Falco / Olimar
0.81 Zero Suit Samus
0.80 Fox
0.79 Metaknight / Pikachu
0.78 Kirby
0.75 Game & Watch / Squirtle
0.68 Jigglypuff

Spoiler

You should probably find the release frames and 1st actionable frames for weight dependant throws against Ivysaur/Lucario as they have a 1x multiplier (weight of 100 in PSA). Then knowing that you should be able to freely calculate it being used on any of the other characters if you wanted.

This is my thread that includes throw frame data for Melee:
http://www.smashboards.com/showthread.php?t=206469



The actual slowdown/speedup effect on the animation's progression is a result of: 100/Weight

So with a weight value of 120 (Bowser), the animation will progress by 0.8333... for every 1 in-game frame that passes. If an event occurs on 10.000 of the animation, it would instead happen on frame 12 in the game.

The animation would progress like so:
0.833, 1.667. 2.500, 3.333, 4.167, 5.000, 5.833, 6.667, 7.500, 8.333, 9.167, 10.000 (event)



You can shortcut the entire process by simply taking the frame the event takes place on and multiplying it by their Weight/100 (Bowser would be a 1.200 multiplier), and then rounding UP to the next frame.

So something taking place on 14.000 of the animation would happen on frame 17 for Bowser
(14 x 1.2 -> 16.8 -> 17)



Example:

***A throw releases on frame 14.000 of the animation and you can shield starting on frame 32.000 (Marth's Melee f-throw).***

When used on Lucario the animation would progress like so:
1.000, 2.000, 3.000, 4.000, ...[snip]... 13.000, 14.000 (release), 15.000, 16.000, ...[snip]... 31.000, 32.000 (1st actionable frame)

Resulting in 18 frames of lag (frames 14 through 31 inclusive)

Which could be easily calculated with:
(32 x 1.00 -> 32) - (14 x 1.00 -> 14) = 18
32 - 14 = 18



When that same throw is used on Bowser it would go:
0.833, 1.667. 2.500, 3.333, 4.167, ...[snip]... 12.500, 13.333, 14.167 (release), 15.000, 15.833, ...[snip]... 30.833, 31.667, 32.500 (1st actionable frame)

Resulting in 22 frames of lag

Calculation:
(32 x 1.20 -> 38.4 -> 39) - (14 x 1.20 -> 16.8 -> 17) = 22
39 - 17 = 22

Some notes from me on throw data:

Spoiler

•the hitstun on all throws is roughly consistent across the cast at 0% (~same number of frames of stun). As would be expected, the hitstun growth rate varies by character.

•Throws with internal damage (ie, more than one hit) have a set amount of lag after the release point (I calculate the "lag" based on the frame the last hits damage is applied on... if you need clarification talk to me on AIM. This is the best and easiest way to find lag on throws).

•Throws without internally applied damage (single hit) have lag that varies (∂W) across the cast. Testing these is a nightmare and as such I'm only going to be testing a few characters single hit throws.

example of preliminary throw frame data test results from an earlier B+ set: kirby selected arbitrarily but I've done all of the characters at least once.

Kirby	f-throw	[62-45=17]*	b-throw	[46-33=13]*	up-throw [80-51=29]*	d-throw	[90-60=30]	
	HS@0	Lag	Adv @0	HS@0	Lag	Adv @0	HS@0	Lag	Adv @0	HS@0	Lag	Adv @0
DK	32	19	13	42	15	27	41	33	8	41	30	11
Snake	32	20	12	42	14	28	41	33	8	41	30	11
Bowser	32	19	13	42	15	27	41	32	9	41	30	11
DDD	32	19	13	42	15	27	41	32	9	41	30	11
Zard	32	19	13	42	14	28	41	31	10	41	30	11
Ganon	32	18	14	42	15	27	41	32	9	41	30	11
Samus	32	18	14	42	14	28	41	31	10	41	30	11
Wario	32	18	14	42	14	28	41	31	10	41	30	11
Yoshi	32	18	14	42	14	28	41	31	10	41	30	11
Rob	32	18	14	42	14	28	41	30	11	41	30	11
Ike	32	18	14	42	14	28	41	30	11	41	30	11
CF	32	18	14	42	13	29	41	30	11	41	30	11
Link	32	18	14	42	13	29	41	30	11	41	30	11
Wolf	32	18	14	42	13	29	41	29	12	41	30	11
Ivy	32	17	15	42	13	29	41	29	12	41	30	11
Lucario	32	17	15	42	13	29	41	29	12	41	30	11
Mario	32	16	16	42	13	29	41	29	12	41	30	11
Luigi	32	17	15	42	12	30	41	28	13	41	30	11
sonic	32	16	16	42	12	30	41	27	14	41	30	11
Lucas	32	16	16	42	12	30	41	28	13	41	30	11
Ness	32	16	16	42	12	30	41	28	13	41	30	11
Pit	32	16	16	42	12	30	41	28	13	41	30	11
dK	32	16	16	42	12	30	41	27	14	41	30	11
IC	32	16	16	42	12	30	41	27	14	41	30	11
TL	32	16	16	42	12	30	41	27	14	41	30	11
Peach	32	15	17	42	12	30	41	26	15	41	30	11
Marth	32	14	18	42	12	30	41	25	16	41	30	11
Sheik	32	14	18	42	11	31	41	24	17	41	30	11
Zelda	32	14	18	42	11	31	41	24	17	41	30	11
Falco	32	14	18	42	10	32	41	24	17	41	30	11
Olimar	32	14	18	42	10	32	41	24	17	41	30	11
ZSS	32	14	18	42	11	31	41	23	18	41	30	11
Fox	32	14	18	42	10	32	41	23	18	41	30	11
MK	32	13	19	42	10	32	41	23	18	41	30	11
Pikachu	32	13	19	42	10	32	41	23	18	41	30	11
Kirby	32	13	19	42	10	32	41	23	18	41	30	11
GW	32	13	19	42	10	32	41	21	20	41	30	11
Squirt	32	13	19	42	10	32	41	21	20	41	30	11
JP	32	12	20	42	9	33	41	20	21	41	30	11

The most important thing you will ever learn about frame advance data mining:

Spoiler

OK, time to share something kinda boring but really useful.

Counting frames is incredibly tedious and a waste of time. If you're collecting data that requires frame-advance rather than PSA (say you're finding shield or hitstun data) its a lot easier if you give a frame value to the clock timer. What I like to do to make things easiest for me is to have the initial input frames for whatever I'm testing occur on the x:00 mark.

So I made this little chart for easy conversions:

Time	Frame			
x:00	0			
98	1		48	31
96	2		46	32
95	3		45	33
93	4		43	34
91	5		41	35
90	6		40	36
88	7		38	37
86	8		36	38
85	9		35	39
83	10		33	40
81	11		31	41
80	12		30	42
78	13		28	43
76	14		26	44
75	15		25	45
73	16		23	46
71	17		21	47
70	18		20	48
68	19		18	49
66	20		16	50
65	21		15	51
63	22		13	52
61	23		11	53
60	24		10	54
58	25		8	55
56	26		6	56
55	27		5	57
53	28		3	58
51	29		1	59
50	30		x+1:00	60

Ex. lets say I'm finding throw data.

I'll grab Lucario (with his weight mod of 0) at the desired % with the character in question. Let the timer run down to the xx:00 mark (seconds:milliseconds), and input the throw on that frame. I than have a point of reference and can really easily gather the rest of the data by buffering shield to determine the IASA, alternating jump and tap-jump to determine the escape frame, watching the damage marker to determine release frame... and I can play with DI or teching etc etc etc... you see how this is way easier than counting frames when you're doing close to a thousand tests minimum.

How to find stuff in frame advance

Grounded IASA: buffer shield
Aerial IASA or escape frame: alternate jump and tap jump

With finding the hitstun escape frame its best to make sure the opponent is thrown offstage, otherwise you'll find the "first techable frame" which you may also want depending on the throw.

If you are gathering hitstun data:
-hitstun = Escape frame - Release frame
-keep in mind its % and character dependent
-most characters suffer equal hitstun from a move at 0%.
-moves with a high bkb to KBG ratio will have more consistent hitstun values across the cast and %.

If you are gathering ONLY advantage data on a throw:
-Advantage on a non-teched throw= Escape frame (thrown character) - First actionable frame.
-keep in mind that weight dependent throws will yield different FAFs based on character thrown.

obviously Advantage also = (hitstun + release frame) - First actionable frame.

moving that data around from my initial dump thread...

ICs visible hibubble .pac: http://smash.everalert.net/downloads/Fit...e_v0.1.pac

 

[rPSIvysaur]

Have you got any of your WBR friends to unmap the z-button for frame by frame?

 

[Veril]

I had completely forgot about that...

Oh, thought I'd share this here before copying in anything else CAUSE IT IS THE SINGLE MOST IMPORTANT PIECE OF VBRAWL FRAME DATA.

Best move in the game:

The shield (revised optimal shield drop repeat breakdown) <3 <3

Frame 0: input shield
Frame 1: shield appears
Frame 1-7: in shield, OOS-limited
Frame 8: shield drops
Frame 8-14: shield-drop lag*
Frame 15: earliest shield reappearance
Frame 177: shield breaks automatically

*Shield-drop lag is the state in which the only option available is jumping or jump canceled options. This lasts 7 frames.

 

[Remzi]

Isn't the soonest you can do any action (besides one that involves jumping or cancelling a jump) frame 15 anyways?

If you input shield on frame 0, the soonest you can begin to drop your shield is frame 7 as far as I know. On frame 8, a period of 7 frames begins (shield drop lag) in which you can't do anything that doesn't involve jumping. After shield drop lag ends, you are at frame 15 where you can bring your shield backup. But frame 15 is also the first frame that you regain the ability to do almost everything, not just shielding.

 

[Veril]

Yes, that is true. "Clarifies"

I just really like the term shield refraction >.>

Maybe we could use that for the 7 frames a shield must stay up?

OOS vs OOSDL:

OOS (out of shield) options: roll, spotdodge, grab, and jump (except for poor poor Yoshi). It is possible to shield-drop after frame 8 (but then your enter shield drop-lag).
-OOJS (out of jump-start ie jump canceled): up-smash, up-b.
-rolls can be canceled early on into throws (aka glide tossing)

OOSDL (out of shield-drop lag) options are limited to jump.

 

[Remzi]

I wasn't aware of the terms OOJS or OOSDL, are those new? Either way, I like them and will try to memorize them.

And shield refraction is definitely a name awesome enough to warrant some sort of usage, so I'm perfectly fine with using it for the 7 frame period you referenced.

 

[rPSIvysaur]

I have an idea for this. We can use Google docs to share the data on spreadsheets. Thoughts?

 

[EverAlert]

I love it, I use Google Docs for everything as it is.

 

[Veril]

Have you got any of your WBR friends to unmap the z-button for frame by frame?

I've got someone working on it.

I wasn't aware of the terms OOJS or OOSDL, are those new? Either way, I like them and will try to memorize them.

And shield refraction is definitely a name awesome enough to warrant some sort of usage, so I'm perfectly fine with using it for the 7 frame period you referenced.

I think renovating the fairly arbitrary use of "canceled" will help with terminology. OOJS is basically the equivalent of (single) Jump-canceled except it actually accurately describes what is being canceled by what.

OOSDL is fairly unneeded but it does describe a situation separate and distinct from OOS (in that you are limited to only jump and OOJS options).


I don't think all of these terms need to be catchy and we should still keep track of the "vernacular" existent terminology but for purely technical discussion I think using the most accurate and least confusing term is best.

 

[Indigo Jeans]

The current use of "cancelled" isn't confusing at fist, as the smash communtiy has always used it when refering to an attack cancelling another. But that's the problem. Like you said Veril, the syntax is reversed. In DACUS, we have Dash Attack Cancelled Up Smash. X cancelled Y. If you break it down and think about it, it really makes more sense that this would refer to an USmash that was cancelled by a dash attack. Which isn't the case. Rather, it should be USmash cancelling Dash Attack. However, because of the way the grammatical mind works, we tend to think of it being adjective-adjective-noun, which would explain the incorrect use of "cancelled". To retain the word order and to cause less confusion among the vernacular-speaking community, I suggest we simply change the -ed in "cancelled" to -ing. Dash Attack Cancelling Up Smash. DACUS.

 

[rPSIvysaur]

I thought it stood for Dash Attack Cancelled into Up Smash. >.>

 

[Veril]

Any new terms we use should be clear based on the acronym and not need to be inferred.

DACUS is already established. It could be interpreted as Dash attack Canceling up-smash, but the same problem exists of syntax is present.

The way to deal with this with all new ATs /acronyms is consistently placing the move which is canceled first, and the canceling move second. There are a lot of preexisting exceptions like JC shine, in which the cancelling move is listed first, but those we will simply have to note as being exceptions (even though shine does have momentum altering properties that might qualify it as being able to "cancel" a jump as well >.<).

blech

 

[Indigo Jeans]

Hm? I had thought "JC Shine" was "Jump canceling Shine", where you jumped and immediately input a Shine to cancel your jump momentum, then your shine was cancelled by landing. >__> Or at least that's what happens in 64.

So JC shine = a Shine cancelled by/into a jump, right?

 

[Veril]

and this is why we have an issue with nomenclature ^^

 

[KayLo!]

I'm just gonna repeat what I said in the other thread......

Hmm.... I always thought of the canceled/canceling thing like this:

For "X canceled Y", I would naturally think Y is being canceled by X.
For "X canceling Y", I would think Y is canceling X.

Adding a hyphen makes it easier to follow imo...... "ledge-canceled _____", "jump-canceling _____", etc.

So for ex: jump canceled usmash..... makes no sense. To me, that would imply that it's a usmash being canceled by a jump. x.x

Basically what Indigo said now that I read it thoroughly, lol. We should follow this pattern from now on imo..... makes more sense. Hyphens help -- more so for "-canceled"s (whether that's grammatically correct or not).

 

[GimR]

All invincibility and super Armor frames. that'd be great too. I know that kind of flows a long with seeing the hurt bubbless, but I thought'd I'd put that out there.

 

[DMG]

Indeed. Covering planking is gonna be interesting

 

[adumbrodeus]

I'd like something else in the human element actually.

Quantifying how long it takes to input different things after a person "reacts" (in other words, realizes what the opponent is doing and moves to counter). The thing is, different moves take different amounts of time to input, ex. I don't think it's possible for the L and R inputs to actually register frame 1 due to the springs, and quarter circle DI is obviously a multi-frame affair. Having a baseline would help us better quantify what inputs are humanly possible on reaction.


That said, I'm still at a bit of a loss on how to figure that out.

 

[KayLo!]

By humanly possible, I'm guessing you mean at pro-level...... because the range for all players is pretty **** wide. And for that to happen, we'd need input from the best players (M2K, Ally, etc.), who undoubtedly have the best of the best reaction times.

Sounds interesting, but I have no idea how you'd manage to figure it out, much less for every useful move, lol.

Also, no springs ftw. <333

 

[adumbrodeus]

Pro level, to get really effective analysis gotta assume top of the metagame, cause it's much more useful if it's something people can practice to as opposed to something that only applies to lower levels of play.

 

[KayLo!]

So uh, after this weekend, I'm gonna get started on redoing/finishing Zelda's complete hitbox data (or at least get as far as I can before I get frustrated by Z-button shenanigans).

No real reason for me to announce it, but this place is dead & I'm calling it in case anybody else wanted to do it for some reason.

 

[Veril]

I'd like something else in the human element actually.

Quantifying how long it takes to input different things after a person "reacts" (in other words, realizes what the opponent is doing and moves to counter). The thing is, different moves take different amounts of time to input, ex. I don't think it's possible for the L and R inputs to actually register frame 1 due to the springs, and quarter circle DI is obviously a multi-frame affair. Having a baseline would help us better quantify what inputs are humanly possible on reaction.


That said, I'm still at a bit of a loss on how to figure that out.

This must be what you wanted to talk to me about lol

Yeah I figured a ton of reaction time and physical frame input requirements stuff out over the course of working on 5 different modding project.

Sorry I've been out so long. I've been working on a huge data package for vBrawl, creating a new CG framework for the ICs in B+, and looking in depth at the BS people say about vBrawl MK (other than the planking and IDC critiques, that's not bs).

So uh, after this weekend, I'm gonna get started on redoing/finishing Zelda's complete hitbox data (or at least get as far as I can before I get frustrated by Z-button shenanigans).

No real reason for me to announce it, but this place is dead & I'm calling it in case anybody else wanted to do it for some reason.

You mean her frame advantage on d-tilt stuff? If you need hitbox data that stuff is easy to get.


M2K does not have the absolute fastest reaction time btw. Its very good, but Ally and some other players have better raw CRT. CRT is not as pronounced a factor in brawl anyway. I've heard M2K's is 13 frames but I could definitely figure it out if I had a 60fps replay of him.

 

[adumbrodeus]

That (I wanted to see if we could figure out a way to test for that), but also there was another project I wanted to talk to you about, more of a long-term meta-project that incorperated all the data we're working with.


Catch me online sometime and we'll talk.

 

[KayLo!]

You mean her frame advantage on d-tilt stuff? If you need hitbox data that stuff is easy to get.

By complete frame data, I mean hitbox data, fresh/stale damage, frame advantages, shield stun, etc. Some of it's easy to get; some of it will probably take me forever/I'll need help, but I wanna start with Zelda rather than Pika since she's a character nobody cares about (i.e. good practice grounds).

..........I also promised them I'd work on this stuff ages ago, so it's about time I deliver. ;;

 

[rPSIvysaur]

I think someone should set-up a Google Docs for us to hold this info. Any volunteers?

 

[adumbrodeus]

I can set it up, doing so atm

 

[DMG]

Yeah M2K has a fairly "bad" reaction time. Ally is pretty darn fast, he might be somewhere around 6 frames. I probably hover around 7-8 when I am intently focused.

 

[adumbrodeus]

I've got a folder set up, here's the link:

http://docs.google.com/leaf?id=0B3jXfnQLA-ISMTAzNjBiODYtYzFlYS00YWI1LTg2ZGEtZmI1MDYzZGEyYWE2&hl=en


Four options.

1. We allow anyone to view the data and give out the link freely, but only we can edit.

2. We don't give out the link and allow anyone with it to edit.

3. We don't give out the link and require you to be invited to edit anyway.

4. We establish a separate folder as a site for random information and projects in progress and use this folder for the finished projects, and give out the link for this freely, but only we can edit.

 

[KayLo!]

For now, I saw we don't give out the link. When it's a bit more filled in/polished/etc., I think that's when we should start giving the link out to whoever wants to view the information.

Anybody who's a Researcher should be able to edit if they ask imo.

 

[adumbrodeus]

More wondering if we should add everyone manually as opposed to just having a link back here that everyone can access.


More thinking about the future, but there's plenty of stuff we can put polish and put up, especially from the collected data thread.


I'm personally in favor of having a "releases" folder which everyone can see and we post a link to conveniently in tactical and having a private folder two subfolders, "dumpsite" for raw data, and a "projects" where projects in the works are stored.

 

[KayLo!]

Add people manually..... that's why I said "if they ask".

Honestly tho, I don't care how it's done..... as long as it's easy to edit/keep up-to-date and fairly easy for the general public to follow once it's made viewable.

 

[adumbrodeus]

Ok, fair enough, but I think every smash researcher should be able to edit by default.



Anyone else have any opinions?

 

[rPSIvysaur]

I think it should be for all of us researchers. If someone starts editing it that isn't a researcher (via leak ) then we can start doing it manually.

 

[Veril]

Yeah M2K has a fairly "bad" reaction time. Ally is pretty darn fast, he might be somewhere around 6 frames. I probably hover around 7-8 when I am intently focused.

Choice Reaction time ≠ raw reaction time. CRT varies with an inverse relationship between the number of total options and number of viable options. CRT is by default higher than raw reaction time and CRT of 6 frames is impossible. Even a raw reaction time of 6 frames, where response to the stimulus does not require taking the cognitive high road, would be insane. Like, world record holding Olympic sprinter reaction time. In fact, if you were off the starting block of a sprint in under 6 frames after the gun you would be counted as having a false start, because it is humanly impossible to react that fast even at the very peak of human potential (I think the closest ever recorded start was .103 after the gun or a tiny bit over 6 frames in smash-terms).

So no, Ally doesn't have 6 frame CRT, though its possible he has a raw reaction time of under 10 frames a CRT that low is neurologically impossible.

I've got a folder set up, here's the link:

http://docs.google.com/leaf?id=0B3jXfnQLA-ISMTAzNjBiODYtYzFlYS00YWI1LTg2ZGEtZmI1MDYzZGEyYWE2&hl=en


Four options.

1. We allow anyone to view the data and give out the link freely, but only we can edit.

2. We don't give out the link and allow anyone with it to edit.

3. We don't give out the link and require you to be invited to edit anyway.

For now, I saw we don't give out the link. When it's a bit more filled in/polished/etc., I think that's when we should start giving the link out to whoever wants to view the information.

Anybody who's a Researcher should be able to edit if they ask imo.

#3

and I agree with Kaylo. I want to limit editing permissions to people who are actually experienced frame data analysts if its a frame data thread, hacking information and codeset to people who actually hack, etc. Everyone in the smashlab should have access and eventually everything should be fact checked and made public in a way appropriate to the information. We could even release something on a monthly basis, like a journal, in this case a peer reviewed journal because this is an incredibly savvy group.

For example, I talked with Hot Garbage and pointed out some errors in his MK frame data (amazing as it is <3). A project I've been working on is reformatting all his MK data, fact checking, getting more detailed information, etc, and when that's ready I'm gonna release.

More wondering if we should add everyone manually as opposed to just having a link back here that everyone can access.


More thinking about the future, but there's plenty of stuff we can put polish and put up, especially from the collected data thread.


I'm personally in favor of having a "releases" folder which everyone can see and we post a link to conveniently in tactical and having a private folder two subfolders, "dumpsite" for raw data, and a "projects" where projects in the works are stored.

Projects should be based here. People should not have read access to raw data especially anything that's sensitive, such as MK data. Notably with something like the planking data, I'm not comfortable discussing that publicly when it is literally IMPOSSIBLE to have a civil technical discussion of MK without it devolving into a ban argument. I'm strongly anti-ban fyi, and I can and will **** pro-ban's "frame safe perfect options" nonsense. At the same time I recognize that MK has a textbook broken quality in his planking. You see how read-access is not something I will work with if its MK related.

Will the information become public? Yes. Real labs aren't generally open to the public, remember.

Ok, fair enough, but I think every smash researcher should be able to edit by default.



Anyone else have any opinions?

Everyone should be able to edit within their field(s) of expertise.

I think it should be for all of us researchers. If someone starts editing it that isn't a researcher (via leak ) then we can start doing it manually.

I strongly STRONGLY favor doing it manually. Having actually dealt with leaks of sensitive out of context information, I am not willing to deal with that crap here.

 

[The Cape]

I have begun putting together a list of aerial IASA and autocancel points for all characters. Its about 95% done and I should be able to post it here tomorrow. Is there any other accurate information that you wish to have posted here about the aerials? Such as landing lag or whatever?

 

[Indigo Jeans]

Mm, I agree with Veril. We should treat these documents like one in a research lab would treat rough drafts for a journal. We should release stuff on a monthly basis. Hell, we could give it a fancy name like "Research in Review" or "the Lab's Monthly".

We need to keep the public as objective to speculative data as we can. If the link ever got leaked, or any unfinished data for that matter, it would cause a lot of problems that would be hard to fix. I'd imagine stuff along the lines of Pro-Ban hopping right on possibly innacurate planking data for their own benefit. What would happen then would be that this data would be absorbed into the mainstream, become "common knowledge". This of course would make people make incorrect assumptions.

For example (and only as an example), let's say stem-cell researches think they've found a way to reverse the degeneration of nucleic chains in cells, effectively "stopping" aging. If this unfinished news got out to the public -and sadly, this sometimes happens- discussion would erupt about living forever blah blah blah. This can only end in three ways. The guys at the lab were already close to the end of their research anyways, so they release correct data in time to render the other data obsolete in the public eye, they rush to get their stuff done and stop the confusion, but they release flawed data, or the time period between the leak and the actual release is so large the new, "right" information is ignored and the old, "wrong" information is kept.



Tl;dr yeah let's keep this Researcher exclusive. >__>

 

[Veril]

I have begun putting together a list of aerial IASA and autocancel points for all characters. Its about 95% done and I should be able to post it here tomorrow. Is there any other accurate information that you wish to have posted here about the aerials? Such as landing lag or whatever?

I'm working with Cape (best smash research duo ever) and will be adding in any first actionable frames that result from the animation simply ending. Also I'll be uploading jump data and aerial input maps (sans FF landing point permutations for now as that is fairly time consuming and will take me longer to complete). In the case of Bowser I'll include his SJR data as well (ie grounded double jump input maps).

 

[adumbrodeus]

The main point I was trying to get across was that a read-only google documents archive for our COMPLETED projects, in order to make them more accessible.



Sub-dividing them by type would be useful however, I like that idea.

 

[DMG]

I was talking simply about Raw, yes.