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

[ForOhFor Error]

Doing that in Final Destination?

[pikazz]

found more how objects are stored and load ingame!

and damn, it's like looking in a maze!
it doesn't not load through a method inside a object (as it seems), more of asm OUTSIDE.
the thing I saw how grGimmick load isn't in method that Module Editor2.2 couldn't find :/

I know that initiaziler is branching to one method that no object using which makes one object load through there.
have found all 3 objects in final destination and where they get loaded, but how those 2 other invisible methods gets loaded is still a mystery

Doing that in Final Destination?

yes, it is final destination! cause it's the simplests of all stage modules!

[PhantomWings]

Alright, Info Dump time!

It looks like modules aren't so chaotically structured after all. There's actually quite a bit of coherence to them if you know where to look.

First of all, here's a mapping of some of the more important functions in ftLucario.rel:

("ctor" is short for "constructor")

Sorry but you are not allowed to view spoiler contents.

Next, here's a mapping for a few constructor functions in sora_melee.

Sorry but you are not allowed to view spoiler contents.

Finally a few more functions which are relevant to Lucario in the sora_melee module:

Sorry but you are not allowed to view spoiler contents.

So what is the significance of all this? Well, I'll try to explain it the best I can.



All interfacing with the character modules are primarily done through the ftClassInfoImpl objects. In particular, whenever the game needs an instance of Lucario, it calls ftClassInfoImpl<33, ftLucario>.Method[0][2]. This function simply calls ftLucario.ctor.

ftLucario.ctor calls Fighter.base_ctor, ftFighterBuildData.base_ctor, soInstanceManagerFixedSimple.base_ctor, soModuleAccessor.base_ctor and each of the module constructors. Most character modules will usually create derived versions of the modules so they will implement their own constructors which will generate part of the object and then call the sora_melee version of the constructor. Sometimes though the character module will instead just opt to call the base constructor on its own as all it needs is the base functionality of the sora_melee version. Other times, a null placeholder will be loaded up in place of the module instead.

I haven't mapped all the functions that ftLucario.ctor calls yet, but that much on its own is pretty interesting.

Of particular interest is the soGenerateArticleManageModuleImpl.ctor function. Characters who don't use articles will fill the soGenerateArticleManageModuleImpl spot with a null placeholder, but characters who do use articles will have this function implemented. In addition to creating the base soGenerateArticleManageModuleImpl object, the implemented constructor will also create create soInstancePool, soInstancePoolSub and wnInstanceHolder objects inside of the soGenerateArticleManageModuleImpl object. Additionally, it will also call the constructor functions for the articles (in Lucario's case, it calls wnLucarioQigong.ctor and wnLucarioAuraBall.ctor). Essentially, this function sets up all of Lucario's articles for use. Later on when we want to create instances of the articles, we call soArticleMediatorImpl.Method[0][1] which in turn calls either create_wnLucarioQigong_instance or create_wnLucarioAuraBall_instance.

On a side note, the reason the wnLucarioAuraBall constructor and instance generator functions are in sora_melee is because Kirby can copy Lucario's AuraBall.


There are other points of interest to this information too. When cloning modules, the places that cause difficulties in the cloning process are mainly the article constructors. Both wnLucarioQigong.ctor and wnLucarioAuraBall.ctor require a .pac_resource pointer. Cloned modules will usually try to retrieve the original's .pac_resource pointer which causes a crash if the original isn't loaded. Lucario's create_wnAuraBall_instance function also references a .pac_resource pointer. The ftLucarioExtendParamAccessor.ctor and ftClassInfoImpl<33, ftLucario>.ctor functions both statically reference the module id - both need to be changed when cloning. Fighter.base_ctor and ftFighterBuildData.base_ctor also reference the module id - when they are called in ftLucario.ctor, the passed id needs to be changed.

Finally, there some spots here and there which needs to gain access to the ftClassInfoImpl object. this is usually done by calling a specific sora_melee function and passing in the module id. One of the places that needs to call this function is near the end of ftLucario.ctor (this is the same for all characters). For Lucario's module, there are two other places which does this: ftLucario.Method[17][16] and ftLucario.Method[0][3]. I'm not sure the significance of these two functions, but their use doesn't seem to be universal.



Anyways, I think this information will prove useful not just for cloning characters, but for adding additional functionality to existing characters as well. Unfortunately, there seems to be a lot of syntax to follow in order to ensure things run nicely - but hopefully that will come with time.

