No. I did exactly what you did and got rid of everything but the CSP folder, and system folder (with common 3 only) and the only codes were File patch, and SDHC expansion code. It works when I do that, but if I include anything that touches the CSS in anway (CSS fix, Custom CSS, etc.), it crashes.

That's to be expected to some extent. Those codes modify assembly in sora_menu_sel_char.rel. If you change the size of the module, then the alignment of the file changes causing a shift in the assembly code. This causes those codes to write to the wrong places making things unstable. There's also a small gotcha with the way module sections are aligned. Due to a small quirk in the way they're structured, the module editor can't perfectly recompile them to the exact same alignment. You can however, force the sections to line up properly if you pad out each section with extra bytes. The best way to ensure code compatibility is by first ensuring that the module's FixSize matches the original, and then performing a diff on the two files to see where where the section alignments differ (Note that they only need to match up to the FixSize.). From there, you can manually pad out each section to properly line them up again.

I dunno. I'll have to check whenever I can.

Regarding file size limit, the texture and model are way below the limit, and the moveset is about 90 kb over. The FitLucario clone file I'm using is about 100 kb over.
I may just replace them with the normal ones and see what happens, because FitLucarioMotionEtc.pac and the FitLucario.pac files I'm using are from a custom PSA. I will post my progress whenever I get the chance.

EDIT1: I got the chance, and tested the clone with normal files (save for the model-texture file for the clone) and right when I went to hover my cursor over the clone, the game crashes. Sooooo........what did I do wrong?

Crashing due to hovering over the icon implies an error in the CSP data. To confirm this, you could try changing the CSSSlot config file's cosmetic ID to someone that you know already works like Mario. If it still crashes, then it is likely there is something wrong with your core BrawlEx file setup.

Whoa, that was fast! Thanks for the info, I'll continue to attempt this method. Now is there any specific program to use this method with? Like a hex editor or brawlbox? Perhaps the module editor?

Even if I were to copy lines of hex, it doesn't seem to copy comments and other info (red text/ highlighted stuff.) I have tried all three programs, all of which gave me a bad file when booting smash.

For the most part, I use the module editor 3. Open up a vanilla copy of the module and add a section[7] with the size needed (make sure you mark it as an Executable section). Then copy over the hook and hook function using a hex editor. The relocations (highlighted in red) will need to be copied over by hand using the Module Editor, but they aren't too complex. Things should work just fine with just that, but if it still isn't working after that, you may need to reduce the size of the module by the amount you added to make sure it properly fits. Section[5] usually has a bunch of free space at the end of it, so you can reduce it by the same size that you added for section[7]. The important part is that the new module's FixSize matches the original module's FixSize. You can freely override this value in the module's properties.

Hey, PW, or anyone who knows.. is it possible to use the method of loading CSPs through the brawlex directory without using Roster.dat.

The reason being is I would like to use independent pokemon (no trainer) with custom CSPs for everyone (and no file size).

I cannot use Brawlex at full strengh because ASL conflicts with that, so I'm just using Brawlex JUST for extra CSP space, but I can't use the Independant pokemon fighter config file because it's not loaded since I'm just using the brawlex one way.

Sorry for the confusion, any questions I'll be happy to answer lol

The external CSP loader more or less stands as it's own unit inside sora_menu_sel_char.rel (Common3's MiscData[13].rel file). The only reason it's paired up with the CSS Roster Expansion is that their hook points both happen to be in there.

I'm pretty booked for this coming weekend and the next, so I don't think I'll be able to help you any time soon, but if you'd like to look into it yourself, you can take a look at the module in Resources\Common3 of the 2.0.0.x package and try to extract the changes yourself. There are 3 things that you'll need to copy out from the module into a vanilla sora_menu_sel_char.rel module. The hook is at section[1] 0x1109C while the corresponding hook routine is at section[7] 0x0. There's also a directory string at section[5] 0xE40 that you'll need to copy and/or change depending on where you want to load from.

Best of luck.

