Important Melee, Hacks, and You -- New Hackers Start Here, in the OP!

[zankyou]

Well I wouldnt get rid of them all of them. Especially something like Godfeds post. Was definitely helpful when I was looking into the format and one of the most annoying things I find about brawl hacking is how little info there is about the formats and how much people rely on programs.

 

[Mazdamaxsti]

This might be a common question, but where do I start? Theres like 100 links here and should I be looking at them in order, or a specific order?

 

[Achilles1515]

This might be a common question, but where do I start? Theres like 100 links here and should I be looking at them in order, or a specific order?

Look at them in the order of your interest.

 

[DRGN]

Ok, Audio section updated. (Finally! Welcome to the modern era, Audio Section.)

I almost left an "Archive" spoiler in the section, with the old content. But could not really see any use in it, and so I left it out as well. If anyone thinks it might be useful, let me know and I may still add it.

I kept the post by GodFed on the HPS format because I agree with zankyou about it being important to preserve that format information for future coders. I updated the description to it though to better reflect that purpose.

Thanks, @jmlee337

 

[Itaru]

I'll make a thread tomorrow.

edit: http://smashboards.com/threads/anim...ou-can-use-victory-pose-animation-now.440443/

 

[zankyou]

Modifying the stage select screen. I can't get rid of the transparency on the portrait because its tied to an unknown structure but it doesnt look too bad hopefully. I just hope the ram supports the amount of images Im going to try to add.

btw if anyone is wondering what happened to this, dolphin wasnt emulating it properly so it made it hard to trouble shoot.

 

[MethaneMan0]

simple question, ive been looking for just green lasers (both fox/falco) and and green firebird/firefox. I saw one of the original posts but there isnt a download there anymore and the pictures have even disappeared (the post was from 2010). So, does anybody have a download for green lasers (fox/falco) and green firebird/firefox? Would be much appreciated

 

[Geranimo]

Hi, I downloaded the Toomai's hitbox collection, but I have questions.

- How do I know what part of the character the bone ID represents?
- Where can I find the bones positions of each playing character in the melee memory (when the game is running)
- Are the XPos, YPos and Zpos relative to the TopN or the bone?
- How are the X, Y and Z coords placed (ex in my screen x is left to right, y is top to bottom, etc)
- Where is the duration of the hitbox? For example, cpt falcon's uair hits during 8 frames, however, line 844 in the excel file, there's only 3 states for it: clean, mid and late. How do I know the duration of each of the clean, mid and late hitboxes?

Thanks

 

[Punkline]

Geranimo Sorry, I got your PM but I missed this post. I covered some of this in my reply, but I’ll go over it again briefly for anyone else and try to answer your questions here more specifically:

How do I know what part of the character the bone ID represents?

The best way I know of right now is to use brawlbox and these bone mdl0 files provided by Z zankyou

Where can I find the bones positions of each playing character in the melee memory (when the game is running)

Internal player data offset 0x5E8 holds a pointer to the bone data of an individual player entity. Each entry on this data table is 0x10 bytes long (indexed by bone ID) and contains a pointer (offset 0x0) to data used by things like hitboxes as a means of referencing bones. It contains XYZ position floats starting at offset 0x38.

(internal player -> 0x5E8 -> (boneID * 16) -> 0x38 == X position of a specific bone)

From an external player data pointer (like those passed to most player-related functions) you can load the pointer value at offset 0x2C to get the internal player data pointer.

(external player -> 0x2C == internal player data pointer)

You can use player-related functions, r13, or one of the static player block entity pointers as a means of acquiring an external player data pointer. An example using the static player blocks that begin at RAM address 80453080 in Melee v1.02:

(80453130 == external player 1 data pointer)
(80453F10 == external player 2 data pointer)
etc.

So, a couple of examples:
80453130 -> 0x2C -> 0x5E8 -> 0 -> 0x38 == player 1 topN X position
80453F10 -> 0x2C -> 0x5E8 -> 0x10 -> 0x3C == player 2 transN Y position

Are the XPos, YPos and Zpos relative to the TopN or the bone?

I believe all child bones are relative to their parent bone, and TopN is the parent of the whole skeleton. You can reference a parent bone from the bone data at offset 0xC.

You can reference TopN from the bone table as mentioned above, or you can take a shortcut by loading the XYZ floats at internal player data offset 0x6F4.
(internal player -> 0x6F4 == XYZ position floats for TopN)

