Stage Hitboxes

[standardtoaster]

How did you find the catapult hitbox?

EDIT:

Thanks for the info.
Just a crazy thought, but would it be possible to change the bone that the hitbox is attached to??
Like say, to different models like a collision in MiscData[2]?

Edit:I forgot to tell you guys, after changing 1 car hitbox, all the cars followed suit.
It's like they all are using a go to command.

Which stage? PTAD or Onett?

 

[Eternal Yoshi]

1. I looked up the Sakurai angle like so:
38 e0 01 69

This is how I found the bomb hitboxes.

Then I looked up this angle
38 e0 00 00

and I eventually found it when I saw the Knockback Base insanely High and the damage 0.

2. Port Town Aero Dive.

 

[standardtoaster]

Very interesting find about the cars.

EDIT: Just wanted to note that the flags on stage hitboxes do not seem to follow the same things normal hitbox flags do.

 

[Amazing Ampharos]

Shouldn't the angle be 38e00169 if it is special angle 169? In my experience angle is 38e0, not 38a0.

Speaking of which, angle is before damage on Norfair's lava walls. I don't know what format flags are in at all. If you find flags for any hitbox for sure or any of the values other than damage, base knockback, knockback growth, or angle for sure, letting us know would be helpful (including what their "header" is).

 

[standardtoaster]

I'd easily be able to find what their flags are if you don't want me to look through the rel. Much easier for me to go looking through with my gecko, lol.

 

[Eternal Yoshi]

Oop. Mistyped that. Fixed.
I THINK that 39 20 XX XX could be weight knockback, but I need to test it though....

 

[Dantarion]

There must be a way to automate the finding of these, ill figure it out when I have some time.
If all the collision creations form from the game loading an address into a register, then branching to a function, I can find the branches to that function, and then work backwards to when the register gets the address, and voila!

 

[wildvine47]

So, if I understand this correctly, this will eventually lead to being able to add custom hitboxes to stages (and even to hacked stages)?

If so, hype gotten.

 

[Amazing Ampharos]

Oh, finding any physical values for these hitboxes in RAM is super doable now including flags. The hard part is working backward to the module, and I have no idea how to pick flags out at this point.

I'll probably get to work making actually changed .rel files for Bbrawl in the next few days; that may or may not involve new discoveries.

 

[standardtoaster]

I could not seem to find the hitbox for the bombs anymore after returning to pirate ship and i could not seem to find the boat bow beaching on the rock hitbox in StageInstance.

StageInstance : 0.50MB Used 0.00MB ( 0%) adr S 814ce460 E 8154e560 SIZE 00080100


EDIT: TSON told me that the unknown float was most likely trip rate and the Next Word was most likely the special flags.

 

[Eternal Yoshi]

OK.
3920XXXX IS the weight knockback.

I'm trying to find the size of the hitbox using Onett's Car.
It's confirmed to be 5 already.

I tried to look for 40A00000, but the offsets they were located at were at
8BD8 and 8C38.......

PS: The parameters(Damage/angle/WKB/BKB/KBG) of the hitbox are at 4200. There doesn't seem to be anything saying 5 in that range, float or hex.

 

[Amazing Ampharos]

Flags are similarly proving very impossible. I know the flags for Flat Zone 2 lion tamers must end in 8 since they hit slip element. I tried changing every 8 at the end of a word in the proximity of the hitbox. I got a few crashes and totally removed the hitbox a few times but sure wasn't able to find what I was looking for. If anyone has any bright ideas to find some of this stuff, it would be pretty awesome.

 

[standardtoaster]

I should start looking at rel files now. ;p

ALL VALUES IN DECIMAL

Pirate ship hitboxes

I forgot to write what the special flags and refresh rate of the main hit of bomb was. I could not seem to find the hitbox for the bombs anymore after returning to the stage or the boat bow beaching on the rock hitbox in StageInstance.

Main hit of bomb
Damage: 35%
X Offset: 0.0
Y Offset: 0.0
Z Offset: 0.0
Size: 35
Angle: 361
KBG: 100
WKB: 30
BKB: 80
Trip Rate: 1.0
Hitlag Multiplier: 1.0
SDI Multiplier: 1.0
Flags: 007FFDE5


Second hit of bomb
Damage: 20%
X Offset: 0.0
Y Offset: 0.0
Z Offset: 0.0
Size: 15
Angle: 361
KBG: 100
WKB: 0
BKB: 70
Float: 1.0
Hitlag Multiplier: 1.0
SDI Multiplier: 1.0
Flags: 007FFDE0
Special Flags: 0020018B
Refresh rate: 60