Hm, i used the search function for this question.
how does one put multiple character PSA's onto one CSS slot?
I had an idea for Zelda (and other characters) that they would have variant PSA's based on Costume. I'm not sure how to do this with BrawlEX. Like the first costume is Vanilla, but after the red/green/blue costumes, you have an extra costume that has a small variant PSA that the chracter could have. I read that it was possible a while ago, but i never bothered trying it.

Currently there isn't any characters that normally support this kind of feature. The closest to it is Wario, but that's just a costume swap. There are ways you can go about doing it using codes I believe, but that's not actually changing the roster. Otherwise, as Itman said, you can create a custom moveset that will change which moves are used depending on the current costume. This is what Nebulon's Brawl4All already pack uses for certain characters.

Yet another thing I would like to get done someday is to add the ability to make any CSS icon have multiple characters like Zelda/Sheik or Pokemon Trainer. In this way, you could use a single CSS icon for 2 or 4 different variants of a character that you could choose by clicking on the corners of the character's portrait. Again, this is another thing that will have to wait until I have time to do though...

Has any one got a lone Zero Suit samus clone working? I can't get any of the Samus/Zelda clones working. and mind you i have a ton of clones. am i missing anything new to make them work?

Cloning the alone variants of them should be the same as any other character. Cloning both transforming characters together requires a little bit of extra work:

If you just want the alone variant of the character, then you can clone them exactly the same way you'd clone any other character. For cloning both characters, you'll need to do a little bit more with the config files.

Start by cloning both of the characters as you would normally. For this example, I'll say I'm going to clone Zelda and Sheik as ZeldaEx and SheikEx into slots 3F and 40. The one main thing that's different is that there's only 1 ExModule to work with: ft_zelda-sheik.rel. This module can be configured similarly to the regular ExModules, except that there are two spaces in section[8] for both Zelda and Sheik's ids. In this case, I'm going to be changing those ids to 3F and 40. After configuring the ExModule, you can name it to something like ft_zeldaex-sheikex.rel and place it in your modules folder. From here, you can configure your Fighter Config files to point to the FitZeldaEx and FitSheikEx resources. After configuring the Fighter Config files, open them back up with a hex editor and change the both of the module reference strings to "ft_zeldaex-sheikex.rel". Finally, open up the Slot Config files for both characters and change the Edit Flags (@0x0C) to 0x00000001, and change the Slot Characters (@0x10) to 0x0000003F and 0x00000040 for Zelda's Slot Config and 0x00000040 and 0x0000003F for Sheik's Slot Config. After that, you should be ready to go.

To Summarize:
- Acquire fighter resources, config files, and the 1 ExModule file.
- Configure both character ids and the module id of the ExModule.
- Configure the Fighter Config files to point to the fighter resources.
- Manually change the 2 Fighter Config files to reference the 1 ExModule file.
- Manually change the Slot Config files to point to both of the new fighters in either order of your choice.

One final thing to note: If you're going to clone Bowser and GigaBowser together, you'll need to make one additional change: When you're configuring the fighter config files, be sure to check the "Merge Motion/Etc" check box. Additionally, you'll need to use the merged Bowser and GigaBowser MotionEtc.pac files from the downloads section on the main page.

Also, if you want to use Giga Bowser alone, he will work with his normal files, but he won't have his attack effects as they are loaded from Bowser's moveset file. The same download link I just mentioned also has a modified GigaBowser moveset file that has Bowser's effect file added into it. Use this moveset file instead if you want the attack effects to show up.

Has anyone had any success with multiple Giga Bowsers for Bowser's final smash? Modifying his fighter data to have more colour slots didn't seem to have any effect (he still loads slot 00). I know PM has this feature, but I don't think I've seen anyone backport it to vbrawl, and I'm sure with the tools BrawlEx has it must be possible in some way.

Right now there isn't a way to have multiple costumes for Giga Bowser as the game internally restricts him to 1 costume. It's on my todo list though. For the most part, I already know what needs to be changed. It's just a matter of finding time to get it into the next update.

I've been wondering...Has CSS Expansion v2 been looked into a bit more in an attempt to fix its issues?

Not much since last update. It's one of the things I'd want to do next though. I really hate having to downres the CSS portraits. The issue is caused by a combination of two things: the first being that everytime you hover over an icon, it reloads both the previous portrait and the new portrait twice for some reason; and the second being that the more files you have in a single directory on an SD card, the longer it takes to load a file from that directory.