How are the X, Y and Z coords placed (ex in my screen x is left to right, y is top to bottom, etc)

I’ve been a bit confused about this myself. The game rotates the player 90 degrees on stage, so it’s easy to confuse X and Z… For bones, I think it’s relative to how you would expect to find them in a T-pose, so they are rotated from what you might expect in a stage orientation.

Where is the duration of the hitbox? For example, cpt falcon's uair hits during 8 frames, however, line 844 in the excel file, there's only 3 states for it: clean, mid and late. How do I know the duration of each of the clean, mid and late hitboxes?

Hitboxes are a part of the player subaction event system. Check out Crazy Hand in the Customized Movesets subforum to explore how event data works.

In a nutshell, hitbox initialization data (the 5 “Data” columns D, E, F, G, and H in the spreadsheet you linked) is a type of subaction event, and each is a part of a larger body of data that gets parsed alongside other events to describe scripted interactions with action state animations. Chunks of data are read at a time in the form of keyframes defined by in-line timer events; and a hitbox is simply terminated by another event that follows initialization--so it may potentially span multiple keyframes.

Together, a hitbox initialization, timer, and hitbox termination event in sequence are used to create a window of time for the hitbox to be active.

The game doesn’t actually keep track of the remaining time in an active hitbox--rather it keeps track of the time until the next chunk of subaction event data is read. You can remove the termination event and expect a hitbox to last for the entire duration of an action state.

It might be possible to write a code that scans the remaining event data for a subaction in order to calculate the remaining frames based on the subaction timer, but it would probably be a little meaty. You would have to inform the code of different event data lengths to be recognized by opcode, and the only way I can think to do that is to create an array.

It’s possible though to easily check if (any) hitbox is currently active on a player by referencing the flag bit stored at internal player data offset 0x2219 (bit 0x10) by both the hitbox initialization and termination events.
(internal player -> 0x2219 (bit 0x10) == active hitbox flag)

 

[Roundel]

hi guys, i'm new here so i'm not sure if this is the right place to ask, but, I'm looking for a way to find, from reading RAM (not executing code), if the current actionState is currently cancellable. For example, the Wait actionstate is always cancellable, or how for many moves they are cancellable after a certain frame.

Additionally, would there be a way to find, from reading RAM, when some arbitrary given actionstate becomes cancellable? I was thinking along the lines of following the pointer to the state's function and looking for the IASA function there, then inferring maybe from the parameters or memory offsets how long into the actionstate that would happen. Am I way off base with this?

 

[Achilles1515]

hi guys, i'm new here so i'm not sure if this is the right place to ask, but, I'm looking for a way to find, from reading RAM (not executing code), if the current actionState is currently cancellable. For example, the Wait actionstate is always cancellable, or how for many moves they are cancellable after a certain frame.

Additionally, would there be a way to find, from reading RAM, when some arbitrary given actionstate becomes cancellable? I was thinking along the lines of following the pointer to the state's function and looking for the IASA function there, then inferring maybe from the parameters or memory offsets how long into the actionstate that would happen. Am I way off base with this?

Via RAM, you can tell if the IASA flag is enabled/disabled, and you can get the address of the current action state's interrupt function. But there is not a good way to just automatically know the extent of what the interrupt function holds (what all actions it can "cancel" into). All you are given is a RAM address to the start of the assembly function that controls performing the checks.

To figure out when the IASA flag is enabled/disabled for any action state, you would have to parse the action state's script event data (the stuff that is editable via Crazy Hand), and use the synchronous/asynch timer events to figure out what frame the IASA flag is being enabled. IASA enable/disable is an event itself.

 

[Roundel]

Via RAM, you can tell if the IASA flag is enabled/disabled, and you can get the address of the current action state's interrupt function. But there is not a good way to just automatically know the extent of what the interrupt function holds (what all actions it can "cancel" into). All you are given is a RAM address to the start of the assembly function that controls performing the checks.

To figure out when the IASA flag is enabled/disabled for any action state, you would have to parse the action state's script event data (the stuff that is editable via Crazy Hand), and use the synchronous/asynch timer events to figure out what frame the IASA flag is being enabled. IASA enable/disable is an event itself.

Thanks for the reply, I was thinking the IASA flag was 8bits when in reality it is 32, and the most significant bit seems to be the one i'm looking for, so no wonder I was missing it haha.