[pikazz]

ooooh! nice information you got there, you need to get a promotion!
YOU'RE GETTING A PROMOTION!

okay, seriously. that's are really helpful. I will start to look at lucario's chor.

also, could you add a function in Module Editor 2.2 that can read PPC that isn't in a method? every module has those and st/FtClassInfo Method[0][1] are always loading the beginning of the Section1 = always loading 0xCC in all modules I have checked!

cause that would be very helpful! found out how objects gets "load" ingame in therody but that would be very helpful to see all the commands instead for hex

[Battleon469]

ok seriously WTF? Dr eggman said he's giving a promotion but he gets one himself???

[PhantomWings]

Yeah, sorry about the Module Editor 2.2. Unfortunately, I programmed it really poorly, so adding a function to view the whole assembly block is really more trouble than it's worth. Instead, I've been using the first version of the module editor whenever it comes to viewing standalone functions (I actually use all 3 versions for different purposes XD). Now that BlackJax has started to implement the assembly viewer in BrawlBox, I don't think continuing to work on the Module Viewer is really worth it anymore.

Anyways, here's the v1 download in case you need it:

Module Editor v1

[pikazz]

Yeah, sorry about the Module Editor 2.2. Unfortunately, I programmed it really poorly, so adding a function to view the whole assembly block is really more trouble than it's worth. Instead, I've been using the first version of the module editor whenever it comes to viewing standalone functions (I actually use all 3 versions for different purposes XD). Now that BlackJax has started to implement the assembly viewer in BrawlBox, I don't think continuing to work on the Module Viewer is really worth it anymore.

Anyways, here's the v1 download in case you need it:

Module Editor v1

oh yeah, thats true xD

but I download v1 to check out on the setup! I will be back for more information and what I did find

[SonicBrawler]

*Reads PW's Post*

It seems I read German. I have no clue what it means

Hopefully someone else understood it.

[pikazz]

*Reads PW's Post*

It seems I read German. I have no clue what it means

Hopefully someone else understood it.

russian is way harder :srs:

I kinda know what he said, but I am in the situation that are "I know how the car works and how to drive it but dont know how the engine works" scenario


sorry all for not being active in Module recently but I am pretty stuck with my other projects and my IRL :/

[SonicBrawler]

russian is way harder :srs:

I kinda know what he said, but I am in the situation that are "I know how the car works and how to drive it but dont know how the engine works" scenario

i see. I am kinda understanding sorta. okay nvmd i feel like i am reading brail

[pikazz]

I am little angry :srs:

I am planing to do a Special Throw Guide using Module files and Jigglypuff as an example
but now I can't delete the Relocation that has the ID of "1B" inside Jigglypuffs Module file!
it works on other characters but not on jigglypuff! but I know I can delete those before in jigglypuffs module file! :c but nope!

EDIT: what is this shiet! if I just do a sligtly little edit in a module file in a hex editor, I can't open it in Module Viewer 2 :c that makes me angry!

[DarkPikachu]

hey PW...
could you email me a copy of the REL structuring stuff...

I don't have the time to read it right now,
and I won't be able to read it other than Gmail when I get home...
(kinda hard when you can't view kc-mm or even google search)

I'm working on structuring a scripting system for UMC and this would really help out.
(especially with my HexEdit template, and a few other programs)

thanx.


EDIT:
actually... don't worry about it...
I can now access kc-mm through VTunnel.

thanx :)

[pikazz]

I released a guide of how to add Specials throw with Module files!
so if anyone are intresting of more how Modules works, you should check it to get little more info

http://forums.kc-mm.com/index.php?topic=49878.msg1011427#msg1011427

[DarkPikachu]

@PW: your post was extremely useful for me...

and helps me out to better see some of the inner working of ftPikachu.rel


I was already expecting alot of syntax constraints... :P
for the people who don't know:
rel files are the end result of a long and cmplex process beginning from basic C++ src files.
(the compiler works to clean the code much better than exe compilers)

I was wrong about plf files...
apparently plf files are the "dirty" compiled code...

when plf files become rel files,
they are cleaned and also contain a section that's removed when the conversion finishes.

EDIT:
could tell BJ to add an import option for the str file :P
(for the name offset in the rel header)

the only use it really serves is the creation directory... :P
but still, it's nice to have the compatibility of it's plf name...

[Dantarion]

Hello PhantomWings
http://opensa.dantarion.com/module2013/