Of course, the main issue is memory constraints. There simply isn't enough resource memory in the Wii available to store so many unique portraits at such a high resolution all at once. It may be possible to make due with just using the SD card for storage using buffered loading if it proves to be impossible to get those load times down, but otherwise, the only other option is to make due with what we already have.

Hey Im having a problem with the CSS where I can't have more than 50 icons/slots on the screen. Dose any one have a fix or a solution for me?

If you're using the BrawlEx CSS Expansion, and you're still stuck at 50, then you probably don't have the BrawlExCSS's sc_selcharacter.pac file in your patching directory. Without it, your CSS will only go up to 50.

Is it possible to clone a solo shiek?

Currently, no. Sheik is dependent on Zelda for the Final Smash resources that are stored in FitZelda.pac. That being said, there's nothing stopping you from creating a character slot that selects Sheik by default and then just removing the ability to transform into Zelda.

I was going through my mail archives and I don't think I ever mentioned this publicly. Maybe someone will find it interesting:

Hi Pikazz, thanks for being patient with me getting back to you.

It turns out that there isn't a whole lot that goes into initializing the soStatusUniqProcess objects for a character. For regular actions of Id 0 up to 111, the unique processes are initialized using a generic function called for all characters when they are created.

For the unique processes corresponding to a character's special moves - that is, Action Ids 112 and above - they are initialized inside the character's constructor located inside their module. Luckily it's not too hard to find the place where this particular bit of code is located:

If you're looking to swap out any of the unique processes for Action Ids 111 and below, those are set at the instructions located at m1b[1] 0x128504 (80832F18 in memory). The code used there is fairly similar to what's used inside the character's constructor.



This is a pretty interesting discovery. It seems unique processes are fairly easy to swap too. Here's the unique process for Lucario's up-B, ftLucarioStatusUniqProcessSpecialHiRush, placed on his neutral-B allowing controller based directional movement:





Anyways, I hope you found this helpful. Good luck with your modding Pikazz.

Thanks for answering.

As for the Article subject, could we use this information to create new custom articles, rather than increase the amount of existing articles on the stage?

Technically yes. Doing so would require a custom soInstanceHolder constructor and custom instantiation function, but that doesn't mean it would be impossible to use another article as a template. I imagine porting articles to other characters would be the first step in that direction. The easiest articles to port are the ones that can be copied by Kirby as their soInstanceHolder constructors and instantiation functions are stored in sora_melee and therefore always loaded. All other articles are completely encapsulated inside their character's module file, so porting them over to another character would require copying over all the assembly related to making them run.

I'm sure this is the question we're all thinking about.

Although, I wonder... how did PW start with all this module stuff to begin with?

Sometimes I wonder the same. :O

Continuing,

The soGenerateArticleManageModule contains an instance pool that holds reserved memory for all the article instances allowed for that character.

The regular soGenerateArticleManageModule with 3 aura spheres is on the left and our goal which has 8 aura spheres is to the right. To get from 3 to 8, we need to add space for 5 wnInstanceHolder<wnLucarioAuraBall> objects and 5 soInstancePoolSub<... wnLucarioAuraBall> objects.

Each soInstancePoolSub regardless of type will always be 0x4 bytes. The wnInstanceHolder objects vary in size, but you can determine their size by looking into the soGenerateArticleManageModule constructor:

Here, we can observe 3 wnInstanceHolder<wnLucarioAuraBall> constructors calls into 0x84DC. We can subtract two of the offsets passed into the constructors to get the wnInstanceHolder<wnLucarioAuraBall> size.

instanceHolderSize = 0x2060 - 0x0C = 0x2054

From here, we can calculate the size increase for adding 5 aura spheres:

sizeIncrease = 5 * (instanceHolderSize + instancePoolSubSize) = 0xA1B8

In order to continue, we also need to determine the original size of the soGenerateArticleManageModule. Because we are moving it to a completely new location, we can't use the old allocated memory for it.

Determining the size of the soGenerateArticleManageModule can easily be done by subtracting the location of the following module - soEffectModule - from the location of the soGenerateArticleManageModule. Looking a bit further down from where the soGenerateArticleManageModule constructor is called:

