Let's look into Module Fíles (.rel) - Defensive Collision is now!

[Sky Grounder]

peach castle bullet bill is my first tough xD  and my second and favorite stage ever safron city with damaging pokemons where you cant touch them unless its chancey

Except the Bullet Bill/Pokémons doesn't even use collisions.

[Carnage]

Except the Bullet Bill/Pokémons doesn't even use collisions.

you can add them if they gonna have hitboxes  xD

[PhantomWings]

If you're looking for more details on stage hitboxes, I think there was some research done on the boards here a while ago concerning the cars on Onnett among other things. I think someone ended up discovering a certain pattern to the function calls inside the module files of the stages that allowed them to customize the hitboxes. They couldn't add or remove them though because there wasn't a way to effectively modify modules at the time.

Anyways, I imagine there'd be a lot of useful information in that thread if you can find it. I can't do a whole lot of research these days, but I just thought I'd drop by to see if I could help out at all.

[pikazz]

If you're looking for more details on stage hitboxes, I think there was some research done on the boards here a while ago concerning the cars on Onnett among other things. I think someone ended up discovering a certain pattern to the function calls inside the module files of the stages that allowed them to customize the hitboxes. They couldn't add or remove them though because there wasn't a way to effectively modify modules at the time.

Anyways, I imagine there'd be a lot of useful information in that thread if you can find it. I can't do a whole lot of research these days, but I just thought I'd drop by to see if I could help out at all.

thank you for dropping by! x3 but I believe we are speaking about 2 diffirent hitboxes.
if you mean this thread: http://forums.kc-mm.com/index.php?topic=18505.0
you will notices that the hitboxes using the HEX value in object section "38 A0 00 XX" which mean Li 5 and since the onett cars does 30%, it's 1E instead for XX.

but the hitboxes (Constant Hitboxes to collusion data) I found out doesn't use any Load Instant or any function at all in object section, it's because it's constant inside the constant section and are in float value!

found out also how they work (atleast how they get called), it's called upon in Stage Builder and Break the Targets, it looks something like this:

the m59[04] 0x0 on both calls the floating point value which is the hitbox data to register 29 and add once more in 29 later on.
the m59[05] 0x0 calls its name which is stTargetBreak (but I think you already know that)

have found 3-5 times in stage builder to same asm commandsand ONE asm command "3E 00 00 00" but haven't looked into break the targets yet about the last one.
I believe they are multiplied in stage builder because you can change the size limit in stage builder.

I hope we can edit the modules so we can add constant hitbox to stages.

also, I might be along shot but do you have skype or msn? cause I would like to speak with you more about rels and modules more, want to learn more!

EDIT: I found out how Special Throw are stored in each character module to those who has it!
so after a heavy module editing, I made Ike's B-up being grabable just like Captian Falcons B-up!


it's works pretty well! but it isn't perfect, Ike get stuck on the opponent after throwing! I think that's a PSA problem. at least it's something!

and I might found out how articles are stored so I will play with that after I successfully made special grab 100% glitchfree! <w<

[PhantomWings]

Awesome find you've got there. It sounds like you're getting pretty good at editing modules.

I'm not much of a Skype or MSN person, but if I get the chance, we can try to meet up on IRC.



Anyways, you spiked my curiosity with what you found in the st_tbreak constructor. Here's what I've found out so far:

First off, a few things to note:
-Almost all object methods have r3 pointing to the calling object. (sort of like the "this" keyword in C++)
-Objects that inherit from the "Ground" object have a node like behavior in that they can point to eachother.


So I started off with that method you were looking at - Method[23]: the stage constructor or initializer.

It starts off doing a bit of housecleaning such as storing various variables onto the stack, but there's a few importing things it does to start off:
-Set r27 to r3 ("this")
-Set r29 to Section[4] (Constants)
-Set r30 to Section[5] (Object Declarations)