Since I made that post I've been digging through the internet and cross-referencing the dolphin debug mode, and I know more specifically what I'm trying to ask. I'm looking to parse the subaction scripts to find the IASA-setting event there but I have two problems.

The first is that although I could make a table of where every script is stored (since they seem to always end up in the same static RAM addresses), I would prefer to find the script programmatically given a character and an actionstate. From what I understand, each character has some spot in memory that contains a list of offsets to that character's subaction scripts. I think I've found that list, each entry seems to be 6*4 bytes long, and they look like they include 2 pointers and some data, does that sound right? If so, is there a known way to find which actionState these entries correspond to? Or reversely, if given an actionstate and a character, could that information lead me to a pointer that could lead me to the relevant script?

The second problem is about the length of the subaction events in memory. The events seems to generally be either 4, 8, or 20 bytes long. I'm looking for a list of how long each event is in memory. I've noticed that there are lists all over the internet with info about the different subaction event ids (like 08 being async timer and being 4 bytes, hitboxes being 20 bytes, etc) and what they do, but they don't seem to include info about how long the unknown ones are. Is this something that someone has compiled before, or should I spend some time poking around and figure this one out myself?

 

[Punkline]

If so, is there a known way to find which actionState these entries correspond to? Or reversely, if given an actionstate and a character, could that information lead me to a pointer that could lead me to the relevant script?

You can see how the game does this by looking in on the action state change function.

At internal player data offsets 0x1C and 0x20 are pointers that point to the beginning of move logic data for common action states (0x000 - 0x154) and unique action states (0x155+) respectively. The entries are actually aligned by 8*4.

If the action state you want to look at is a normal action state shared between characters (< 0x155) then just multiply the ID by (8*4) and add it to the address in 0x1C. If it’s a special move, or something unique to a character; then subtract 0x155 from the ID, then multiply it by (8*4) and add it to the address in 0x20.

From there you can grab the pointer to the action state’s associated move logic pointers, such as the IASA checks from 0x10. An example of the common index and the standing state:

I think these are static, and can be found in start.dol

The second problem is about the length of the subaction events in memory. The events seems to generally be either 4, 8, or 20 bytes long. I'm looking for a list of how long each event is in memory. I've noticed that there are lists all over the internet with info about the different subaction event ids (like 08 being async timer and being 4 bytes, hitboxes being 20 bytes, etc) and what they do, but they don't seem to include info about how long the unknown ones are. Is this something that someone has compiled before, or should I spend some time poking around and figure this one out myself?

The only way to know of the length of subaction event (to my knowledge) is to observe the involved parsing functions. They seem to stubbornly move the pointer 1 word at a time, so you can expect an alignment of 1*4, and similar looking instructions for each 4-byte step.

(Edit - fixed the pointers; accidentally posted the functions that use them R Roundel )

803b9840 - index of pointers to control subaction event parsing functions (events 00 - 24)
803c06e8 - index of pointers to player subaction event parsing functions (events 28 - E8+?)

If you put a breakpoint at the beginning and end of each of the functions on these lists, you'll be able to watch the pointer at internal player data offset 0x3EC move by the length of the corresponding event. Alternatively, you can just scan them for instructions that appear to be moving the pointer loaded from 0x8 of argument r4.

It probably wouldn't be too hard to compile a list based off of this knowledge, assuming it was only for vanilla subaction events. Most of the lengths have already been documented by Crazy Hand.

 

[Geranimo]

Is it a bug in brawlbox that the coordinates are not correct? For example, in CrazyHand, if I modify falcon's up-air hitbhox[1] z-offset, it moves the hitbox farther (or closer) following the line between bones 7 and bones 8 (hitbox[1] is on bone 8). However, in brawlbox, if I put the mode in translation mode, it says that the direction that points in the direction (bone 7 -> bone 8) is the X coordinate.

Edit: You said it right PunkLine in your previous post. So does melee rotate all the brawlbox bones coordinate systems 90 degrees clockwise around Y?

In fact it seems that brawlbox and melee have inverted the X and Z coordinates. In their Viewer Help, they say
X is red, Y is green, Z is blue.

However if I think
Z is red, Y is green, X is blue.
everything works.


Edit again: I don't understand why some bones have rotation values even if they are in the same direction as the parent bone. For example, for falcon, bone6 is child of bone4, and both bones 6 and 4 are in the same direction for the coordinates. However, bone6's rotation is -90.57, 0, -89.999. Why?