We find that the soEffectModule is constructed at [soInstanceManagerFixedSimple + 0xDC40]. This means the size of the soGenerateArticleManageModule is:

moduleSize = 0xDC40 - 0x5C24 = 0x801C

From here, we can calculate the new memory allocation size of our character.

newAllocSize = oldAllocSize + moduleSize + sizeIncrease = 0x2271C


We've increase the size of our character's memory space, and repositioned our soGenerateArticleManageModule into its new location, but we still need to add those 5 extra wnInstanceHolders and InstancePoolSubs. Let's look into the module soGenerateArticleManageModule constructor again.

As it turns out, there's enough repeated code here to merit a loop. And with a loop, we can control however many iterations we want - be it 3 or 8. Doing a little bit of refactoring gets us:

Code:

s[1] 0x844C:

li r27, 0x00000000
addi r3, r28, 0x1E5C
mulli r4, r27, 0x2054
add r3, r3, r4
mr r4, r31
bl s[1] 0x84DC
addi r27, r27, 1
cmpwi r27, 8
blt+ -0x1C
lis r3, 0x0000
addi r3, r3, 0x0000
stw r3, 0(r28)

If there weren't enough space to add duplicate instance holders - or if we were adding a completely new article, then we would need to use another hook to do the additional work required. Neither case is very much of an issue.

As was the case when we moved the soGenerateArticleManageModule, if we update the constructors, we also need to update the destructors. In this case we need to update the offsets inside each soInstancePoolSub<... wnLucarioAuraBall>Method[0][0] to reflect the new offsets. There's a bit more to it than that, but I'll save the details on it for later.

Now that we have 8 instance holders to store our 8 Aura Spheres, we need to change the character's ftArticleMediator to actually allow us to make those 8. Before continuing, let's take a look at the OpenSA documentation on ftArticleMediatorImpl

http://opensa.dantarion.com/wiki/SoArticleMediatorImpl

There are 4 methods in this class that need to be changed: GetInstanceCount, GetInstanceCap, and the two versions of ClearInstances. These are just numeric caps on the number of instances for the aura ball type that we need to change from 3 to 8.

s[1] 0xAD24 cmpwi r31, 8   // ClearInstances
s[1] 0xAF84 cmpwi r31, 8      // GetInstanceCount
s[1] 0xB188 li r3, 8         // GetInstanceCap
s[1] 0xB534 cmpwi r31, 8   // ClearInstances (All)

Finally, we need to change the instantiation function itself that actually puts an instance of the article into the instance holder. This is the GenerateArticle method of the ftArticleMediator. Changing it it more or less the same process as how we changed the construction process for the instance holders - that is, we replace hard coded references to each instance holder with a loop that iterates over them.



And that's about it. I ged over a bit more than I would have liked, and I think I may have missed a few things all together, but I'll leave a file here with all the changes I made to the Lucario module.

Changelist

I've also made a near complete memory map of ftLucario in-game. It may come in handy for future references:

Code:

============== ftLucario ===================
POS: 0x0000
SIZE: 0x10548

0x00000 p_nodeName // "LUCARIO"
0x00004 Prev Node
0x00008 Next Node
0x0000C Prev Node
0x00010 Next Node
0x00014 Prev Node
0x00018 Next Node
0x0003C p_classMTable    // ftLucario
0x00040 p_ancestorMTable
0x00048 p_ancestorMTable
0x00054 p_ancestorMTable
0x00060 p_soModuleAccessor
0x00064 p_ancestorMTable
0x00070 p_ancestorMTable
0x0007C p_ancestorMTable
0x00088 p_ancestorMTable
0x00094 p_ancestorMTable
0x000A0 p_ancestorMTable
0x000AC p_ancestorMTable
0x000B8 p_ancestorMTable
0x000C4 p_ancestorMTable
0x000D0 p_ancestorMTable
0x000DC p_ancestorMTable
0x000E8 p_ancestorMTable
0x000F4 p_ancestorMTable
0x00100 p_ancestorMTable
0x00110 Fighter ID
0x0013C ftOutsideEventPresenter