Catapult
Damage: 0%
X Offset: 0.0
Y Offset: 15
Z Offset: 0.0
Size: 10
Angle: 20
KBG: 15
WKB: 0
BKB: 150
Trip Rate: 1.0
Hitlag Multiplier: 1.0
SDI Multiplier: 1.0
Flags: 007FFDE0
Special Flags: 40200398
Refresh Rate: 003C0C80 (60?)

Ship
Damage: 20%
X Offset: -50
Y Offset: -25
Z Offset: 0
Size: 10
Angle: 270
KBG: 200
WKB: 200
BKB: 100
Trip Rate: 1.0
Hitlag Multiplier: 1.0
SDI Multiplier: 1.0
Flags: 017FFDE0
Special Flags: 822002C0
Refresh Rate: 003C0100 (60?)

Damage: 20%
X Offset: 60
Y Offset: 0.0
Z offset: 0.0
Size: 7
Angle: 270
KBG: 200
WKB: 200
BKB: 100
Trip Rate: 1.0
Hitlag Multiplier: 1.0
SDI Multiplier: 1.0
Flags: 007FFDE0
Special Flags: 82002BE0
Refresh Rate: 003C0000 (60?)

Damage: 20%
X Offset: 10
Y Offset: -10
Z Offset: 0.0
Size: 7
Angle: 270
KBG: 200
WKB: 200
BKB: 100
Trip Rate: 1.0
Hitlag Multiplier: 1.0
SDI Multiplier: 1.0
Flags: 007FFDE0
Special Flags: 820029E0
Refresh Rate: 003C0000 (60?)

 

[standardtoaster]

Yeah, I can only seem to find damage, angle, and all three types of knockback.

 

[Eternal Yoshi]

Hey, what's 3800XXXX?

It's located about 2 lines above the damage.

Onett Car Hitbox - 38 00 00 3C.
The Klaptrap - 38 00 00 20.
The FZero Cars - 38 00 00 3C.
The Pirate Ship Bomb(primary hitbox) - 38 00 00 3C.

Also, what's 3960XXXX?

Onett Car Hitbox - 39 60 00 0F.
The Klaptrap - 39 60 00 08.
The FZero Cars - 39 60 00 03.
The Pirate Ship Bomb(primary hitbox) - 39 60 00 0F.

 

[standardtoaster]

Change them and see what happens? :O Looking at 3800XXXX, it seems to be the refresh rate.

 

[MonkUnit]

MULTIHIT BOMBS?!? Yeeeeeee

 

[Eternal Yoshi]

3800XXXX is indeed the refresh rate.

Changing 3960XXXX from 0F to 55 and FF didn't seem to do anything....
Not shield damage either.

Is 3980XXXX Shield damage???

The default for Onett's car is 07.

Changing it to 80 seems to make the hitbox non existant...
I need to look more into it.

OK. Changing that to 10 and even 8 seems to also make the hitbox gone...

3BA0XXXX....... changing it froze the game when the car arrived.

 

[Jilhear]

From reading the posts, the rel files are assembly code, and the Onett car code is in grDxOnettAttack.Method[117] using the module viewer, and starts at 0x417C looking at the rel file in a hex editor. Looking at it as Power PC assembly code, this function is loading a bunch of values into registers, storing a few values in a stack frame, and calls a couple more functions. (It does do other things.)

The 3800XXXX through 3BE0XXXX are instructions to store XXXX in various registers. The 9001XXXX through 93E1XXXX are instructions to store registers in various locations in the stack frame (memory). Only a few of the registers are actually stored anywhere in the stack.

Messing with 3BA00000 should be a dead end. What it does is store 0 in register 29. Most of the writes to the stack frame are actually copying register 29 to the stack (93A1XXXX), or in other words, filling the stack with zeroes. Changing 3BA00000 is not just changing a single register value, it is changing over 20 entries in the stack.

Edit:
Looking at both Onett and Norfair, the game is recycling some registers. Some are being used to write one value to the stack, and then given another value before the next function is called. Norfair uses register 8 to write a 7 to the stack, but then uses register 8 to pass a 50 (0x32) to the next function. Which registers are used to write to the stack aren't always the same between stages. Onett uses r29 for all of its zeroes, while Norfair magma [119] uses r28. What is written where in the stack is presumably constant across stages, and what registers are actually used by the next function are presumably constant.

 

[standardtoaster]

I like this guy.

 

[Phantom Wings]

I like this guy.

My sentiments exactly.

Come my friend. It has been a while since I've seen someone who can wrap their minds around the workings of assembly so clearly - we need new blood around here. If you have any questions or requests, be sure to ask and I will personally do my best to fulfill them.

 

[MK26]

i ****ing love you all

i may have to get back into stage hacking because of this

 

[shanus]

My sentiments exactly.

Come my friend. It has been a while since I've seen someone who can wrap their minds around the workings of assembly so clearly - we need new blood around here. If you have any questions or requests, be sure to ask and I will personally do my best to fulfill them.