These registers (as far as I've gotten) remain the same for the whole constructor function.

Next it calls a routine from st_melee at Section[1] 0x223140 and passes in "this". Other stages do this too, so I'm guessing its the most basic form the stage constructor.

A bit later you'll see an instruction bl 0x1884 that isn't bound to a relocation instruction (you'll also see similar calls later on, but they're all calling the same subroutine). This small subroutine is used frequently throughout the constructor - it takes 3 parameters:
r3 an integer
r4 an unknown pointer
r5 a string pointer

This subroutine does a few things:
-Immediately discard r4 (oddly enough...)
-Call malloc (at 0x8000C8B8) with a size of 0x1A4
-Call the Ground Object constructor passing in the new malloc'd ptr and the string pointer.
-Call the new Ground Object's Method[0][26].
-Call the new Ground Object's Method[0][42] passing in the integer argument
-Call two more unknown st_melee functions on the new Ground Object.


I'm not sure if the string pointer is directly used or if it's just used for naming the node, but strings passed to it are things like grTargetBreakGround, grTargetBreakGroundIce and BeltConveyorNode%02dS.

After creating the node, it usually stores it in some arbitrary place in the stage object. After that it does a few other things, but it seems that it always calls the node's Method[0][37] and Method[0][39] after it is done.



That's about everything I've got so far, I'm still in the middle of analyzing things, so I don't know exactly what's what yet. There's one more interesting function that should be useful if anyone has a debugger:

dbgprintf (r3=format, r4=param)
0x801D8600

I'm not entirely sure if it is truly a debug printout function, but it seems to be used to describe in plaintext activities that are in the middle of taking place. Placing a breakpoint there might prove to be useful.

[pikazz]

Awesome find you've got there. It sounds like you're getting pretty good at editing modules.

I'm not much of a Skype or MSN person, but if I get the chance, we can try to meet up on IRC.



Anyways, you spiked my curiosity with what you found in the st_tbreak constructor. Here's what I've found out so far:

First off, a few things to note:
-Almost all object methods have r3 pointing to the calling object. (sort of like the "this" keyword in C++)
-Objects that inherit from the "Ground" object have a node like behavior in that they can point to eachother.


So I started off with that method you were looking at - Method[23]: the stage constructor or initializer.

It starts off doing a bit of housecleaning such as storing various variables onto the stack, but there's a few importing things it does to start off:
-Set r27 to r3 ("this")
-Set r29 to Section[4] (Constants)
-Set r30 to Section[5] (Object Declarations)

These registers (as far as I've gotten) remain the same for the whole constructor function.

Next it calls a routine from st_melee at Section[1] 0x223140 and passes in "this". Other stages do this too, so I'm guessing its the most basic form the stage constructor.

A bit later you'll see an instruction bl 0x1884 that isn't bound to a relocation instruction (you'll also see similar calls later on, but they're all calling the same subroutine). This small subroutine is used frequently throughout the constructor - it takes 3 parameters:
r3 an integer
r4 an unknown pointer
r5 a string pointer

This subroutine does a few things:
-Immediately discard r4 (oddly enough...)
-Call malloc (at 0x8000C8B8) with a size of 0x1A4
-Call the Ground Object constructor passing in the new malloc'd ptr and the string pointer.
-Call the new Ground Object's Method[0][26].
-Call the new Ground Object's Method[0][42] passing in the integer argument
-Call two more unknown st_melee functions on the new Ground Object.


I'm not sure if the string pointer is directly used or if it's just used for naming the node, but strings passed to it are things like grTargetBreakGround, grTargetBreakGroundIce and BeltConveyorNode%02dS.

After creating the node, it usually stores it in some arbitrary place in the stage object. After that it does a few other things, but it seems that it always calls the node's Method[0][37] and Method[0][39] after it is done.



That's about everything I've got so far, I'm still in the middle of analyzing things, so I don't know exactly what's what yet. There's one more interesting function that should be useful if anyone has a debugger:

dbgprintf (r3=format, r4=param)
0x801D8600

I'm not entirely sure if it is truly a debug printout function, but it seems to be used to describe in plaintext activities that are in the middle of taking place. Placing a breakpoint there might prove to be useful.

thank you x3
well, I aren't good at C++, PPC or any kind of programming. but I am good at find out how things work, find solutions, where to look and find things and hex xD

and that's look pretty awesome with what you found out and I like there this is going!
thank you for sharing the info!

also, I would like to share info aswell.
yesterday, I successfully edited Ike's module to make Ike being able to use Special Grab on a Special Action just like Captain Falcon! without the module piece, you can't make the character grab otherwise.


in each character Module file, inside Fit[character] in Method[0][16] contains various information, including Special Grabs and Articles!
dont know exactly everything inside that yet and I aren't using my hacking computer to check out what exactly its commands.

but I know it's Load something from Sora_Melee, using 2C 03 0X XX commands to load Actions that the special grab is on, the action the opponent will do AND the action you will do once successfully do and stores it back to Sora_Melee.

also, it also contains articles! if you disable the articles, if will freeze when you try to generate the article ingame!

I dont remember this very well, but I think I saw the articles calls routine from the module itslef together with Sora_Melee but I didn't have articles in mind, just with the special throw!


and I want to ask you, do you know how a "Method[X][X]" is build and how it's called? example, I wanna try to add a Method[99][99] if a character doesn't have that Method, how would I do?

[PhantomWings]

Object methods are all stored in a table inside the module's Section[5]. They usually look like this:

(Viewed with the Module Editor 3.1)


The spot I've selected is the start of ftCaptain's virtual pointer table - the table that holds all of ftCaptain's methods. The first two words are a pointer to ftCaptain's declaration and a blank space. Immediately following that are all the methods in order.

I'm not entirely clear on their structure, but the places where you see FFFFFFC0 and such seem to divide the table up into subtables - hence the reason I've listed the methods as Method[X][Y]. So, for example, the  Method[3][1] is stored at 0x1B0.

You may have seen a particular set of instructions during your time looking inside the modules - it almost always looks like this:

Code:

lwz r12, 60(rX)
lwz r12, YY(r12)
mtctr r12
bctr

This set of instructions is used to call a method off of an object's method table. If rX contains the "this" pointer, then it will load up the object's method table into r12, then load the method from the table according to YY. The mtctr and bctr instructions will then call that method.

If you want to find the numeric value of the method called, then you just take:

method # = ( YY - 8 ) / 4

So, for example, if YY = 64 and I know that rX points to the ftCaptain object, then I'd know that that particular string of instructions is calling ftCaptain.Method[0][14]

Right now, it might difficult to add methods on to the end of the table as there isn't a lot of free space in Section[5] and it's not very easy to move memory around thanks the hardcoded nature of modules, but if you want to override an existing method, you could consider writing your new assembly code into a new Section[7] and change the table entry's relocation to point to the new assembly code.



I'm interested in what you've found for the special grabs, but I'm not seeing anything in ftCharacter.Method[0][16]. For both Ike and Captain Falcon, they just reference the same generic base function in sora_melee. Are you sure that's the right method?



As for stages, it seems that the stages definitely store most of their data in Linked List Nodes. The stage object's "head" node is located at ["this" + 0x88] while the node "next" pointers are located at ["node" + 0x50]

Here's a few functions that I've found:

AddToTail (r3=stage, r4=node)
0x2227B0

RemoveNode (r3=stage, r4=node)
0x2227E8

GetNodeCount (r3=stage)
0x222830

GetNodeAt (r3=stage, r4=index)
0x222850

The AddToTail function is used frequently in stStageName.Method[0][23] constructors. It might be useful to keep this in mind when examining the stage modules.

[pikazz]

good and nice information~

Object methods are all stored in a table inside the module's Section[5]. They usually look like this:

(Viewed with the Module Editor 3.1)


The spot I've selected is the start of ftCaptain's virtual pointer table - the table that holds all of ftCaptain's methods. The first two words are a pointer to ftCaptain's declaration and a blank space. Immediately following that are all the methods in order.

I'm not entirely clear on their structure, but the places where you see FFFFFFC0 and such seem to divide the table up into subtables - hence the reason I've listed the methods as Method[X][Y]. So, for example, the  Method[3][1] is stored at 0x1B0.

You may have seen a particular set of instructions during your time looking inside the modules - it almost always looks like this:

Code:

lwz r12, 60(rX)
lwz r12, YY(r12)
mtctr r12
bctr

This set of instructions is used to call a method off of an object's method table. If rX contains the "this" pointer, then it will load up the object's method table into r12, then load the method from the table according to YY. The mtctr and bctr instructions will then call that method.

If you want to find the numeric value of the method called, then you just take:

method # = ( YY - 8 ) / 4

So, for example, if YY = 64 and I know that rX points to the ftCaptain object, then I'd know that that particular string of instructions is calling ftCaptain.Method[0][14]

Right now, it might difficult to add methods on to the end of the table as there isn't a lot of free space in Section[5] and it's not very easy to move memory around thanks the hardcoded nature of modules, but if you want to override an existing method, you could consider writing your new assembly code into a new Section[7] and change the table entry's relocation to point to the new assembly code.



I'm interested in what you've found for the special grabs, but I'm not seeing anything in ftCharacter.Method[0][16]. For both Ike and Captain Falcon, they just reference the same generic base function in sora_melee. Are you sure that's the right method?



As for stages, it seems that the stages definitely store most of their data in Linked List Nodes. The stage object's "head" node is located at ["this" + 0x88] while the node "next" pointers are located at ["node" + 0x50]

Here's a few functions that I've found:

AddToTail (r3=stage, r4=node)
0x2227B0

RemoveNode (r3=stage, r4=node)
0x2227E8

GetNodeCount (r3=stage)
0x222830

GetNodeAt (r3=stage, r4=index)
0x222850

The AddToTail function is used frequently in stStageName.Method[0][23] constructors. It might be useful to keep this in mind when examining the stage modules.

wow, was it that easy? O_o I thought it would be much more difficult to found out or more complex!

just a quick question, there are many method that just contains like Blc or like 2-5 rows of ASM with a end of BLC. how do they know their method X and Y?

I will test to add a Method to Jigglypuff which I know its Method is missing but Captain Falcon has!

and I am sorry, I wrote the wrong Method D:
I Ment Method[3][16], not Method[0][16]
the same method I will try to add jigglypuff

[PhantomWings]

Unfortunately, there is no simple way of identifying which method pointer calls a particular method by just looking at the method alone... I'm pretty sure a lot of methods aren't even specifically associated with a method pointer, but are instead indirectly called by other functions.

Also, remember that just because a method is marked in red in the Module Viewer, it doesn't mean that the character doesn't have it; it just means that that character uses the original method from its base class. So overwriting it with your own function may yield unintended side effects. If you want to see the original method, open up the sora_melee module first in the Module Viewer 2 and then open up your module - it should fill in the method pointers that refer to sora_melee.



Anyways, I think I'm finally starting to get somewhere with this.

I'm not exactly sure when Method[3][16] is exactly called, or what it is exactly used for, but it has provided a lot of insight in how special routines like this work.

The method enters with the following parameters:
r3=this
r4=?status?
r5=soModuleAccessor
r6=unknown
r7=unknown

Primary changes are made using the the modules in soModuleAccessor. The code will either use r5 to directly access it or it will sometimes retrieve it by reading ["this" + 0x60].

soModuleAccessor contains an array of all the modules used inside the character. If anyone remembers the Super Codes back in the olden days of Brawl Hacking, those codes worked primarily through the soModuleAccessor. The array of modules is pointed to at ["soModuleAccessor + 0xD8].

These are the modules contained in the array.
(listed in offset form instead of index form)

Code:

0x00 so Rescource Module Impl
0x04 so Model Module Impl
0x08 so Motion Module Impl
0x0C so Posture Module Impl
0x10 so Ground Module Impl
0x14 so Situation Module Impl
0x18 so Team Module Impl
0x1C so Collision Attack Module Impl
0x20 so Collision Hit Module Impl
0x24 so Collision Shield Module Impl
0x28 so Collision Shield Module Impl
0x2C so Collision Shield Module Null
0x30 so Collision Catch Module Impl
0x34 so Collision Search Module Null
0x38 so Damage Module Actor
0x3C so Catch Module Impl
0x40 so Capture Module Impl
0x44 ft Stop Module Impl
0x48 so Turn Module Impl
0x4C so Shake Module Impl
0x50 so Sound Module Impl
0x54 so Link Module Impl
0x58 so Visibility Module Impl
0x5C ft Controller Module Impl
0x60 so Camera Module Impl
0x64 so Work Manage Module Impl
0x68 so Debug Module Null
0x6C so Anim Cmd Module Impl
0x70 so Status Module Impl
0x74 ft General Term Diside Module Impl
0x78 ft Switch Decide Module Impl
0x7C so Kinetic Module Generic Impl
0x80 so Event Manage Module Impl
0x84 so Generate Article Manage Module Impl
0x88 so Effect Module Impl
0x8C ft Combo Module Impl
0x90 ft Area Module Impl
0x94 so Territory Module Null
0x98 so Target Search Module Null
0x9C so Physics Module Impl
0xA0 so Slope Module Impl
0xA4 so Shadow Module Impl
0xA8 so Item Manage Module Impl
0xAC so Color Blend Module Impl
0xB0 so Jostle Module Impl
0xB4 ft Abnormal Module Impl
0xB8 so Slow Module Impl
0xBC so Reflect Module Null
0xC0 so Heap Module Impl
0xC4 ft Param Customize Module Impl
0xC8 ft Glow Module Impl

I'm just getting started, but I've already identified two critical functions:

soStatusModuleImpl (0x70)
Method[0][3] SetAction (r3=this, r4=value, r5=soModuleAccessor)
Method[0][16] GetAction (r3=this)

I've also found the functions that are probably being used for C.Falcon's special grabs:

soCatchModuleImpl (0x3C)
Method[0][5] Unk @C.Falcon (r3=this, r4=unk)
Method[0][12] Unk @C.Falcon (r3=this, r4=unk)
Method[0][14] Unk @C.Falcon (r3=this, r4=unk)

[pikazz]

wow, you really know your stuff thats for sure!
tried like you said how to add Methods :3
used both Section 1 and 7 with Method[3][16], didn't freeze ingame but he didn't grab :/
that's atleast something about rebuildable Module files!

one question, I haven't catch about the arrays, when will they appear? O.o
inside the Sora_Melee or in each Character Module.

didn't knew you could open Sora_Melee first in v2 to see the pointers, the sad thing is it lags and it's pretty heavy file o.o

[PhantomWings]

Yeah, the Module Viewer 2 isn't very efficient, but that's because I needs to identify all the objects and method pointers inside the file.

The array I was referring to inside the soModuleAccessor isn't actually stored in any files, but is generated while the game is running. However, the module instances stored in it are still perfectly useable as long as you utilize them inside the context that they were created in. That's why using them allows so much more control things.


Is it alright if I see the two modules you've made? The one for Ike and the one for Jigglypuff? I'm curious about what exact changes you've made to them to use the special grabs.

#EDIT#

Maybe it's best if I give an example about what I mean for the runtime modules.



In the image, at the line I've selected, r3 is currently pointing to "this" - the ftCaptain object. The first instruction loads up the soModuleAccesser object by reading ["this" + 0x60] (I'm using Hex.). Following that, it loads the pointer to the module array I mentioned by reading ["soModuleAccessor" + 0xD8]. It then loads up the soStatusModuleImpl (at offset 0x70). From there, it loads up the soStatusModuleImpl Method Table which pointed to at offset 0x00. By examining the offset after that, we can determine that it is calling Method[0][16] which is the GetAction method. You can see afterwards that it is checking the returned value r3 against the action id 0x114 which is Captain Falcon's Up-B.

[pikazz]

aah, I see now :3
that's was easier than expected!

and sure, let me send to you through PM!

[pikazz]

PW: I found something useful, I did PM you about what I found out!

[PhantomWings]

Alright I got it!

Checkout Method[3][1]. If you calculate where the b -0x3C1C goes to you'll see that it calls Method[3][16] - Method[3][1] seems to be a function overload of Method[3][16]. The only difference is it calls method[3][16] using a direct branch instead. From the looks of things, Method[3][1] is what has been being called all this time. That would explain why we haven't been getting any changes when we've been modifying the Method Table reference to Method[3][16].

Objects which don't have an internally defined Method[3][16] will call the sora_melee Fighter.Method[3][16] from their Method[3][1]. So if you want to add a Method[3][16], you have to change the reference in Method[3][1] to also call the new Method[3][16] - otherwise it will still call the original sora_melee version.



As for Method[3][15], it's only used for characters which have unique PSA instructions. I know Zelda uses a PSA instruction to switch to Sheik, so she should have a Method[3][15].

[pikazz]

Alright I got it!

Checkout Method[3][1]. If you calculate where the b -0x3C1C goes to you'll see that it calls Method[3][16] - Method[3][1] seems to be a function overload of Method[3][16]. The only difference is it calls method[3][16] using a direct branch instead. From the looks of things, Method[3][1] is what has been being called all this time. That would explain why we haven't been getting any changes when we've been modifying the Method Table reference to Method[3][16].

Objects which don't have an internally defined Method[3][16] will call the sora_melee Fighter.Method[3][16] from their Method[3][1]. So if you want to add a Method[3][16], you have to change the reference in Method[3][1] to also call the new Method[3][16] - otherwise it will still call the original sora_melee version.



As for Method[3][15], it's only used for characters which have unique PSA instructions. I know Zelda uses a PSA instruction to switch to Sheik, so she should have a Method[3][15].

that's must be the greatest find in the history extremly great work PW!

I will start to play with the branch command and test things!

I will be back later today and tell how it went!

EDIT: back again! and about the Method[3][1], you were right! it was the only missing piece that was left!

now jigglypuff can grab!

and I wonder what happens if we playing with method[3][15] on zelda/sheik! maybe we CAN make the characters change which they literally cant O_o but that would also requirer to change the "rel ID to switch" inside the sora_melee's section 4!
also, the switchable characters has their rel file in a single, maybe we can make one rel file load an separate rel file and vise verca! that would be something!

EDIT2:

SpecialGrabslol

did a short video! some are glitchy but that isn't modules doing, it's my choice of actions :/