0x00194 INSTANCE MANAGER DATA

0x0FF98 ftCancelModuleImpl
0x0FFD4 ftVirtualNodeMatrixPoolImpl

0x1048C GIMMICK DATA

0x10524 ?
0x10528 0x00000001
0x1052C ?
0x10530 0x00000001
0x10534 soArrayContractibleTable<const soStatusData>
0x10544 ?

===== INSTANCE MANAGER DATA ======
POS:  0x0194
SIZE: 0xFE04

0x0000 soInstanceManagerFixedSimple

0x0014 soArrayVector<soInstanceUnit<soEventUnit *>, 19>
0x0020 soInstanceUnit<...> [00]
0x0028 soInstanceUnit<...> [01]
...
0x00A8 soInstanceUnit<...> [17]
0x00B0 soInstanceUnit<...> [18]

0x00B8 soEventManageModuleImpl
0x09D0 soModuleAccessor
0x0AB0 soHeapModuleImpl
0x0AC8 ftLucarioParamCustomizeModule
0x115C soResourceModuleImpl
0x1180 soModelModuleImpl
0x1440 soMotionModuleImpl
0x17D4 soPostureModuleImpl
0x1888 soGroundModuleImpl
0x1930 soSituationModuleImpl
0x196C soTeamModuleImpl
0x19E0 soCollisionAttackModuleImpl
0x1FFC ===== [BASE] soCollisionAttackModuleImpl
0x209C soCollisionHitModuleImpl
0x2990 ===== [BASE]soCollisionHitModuleImpl
0x29F8 soCollisionShieldModuleImpl
0x2D4C ===== [BASE]soCollisionShieldModuleImpl
0x2DA0 soCollisionShieldModuleImpl
0x37B4 ===== [BASE]soCollisionShieldModuleImpl
0x380C soCollisionCatchModuleImpl
0x3988 ===== [BASE]soCollisionCatchModuleImpl
0x3A70 soDamageModuleActor
0x3B1C ===== [BASE]soDamageModuleActor
0x3C20 soCatchModuleImpl
0x3C84 soCaptureModuleImpl
0x3CB8 ftStopModuleImpl
0x3CDC soTurnModuleImpl
0x3D14 soShakeModuleImpl
0x3D90 ===== [BASE]soShakeModuleImpl
0x3DC0 ===== [BASE]soSoundModuleImpl
0x3E1C soLinkModuleImpl
0x3F60 ===== [BASE]soLinkModuleImpl
0x3FB4 soVisibilityModuleImpl
0x3FE4 ftControllerModuleImpl
0x459C ===== [BASE]ftControllerModuleImpl
0x4708 soCameraModuleImpl
0x4758 ===== [BASE]soCameraModuleSimple
0x477C soWorkManageModuleImpl
0x47B0 soAnimCmdModuleImpl
0x48A4 soStatusModuleImpl
0x5688 ===== [BASE]soStatusModuleImpl
0x5738 soKineticModuleGenericImpl
0x5C00 ===== [BASE]soGeneralWorkSimple
0x5C24 soGenerateArticleManageModuleImpl
0xDC04 ===== [BASE]soGenerateArticleManageModuleImpl
0xDC40 soEffectModuleImpl
0xDCAC ===== [BASE]soEffectModuleImpl
0xDDE4 ftComboModuleImpl
0xDE14 ftAreaModuleImpl
0xDE24 ===== [BASE]ftAreaModuleImpl
0xE188 soPhysicsModuleImpl
0xE204 ===== [BASE]soPhysicsModuleImpl
0xE24C soSlopeModuleImpl
0xE2CC soShadowModuleImpl
0xE314 soItemManageModuleImpl
0xE3B8 ===== [BASE]nhsoItemManageModuleImpl
0xE424 soColorBlendModuleImpl
0xE578 soJostleModuleImpl
0xE5C4 ftAbnormalModuleImpl
0xE62C soSlowModuleImpl
0xE668 ftGlowModuleImpl

0xE7E8 soArrayContractibleTable<const soStatusData>
0xE7F8 ANIM CMD DATA

============== ANIM CMD DATA =============
POS:  0xE7F8
SIZE: 0x160C