Yet another edit: it seems that the rotation values are for the next bone in the bones list, not for the bone's actual rotation compared to its parent.

Editing never stops: concerning phantom hits, ssbmwiki states that "Such hits occur when a hitbox connects less than 0.01 units through a hurtbox". Does it mean that the volume of the connection is less than 0.01 melee-meter³? Or that the length of the overlap must be less than 0.01?

 

[Meistermayo]

Hey I'm new to Melee hacking and I have a question:

Is there any appendix of IASA function indexes out in these boards somewhere? In Magicscrumpy's Jigglypuff Shine mod i learned 800CAED0 calls a grounded jump function and 800CB870 calls a doublejump function. I want to try to employ other types of cancels and maybe on-hit cancels but I can't find any information on IASA functions.

 

[zankyou]

Is it a bug in brawlbox that the coordinates are not correct? For example, in CrazyHand, if I modify falcon's up-air hitbhox[1] z-offset, it moves the hitbox farther (or closer) following the line between bones 7 and bones 8 (hitbox[1] is on bone 8). However, in brawlbox, if I put the mode in translation mode, it says that the direction that points in the direction (bone 7 -> bone 8) is the X coordinate.

Edit: You said it right PunkLine in your previous post. So does melee rotate all the brawlbox bones coordinate systems 90 degrees clockwise around Y?

In fact it seems that brawlbox and melee have inverted the X and Z coordinates. In their Viewer Help, they say
X is red, Y is green, Z is blue.

However if I think
Z is red, Y is green, X is blue.
everything works.


Edit again: I don't understand why some bones have rotation values even if they are in the same direction as the parent bone. For example, for falcon, bone6 is child of bone4, and both bones 6 and 4 are in the same direction for the coordinates. However, bone6's rotation is -90.57, 0, -89.999. Why?

Yet another edit: it seems that the rotation values are for the next bone in the bones list, not for the bone's actual rotation compared to its parent.

Editing never stops: concerning phantom hits, ssbmwiki states that "Such hits occur when a hitbox connects less than 0.01 units through a hurtbox". Does it mean that the volume of the connection is less than 0.01 melee-meter³? Or that the length of the overlap must be less than 0.01?

When you rotate a bone, it doesnt translate the bone, it changes the direction its pointing. It will still rotate all vertices tied to that bone so saying its for the next bone isnt quite right.

 

[tatatat0]

Hey I'm new to Melee hacking and I have a question:

Is there any appendix of IASA function indexes out in these boards somewhere? In Magicscrumpy's Jigglypuff Shine mod i learned 800CAED0 calls a grounded jump function and 800CB870 calls a doublejump function. I want to try to employ other types of cancels and maybe on-hit cancels but I can't find any information on IASA functions.

I'm not very sure if there is a definitive list. Simply copying other character's special interrupts works fine. You can also take a look in the "Melee Table of Contents" at 0x3BF800 in the start.dol which I believe uses the same format as the characters' special interrupts.

 

[Geranimo]

When you rotate a bone, it doesnt translate the bone, it changes the direction its pointing. It will still rotate all vertices tied to that bone so saying its for the next bone isnt quite right.

If the next bone is rotated, the parent's rotation values will have the next bone's rotation, but the parent's coordinate system won't be rotated, it's the child that will be rotated by the amount defined in the parent's rotation values, and the child's rotation values will be 0,0,0

 

[zankyou]

If the next bone is rotated, the parent's rotation values will have the next bone's rotation values, but the parent's coordinate system won't be rotated, it's the child that will be rotated by the amount defined in the parent's rotation values.

If you go in brawl box and change the rotation, youll see the lines indicating its direction change. While it doesnt move, its rotated and all vertices weighted to it are rotated.

 

[Geranimo]

What I say is: when a bone has anything other than 0,0,0 as rotation values, this bone won't be rotated by this but the next bone yes. I find this counter intuitive because I was thinking translation AND rotation were the difference with the parent and applied directly.

 

[zankyou]

What I say is: when a bone has anything other than 0,0,0 as rotation values, this bone won't be rotated by this but the next bone yes. I find this counter intuitive because I was thinking translation AND rotation were the difference with the parent and applied directly.

I believe you are talking about rotations about an axis. Which is the difference is LRS vs RSL. But saying its not rotated is incorrect.

 

[Geranimo]

Ok so it's just a brawlbox bug?

 

[zankyou]

Id have to see an example of it.

 

[Geranimo]