So basically I just need him to ask you to solve landing detection for Project M?

jk, good to see some new ASM-blood around here. I've been reading up on it, but find it incredibly difficult to obtain much without seeing what's truthfully written to/read out from the registers.

 

[Eternal Yoshi]

From reading the posts, the rel files are assembly code, and the Onett car code is in grDxOnettAttack.Method[117] using the module viewer, and starts at 0x417C looking at the rel file in a hex editor. Looking at it as Power PC assembly code, this function is loading a bunch of values into registers, storing a few values in a stack frame, and calls a couple more functions. (It does do other things.)

The 3800XXXX through 3BE0XXXX are instructions to store XXXX in various registers. The 9001XXXX through 93E1XXXX are instructions to store registers in various locations in the stack frame (memory). Only a few of the registers are actually stored anywhere in the stack.

Messing with 3BA00000 should be a dead end. What it does is store 0 in register 29. Most of the writes to the stack frame are actually copying register 29 to the stack (93A1XXXX), or in other words, filling the stack with zeroes. Changing 3BA00000 is not just changing a single register value, it is changing over 20 entries in the stack.

Edit:
Looking at both Onett and Norfair, the game is recycling some registers. Some are being used to write one value to the stack, and then given another value before the next function is called. Norfair uses register 8 to write a 7 to the stack, but then uses register 8 to pass a 50 (0x32) to the next function. Which registers are used to write to the stack aren't always the same between stages. Onett uses r29 for all of its zeroes, while Norfair magma [119] uses r28. What is written where in the stack is presumably constant across stages, and what registers are actually used by the next function are presumably constant.

Thanks, and welcome to the Smash Workshop.

The size of the car hitbox of Onett is at 8C38 as a float. Maybe someone more experienced with assembly can explain why this is so.

 

[Phantom Wings]

I GOT IT! I think...

Does anyone remember the Super Codes? Those performance enhancing things that worked better than steroids? Anyways, the codes ran off of a basic shell that was used to access - what I called it at the time - the character's Root. From the Root you could access pretty much anything from the character including position, animation frame and hitboxes. It was later that I figured out that the concept of the Root wasn't confined to characters, but also items, enemies and bosses - though their structures varied slightly. It was later still that I found that the idea of the Root was actually a class object called soModuleAccessor and that it allowed access to the following modules (for characters that is.)

Spoiler

+08 = Parent
+0C = so Rescource Module Impl
+10 = so Model Module Impl
+14 = so Motion Module Impl
+18 = so Posture Module Impl
+1C = so Ground Module Impl
+20 = so Situation Module Impl
+24 = so Team Module Impl
+28 = so Collision Attack Module Impl
+2C = so Collision Hit Module Impl
+30 = so Collision Shield Module Impl
+34 = so Collision Shield Module Impl
+38 = so Collision Shield Module Null
+3C = so Collision Catch Module Impl
+40 = so Collision Search Module Null
+44 = so Damage Module Actor
+48 = so Catch Module Impl
+4C = so Capture Module Impl
+50 = ft Stop Module Impl
+54 = so Turn Module Impl
+58 = so Shake Module Impl
+5C = so Sound Module Impl
+60 = so Link Module Impl
+64 = so Visibility Module Impl
+68 = ft Controller Module Impl
+6C = so Camera Module Impl
+70 = so Work Manage Module Impl
+74 = so Debug Module Null
+78 = so Anim Cmd Module Impl
+7C = so Status Module Impl
+80 = ft General Term Diside Module Impl
+84 = ft Switch Decide Module Impl
+88 = so Kinetic Module Generic Impl
+8C = so Event Manage Module Impl
+90 = so Generate Article Manage Module Impl
+94 = so Effect Module Impl
+98 = ft Combo Module Impl
+9C = ft Area Module Impl
+A0 = so Territory Module Null
+A4 = so Target Search Module Null
+A8 = so Physics Module Impl
+AC = so Slope Module Impl
+B0 = so Shadow Module Impl
+B4 = so Item Manage Module Impl
+B8 = so Color Blend Module Impl
+BC = so Jostle Module Impl
+C0 = ft Abnormal Module Impl
+C4 = so Slow Module Impl
+C8 = so Reflect Module Null
+CC = so Heap Module Impl
+D0 = ft Param Customize Module Impl
+D4 = ft Glow Module Impl

Now, it seems that all class object methods get called with a very specific pointer stored in r3. I haven't been able to figure out what that pointer is, but I haven't exactly been trying to either. I've noticed that any method that creates a hitbox calls a specific function from r3 using:

lwz r12, 0x3C(r3)
lwz r12, 0x1BC(r12)
mtspr ctr, r12
bctr