0x0000 soArrayVector<const acAnimCmdConv *, 293>
0x000C acAnimCmdConv[000]
0x0010 acAnimCmdConv[001]
...
0x049C acAnimCmdConv[292]

0x04A0 soArrayVector<const acAnimCmdConv *, 293>
0x04AC acAnimCmdConv[000]
0x04B0 acAnimCmdConv[001]
...
0x093C acAnimCmdConv[292]

0x0944 soArrayVector<acCmdInterpreterStackData, 8>
0x0950 acCmdInterpreterStackData [0]
0x0964 acCmdInterpreterStackData [1]
...
0x09DC acCmdInterpreterStackData [7]

0x09F0 soAnimCmdAddressPackArraySeparate
0x0A0C soAnimCmdInterpreter
0x0A5C soArrayContractibleTable<const acAnimCmdConv *>
0x0B88 soArrayContractibleTable<const acAnimCmdConv *>
0x0CB4 soArrayContractibleTable<const acAnimCmdConv *>
0x0DE0 soArrayContractibleTable<const acAnimCmdConv *>
0x0F0C soArrayContractibleTable<const acAnimCmdConv *>
0x1038 soArrayContractibleTable<const acAnimCmdConv *>
0x1164 soArrayContractibleTable<const acAnimCmdConv *>
0x1290 soArrayContractibleTable<const acAnimCmdConv *>

0x13BC soAnimCmdInterpreter
0x14E0 soArrayContractibleTable<const acAnimCmdConv *>


========= GIMMICK DATA =========
POS:  0x1048C
SIZE: 0x00098

0x00 ftStatusGimmickUniqProcessPoolImpl
0x08 ftStatusUniqProcessGimmickBarrel
0x20 ftStatusUniqProcessGimmickDoor
0x34 ftStatusUniqProcessGimmickCatapult
0x48 ftStatusUniqProcessGimmickLadder
0x5C ftStatusUniqProcessGimmickSpring
0x70 ftStatusUniqProcessGimmickTruck
0x84 ftStatusUniqProcessGimmickEaten



========= ARTICLE MEDIATOR MODULE ========
POS:  0x5C24
SIZE: 0x801C
============
0x0000: soArrayVector<soArticle *, 5>
0x0020: soArrayVector<soArticleEventObserver *, 5>

0x007C: soArticleMediator<...> T1
0x0080: soArticleMediator<...> T2

0x0084: == INSTANCE POOL ===
0x0084: == LINE HIERARCHY ==
0x0084: Decl

0x0088: soInstancePoolSub<...>
0x008C: x
0x0090: == INSTANCE HOLDER DATA == [0x1E40]
0x0090: soInstanceHolder<...>.decl
0x0094: ? (0x8508)

0x1ED0: soInstancePoolSub<..., 3>
0x1ED4: soInstancePoolSub<..., 2>
0x1ED8: soInstancePoolSub<..., 1>
0x1EDC: x
0x1EE0: == INSTANCE HOLDER DATA == [0x2054]
0x1EE4: soInstanceHolder<...>.decl

0x3F34: == INSTANCE HOLDER DATA == [0x2054]
0x3F38: soInstanceHolder<...>.decl

0x5F88: == INSTANCE HOLDER DATA == [0x2054]
0x5F8C: soInstanceHolder<...>.decl

0x7FDC: byte Flag (END OF soArticleMediator)

0x7FE0: == ARTICLE MODULE BASE == [0x3C]

It also comes with a visual! Buy 1 for the low price of 0 dollars and get the second 1 50% off!

Buy Now!


I hope this helps anyone looking to get serious with modules. Let me know if there's any questions.

So how are Article Floating Points handled?

And a bit unrelated, but which part of the rel tells the character to use an animation for their DamageFace Sub Action? I'd like to get a character of mine to use a tail animation (like Charizard's tail and wings) when being thrown, but I just couldn't figure it out. So I'm assuming it's module-related.

As Sammi-Husky mentioned, article floating point parameters are mostly to do with the ParamAccessor objects. That being said, I haven't done too much research into them either, so Sammi-Husky probably knows more than me at this point.