For example for cpt falcon:

Spoiler: bone 4

Spoiler: bone 6 has -90, 0, -90 but is not rotated compared to its parent bone 4

Spoiler: bone 6's child, bone 7, is rotated by -90, 0, -90

 

[zankyou]

Yeah thats how its supposed to work. It doest rotate about the parent joint. Everything tied to that joint is rotated. Including verts/normals. I think this is the standard convention but I only looked this up when I was making the transformations. It makes sense to me since when I think of rotation a joint I dont think of rotating it by an axis but turning it, like bending your wrist.

If you are trying to calculate the transformation matrices its Parent*location*scale*rotation(zyx)

 

[Fug Ebin Meme]

Hey I'm new to Melee hacking and I have a question:

Is there any appendix of IASA function indexes out in these boards somewhere? In Magicscrumpy's Jigglypuff Shine mod i learned 800CAED0 calls a grounded jump function and 800CB870 calls a doublejump function. I want to try to employ other types of cancels and maybe on-hit cancels but I can't find any information on IASA functions.

If I need an IASA function, I usually just go to the Community Symbol Map and Ctrl-f for "interrupt", and sift through all of them until I find the one I'm looking for.

 

[tatatat0]

Well, spent four hours brute forcing special attributes. Jigglypuff Special Values [tatatat0]:

Spoiler

0x3A68: 00000005: Unknown (Neutral-b)
0x3A6C: 00000155: Unknown (Neutral-b)
0x3A70: FFFFFFFF: Unknown (Neutral-b)
0x3A74: 00000054: Rollout total frames (Neutral-b)
0x3A78: 00000014: Unknown (Neutral-b)
0x3A80: 3FA66666: Unknown (Neutral-b)
0x3A84: 3DCCCCCD: Unknown (Neutral-b)
0x3A88: 3D4CCCCD: Unknown (Neutral-b)
0x3A8C: 40C00000: Initial Velocity (Neutral-b)
0x3A90: 41800000: Velocity Growth(?) (Neutral-b)
0x3A94: 3DA3D70A: Unknown (Neutral-b)
0x3A98: 3DCCCCCD: Aerial Horizontal Velocity backwards(on startup) (Neutral-b)
0x3AA0: 3F800000: Aerial Horizontal Velocity Forward (Neutral-b)
0x3AA4: 40000000: Unknown (Neutral-b)
0x3AA8: 3F000000: Joystick position to turn?(Neutral-b)
0x3AAC: 40800000: Turning animation/sound speed(Neutral-b)
0x3AB0: 00000008: Unknown (Neutral-b)
0x3AB4: 40D00000: Unknown (Neutral-b)
0x3AB8: 3ECCCCCD: Air to ground vertical bounce velocity (Neutral-b)
0x3ABC: 3F4CCCCD: Air to ground animation related (Neutral-b)
0x3AC0: 40000000: Charge percent growth per cycle (Neutral-b)
0x3AC4: 40400000: initial percent (Neutral-b)
0x3AC8: BE051EB8: Grounded velocity on hit (Neutral-b)
0x3ACC: 3FCCCCCD: Unknown (Neutral-b)
0x3AD0: 3F19999A: End velocity acceleration (Neutral-b)
0x3AD4: 3F4CCCCD: Unknown (Neutral-b)
0x3AD8: 3F99999A: Rollout animation speed? (Neutral-b)
0x3ADC: 00000020: Unknown (Neutral-b)
0x3AE0: 42480000: Velocity related? (Neutral-b)
0x3AE4: 43340000: Maximum charge frames (Neutral-b)
0x3AE8: 40400000: Charge Related? (Neutral-b)
0x3AEC: 3E570A3D: Charge Related? (Neutral-b)
0x3AF0: 41A00000: Charge Related? (Neutral-b)
0x3B18: 41F00000: Unknown (Side-b)
0x3AF4: 00000000: Deceleration?(Neutral-b) (float?)
0x3AF8: 42200000: Unknown (Side-b)
0x3B1C: 3DCCCCCD: Stick position to angle down? (Side-b)
0x3B20: 3F000000: Stick position to angle up? (Side-b)
0x3B24: 41A00000: rising pound Horizontal velocity subtracted (Side-b)
0x3B2C: 3E4CCCCD: Unknown (Side-b)
0x3B30: 400CCCCD: Velocity (side-b)

@Tater Ampers

 

[Fug Ebin Meme]

