If I might make a suggestion about the assembly viewer, don't limit it to the function range like I did with the ModuleEditor 2. Instead, have the assembly viewer just label the sections of the code that are continuous. When you try to view the function, just have Brawlbox open up the full assembly block navigated to the selected address. More often than not, methods branch forward and backward in the code like the function in the picture you posted. Trying to define them using a crawler often leads to clipping the function down to just a stub. Doing this might also allow us to better see how the assembly block is organized overall.
One other thing you might do that would help would be to highlight the blr instructions.
do you know when soArticleMediator gets called? I mean, it's needs to be called atleast one time to get load, like the inialiazers or that Method[3][16] gets load inside FitChar object?
If you mean when an actual soArticleMediator instance gets created, then it is likely inside the ftClassInfoImpl.Method[0][2]. This object is used when generating the entire character and all of its subclasses, so there's likely a lot more than just that.
If you're looking for when the soArticleMediator.Method[0][1] gets called, then that has to do with the PSA commands. In particular, when the 10000100 (Generate Article) PSA command is encountered, it sends the command to the soGenerateArticleManageModule instance object. The soGenerateArticleManageModule then calls associated character's soArticleMediator.Method[0][1] with the parameters provided in the original PSA command. Thus, if we call the 10000100 PSA command with a parameter value of 01, then eventually, soArticleMediator.Method[0][1] will be called with r4=1. If we continue down the line, we'll see that soArticleMediator.Method[0][1] uses r4 to branch to the particular part of itself which is responsible for generating article 1 of that character.
and I have a theory what a article needs inside a module file:
* soArticleMediator as the "all articles base" * soLineHierarchy, it looks like it's also a base but for all "Attacking articles", not entry or static articles! but I might be wrong.
* soInstancePoolSub * wnInstanceHolder
* wn"Articlename" (example wnLinkBoomerang)
I am pretty sure everyone of these is need to get one article working, how they are link and their purpose is still unknown. but I bet my hat of the "wn"Articlename" is almost the same as soStatusUniq but for articles instead
While the wnArticleName objects are rather similar to the soStatusUniqProcess objects, they are actually closer associated to the ftFighterName objects in that they represent the actual object onscreen. However, you would be correct to assume that most of the behavior of articles is managed by them.
On a side note; Link's bombs, Peaches turnips and other articles that you can swap all are instances of wnSimple. Thus, swapping them doesn't make much of an impact on the stability of the code as you aren't actually replacing the object itself.
Also, the soInstancePoolSub objects are used to contain the actual instances of the article - this is why we are limited with some articles such as Link's arrows (there are 4 soInstancePoolSub objects, so we can only create 4 arrows at once).
The soStatusModuleImpl is an object that is found within the instantiated fighter object at runtime. You can actually see the definition for it in the sora_melee module:
(I guess I should have mentioned that I've documented known methods using single index values because it's difficult to determine the method offset using two index values.)
There's not much point in analyzing the declaration itself unless you want to understand what a particular function does. The real power instead lies in being able to know what function is being called by a given chunk of assembly code. Knowing the broader implications of a function call can go a long way in understanding what that particular chunk of code does.
As for the soArticleMediatorImpl objects, here's what I've found out so far:
Method[0][1] - the create_article method is used when creating an instance of an article. You may have already found this out, but the start of the function simply branches to a different block of the same function according to the article_id value it is being called with. Whenever you use the GenerateArticle PSA command, this function is likely the one that gets called in the end.
Methods [1][0] and [1][1] are Thunk methods like I discussed in my last post. These methods simply adjust the "this" pointer according to the required type and call a different function.
Method[1][2], when called iterates over all existing instances of all article types and calls a couple of their functions. For now, I'm going to guess that this is used to clear all currently existing instances.
Methods [1][3], [1][4] and [1][5] all have similar formats to the create_article method in that the start of the method branches according to the article id passed to it. I'm not sure what these methods are for, but they all seem to iterate over all existing instances of the selected article type.
Method[1][6] will retrieve the number of available articles for that character (however, the soArticleMediator object always implements enough space for 15 articles).
The last two methods are unknown, but I think Method[1][8] is used when you want to retrieve an existing instance of an article.
Not much progress on the ftStatusUniqProcess objects though. They seem to be pretty tough to crack.
Nice find Pikazz. Which method is that in? Perhaps analyzing it will give some insight into where to find the places that need to be patched when creating clone modules.
Anyways, the ftStatusUniqProcess objects I'm referring to are these ones:
I'm not sure what each method does, but they definitely seem related to a lot of special actions. As I said before, I think Methods[1], [2] and [3] are called when entering, inside and leaving an action. Link's UniqProcessWait has Method[1] and [3] implemented, so it would make sense if the defensive collisions were created when entering the action and destroyed when leaving the action. On a side note, it also has Method[4] implemented which in turn calls Method[3] - so perhaps Method[4] is used when leaving an action under a different condition or something.
The ftStatusUniqProcess objects are created in the initializers - here's Link's Initializer[6] which creates the ftLinkStatusUniqProcessWait object:
ftStatusUniqProcess objects are created inside the module's BSS memory (Section[6]). This particular object is created at [Section[6] + 0x1BC]. Once it has the pointer to spot it wants, it calls the ftLinkStatusUniqProcessWait constructor using the bl 0x30. All this call does is simply write the ftLinkStatusUniqProcessWait declaration to [Object +0x00].
After the object has been created, it calls the AddToHead function using bl -0x1105C. This function call will create and add a node onto a linked list inside the module's BSS memory. r3 is the object that is contained within the node while r4 is the destructor function of that object (in this case, Method[0][0]). Both of these fields are bound to the new node which is created at r5.
While the ftStatusUniqProcess constructor method varies, the AddToHead function is almost universally located at the very start of the assembly section - it's usually at file offset 0xCC.
After that, I would assume that the game will run each ftStatusUniqProcess object's methods from the linked list, but we won't know for sure until we try it out.
EDIT:
Hey Dantarion, if you're reading this, I think I found out what the so called "scope" values are for inside the object method tables. The positive values inside the inheritance hierarchy are Cast offsets applied to the "this" pointer when converting the object into one of its superclasses. The negative values inside the v_table are Thunk offsets applied to the "this" pointer when calling an overridden subclass function from the superclass. Oddly enough, it seems the table offset is actually ignored. Most function calls needing this are done using custom Thunk wrappers that subtract the value as a constant.
I think I'm starting to understand the code you gave PW. So all I do is (for example) If I want Link's Green color slot to be changed to say his White color then I just find that part of the code for Link & then put 09 in place of the 03 correct? then all I do then is put 03 where the 09 was & I've switched the Green & White slots right?
Yep, it sounds like you've got the hang of it. Good to hear that the code works as expected.
Why not try the code and see for yourself instead of asking me? I can't use Riivolution or Gecko or a Wii for that matter.
If you're looking for a code that can be used for every character, then here it is. It's different from the last code, but it should give you all the customization you need.
Code:
Color Slot Modifiers: (Credit to Dantarion who recorded all the data pointers for these codes.)
Mario 064551E8 00000010 00000906 01030204 08050302 0C000000
Sonic 06455448 0000000C 01000805 02040302 00010C00 00000000
Code:
Color Associations: (XX) 00 Team Red 01 Team Blue 02 Yellow 03 Team Green 04 Purple 05 Blue 06 Pink 07 Brown 08 Black 09 White 0A Unused 0B Unused 0C List Terminator
You're going to have to get your hands dirty if you want to get the customizations you want. After the first line of each code is the data that is used for specifying the color data. It's format is this:
X1Y1X2Y2 X3Y3X4Y4
The numbered X/Y pairs store the data for the color slots. X represents the color associated with the slot as denoted above and Y represents the numbered .pac file associated with the slot. I suggest you leave the .pac file alone and only modify the color value.
I've put all the default data inside the codes already, so making minor tweaks only requires you to swap specific values. If you wanted to swap Sonic's blue and black color slots as the previous code did, then all you need to do is swap the 01(team blue) and 08(black) in his code resulting in:
Swap Sonic's Blue and Black Color Slots: 06455448 0000000C 08000005 02040302 00010C00 00000000
So, if I'm reading this right, this will make Sonic's default slot load Black sonic, while his Black Sonic slot will load his default (ie, blue team Sonic)?
That's the idea, yes. But it hasn't been tested yet. This code was made using a couple of well educated guesses along with some background knowledge - so it may not work as intended.
More than likely it has to do with some part of the patched module still trying to access the module in the original 0x21 module slot. I'm assuming that you've patched the module so that it gets loaded into a separate slot from the original. Because there's still a section of the patched module that thinks it is stored in the original slot, the game will crash if the original slot is empty. Having the original Lucario in the match fixes the problem as the patched module will just be accessing the original module for the faulty section.
Finding the source of this problem would be simple with WiiRD as it will always catch this particular kind of error and show you where it occurs. However, my Wii's disc drive kicked it so all I can do is speculate on this end.
On a side note, shouldn't this thread and the .rel Porting thread be merged or something? It seems like we've got two threads for similar things here.
Hey Pikazz, have you tried doing anything with the soStatusUniqProcess objects yet? They seem to be responsible for the majority of the work done in complex actions such as Lucario's Up-B and Down-B, Falcon's Final or Link's standing shield. Also, if my theory is correct, they may also be responsible for ensuring that reflect/absorb collision bubbles work reliably.
Before that, take a look at the module initializers. Initializer[0] will always create instances of ftExtendParamAccessor and ftClassInfoImpl. As we already know, the stClassInfo objects are responsible for instantiating stages, so the ftClassInfo objects must be responsible for instantiating the fighters. I'm not sure exactly what the ftExtendParamAccessor is for, but I think its name is pretty self explanatory.
Anyways, both of these objects are bound to linked list nodes and added onto a linked list contained within the module's BSS Memory. The nodes contain the following parameters:
0x00 Next 0x04 Finalizer 0x08 Instantiated Object
The finalizer is used during Finalizer[0]. Finalizer[0] iterates through all of the linked list nodes and calls the finalizer method on the instantiated object.
Returning to the soStatusUniqProcess objects, they are created in the remaining Initializers. So Initializers[1, 2, 3 ...] will create soStatusUniqProcess objects, bind them to Linked List nodes and add them onto the module file's linked list.
The soStatusUniqProcess objects themselves are a bit of a mystery, but if I had to guess, Methods[1], [2] and [3] are called whenever the characters enters, is in and leaves an action respectively (Method[0] is the finalizer). Each method is called with the following parameters:
In any case, it would be worth analyzing exactly how these soStatusUniqProcess objects behave. Using these would allow a new level of complexity to character movesets.
If you're going to analyze the routines though, you'll need some information on the modules. This is most of what I've discovered so far:
Modules: (For more information on how to use this list, see my earlier post.)
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
The soWorkManageModule methods correspond to the PSA command set for variables. The variables themselves are identified in a slightly different manner but they seem to be mostly consistent with the Internal/Runtime/RandomAccess Basic/Float/Bit model setup for PSA. On a side note, PSA commands 1211 and 1212 are Absolute and FloatAbsolute respectively.
Anyways, I'm still in the middle of working things out, but I'm starting to approach the point where I'm going to need some actual experimentation data to go any further.
Is the spin something you added or is it something that the code automatically does? I also noticed that you were able to bind the grab to Jigglypuff's Side-B - can you bind it to any action?
I'm interested to see what else is handled by Method[3][16]. I know that the part of ike's FS that forces the target to the top center of the stage is most likely handled by it. Have you tried switching any other character's Methods around?
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].
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.
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:
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.
Show Posts