As for the damage face animations, I haven't touched on those at all, so I can't really say I can help you there. You would probably be correct in assuming that they are managed by the character module though.

More on adding articles:

Our goal is fairly simple. In order to add more articles to a character, we need to expand the memory stored in the character's soGenerateArticleManageModule. Normally, this would be difficult as simply increasing its size would end up overwriting any module that comes after it. However, we can avoid this issue by adding additional memory to end of the character's allocated memory space and then moving the resized soGenerateArticleManageModule to the new space.

The first step - increasing the character's allocated memory - is easy. The character's size is simply a constant stored in Method[0][2] of the character's ftClassInfoImpl:

Here, the 0x8000C8B8 function call is equivalent to the C-style malloc call. The argument r3 specifies the size in bytes while the r4 argument specifies which heap to allocate the memory on. The highlighted instructions load r3 with 0x10548 - the size of the ftLucario object in memory.

Next, we need to change the ftLucario constructor so that the soGenerateArticleManageModule is created in the new location. Immediately following the malloc call above, is the function call into the the ftLucario constructor. It takes a while to learn the layout of character constructors, but once you do, it becomes fairly easy to find the location where the different module constructors get called. In this case, Lucario's soGenerateArticleManageModule constructor gets called at section[1]+0x75C.

Register r25 actually points to the soInstanceManagerFixedSimple shown in the top image. 0x5C24 is the offset inside of it where soGenerateArticleManageModule gets created. The function call with offset 0x8374 is the constructor for soGenerateArticleManageModule. Moving back up a ways, we can find out what value r25 gets set to:

Here, r24 points to the beginning of the ftLucario object - the pointer we got back from our malloc call. The offset 0x194 is the position inside ftLucario where soInstanceManagerFixedSimple is stored. As a result, in order to move the soGenerateArticleManageModule to the end of the ftLucario memory, we need change the soGenerateArticleManageModule constructor offset value to:

offset = <original ftLucario size> - <instance manager offset> = 0x103B4

Or equivalently, at section[1]+0x75C we need to change

addi r3, r25, 5C24

to

addis r3, r25, 0x0001
addi r3, r3, 0x03B4

This presents a problem as we now need to replace 1 assembly instruction with 2. However, this problem can be solved fairly easily using a hook function that performs the operations needed elsewhere. Looking at the 8 Aura Sphere module you can find an example of this procedure, but I'm not going to go into much more details on the topic besides that.

Now that we have moved the soGenerateArticleManageModule, there are 3 other places where we need to change similar pointers so the new location can be properly accessed. Those 3 places are: the soModuleAccessor reference, the soGenerateArticleManageModule destructor, and the soGenerateArticleManageModule base destructor. The destructors are pretty easy to deal with as the game will crash very close to the point where they are called if their pointers aren't updated. From the crash, you can easily use the Dolphin debugger to trace back to where each pointer gets loaded.

As for the soModuleAccessor pointer, it can be found in the ftLucario constructor as well.

Note that the offset loaded here, (soInstanceManagerFixedSimple + 0xDC04) is not the same as the offset used to create the soGenerateArticleManageModule (soInstanceManagerFixedSimple + 0x5C24). This is because we are actually pointing at the soGenerateArticleManageModule base class which is stored inside the implemented version of the module. We aren't going to change this one yet, as the internal offset of the base class will change once we increase the size of the soGenerateArticleManageModule. However, if you did change this pointer - along with the other ones discussed so far, you could load this modified ftLucario.rel into the game and it would run perfectly fine with the new soGenerateArticleManageModule location.

That being said, we are only half way done. We still need to increase the size of the soGenerateArticleManageModule, add new wnInstanceHolder objects to store the new articles, and refactor the soGenerateArticleManageModule's assembly to work with the new memory layout.

Please stand by as I take a lunch break. We will resume later this evening

Hey PW, I've been looking over your Lucario 8 aura sphere module since I'm trying to up G&W's sausage count to 15 instead of 5.  You replaced a couple of (what I assume to be) target offsets in the main fighter constructor and destructor functions with some new offsets as well as modified the fixed offset accessor functions with a proper function that looks up the address via some well thought out multiplication and addition.  I'm not quite that clever/knowledgeable about module layouts though, and I was wondering if you'd be willing to go through the basic process you had for figuring out the numbers to use for replacing the constructor/destructor offsets as well as the multiplication/addition constants for accessing the new articles?