If we assume that r3 points to the module accessor, then taken to it's logical conclusion this would be accessing the soCollisionCatchModule - which isn't quite right but remember that I said that module accessors differed between object types. Supposing that at 0x3C for stages the module was the soCollisionAttackModule then it wouldn't be too far of a leap to consider that the hitbox creation method would be its 111th method.

That's just the theory anyways, there's still a few things that don't match up. I'd love to take a moment to prove this using WiiRD but not right now. If my theory is correct though, then we pretty much have the equivalent of Super Codes except with using modules - AND we can utilize methods which could open up a whole new set of possibilities.

 

[standardtoaster]

Wow, that's incredible, PW. When I was doing character variable offsets for myself using one of your old posts in the WBR, the "root" of the character really intrigued me. Glad to know this was what it was!

 

[Jilhear]

lwz r12, 0x3C(r3)
lwz r12, 0x1BC(r12)
mtspr ctr, r12
bctr

I've been using those four lines of code to find hit boxes in the rel files, so that I could try to match registers and stack frame construction to known stage data. I'd guessed the above was the important call, because it was always the same and no stage-related values were set after it.

If you can trace the function and have a good idea of what it is doing, is there no need for me to continue to try to work out the stack frame structure before it is called?

 

[Xyless]

Popping on here to wonder, if you can figure out how to automate this, could that possibly mean that people could make their own hazards?

 

[shanus]

PW - how exactly is inheritance determined (or really file structure of soramelee.rel)? Is it string based and are loaded during some type of inheritance header per object?

For example, say we wanted to alter ftStatusUniqProcessDamageAir to maintain the same inheritance of ftStatusUniqProcessDamageFlyRoll?

 

[Phantom Wings]

Type declarations are a bit of a sticky topic in the .rel files. Everything that the Module Viewer can see is just remnants of what's left after the compiler has been over it. The Viewer reads the inheritance hierarchy based on a short list of string pointers that is given to the class declaration. As for the actual implementation of the inherited object, there are multiple methods inside an object that reference external modules (particularly module 1B). My guess is that some of these methods are either the methods of the inheriting object or their constructors. That way it is only a matter for object's constructor to call its inherited constructor and just continue down the chain from there.

...

If you can trace the function and have a good idea of what it is doing, is there no need for me to continue to try to work out the stack frame structure before it is called?

I'm a little curious about that as it seems to fill a lot of it with whitespace. I can't tell whether the stack frame is used to describe the hitbox being made by the function that gets called, or if it's used to put the new hitbox inside in order to return it. I'll let you know the results when I get to trying it out.

 

[shanus]

Type declarations are a bit of a sticky topic in the .rel files. Everything that the Module Viewer can see is just remnants of what's left after the compiler has been over it. The Viewer reads the inheritance hierarchy based on a short list of string pointers that is given to the class declaration. As for the actual implementation of the inherited object, there are multiple methods inside an object that reference external modules (particularly module 1B). My guess is that some of these methods are either the methods of the inheriting object or their constructors. That way it is only a matter for object's constructor to call its inherited constructor and just continue down the chain from there.




I'm a little curious about that as it seems to fill a lot of it with whitespace. I can't tell whether the stack frame is used to describe the hitbox being made by the function that gets called, or if it's used to put the new hitbox inside in order to return it. I'll let you know the results when I get to trying it out.

Yeah - I've definitely been probing through Module 1B (soramelee) and trying to get a better grip on how these objects are manipulated. Do you know the offset of it when its loaded in memory? The PM team identified several areas we want to probe on.

 

[Eternal Yoshi]

I wonder what in the .rel determines what bone/model the hitbox is attached to. Does it work similarly like Stage collisions(.coll files)?

I'm gonna look in the module editor.

I lack knowledge of Assembly, but that hasn't stopped me before.

 

[standardtoaster]

As far as I know, the two sets of 0s before dmg in memory are the bone/id of the hitboxes. That probably doesn't help much though. lol.

 

[Phantom Wings]

Alright bad news, good news and... meh news.

The bad news is that I was wrong about r3 pointing to the module accessor. The good news is that r3 instead points to the instantiated object itself - from which you are able to access the module accessor. The meh news is that instantiated objects aren't exactly consistent with their layout. - although their class declaration is usually pointed to at +0x3C.

That being said, it looks like that method that is responsible for creating hitboxes is whatever the 111th method is for that object (at least in the case of Onett and Norfair). The method in question is one from the soramelee module. However the module viewer can't view it because it has a blr midway through it which is the termination code for the method viewer.

The one thing I haven't figured out is how objects like the StatusUniqueProcess objects effect their host character as they are separate instances from the character or stage and thus only have access to their own members.

I guess it's time I upgraded the module viewer to show a bit more information in respect to the file. It would be nice to have addresses and offsets to assign all these discoveries.