0x3D68: 44080000: Side-b related (Unknown) (Similar to a value found in falcon and ganon's dat files)
0x3D64: 0800000C: Side-b related (Unknown)

umm... aren't those the first two command ID's for jigglypuff's side-b subaction?

 

[tatatat0]

umm... aren't those the first two command ID's for jigglypuff's side-b subaction?

Yep! lol. I didn't use crazy hand's UI though. I was just brute forcing it. Woops

 

[TowerLight]

hello,just starting on melee hacking and I was wondering, is it possible to change peach's turnip into another item?

 

[tatatat0]

hello,just starting on melee hacking and I was wondering, is it possible to change peach's turnip into another item?

Yes. Edit the Item ids in peach's special attributes, and set all the turnips whose item ids you can't edit to zero.

 

[TowerLight]

is there a list of item IDs? I cant seem to find any

 

[tatatat0]

is there a list of item IDs? I cant seem to find any

A list of item IDS is [here]

 

[tatatat0]

Working on finding IC's special attributes

Spoiler

This is all I've been able to find as of right now
IC's Special Attributes [tatatat0]:

Spoiler

0x3A7C: 3F4CCCCD: Unknown (Neutral-b)
0x3A80: 3F800000: Unknown (Neutral-b)
0x3A84: 00000000: Rotation in air. Unknown Unit (Neutral-b)
0x3A88: 3E4CCCCD: Ice block air vertical acceleration(gravity) (Neutral-b)
0x3A8C: 3FD33333: Ice block air max vertical acceleration? (Neutral-b)
0x3AB8: 40A00000: Unknown (Neutral-b)
0x3AC0: 40A00000: Unknown (Neutral-b)
0x3AC4: 40A00000: Unknown (Neutral-b)
0x3AC8: 41A00000: Unknown (Neutral-b)
0x3ACC: 3DCCCCCD: Unknown (Neutral-b)
0x3AD0: 3F59999A: Unknown (Neutral-b)
0x3AD4: 00000000: Unknown (Neutral-b)
0x3AD8: 3F800000: Ice block model size (Neutral-b)
0x3ADC: 00000421: Ice block destruction graphic id? (int)(Neutral-b)
0x3AE0: 00000421: Duplicate of 0x3ADC?(int)(Neutral-b)
0x3AE4: 00083D60: Offset?(int)(Neutral-b)
0x3AE8: 00083D60: Duplicate of 0x3AE4(int)(Neutral-b)
0x3AEC: 000000DC: Unknown(int)(Neutral-b)
0x3AFC: 42700000: Iceblock lifetime(Neutral-b)
0x3B00: 40a00000: Unknown(Neutral-b)
0x3B04: 40400000: Unknown(Neutral-b)
0x3B08: 3FE66666: Unknown(Neutral-b)
0x3B0C: 3FC00000: Iceblock Horizontal Velocity(Neutral-b)
0x3B10: 3F4CCCCD: Unknown(Neutral-b)
0x3B14: 3E800000: Unknown(Neutral-b)
0x3B18: 3E6147AE: Unknown(Neutral-b)
0x3B1C: 3F733333: Unknown(Neutral-b)
0x3B20: 3E4CCCCD: Shrink factor on ground?(Neutral-b)
0x3B24: 3F4CCCCD: Growth factor on ground?(Neutral-b)

 

[TowerLight]

poor falcon's about to get Titanic'd

 

[Krusteaz]

I can't for the life of em figure out how to change a _2 texture to a _5. The guides on how to have pictures that have expired so some crucial info is missing on how to do it. Anybody have any help?

 

[tatatat0]

Some Game & Watch offsets[tatatat0]:

Spoiler

0x37FC: 40000000: Unknown Aerial?(Don't set to zero)(Down-b)
0x3800: 3B23D70A: Aerial Horizontal Decceleration(Down-b)
0x3804: 3D23D70A: Gravity(Down-b)
0x3808: 3F99999A: Terminal Velocity(Down-b)
0x380C: 40A00000: Unknown(Down-b)
0x3810: 3FC00000: Unknown(Down-b)
0x3814: 40C00000: Unknown(Down-b)
0x3818: 00000006: Unknown(Int)(Down-b)
0x43A8: 3F8CCCCD: Horizontal velocity of sausage 1(Neutral-b)
0x43AC: 3FA00000: Vertical velocity of sausage 1(Neutral-b)
0x43B0: 3D75C28F: Gravity of sausage 1(Neutral-b)
0x43B4: 40E00000: Spin of sausage 1(Neutral-b)
0x43B8: 3EBFC2C7: Also spin of sausage 1(Neutral-b)
0x43BC: 3F4CCCCD: Horizontal velocity of sausage 2(Neutral-b)
0x43C0: 3F8CCCCD: Vertical velocity of sausage 2(Neutral-b)
0x43C4: 3D23D70A: Gravity of sausage 2(Neutral-b)
0x43C8: 40200000: Spin of sausage 2(Neutral-b)
0x43CC: 3F0A8263: Also spin of sausage 2(Neutral-b)
0x43D0: 3F19999A: Horizontal velocity of sausage 3(Neutral-b)
0x43D4: 3F99999A: Vertical velocity of sausage 3(Neutral-b)
0x43D8: 3D23D70A: Gravity of sausage 3(Neutral-b)
0x43DC: 40200000: Spin of sausage 3(Neutral-b)
0x43E0: 3E0EFA35: Also spin of sausage 3(Neutral-b)
0x43E4: 3ECCCCCD: Horizontal velocity of sausage 4(Neutral-b)
0x43E8: 3FA66666: Vertical velocity of sausage 4(Neutral-b)
0x43EC: 3D23D70A: Gravity of sausage 4(Neutral-b)
0x43F0: 40200000: Spin of sausage 4(Neutral-b)
0x43F4: 3F3BA866: Also spin of sausage 4(Neutral-b)
0x43F8: 3E4CCCCD: Horizontal velocity of sausage 5(Neutral-b)
0x43FC: 3FB33333: Vertical velocity of sausage 5(Neutral-b)
0x4400: 3D23D70A: Gravity of sausage 5(Neutral-b)
0x4404: 40200000: Spin of sausage 5(Neutral-b)
0x4408: 3E567750: Also spin of sausage 5(Neutral-b)

Didn't include the ones already found in crazy hand(with the exception of sausage one)
Ampers @Tater

 

[tatatat0]

Old Pichu Offsets [tatatat0]:

Spoiler

Pichu:
Quick Attack
0x362C: .05 momentum subtracted during ending frames 9-49
0x3630: 1 momentum cap from subtraction during endlag
0x3634: 20 ?? Read on startup
0x3638: 8 Travel distance ???
0x363C: 0.02666 Momentum subtracted frames 11-13 during startup?
0x3640: .2618 model rotation traveling on ground
0x3644: .8 model width multiplier traveling on ground
0x3648: .8 Model height multiplier traveling on ground
0x364C: 1.2 Model length multiplier traveling on ground
0x3650: 0.2618 Model rotation traveling in air
0x3654: .8 Model with multiplier traveling in air
0x3658: .8 Model height multiplier traveling in air
0x365C: 1.2 Model length multiplier traveling in air
0x3660: 4 ?? (Pikachu’s is 2)
0x3664: 0.5 aiming sensitivity
0x3668: 2.2 Has to do with starting momentum
0x366C: 2.2 momentum added to 3668??
0x3670: 1 Second segment length multiplier
0x3674: .6 Horizontal momentum?
0x3678: 0x32 Unknown
0x367C: .6 Horizontal Momentum subtracted??
0x3680: 0x05 Unknown
0x3684: .4 Not Read
0x3688: 12 Landing Lag
Thunder:
0x368C: .66 vertical momentum on aerial thunder hit
0x3690: 0.016 something to do with rising from an aerial thunder hit?
0x3694: 4.5 something to do with vertical range for thunder self-hit?
0x3698: -5 Thunder travel speed
0x369C: 6.66 horizontal range for thunder self-hit?
0x36A0: 8 vertical range for thunder self-hit?
0x36A4: -18 vertical displacement of cloud graphic
0x36A8: 150 height of thunder creation
0x36AC: 0x04 Number of lightning bursts
0x36B0: 0x08 time between individual lightning
0x36B4: 0x52 unknown (Freezes if not 51 or 52)

 

[tatatat0]

Shiek Offsets[tatatat0]:

Spoiler

Shiek:
0x35C8: 40600000: Vertical Velocity(Up-b)
0x35CC: 3E428F5C: Minimum velocity during aerial Up-b?(gravity)(Up-b)
0x35D0: 3E800000: Terminal velocity during aerial Up-b(gravity)(Up-b)
0x35D8: 40400000: Unknown(Up-b)
0x35DC: 3F000000: angles related?(Up-b)
0x35E0: 3F800000: distance related?(Up-b)
0x35E4: 3F800000: distance related?(Up-b)
0x35E8: 3F19999A: Unknown(Up-b)
0x35EC: 0000002D: Unknown(int)(Up-b)
0x35F0: 3E99999A: distance related?(Up-b)

Samus Offset(s?)[tatatat0]:

Spoiler

Samus:
0x3E34: 3F800000: Unknown(Neutral-b)
0x3E6C: 3F000000: Unknown(Neutral-b)
0x3E70: 3F000000: Unknown Grounded Projectile?(Neutral-b)
0x3E74: 3F000000: Unknown(Neutral-b)
0x3E78: 3F000000: Unknown(Neutral-b)
0x3E8C: 3F800000: Charge Shot Graphic Size(Neutral-b)
0x3630: 40400000: Unknown(Neutral-b)

Continuing to clean up some missing offsets in crazyhand.

 

[Ampers]

Some Game & Watch offsets[tatatat0]:

Spoiler

0x37FC: 40000000: Unknown Aerial?(Don't set to zero)(Down-b)
0x3800: 3B23D70A: Aerial Horizontal Decceleration(Down-b)
0x3804: 3D23D70A: Gravity(Down-b)
0x3808: 3F99999A: Terminal Velocity(Down-b)
0x380C: 40A00000: Unknown(Down-b)
0x3810: 3FC00000: Unknown(Down-b)
0x3814: 40C00000: Unknown(Down-b)
0x3818: 00000006: Unknown(Int)(Down-b)
0x43A8: 3F8CCCCD: Horizontal velocity of sausage 1(Neutral-b)
0x43AC: 3FA00000: Vertical velocity of sausage 1(Neutral-b)
0x43B0: 3D75C28F: Gravity of sausage 1(Neutral-b)
0x43B4: 40E00000: Spin of sausage 1(Neutral-b)
0x43B8: 3EBFC2C7: Also spin of sausage 1(Neutral-b)
0x43BC: 3F4CCCCD: Horizontal velocity of sausage 2(Neutral-b)
0x43C0: 3F8CCCCD: Vertical velocity of sausage 2(Neutral-b)
0x43C4: 3D23D70A: Gravity of sausage 2(Neutral-b)
0x43C8: 40200000: Spin of sausage 2(Neutral-b)
0x43CC: 3F0A8263: Also spin of sausage 2(Neutral-b)
0x43D0: 3F19999A: Horizontal velocity of sausage 3(Neutral-b)
0x43D4: 3F99999A: Vertical velocity of sausage 3(Neutral-b)
0x43D8: 3D23D70A: Gravity of sausage 3(Neutral-b)
0x43DC: 40200000: Spin of sausage 3(Neutral-b)
0x43E0: 3E0EFA35: Also spin of sausage 3(Neutral-b)
0x43E4: 3ECCCCCD: Horizontal velocity of sausage 4(Neutral-b)
0x43E8: 3FA66666: Vertical velocity of sausage 4(Neutral-b)
0x43EC: 3D23D70A: Gravity of sausage 4(Neutral-b)
0x43F0: 40200000: Spin of sausage 4(Neutral-b)
0x43F4: 3F3BA866: Also spin of sausage 4(Neutral-b)
0x43F8: 3E4CCCCD: Horizontal velocity of sausage 5(Neutral-b)
0x43FC: 3FB33333: Vertical velocity of sausage 5(Neutral-b)
0x4400: 3D23D70A: Gravity of sausage 5(Neutral-b)
0x4404: 40200000: Spin of sausage 5(Neutral-b)
0x4408: 3E567750: Also spin of sausage 5(Neutral-b)

Didn't include the ones already found in crazy hand(with the exception of sausage one)
Ampers @Tater

Good stuff tata. You should check out this spreadsheet I started a while back:

https://docs.google.com/spreadsheets/d/1iAfxxAQUboOfaLoJExNVAq76Sv7dG7UkfvTDzzqGgjY/edit?usp=sharing

The mythical "next version of Crazy Hand" that I've been slowly working on for the past million years is going to read all of its values from this sheet, in this format. Right now it has all of the values that are present in CH v1.31. You've been finding tons of amazing values and if you could put them in here, that would be incredible. Unfortunately I don't know when the next CH build will actually be available... real life is hectic.