Hey Mawootad. It's good to hear that you're interested in this. You seem pretty dead set on figuring this out, so give me until this weekend and I'll see about compiling everything I know on the topic.


By the way, Pikazz. I just realized that I still haven't replied to your messages yet.    Give me until the weekend and I'll make sure I get back to you this time. Thanks for being so patient.

KingJigglypuff more or less summed things up. The only thing I might add is that I think Sammi-Husky was doing a little bit of investigation into adding items into the game. I think he was waiting for me to get back to him on something before he could continue. I don't remember exactly what it was, so be sure to send me a reminder if you see this.

Anyways, I haven't had a chance to do very much for BrawlEx since the new year. These days, I usually don't have time to get anything done except during holidays - and even then, there's a chance that I won't be able to. Lately, it seems Brawl's hacking scene has reached a pretty good settling point. As much as I'd like to see some of the larger plans realized, it may be a while until you see anything new from me.

Thanks for the heads up... but it sounds like a bit of a headache.

That being said, is there some secret to making more than one metaknight clone? I asked once already but I'm gonna ask again. I can't get Tails and Gray Fox to work unless I remove one or the other. I've tried making other MK clones but the same thing happens. What's the trick? What am I missing here??

I'm also having the same problem with Little Mac. He works on other people's pacs but when I put him in mine he freezes mid battle at random things like using his down smash or dodge rolling. What's the deal with this?

This is the first I've heard of this kind of bug. Do you think you could send me a message with a copy of your patching directory setup with one of these crashing characters?

If I want to make independent Samus/SZZ, would it be better to use the solo module that BrawlEx has or with gecko codes?

Normally I'd recommend using the independent modules as then you can share your moveset without having to share codes along with it. They also have the advantage of not needing to load the other character's resources - so characters like ZSS who have a very small file .pac size limit should be given a bit more space to work with.

That being said, the Samus module still needs a bit of work as it has a visual bug that makes the Charge Shots invisible. Functionally it works fine - final smash and all. The ZSS module works without any problems, however, you'll need to define a new Final Smash for her if you want her to be able to use one.

I have finally gotten the new version and I love your bugfix on the transformation characters! but I have encounter one problem:

Something is right yet wrong

as you see, it successfull swaps ingame, but at the end of the fight, it keep the same "slot" as it was selected in the beginning of the battle o:
it could be that non of the character I using is an old transforming character but simply modified Purin and Ganon Modules. I dont know what causes this! I have tried everything ;_;

Alright. That's one thing I never checked, so I'll look into it later today. Thanks for the bug report.

Also, your Jigglypuff moveset looks awesome.

Hmm. I'm fine with not using Brawlex if it means I could use the ASL... but, I do like the fact that you can load portraits elsewhere to save file size limits. Is there anyway I could just use THAT part of the code? Is there a section I could just cut out and I just have that? Or, is it that, that part of the code is scattered throughout the file patch code? I hate to keep asking this, and I know it must be like a broken record; I thank you for your response. I just would like to know. Thanks!

If you are referring to the BX CSS Expansion v2, then that can be used separate from the BX Clone Engine. The BX CSS Expansion works by replacing an existing module at the CSS instead of loading up an original one at startup, so I don't think it will cause any compatibility issues with the ASL. Give it a shot and see if it works out - but perhaps it'd be best if you backed up your save file beforehand just in case.

Don't worry too much about asking questions. I know you've been around since GSCentral, so the very least I can do is answer your questions.

EDIT:

I need help! I put pikezars pack on my SD card and whenever I load it up with riivolution the character select screen is completely empty! Help plzz!

If I recall correctly, most Riivolution xml files are setup to only replace files that are already on the disk. The BrawlEx/CSSRoster.dat file is not normally part of the game, so Riivolution won't load it unless it's told how to. I can't use Riivolution myself, so I can't help you too much with the debugging, but if you post the contents of your xml file, we might be able to help you.