Kitty Corp Meow Mix Forums

Super Smash Bros. Brawl Hacking => Programming => Topic started by: pikazz on May 04, 2012, 06:58:26 AM



Title: Let's look into Module Fíles (.rel) - Defensive Collision is now!
Post by: pikazz on May 04, 2012, 06:58:26 AM
hi, I made this thread so we can collect all the Module information, try to understand that and how to rebuild them.
this is a very hard task, the legends of brawlhacking Dant and Phantomwings looked into it much but they desiced to take a life-long break before they have complete it.
so lets continue their footsteps.

What is Module File?
Module Files (.rel) is there all the information is about characters, stages, menu.
it can example say how many brres one stage will load in a pac, if any event like things that can hurt you in stage load, Characters Articles like Lucarios Aura Sphere.

How much information is it about Module files?
currently not much, only Dant and Phantomwings knows it like 20 times more than us and that sadly true pretty little.
the only things we know is how they work since Phantomwings gave that's information out.
but we know there is ASM in Module Files

Module IDs
IDs:

00 - main.dol?
01 - sora_scene
02 - sora_menu_main
03 - sora_menu_tour
04 - sora_menu_qm
05 - sora_menu_edit
06 - sora_menu_collect_viewer
07 - sora_menu_replay
08 - sora_menu_snap_shot
09 - sora_menu_event
0A - sora_menu_sel_char
0B - sora_menu_sel_stage
0C - sora_menu_game_over
0D - sora_menu_intro
0E - sora_menu_friend_list
0F - sora_menu_watch
10 - sora_menu_name
11 - sora_menu_sel_char_access
12 - sora_menu_rule
13 - sora_menu_simple_ending
14 - sora_minigame
15 - sora_menu_time_result
16 - sora_menu_boot
17 - sora_menu_challenger
18 - sora_menu_title
19 - sora_menu_title_sunset
1A - sora_fig_get_demo
1B - sora_melee
1C - sora_adv_menu_name
1D - sora_adv_menu_visual
1E - sora_adv_menu_sel_char
1F - sora_adv_menu_sel_map
20 - sora_adv_menu_difficulty
21 - sora_adv_menu_game_over
22 - sora_adv_menu_result
23 - sora_adv_menu_save_load
24 - sora_adv_menu_seal
25 - sora_adv_menu_ending
26 - sora_adv_menu_telop
27 - sora_adv_menu_save_point
28 - sora_adv_stage
29 - sora_enemy
2A - st_battles
2B - st_battle
2C - st_config
2D - st_final
2E - st_dolpic
2F - st_mansion
30 - st_mariopast
31 - st_kart
32 - st_donkey
33 - st_jungle
34 - st_pirates
35 - st_oldin
36 - st_norfair
37 - st_orpheon
38 - st_crayon
39 - st_halberd
3A - st_starfox
3B - st_stadium
3C - st_tengan
3D - st_fzero
3E - st_ice
3F - st_gw
40 - st_emblem
41 - st_madein
42 - st_earth
43 - st_palutena
44 - st_famicom
45 - st_newpork
46 - st_village
47 - st_metalgear
48 - st_greenhill
49 - st_pictchat
4A - st_plankton
4B - st_dxshrine
4C - st_dxyorster
4D - st_dxgarden
4E - st_dxonett
4F - st_dxgreens
50 - st_dxrcruise
51 - st_dxbigblue
52 - st_dxcorneria
53 - st_dxpstadium
54 - st_dxzebes
55 - st_stageedit
56 - st_otrain
57 - st_heal
58 - st_homerun
59 - st_targetbreak
5A - st_croll
5B - ft_mario
5C - ft_donkey
5D - ft_link
5E - ft_samus
5F - ft_yoshi
60 - ft_kirby
61 - ft_fox
62 - ft_pikachu
63 - ft_luigi
64 - ft_captain
65 - ft_ness
66 - ft_koopa
67 - ft_peach
68 - ft_zelda
69 - ft_iceclimber
6A - ft_marth
6B - ft_gamewatch
6C - ft_falco
6D - ft_ganon
6E - ft_wario
6F - ft_metaknight
70 - ft_pit
71 - ft_pikmin
72 - ft_lucas
73 - ft_diddy
74 - ft_poke
75 - ft_dedede
76 - ft_lucario
77 - ft_ike
78 - ft_robot
79 - ft_toonlink
7A - ft_snake
7B - ft_sonic
7C - ft_purin
7D - ft_wolf
7E - ft_zako
What is ASM?
ASM stands for Assembly language
here is a wiki about ASM

http://en.wikipedia.org/wiki/Assembly_language (http://en.wikipedia.org/wiki/Assembly_language)

ASM simplies
here is a great site to see all the ASM doing like li, stw, blr ect
http://class.ee.iastate.edu/cpre211/labs/quickrefPPC.html (http://class.ee.iastate.edu/cpre211/labs/quickrefPPC.html)


Any helpful information or links?
http://forums.kc-mm.com/index.php?topic=29937.0 (http://forums.kc-mm.com/index.php?topic=29937.0) The information Phantomwhings gave us personally on how stages works.
http://opensa.dantarion.com/wiki/Patching_Charcter_Modules (http://anonym.to/?http://opensa.dantarion.com/wiki/Patching_Charcter_Modules) a helpful wiki done by Dant and that's more about Characters to "patch"

PW's Gift
he gave us a gift :3
look at his post!
sneak, snea-

...

Oh, who am I kidding.

Hi everyone, Phantom Wings here. I haven't been by for a while now so I figured I'd drop by and pay my regards to the Brawl Hacking community. I notice that there's been a little bit of interest in the workings of .rels in this here thread so:

[Download] ([url]https://www.dropbox.com/s/j7ib68nol77beho/Module%20Editor%203.zip[/url])

[Source] ([url]https://www.dropbox.com/s/819qzpwp8dxs4fz/Module%20Editor%203%20Source.zip[/url])

I had this one on the backburner before I left the last time. It's not as intuitive as the Module Editor 2, but it does support editing blocks and relocations as well as saving - hope it helps.

The app itself isn't that well put together, but the module library should be easy enough to salvage for use in BrawlBox - but as usual, don't expect any commenting in my source code.

That's all for now. See you guys around.



Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: ♤♡◇♧ on May 04, 2012, 07:46:12 AM
I suggest to also take a look at the sora_melee.rel (sora standing for 'shared object random access'), as that module is basically the main module and contains scripts for things like items (both normal items and assist trophies), stages, characters (like Lucario's Aura Sphere) and even basic things like collisions, sounds and tethers.


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: pikazz on May 04, 2012, 08:44:45 AM
I suggest to also take a look at the sora_melee.rel (sora standing for 'shared object random access'), as that module is basically the main module and contains scripts for things like items (both normal items and assist trophies), stages, characters (like Lucario's Aura Sphere) and even basic things like collisions, sounds and tethers.
I know but I haven't got into that big file yet, just on stage and characters to begin with

it looks like Modules are ASM o.o
cause it reminds me of SMW hacking ASM but way more advanced


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: Sky Grounder on May 04, 2012, 11:14:37 AM
Subbed to thread, this is interesting stuff! I can't help much though, I don't know ASM at all (if that's what's used in module files).


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: KnightMario on May 04, 2012, 02:44:43 PM
sweet.
so will I be able to do stuff like port sonic's final smash to mario?
because that would be epic.
and don't forget blackjax is working on these too.


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: Eternal Yoshi on May 04, 2012, 05:44:22 PM
I'm subbing too, though I don't know PPC ASM yet.

I want to learn how to make more generic.rel files like the one Phantom Wings made for Ike.


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: DoctorFlux(Mariodk) on May 05, 2012, 12:26:37 AM
sweet.
so will I be able to do stuff like port sonic's final smash to mario?
because that would be epic.
and don't forget blackjax is working on these too.
that will be a awesome FS for Cape mode on SMBZ mario (tried to make it before without transfrom but just with moving around/make dmg like as Super sonic but failed)


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: pikazz on May 05, 2012, 04:45:46 AM
added stuff in OP

will try to replace the bob-ombs in sudden death to pokeballs, that's my next project in modules :srs:
sweet.
so will I be able to do stuff like port sonic's final smash to mario?
because that would be epic.
and don't forget blackjax is working on these too.
yeah but we must know where to port and how to port


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: checkmate on May 05, 2012, 05:06:26 AM
The .pdf at the following link may prove useful for ASM.

http://wiird.l0nk.org/forum/index.php/topic,2844.0.html (http://wiird.l0nk.org/forum/index.php/topic,2844.0.html)

This has me interested if I can further my studies.

I hope this helps,

-checkmate


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: pikazz on May 05, 2012, 05:34:54 AM
here is a wiki page about ASM

http://en.wikipedia.org/wiki/Assembly_language (http://en.wikipedia.org/wiki/Assembly_language)

and I have found a site about "ASM simplier" code whichs Modules also using!

http://class.ee.iastate.edu/cpre211/labs/quickrefPPC.html (http://class.ee.iastate.edu/cpre211/labs/quickrefPPC.html)

The .pdf at the following link may prove useful for ASM.

[url]http://wiird.l0nk.org/forum/index.php/topic,2844.0.html[/url] ([url]http://wiird.l0nk.org/forum/index.php/topic,2844.0.html[/url])

This has me interested if I can further my studies.

I hope this helps,

-checkmate

that's great :3


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: SonicBrawler on May 05, 2012, 09:41:56 AM
yes. i support this. i have been wanting moduel files to be explored. imagine if we could make ssbb like street fighter or mortal kombat :D

plus the fact porting characters could be done easiyer if a program is made


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: ForOhFor Error on May 05, 2012, 09:45:14 AM
Of course it's in assembly, it's probably compiled C++


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: Eternal Yoshi on May 05, 2012, 09:53:19 AM
Pikazz, we don't even know which file would trigger the sudden death bombs.

Maybe start smaller by modding something that we know which file(s) to look in to?

Can we try to say, gather more data on how stage module files store and organize their hitboxes?


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: SonicBrawler on May 05, 2012, 09:57:44 AM
I'm subbing too, though I don't know PPC ASM yet.

I want to learn how to make more generic.rel files like the one Phantom Wings made for Ike.

what was the point of it? was it so that it is easyer to port ike hacks? because i can port ike hacks w/out the generic .rel adn just a reg one


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: Eternal Yoshi on May 05, 2012, 10:27:03 AM
But generic .rel ports are better overall since they have functional articles, unlike most PSA ports.


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: BlackJax96 on May 05, 2012, 10:28:56 AM
pikazz and checkmate.
dem links.
thank you :srs:


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: SonicBrawler on May 05, 2012, 10:32:56 AM
But generic .rel ports are better overall since they have functional articles, unlike most PSA ports.

oh okay.


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: ♤♡◇♧ on May 05, 2012, 10:40:38 AM
After looking into Ike module a bit more, I can see why Phantom Wings chose Ike over lets say Lucario.
Ike is one of the few that actually has all his article data in his own module, rather then having some located in the sora_melee module (making patching such character modules that much harder).


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: SonicBrawler on May 05, 2012, 10:43:53 AM
so what other characters have that besides ike? is it the ones liek marth purin and mk? or is it other ones that are not what i said?


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: pikazz on May 05, 2012, 10:55:29 AM
I'm subbing too, though I don't know PPC ASM yet.

I want to learn how to make more generic.rel files like the one Phantom Wings made for Ike.
it's easy to find the Module ID on each character Module, have found all of them everytime
but each Character ID (to articles) is a hell to find D:
Pikazz, we don't even know which file would trigger the sudden death bombs.

Maybe start smaller by modding something that we know which file(s) to look in to?

Can we try to say, gather more data on how stage module files store and organize their hitboxes?
I saw sora_melee has suddendeath so I looking in there first.
and I believe I know what I should change to pokeball

but hm, the hitboxes is a other thing :/
yes. i support this. i have been wanting moduel files to be explored. imagine if we could make ssbb like street fighter or mortal kombat :D

plus the fact porting characters could be done easiyer if a program is made
to make a program for that would be extremly hard and take alot of time :srs:


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: SonicBrawler on May 05, 2012, 11:02:05 AM
i knwo im just saying >.>


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: pikazz on May 05, 2012, 11:08:27 AM
After looking into Ike module a bit more, I can see why Phantom Wings chose Ike over lets say Lucario.
Ike is one of the few that actually has all his article data in his own module, rather then having some located in the sora_melee module (making patching such character modules that much harder).
have looked into articles in sora_melee and will scout when I see it's portable like genelic ike
pikazz and checkmate.
dem links.
thank you :srs:
indeed that link is awesome :3


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: BlackJax96 on May 05, 2012, 11:12:43 AM
plus the fact porting characters could be done easiyer if a program is made
to make a program for that would be extremly hard and take alot of time :srs:

But it is being done


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: pikazz on May 05, 2012, 11:25:13 AM
But it is being done
i see what you did there <w<


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: Shun_One on May 05, 2012, 11:54:42 AM
This thread is relevant to my interests despite not having any knowledge on how to help contribute. I'll follow the progress here any way though. I'm rooting for you guys!


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: ♤♡◇♧ on May 05, 2012, 01:02:18 PM
so what other characters have that besides ike? is it the ones liek marth purin and mk? or is it other ones that are not what i said?
Marth and Jiggz don't have articles, while MK doesn't have any special references to his article.
As far as I can tell (and don't quote me on it), characters who don't have article data in sora_melee.rel are Sonic, C. Falcon, Olimar, Wario (shares his module with Warioman), Ganondorf and DK.


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: Eternal Yoshi on May 05, 2012, 01:06:02 PM
umm.... this is awkward...

I have IDA pro, and not much knowledge on how to use it to open.rel files.

What settings should I use to import .rel files?


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: pikazz on May 05, 2012, 03:28:50 PM
Marth and Jiggz don't have articles, while MK doesn't have any special references to his article.
As far as I can tell (and don't quote me on it), characters who don't have article data in sora_melee.rel are Sonic, C. Falcon, Olimar, Wario (shares his module with Warioman), Ganondorf and DK.
that's great info :3
I will look into them and see if I can find "character ID" switching which is need to generic character''

Btw, I believe I have found something in modules o.o
but I will not tell you until I have test it, I really hope it works

also, I mailed PhantomWings about this thread and I hope he can leave us some notes about modules or a response :3
I would be happy if he answer!

Post Merge: May 06, 2012, 07:23:35 AM
gah! I feeling miseble ;_;

I can't get my rel to work, not even PW's generic Ike and I am very positive and sure how to make ganon generic.
but I would like some help to test from anyone who have succeesed with PW's generic ike :/
like you ds22!
can you help me with my generic ganon? wanna test it?


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: ♤♡◇♧ on May 06, 2012, 09:47:11 AM
I could test it, but you have to know this beforehand.
Creating a generic module may seem easy, but you need to edit A LOT of offsets in the module due to adding those few lines of ASM.


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: pikazz on May 06, 2012, 10:10:16 AM
I could test it, but you have to know this beforehand.
Creating a generic module may seem easy, but you need to edit A LOT of offsets in the module due to adding those few lines of ASM.
I know that :P
if you add just one byte, you have to change all the offset and string offset to correct those. that's why I just replacing for now with same amount byte that I took away

I will send you a NTCS-U changed Ganon.rel for test and I will give you what offset you must change if the character I suggest didn't work


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: Carnage on May 06, 2012, 10:23:41 AM
if someone makes out how the ike generic rel worked any chance of a pal one?


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: pikazz on May 06, 2012, 10:29:47 AM
if someone makes out how the ike generic rel worked any chance of a pal one?
it's easy to make generic ike for pal since I am using it.

but it looks like my codes or riivolution doesn't like rel D:
dont know where to put it and what codes I should have or only riivolution ect.


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: Carnage on May 06, 2012, 10:32:57 AM
it's easy to make generic for pal since I am using it.

but it looks like my codes or riivolution doesn't like rel D:
dont know where to put it and what codes I should have or only riivolution ect.
really you have a generic ike rel? send it to me i can test it :P


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: JCentavo on May 06, 2012, 03:45:37 PM
http://opensa.dantarion.com/wiki/Clone_Engine_Example_Codes (http://anonym.to/?http://opensa.dantarion.com/wiki/Clone_Engine_Example_Codes)
Want to remind people of that thing about adding more characters in without having to replace.
Sorry I can't really contribute because I haven't really bothered trying to look into .rels more. Most of my info I collected is pretty much already here anyway.


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: pikazz on May 07, 2012, 05:41:19 AM
I did a kinda generic ike for pal.
but it's funny and incomplete. the problem is in pal ike rel, it's alot harder to find the Character ID to his sword artcle D:
so I did a test

made it over marth with the pal ike, put every ike pacs in marth's folder and put ft_ike (renamed to ft_marth) in modules.

but ingame, marths want to use ikes PSA only up to 50%, you hear ikes sound effects but at the same time marths.
his Side B is a paradoxs of Ikes, if you hit the B buttom one-two times after the first time you can teleport at the same distance ike would have trawel o.o
his final smash is marths, but he is freeze in one place (looping animation) and hitting a buttom will make him hit the opponent before him o.o

also, shielding with your counter will make the wii freeze D:

EDIT: ignore what I wrote. I got an nealy perfect PAL generic ike over marth.
he can do anything exactly like a ike can do
only problem left: the wii freeze if you pick someone else and when marth, ike must be loaded before marth. if ike is not loaded, the wii will freeze

why make a new generic ike? cause the pal needs some love too :srs:
or has pal generic ike been done aleady?


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: Carnage on May 07, 2012, 05:57:46 AM
I did a kinda generic ike for pal.
but it's funny and incomplete. the problem is in pal ike rel, it's alot harder to find the Character ID to his sword artcle D:
so I did a test

made it over marth with the pal ike, put every ike pacs in marth's folder and put ft_ike (renamed to ft_marth) in modules.

but ingame, marths want to use ikes PSA only up to 50%, you hear ikes sound effects but at the same time marths.
his Side B is a paradoxs of Ikes, if you hit the B buttom one-two times after the first time you can teleport at the same distance ike would have trawel o.o
his final smash is marths, but he is freeze in one place (looping animation) and hitting a buttom will make him hit the opponent before him o.o

also, shielding with your counter will make the wii freeze D:

EDIT: ignore what I wrote. I got an nealy perfect PAL generic ike over marth.
he can do anything exactly like a ike can do
only problem left: the wii freeze if you pick someone else and when marth, ike must be loaded before marth. if ike is not loaded, the wii will freeze

why make a new generic ike? cause the pal needs some love too :srs:
or has pal generic ike been done aleady?
no pal users can only port MK , jiggly and marth by rel :S but you should try making a pal ike rel over someone like DDD so ppl actually can use direct rel xD


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: DarkPikachu on May 07, 2012, 08:53:47 AM
the RVL_SDK describes relocatable modules (REL's) as being written in C++ as PLF files.
these are pre-compiled with the ELF to get the DOL and REL's.

what I intend to do once figuring these out is to seperate the common data used by the characters.

what I mean is I could give DP his dark-green thunder, while giving Pachi an anime-blue-ish thunder.


along with managing RAM memory more efficiently.
(unloading and loading data at the proper times)

shoot...
maybe I could even create a file on an SD/USB and use that as extended RAM
(IK this will slow it down as RAM is direct bit access where SD/USB is indexed)
but you should be able to load larger data sizes ;)


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: KnightMario on May 07, 2012, 08:56:08 AM
do you have RVL_SDK?
if you do, is it gotten legaly? (probably not...)


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: DarkPikachu on May 07, 2012, 09:38:03 AM
do you have RVL_SDK?
if you do, is it gotten legaly? (probably not...)
lol why's that matter??
of course I have it XDD
both 2.1 and the latest release (2.1 was the brawl release)

if you want it, I can't send it to you with the current compy as I'd have to DL it...
but I'm sure you can find a torrent or something ;)
(2.1 is a pain to find) D=


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: KnightMario on May 07, 2012, 02:54:58 PM
true, we are hacking right now XD
my computer gets weird with torrent programs (windows sucks x 7)


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: SonicBrawler on May 07, 2012, 06:39:12 PM
more ram? what can that do? increase file size limits?


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: KnightMario on May 07, 2012, 06:41:17 PM
increasing filesize limits is dumb, unless you have more ram like you said.


Title: Re: Let's look into Module Fíles (.rel) and parche it
Post by: pikazz on May 08, 2012, 03:00:41 AM
I FOUND OUT SOMETHING ON NORFAIR REL!

I made so the lava at the bottom deals 40 damage instead for 14 and you get launch diagonally Down-Right instead for straight up! :D

EDIT: now I know how to the edit magma (the magma that rises from the bottom):
Damage
Direction
Weight Knockback (?) (untested and dont know what Weight Knockback does)
Knockback Growth

currently I looking for the bones attachment to collusion, the flags and it's refresh rate :srs:
want to make the magma will freeze you instead or adding you 1-2 damage each half-second with "no-flinch" flag if you are in it

and now I have found the magma walls damage :D
but both of the walls sharing the same value so you can't make one of them does 8 and the other one does 20 :/

just the Magma Wave left to find :3 (the wave you must enter the safity zone or shield against)
when I need to find the rest of the attack (flags, directions, refresh rate ect)

I also found a bres and mdl0 note in Sora_melee o-o
and all the character in Caps too but I didn't take a pic of it :oshi:


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: KnightMario on May 08, 2012, 05:51:20 AM
nice


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: Sky Grounder on May 08, 2012, 08:16:35 AM
That's great! Also pikazz, you said the module files are coded in ASM, is it possible to already start parsing these files without doing something else with these files?


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: pikazz on May 08, 2012, 08:43:04 AM
That's great! Also pikazz, you said the module files are coded in ASM, is it possible to already start parsing these files without doing something else with these files?
I dont know what to say to that :srs:
yes but extremly difficult since you have to know what the things are, what offset it is or linked to.


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: Carnage on May 08, 2012, 12:19:40 PM
I FOUND OUT SOMETHING ON NORFAIR REL!

I made so the lava at the bottom deals 40 damage instead for 14 and you get launch diagonally Down-Right instead for straight up! :D

EDIT: now I know how to the edit magma (the magma that rises from the bottom):
Damage
Direction
Weight Knockback (?) (untested and dont know what Weight Knockback does)
Knockback Growth

currently I looking for the bones attachment to collusion, the flags and it's refresh rate :srs:
want to make the magma will freeze you instead or adding you 1-2 damage each half-second with "no-flinch" flag if you are in it

and now I have found the magma walls damage :D
but both of the walls sharing the same value so you can't make one of them does 8 and the other one does 20 :/

just the Magma Wave left to find :3 (the wave you must enter the safity zone or shield against)
when I need to find the rest of the attack (flags, directions, refresh rate ect)

I also found a bres and mdl0 note in Sora_melee o-o
and all the character in Caps too but I didn't take a pic of it :oshi:
if you find a way to change the bone index and size of the hitbox and flag  ppl can atleast make stage with collisions  on stages that already harms you like norfair :P

an interesting one would be mario bros to find out how the enemies collisions work and how to change them :P


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: Eternal Yoshi on May 08, 2012, 04:09:16 PM
Very nice Pikazz that you got to this point.

Unfortunately, AA beat you to the punch.

In the meantime, can you find out if the hitboxes use PSA style commands in the .rel?

Any extra info you find WILL be added to my thread.


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: pikazz on May 08, 2012, 10:37:35 PM
Very nice Pikazz that you got to this point.

Unfortunately, AA beat you to the punch.

In the meantime, can you find out if the hitboxes use PSA style commands in the .rel?

Any extra info you find WILL be added to my thread.
AmazingAmpharos? o.o did he found this already?

it doesn't look like hitboxes used PSA D:
but I might have wrong, let me look more deeply


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: SonicBrawler on May 26, 2012, 03:28:48 PM
Sora_Melee.rel (http://www.youtube.com/watch?v=lgJPn_-ytOM#ws)


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: Sky Grounder on May 26, 2012, 04:46:38 PM
Sora_Melee.rel ([url]http://www.youtube.com/watch?v=lgJPn_-ytOM#ws[/url])
The names are probably just references in the file. It's the coding we have to figure out.


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: Eternal Yoshi on May 26, 2012, 04:47:58 PM
Yup. Viewing it in the Module Viewer 2.1 helps though, as it separates and organizes things in a more readable format.


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: SonicBrawler on May 26, 2012, 04:49:58 PM
oh okay. i thought it was teh naem at the end after a fight, so i tried chanign lucairo to mewtwo, so that isnt it.

Yup. Viewing it in the Module Viewer 2.1 helps though, as it separates and organizes things in a more readable format.

oh okay. i'll take a look

edit: is anyoen able to open sora_melee in the MV 2.1?


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: SomeKindOfMetroid on May 26, 2012, 05:38:27 PM
oh okay. i thought it was teh naem at the end after a fight, so i tried chanign lucairo to mewtwo, so that isnt it.
Those are in main.dol. They're one of the two instances where the names are First Caps, with the other being the names that show up in Records.


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: Eternal Yoshi on May 26, 2012, 06:17:26 PM
oh okay. i thought it was teh naem at the end after a fight, so i tried chanign lucairo to mewtwo, so that isnt it.

oh okay. i'll take a look

edit: is anyoen able to open sora_melee in the MV 2.1?

I am.

It takes a while to open though.


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: ♤♡◇♧ on May 26, 2012, 08:49:17 PM
Sora_Melee.rel ([url]http://www.youtube.com/watch?v=lgJPn_-ytOM#ws[/url])

Funny thing is, I already wrote about that MarioD reference a few months back: http://tcrf.net/Super_Smash_Bros._Brawl#References_to_debug_characters (http://tcrf.net/Super_Smash_Bros._Brawl#References_to_debug_characters)
It doesn't have anything pointing to it though.

And about the list of character names, those are just the instant slot names of all the playable characters (including the forbidden 7), using the Japanese name listing (I.E. Koopa being Bowser's name in Japan).


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: SonicBrawler on May 27, 2012, 05:23:56 AM
I am.

It takes a while to open though.


oh okay, cuz when i try to open it, it crashes :/

Funny thing is, I already wrote about that MarioD reference a few months back: [url]http://tcrf.net/Super_Smash_Bros._Brawl#References_to_debug_characters[/url] ([url]http://tcrf.net/Super_Smash_Bros._Brawl#References_to_debug_characters[/url])
It doesn't have anything pointing to it though.

And about the list of character names, those are just the instant slot names of all the playable characters (including the forbidden 7), using the Japanese name listing (I.E. Koopa being Bowser's name in Japan).



oh okay. THAT makes sence


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: Eternal Yoshi on May 27, 2012, 06:38:22 AM
oh okay, cuz when i try to open it, it crashes :/


blah blah blah .NET Framework 4.0 blah blah blah


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: pikazz on May 27, 2012, 11:57:17 AM
trying to look how the collusions are exactly stored.
so we can change the collusion to a grab or an other collusion or null it

believe it's the same way it are stored like in SMW.

first it load a offset, I take example the mario status
when we store some value in it example 00 = small, 01= big ect.
like a old CD player

it's pretty old anddont know how much asm have evolution D:
but its better than nothing :srs:


Title: Re: Let's look into Module Fíles (.rel) and parche it - some discoveries of Norfair
Post by: SomeKindOfMetroid on May 27, 2012, 02:55:37 PM
trying to look how the collusions are exactly stored.
Laughed at the bold.


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: pikazz on July 12, 2012, 12:01:26 PM
I hope I dont have to recreate this thread once again for it's inactivity

but I am One step closer for rebuildable REL, it's a pretty tiny but I know where the link between everything is.

why it's a tiny step is because I dont know HOW it works or if it are MORE place the "string"/link between everything is but a small step is a small step.

also, I have written down the header which was the easy part of the module


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: SonicBrawler on July 12, 2012, 12:22:47 PM
I hope I dont have to recreate this thread once again for it's inactivity

but I am One step closer for rebuildable REL, it's a pretty tiny but I know where the link between everything is.

why it's a tiny step is because I dont know HOW it works or if it are MORE place the "string"/link between everything is but a small step is a small step.

also, I have written down the header which was the easy part of the module

yes! epic!


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: pikazz on July 12, 2012, 12:24:59 PM
I didn't know this tread existed. I'm looking forward to see what can be brought out of this.

Which rebuildable rel your working on btw?
Right now, I am using Both Final Destination and Wifi Waiting stage cause those 2 are the shortest of all REL to understand how a REL file is build so we can rebuild in the future.

also, I did this thread to help BJ96 with Brawlbox when it comes to rebuilding Module Files like PSA or Moveset so we can easy edit it ourself and save it ect.
someone had to start doing this and I took that job :srs:


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Sky Grounder on July 12, 2012, 12:38:29 PM
I hope I dont have to recreate this thread once again for it's inactivity

but I am One step closer for rebuildable REL, it's a pretty tiny but I know where the link between everything is.

why it's a tiny step is because I dont know HOW it works or if it are MORE place the "string"/link between everything is but a small step is a small step.

also, I have written down the header which was the easy part of the module
Mind sharing your notes with us?
Also, I think it would be an idea to look at Battlefield aswell, as the most noticeable difference between BF and FD/WWR is the number of brres indexes, I think


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: pikazz on July 12, 2012, 12:47:42 PM
Mind sharing your notes with us?
Also, I think it would be an idea to look at Battlefield aswell, as the most noticeable difference between BF and FD/WWR is the number of brres indexes, I think
well, the notes are already done by PW and BJ96 since PW made module editor and BJ96 knows that stuff already so I did job that those already done.
and that's just the header D:

also, I trying to understand the "skeleton" of the Module, not the flesh.
the skeleton has every module file and they are build in same way and the other so knowing the skeleton will make rebuilding much easier.
skeleton has the "link" between everything, where everything should be, how it's suppose to be ect while flesh is like you said "how BRRES should be loaded" or "This Brres will have attack collusion or extra animation" or "articles" between the skeleton.

the way I did with PAT0 parshing 1-2 years ago


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Sky Grounder on July 12, 2012, 12:51:51 PM
Well I get a feeling that module files can contain a bit of PSA in it's "flesh". But you're right, it's the main thing we need to focus on.

Wait, you did PAT0 when Bero was around??


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: pikazz on July 12, 2012, 01:03:23 PM
Well I get a feeling that module files can contain a bit of PSA in it's "flesh". But you're right, it's the main thing we need to focus on.

Wait, you did PAT0 when Bero was around??

yeah, I was the first how did PAT0 hacks, I also write down in offset there everything where and that stuff.
sadly Smashboard has taken away that "part" D:
hope someone remembers it

everyone went "oooh! I want that hack" when I released this pics in Smashboards
(http://i45.tinypic.com/5373p5.jpg)
(http://i45.tinypic.com/11ukzz5.jpg)
(http://i46.tinypic.com/24ccysx.jpg)
hoppip say hiii (http://www.youtube.com/watch?v=MggtfYr_gwo#)

and yes, I did do PAT0 when Bero was around if I remember correctly


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Diddy Kong on July 12, 2012, 05:20:20 PM
I found rels in common3.pac


if we can get this rel hacking on it's full feet, maybe item behavior hacks can be possible


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: pikazz on July 12, 2012, 05:28:12 PM
I found rels in common3.pac


if we can get this rel hacking on it's full feet, maybe item behavior hacks can be possible
that was something I didn't know o.o awesome!


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: DSX8 on July 12, 2012, 05:52:36 PM
.rel's in common3? :o   wow

i wonder wats in common2 and 4 then... O.o


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Sky Grounder on July 12, 2012, 06:15:05 PM
I found rels in common3.pac


if we can get this rel hacking on it's full feet, maybe item behavior hacks can be possible
You're right. MiscData[11] has SSS properties!
MiscData[12] I think is rule menu module?
MiscData[13] is CSS module
MiscData[14] doesn't have any names but mo_menu.cpp, a pretty short module.
MiscData[15] seems to be another CSS module.

Other stuff: MiscData[0] has Trophy datalist.
Miscdata[9] and MiscData[10] is font files (compressed, although BB doesn't show it.)

.rel's in common3? :o   wow

i wonder wats in common2 and 4 then... O.o
Common2 also has modules, along with Solo mode data such as all-star mode, classic and event matches. But common4 does only have movesets.

Seriously Diddy, nice find!!

Now, why haven't I noticed this before? :srs:


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: DSX8 on July 12, 2012, 06:28:02 PM
You're right. MiscData[11] has SSS properties!
MiscData[12] I think is rule menu module?
MiscData[13] is CSS module
MiscData[14] doesn't have any names but mo_menu.cpp, a pretty short module.
MiscData[15] seems to be another CSS module.

Other stuff: MiscData[0] has Trophy datalist.
Miscdata[9] and MiscData[10] is font files (compressed, although BB doesn't show it.)
Common2 also has modules, along with Solo mode data such as all-star mode, classic and event matches. But common4 does only have movesets.

Seriously Diddy, nice find!!

Now, why haven't I noticed this before? :srs:
oh ur totally right bout the Common2... i just remembered that libertyernie made a program that lets u edit the Classic Mode, All-Star mode and Event matches.. xD


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: BlackJax96 on July 12, 2012, 06:37:28 PM
Oh hey, there are modules in there.

...I also noticed that unknown entries export with the REL extension... lol bug


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Sky Grounder on July 12, 2012, 06:51:28 PM
Oh hey, there are modules in there.

...I also noticed that unknown entries export with the REL extension... lol bug
Yeah I noticed it too. Also BB didn't recognize that the font files had compression.


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: pikazz on July 13, 2012, 10:07:40 AM
looked into those by myself in hex.

it doesn't look like rel o.o, more like PSA related things in the "_item_params" and the miscData[24] looks like the names to all the thophys while miscData[9] is compressed o.o


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: ASF1nk on July 18, 2012, 06:19:49 PM
Common3.pac
MiscData[0]  = Trophies???
MiscData[9]  = font_latin1.arc
MiscData[10] = font_latin12.arc
MiscData[11] = sora_menu_sel_stage.rel
MiscData[12] = sora_menu_rule.rel
MiscData[13] = sora_menu_sel_char.rel
MiscData[14] = sora_menu_sel_char_access.rel
MiscData[15] = sora_menu_name.rel

The rels are exactly like the ones in the module folder.

Edit: I see MiscData[9] and [10] have been stated to be font files before. :P
Edit2: I found the referenced files. system/font


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Sky Grounder on July 18, 2012, 06:42:23 PM
Common3.pac
MiscData[0]  = Trophies???
MiscData[9]  = font_latin1.arc
MiscData[10] = font_latin12.arc
MiscData[11] = sora_menu_sel_stage.rel
MiscData[12] = sora_menu_rule.rel
MiscData[13] = sora_menu_sel_char.rel
MiscData[14] = sora_menu_sel_char_access.rel
MiscData[15] = sora_menu_name.rel

The rels are exactly like the ones in the module folder.

Edit: I see MiscData[9] and [10] have been stated to be font files before. :P
Edit2: I found the referenced files. system/font
Makes me wonder why there's multiple of the same file... :srs:


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: BlackJax96 on July 18, 2012, 06:57:49 PM
Wow, Fighter.pac is also in Common3. :srs:
It's MiscData[0] under Fighter.


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Sky Grounder on July 19, 2012, 05:23:03 AM
But does Brawl use both of the same files, or just one of them? If so, which?


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: DSX8 on July 19, 2012, 05:30:09 AM
But does Brawl use both of the same files, or just one of them? If so, which?
im guessing it reads from the common3.pac file.. and it tells it to load it from the other file? im not even sure xD

its like with the Common5.. the Sc_SelCharacter and the Sc_SelMap over-rides the Common5.pac file, so it has to be the help of a .rel file..


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Sky Grounder on July 19, 2012, 05:39:10 AM
im guessing it reads from the common3.pac file.. and it tells it to load it from the other file? im not even sure xD

its like with the Common5.. the Sc_SelCharacter and the Sc_SelMap over-rides the Common5.pac file, so it has to be the help of a .rel file..
That doesn't really make sense >.>

Also, I think sora_scene.rel is the one mainly used for switching between module files, or atleast the menu ones.


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: pikazz on July 19, 2012, 10:45:20 AM
Common3.pac
MiscData[0]  = Trophies???
MiscData[9]  = font_latin1.arc
MiscData[10] = font_latin12.arc
MiscData[11] = sora_menu_sel_stage.rel
MiscData[12] = sora_menu_rule.rel
MiscData[13] = sora_menu_sel_char.rel
MiscData[14] = sora_menu_sel_char_access.rel
MiscData[15] = sora_menu_name.rel

The rels are exactly like the ones in the module folder.

Edit: I see MiscData[9] and [10] have been stated to be font files before. :P
Edit2: I found the referenced files. system/font
hm, I wanna see more in [11] and [12]
and the fighter rel too!


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Carnage on July 19, 2012, 11:52:18 AM
pikazz did you ever finish making the pal ike rel? i really wanted to port some ike movesets around on my pal ssbb xD


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: pikazz on July 19, 2012, 01:13:06 PM
pikazz did you ever finish making the pal ike rel? i really wanted to port some ike movesets around on my pal ssbb xD
nah, it didn't work :srs:


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Carnage on July 19, 2012, 02:00:57 PM
nah, it didn't work :srs:
guess no pal rels then :S


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: PhantomWings on July 25, 2012, 05:36:49 PM
sneak, snea-

...

Oh, who am I kidding.

Hi everyone, Phantom Wings here. I haven't been by for a while now so I figured I'd drop by and pay my regards to the Brawl Hacking community. I notice that there's been a little bit of interest in the workings of .rels in this here thread so:

[Download] (https://www.dropbox.com/s/j7ib68nol77beho/Module%20Editor%203.zip)

[Source] (https://www.dropbox.com/s/819qzpwp8dxs4fz/Module%20Editor%203%20Source.zip)

I had this one on the backburner before I left the last time. It's not as intuitive as the Module Editor 2, but it does support editing blocks and relocations as well as saving - hope it helps.

The app itself isn't that well put together, but the module library should be easy enough to salvage for use in BrawlBox - but as usual, don't expect any commenting in my source code.

That's all for now. See you guys around.


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Eternal Yoshi on July 25, 2012, 05:40:15 PM
Thank you for this gift.


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Diddy Kong on July 25, 2012, 05:42:44 PM
sneak, snea-

...

Oh, who am I kidding.

Hi everyone, Phantom Wings here. I haven't been by for a while now so I figured I'd drop by and pay my regards to the Brawl Hacking community. I notice that there's been a little bit of interest in the workings of .rels in this here thread so:

[Download] ([url]https://www.dropbox.com/s/j7ib68nol77beho/Module%20Editor%203.zip[/url])

[Source] ([url]https://www.dropbox.com/s/819qzpwp8dxs4fz/Module%20Editor%203%20Source.zip[/url])

I had this one on the backburner before I left the last time. It's not as intuitive as the Module Editor 2, but it does support editing blocks and relocations as well as saving - hope it helps.

The app itself isn't that well put together, but the module library should be easy enough to salvage for use in BrawlBox - but as usual, don't expect any commenting in my source code.

That's all for now. See you guys around.
we can now potentially see evolution in KICK ASSness with the rel deal being further broken into :)

Diddy Kong Racing ST - Boss Door Unlocked (http://www.youtube.com/watch?v=MKAeP33bJ1o#ws)

music plays as we enter the next big thing of brawl hacking :P


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: BlackJax96 on July 25, 2012, 05:44:13 PM
(http://alltheragefaces.com/img/faces/large/surprised-gasp-l.png)

Hey PW.

I'll work on adding it to Brawlbox soon, no need for comments.
Although they are nice to read

Thank you for this gift.


^


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: the98pika on July 25, 2012, 05:50:47 PM
Oh awesome can't wait to see what brawl hacking can turn into with this :D!


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: pikazz on July 25, 2012, 05:51:26 PM
sneak, snea-

...

Oh, who am I kidding.

Hi everyone, Phantom Wings here. I haven't been by for a while now so I figured I'd drop by and pay my regards to the Brawl Hacking community. I notice that there's been a little bit of interest in the workings of .rels in this here thread so:

[Download] (https://www.dropbox.com/s/j7ib68nol77beho/Module%20Editor%203.zip)

[Source] (https://www.dropbox.com/s/819qzpwp8dxs4fz/Module%20Editor%203%20Source.zip)

I had this one on the backburner before I left the last time. It's not as intuitive as the Module Editor 2, but it does support editing blocks and relocations as well as saving - hope it helps.

The app itself isn't that well put together, but the module library should be easy enough to salvage for use in BrawlBox - but as usual, don't expect any commenting in my source code.

That's all for now. See you guys around.
oooh! PW you came! 83

and awesome with Module editor 3 >w<
also, I need to ask you! do you know something about how the Relocation are linked to Objects and Assembly?

and do you possible know exactly how NameOffset, PrologOffset, EpilogOffset and Unresolved Offset are linked? I just dont find it out how D:

A huge thanks for the gift :D


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Sky Grounder on July 25, 2012, 07:43:01 PM
oooh! PW you came! 83

and awesome with Module editor 3 >w<
also, I need to ask you! do you know something about how the Relocation are linked to Objects and Assembly?

and do you possible know exactly how NameOffset, PrologOffset, EpilogOffset and Unresolved Offset are linked? I just dont find it out how D:

A huge thanks for the gift :D
Just reminding you that when PW arrives, he usually immediately dissappears after making a post D:


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Shinobu Nyan! on July 25, 2012, 08:38:10 PM
Just reminding you that when PW arrives, he usually immediately dissappears after making a post D:
Lol, so true.


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: PhantomWings on July 25, 2012, 11:17:49 PM
oooh! PW you came! 83

and awesome with Module editor 3 >w<
also, I need to ask you! do you know something about how the Relocation are linked to Objects and Assembly?

and do you possible know exactly how NameOffset, PrologOffset, EpilogOffset and Unresolved Offset are linked? I just dont find it out how D:

A huge thanks for the gift :D

Hmm, a lot of questions here. I guess I'll start from the beginning.

When the module is first loaded into memory, the first thing the game does is call a function on it that links the module to each of the other modules loaded into memory. In the Revolution SDK, this function is called OSLink. When called on a module, it resolves all relocations inside the module and checks all existing modules for dependencies on it resolving them in the process.

I won't go into too much detail on how the relocations are stored as you can find that in the Module Viewer 3 Source code, but one important thing to know is the relocation types:

Code:

Value = SectionOffset + Addend

0x00 nop
0x01 Write Word ( target u32 = Value )
0x02 Set Long Branch Offset ( target u32 = (target u32 & ~0x03FFFFFC) | (Addend & 0x03FFFFFC) )
0x03 Write Lower Half ( target u16 = Value & 0xFFFF )
0x04 == 0x03
0x05 Write Upper Half ( target u16 = (Value >> 16) & 0xFFFF )
0x06 == 0x05
0x07 Set Short Branch Offset ( target u32 = (target u32 & ~0xFFFC) | (Addend & 0xFFFC) )
0x08 == 0x07
0x09 == 0x07
0x0A Set Long Branch Destination ( target long branch destination = Addend )
0x0B Set Short Branch Destination ( target short branch destination = Addend )
0x0C == 0x0B
0x0D == 0x0B


Once the module is linked, the _prolog function may be optionally called. In Brawl, the _prolog function is always called. The assembly code for the _prolog function can be found by going to the PrologOffset inside the section specified by PrologSection (the PrologSection is almost always the Section[1]). When called, it invokes the constructor for each of the top level objects inside the module. The pointers to these constructor functions are usually found in Section[2] of the module.

Objects exist in multiple parts. All object declarations, inheritance values and  virtual function tables are usually stored in Section[5]. There isn't a whole lot of organization to the data, but there are a few basic structures that can be found if you know what to look for:

Code:

(because all pointers only exist once the module has been linked, you won't be able to see these values inside a regular hex viewer.
 They can be found using the Module Viewer 3's memory viewer though)

Declaration (8 bytes)
0x00 Name ptr
0x04 Inheritance[] ptr

Inheritance (8 bytes)
0x00 Declaration ptr
0x04 Unknown

Virtual Function Table (8 bytes + 4 * numFunctions)
0x00 Declaration ptr
0x04 Blank
0x08 Function[0] ptr
0x__ Function[...] ptr


Because everything is so unorganized, the only way you can really parse this section is if you use a code crawler like the Module Viewer 2 used. For the time being, Module Viewer 3 supports simple tagging, but hopefully there'll be a way to automate the process soon.

As for the actual objects themselves; they are created by the constructor functions into the Bss Memory which in turn is created at runtime. The Bss Memory is accessed like the rest of the module sections and is usually found at Section[6] - while you can open it in the memory viewer, the actual section doesn't exist in the module and is only created at runtime.


Beyond that, the _epilog function does the opposite of the _prolog function and is called right before the module is unlinked (The destructor function pointers are found in Section[3]). As for the _unresolved function; all external functions calls in the module are initially directed towards this function. That way, if a function doesn't get linked, the _unresolved function is called instead. For the most part, it does something along the lines of throwing an exception while reporting the module's source file (e.g. mo_fighter.cpp)



That's about as much as I know about the module files - the rest of it you already posted in the link in the opening post.

I'll be around, so if you have any other questions, go ahead and ask away.


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: pikazz on July 26, 2012, 12:04:00 AM
Hmm, a lot of questions here. I guess I'll start from the beginning.

When the module is first loaded into memory, the first thing the game does is call a function on it that links the module to each of the other modules loaded into memory. In the Revolution SDK, this function is called OSLink. When called on a module, it resolves all relocations inside the module and checks all existing modules for dependencies on it resolving them in the process.

I won't go into too much detail on how the relocations are stored as you can find that in the Module Viewer 3 Source code, but one important thing to know is the relocation types:

Code:

Value = SectionOffset + Addend

0x00 nop
0x01 Write Word ( target u32 = Value )
0x02 Set Long Branch Offset ( target u32 = (target u32 & ~0x03FFFFFC) | (Addend & 0x03FFFFFC) )
0x03 Write Lower Half ( target u16 = Value & 0xFFFF )
0x04 == 0x03
0x05 Write Upper Half ( target u16 = (Value >> 16) & 0xFFFF )
0x06 == 0x05
0x07 Set Short Branch Offset ( target u32 = (target u32 & ~0xFFFC) | (Addend & 0xFFFC) )
0x08 == 0x07
0x09 == 0x07
0x0A Set Long Branch Destination ( target long branch destination = Addend )
0x0B Set Short Branch Destination ( target short branch destination = Addend )
0x0C == 0x0B
0x0D == 0x0B


Once the module is linked, the _prolog function may be optionally called. In Brawl, the _prolog function is always called. The assembly code for the _prolog function can be found by going to the PrologOffset inside the section specified by PrologSection (the PrologSection is almost always the Section[1]). When called, it invokes the constructor for each of the top level objects inside the module. The pointers to these constructor functions are usually found in Section[2] of the module.

Objects exist in multiple parts. All object declarations, inheritance values and  virtual function tables are usually stored in Section[5]. There isn't a whole lot of organization to the data, but there are a few basic structures that can be found if you know what to look for:

Code:

(because all pointers only exist once the module has been linked, you won't be able to see these values inside a regular hex viewer.
 They can be found using the Module Viewer 3's memory viewer though)

Declaration (8 bytes)
0x00 Name ptr
0x04 Inheritance[] ptr

Inheritance (8 bytes)
0x00 Declaration ptr
0x04 Unknown

Virtual Function Table (8 bytes + 4 * numFunctions)
0x00 Declaration ptr
0x04 Blank
0x08 Function[0] ptr
0x__ Function[...] ptr


Because everything is so unorganized, the only way you can really parse this section is if you use a code crawler like the Module Viewer 2 used. For the time being, Module Viewer 3 supports simple tagging, but hopefully there'll be a way to automate the process soon.

As for the actual objects themselves; they are created by the constructor functions into the Bss Memory which in turn is created at runtime. The Bss Memory is accessed like the rest of the module sections and is usually found at Section[6] - while you can open it in the memory viewer, the actual section doesn't exist in the module and is only created at runtime.


Beyond that, the _epilog function does the opposite of the _prolog function and is called right before the module is unlinked (The destructor function pointers are found in Section[3]). As for the _unresolved function; all external functions calls in the module are initially directed towards this function. That way, if a function doesn't get linked, the _unresolved function is called instead. For the most part, it does something along the lines of throwing an exception while reporting the module's source file (e.g. mo_fighter.cpp)



That's about as much as I know about the module files - the rest of it you already posted in the link in the opening post.

I'll be around, so if you have any other questions, go ahead and ask away.

wow! I am amazed, you actually answer my question and now I am happy :happy:
and that information will be excellent help! I understand more about Epilog, Prolog, Bssoffsets and more about Relocation section thanks to you :3
I appreciate your help! x3

but there is one thing that still bugs me, about nameOffset.
often when it is a Offset, it's most of the time 4-8 hex big and often ends on either 0-4-8-C but the nameOffset ends on almost every single hex that are known (0-F), mostly 6 and 1 :srs:
are they stored/load/created at the same way the Bss Memory are created in runtime?

planing to write completely a whole new Module file from scratch to understand more about it's struckture :kdance:

Just reminding you that when PW arrives, he usually immediately dissappears after making a post D:
not this time :3


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Sky Grounder on July 26, 2012, 07:54:46 AM
I took the liberty to write down all the IDs in the module files using the module editor, in case it could be useful (for references):
IDs:

00 - main.dol?
01 - sora_scene
02 - sora_menu_main
03 - sora_menu_tour
04 - sora_menu_qm
05 - sora_menu_edit
06 - sora_menu_collect_viewer
07 - sora_menu_replay
08 - sora_menu_snap_shot
09 - sora_menu_event
0A - sora_menu_sel_char
0B - sora_menu_sel_stage
0C - sora_menu_game_over
0D - sora_menu_intro
0E - sora_menu_friend_list
0F - sora_menu_watch
10 - sora_menu_name
11 - sora_menu_sel_char_access
12 - sora_menu_rule
13 - sora_menu_simple_ending
14 - sora_minigame
15 - sora_menu_time_result
16 - sora_menu_boot
17 - sora_menu_challenger
18 - sora_menu_title
19 - sora_menu_title_sunset
1A - sora_fig_get_demo
1B - sora_melee
1C - sora_adv_menu_name
1D - sora_adv_menu_visual
1E - sora_adv_menu_sel_char
1F - sora_adv_menu_sel_map
20 - sora_adv_menu_difficulty
21 - sora_adv_menu_game_over
22 - sora_adv_menu_result
23 - sora_adv_menu_save_load
24 - sora_adv_menu_seal
25 - sora_adv_menu_ending
26 - sora_adv_menu_telop
27 - sora_adv_menu_save_point
28 - sora_adv_stage
29 - sora_enemy
2A - st_battles
2B - st_battle
2C - st_config
2D - st_final
2E - st_dolpic
2F - st_mansion
30 - st_mariopast
31 - st_kart
32 - st_donkey
33 - st_jungle
34 - st_pirates
35 - st_oldin
36 - st_norfair
37 - st_orpheon
38 - st_crayon
39 - st_halberd
3A - st_starfox
3B - st_stadium
3C - st_tengan
3D - st_fzero
3E - st_ice
3F - st_gw
40 - st_emblem
41 - st_madein
42 - st_earth
43 - st_palutena
44 - st_famicom
45 - st_newpork
46 - st_village
47 - st_metalgear
48 - st_greenhill
49 - st_pictchat
4A - st_plankton
4B - st_dxshrine
4C - st_dxyorster
4D - st_dxgarden
4E - st_dxonett
4F - st_dxgreens
50 - st_dxrcruise
51 - st_dxbigblue
52 - st_dxcorneria
53 - st_dxpstadium
54 - st_dxzebes
55 - st_stageedit
56 - st_otrain
57 - st_heal
58 - st_homerun
59 - st_targetbreak
5A - st_croll
5B - ft_mario
5C - ft_donkey
5D - ft_link
5E - ft_samus
5F - ft_yoshi
60 - ft_kirby
61 - ft_fox
62 - ft_pikachu
63 - ft_luigi
64 - ft_captain
65 - ft_ness
66 - ft_koopa
67 - ft_peach
68 - ft_zelda
69 - ft_iceclimber
6A - ft_marth
6B - ft_gamewatch
6C - ft_falco
6D - ft_ganon
6E - ft_wario
6F - ft_metaknight
70 - ft_pit
71 - ft_pikmin
72 - ft_lucas
73 - ft_diddy
74 - ft_poke
75 - ft_dedede
76 - ft_lucario
77 - ft_ike
78 - ft_robot
79 - ft_toonlink
7A - ft_snake
7B - ft_sonic
7C - ft_purin
7D - ft_wolf
7E - ft_zako

Also, by looking in sora_adv_stage, I counted 75 unique SSE formats from one of the lists.
There was also names such as "StActTrigger(name, such ResetStock)" which might describe the uses for the different formats. (I can't figure out which format they describes though.)


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: pikazz on July 26, 2012, 09:08:31 AM
I took the liberty to write down all the IDs in the module files using the module editor, in case it could be useful (for references):
IDs:

00 - main.dol?
01 - sora_scene
02 - sora_menu_main
03 - sora_menu_tour
04 - sora_menu_qm
05 - sora_menu_edit
06 - sora_menu_collect_viewer
07 - sora_menu_replay
08 - sora_menu_snap_shot
09 - sora_menu_event
0A - sora_menu_sel_char
0B - sora_menu_sel_stage
0C - sora_menu_game_over
0D - sora_menu_intro
0E - sora_menu_friend_list
0F - sora_menu_watch
10 - sora_menu_name
11 - sora_menu_sel_char_access
12 - sora_menu_rule
13 - sora_menu_simple_ending
14 - sora_minigame
15 - sora_menu_time_result
16 - sora_menu_boot
17 - sora_menu_challenger
18 - sora_menu_title
19 - sora_menu_title_sunset
1A - sora_fig_get_demo
1B - sora_melee
1C - sora_adv_menu_name
1D - sora_adv_menu_visual
1E - sora_adv_menu_sel_char
1F - sora_adv_menu_sel_map
20 - sora_adv_menu_difficulty
21 - sora_adv_menu_game_over
22 - sora_adv_menu_result
23 - sora_adv_menu_save_load
24 - sora_adv_menu_seal
25 - sora_adv_menu_ending
26 - sora_adv_menu_telop
27 - sora_adv_menu_save_point
28 - sora_adv_stage
29 - sora_enemy
2A - st_battles
2B - st_battle
2C - st_config
2D - st_final
2E - st_dolpic
2F - st_mansion
30 - st_mariopast
31 - st_kart
32 - st_donkey
33 - st_jungle
34 - st_pirates
35 - st_oldin
36 - st_norfair
37 - st_orpheon
38 - st_crayon
39 - st_halberd
3A - st_starfox
3B - st_stadium
3C - st_tengan
3D - st_fzero
3E - st_ice
3F - st_gw
40 - st_emblem
41 - st_madein
42 - st_earth
43 - st_palutena
44 - st_famicom
45 - st_newpork
46 - st_village
47 - st_metalgear
48 - st_greenhill
49 - st_pictchat
4A - st_plankton
4B - st_dxshrine
4C - st_dxyorster
4D - st_dxgarden
4E - st_dxonett
4F - st_dxgreens
50 - st_dxrcruise
51 - st_dxbigblue
52 - st_dxcorneria
53 - st_dxpstadium
54 - st_dxzebes
55 - st_stageedit
56 - st_otrain
57 - st_heal
58 - st_homerun
59 - st_targetbreak
5A - st_croll
5B - ft_mario
5C - ft_donkey
5D - ft_link
5E - ft_samus
5F - ft_yoshi
60 - ft_kirby
61 - ft_fox
62 - ft_pikachu
63 - ft_luigi
64 - ft_captain
65 - ft_ness
66 - ft_koopa
67 - ft_peach
68 - ft_zelda
69 - ft_iceclimber
6A - ft_marth
6B - ft_gamewatch
6C - ft_falco
6D - ft_ganon
6E - ft_wario
6F - ft_metaknight
70 - ft_pit
71 - ft_pikmin
72 - ft_lucas
73 - ft_diddy
74 - ft_poke
75 - ft_dedede
76 - ft_lucario
77 - ft_ike
78 - ft_robot
79 - ft_toonlink
7A - ft_snake
7B - ft_sonic
7C - ft_purin
7D - ft_wolf
7E - ft_zako

Also, by looking in sora_adv_stage, I counted 75 unique SSE formats from one of the lists.
There was also names such as "StActTrigger(name, such ResetStock)" which might describe the uses for the different formats. (I can't figure out which format they describes though.)
that's great! I will add those in OP together with PW's Gift! x3

also, I believe the StActTrigger is a function. not actually sure how Function works in ASM if it are any

EDIT: added the ID list and PW's gift to OP!


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Sky Grounder on July 26, 2012, 10:02:53 AM
that's great! I will add those in OP together with PW's Gift! x3

also, I believe the StActTrigger is a function. not actually sure how Function works in ASM if it are any
Yeah, but I meant functions connected to those formats :P

I'll write down a bunch of those "triggers":

StActTriggerGimmickStatus
StActTriggerStockReset
StActTriggerEffect
StActTriggerQuake
StActTriggerChangeScene
StActTriggerCreateFixedItem
StActTriggerMotionPathMove4Stop
StActTriggerMotionPathMove4Start
StActTriggerCameraDemo
StActTriggerForceScrollOn
StActTriggerScrollLockOff
StActTriggerScrollLockOn
StActTriggerStepJump
StActTriggerCB
StActTriggerEnemyPop
StActTriggerSound
StActTriggerAreaSound
Ofcourse, all of the formats isn't necessarily "triggers", but I think these functions relate to some of the formats. (All SSE stages share the same module file.)
Now... maybe I should go back to figuring out SSE files? I've already figured out how songs and stages are connected xP


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Ultraxwing on July 26, 2012, 10:15:27 AM
 From what the above looks like. if all the SSE stages refer to one .REL

those look like things with code. like the ChangeScene one for example might refer to how when you enter a door. it changes the scene. (i don't think that's exactly it) so if one wanted to when it comes the time. when we understand 120% of the Modules. we can Edit SSE stages to do cool things. an idea might be another added in boss.

and if we understand modules better. i bet the Clone Engine will be completely possible. seeing how alot of these things are .RELS and to get a clones character to work isn't just activating a slot and copy and pasting a character. it might involve an edited .REL and other things.

and Phantomwings my man. you are amazing. +1Peachy for you(http://profile.ak.fbcdn.net/hprofile-ak-snc4/158070_159550564158975_138449923_n.jpg) and only for you.


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Sky Grounder on July 26, 2012, 10:36:42 AM
From what the above looks like. if all the SSE stages refer to one .REL

those look like things with code. like the ChangeScene one for example might refer to how when you enter a door. it changes the scene. (i don't think that's exactly it) so if one wanted to when it comes the time. when we understand 120% of the Modules. we can Edit SSE stages to do cool things. an idea might be another added in boss.

and if we understand modules better. i bet the Clone Engine will be completely possible. seeing how alot of these things are .RELS and to get a clones character to work isn't just activating a slot and copy and pasting a character. it might involve an edited .REL and other things.

and Phantomwings my man. you are amazing. +1Peachy for you([url]http://profile.ak.fbcdn.net/hprofile-ak-snc4/158070_159550564158975_138449923_n.jpg[/url]) and only for you.
yknow, since all SSE stages use one common module file, it is pretty much possible to make our own SSE stages. It just involves figuring out those formats that are stored in BLOC files (SSE file container). If a file isn't present, it just won't be used, as simple as that.

But I doubt I could get BJ to code support for those files though D:


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: pikazz on July 26, 2012, 10:45:14 AM
yknow, since all SSE stages use one common module file, it is pretty much possible to make our own SSE stages. It just involves figuring out those formats that are stored in BLOC files (SSE file container). If a file isn't present, it just won't be used, as simple as that.

But I doubt I could get BJ to code support for those files though D:
but we need to be prepared! coding ASM is way harder than Flash or C++, ASM is the closes  to the hardware than any other programming code and the hardest code to learn (but most effectently) so it wouldn't be a dance on flowers to do own SSE stages in REL.

but the idea is lovely! <3

also, thanks for PW's gift I have now seen how they are stored and how I can (possible) relocate them in hex so I will try to build one OWN module file from scratch in hex in soon future


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Sky Grounder on July 26, 2012, 11:00:35 AM
My point is: We can already do our own SSE stages without having to edit the main module. BUT, if we wanted to code a rolling rock that has a hitbox (already coded in the module, I think the format is called GMVA) or something else, we would have to edit the module file.

But the thing is that we don't know what each of the SSE formats do or how they work. There's no way to edit them without hex either. That's pretty much why no one has made their own unique SSE stage.


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: BlackJax96 on July 26, 2012, 12:16:50 PM
But I doubt I could get BJ to code support for those files though D:

Well as long as the file formats aren't gigantic, I could go on a programming spree for supporting minor file formats at some point in time. Since BRSAR is already fully known... I can make arrangements.


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Sky Grounder on July 26, 2012, 02:17:25 PM
The formats are simple as heck, but as I stated in one of my previous posts, SSE have about 75 unique formats, and it's about trying to figure out what they do, which is the time-consuming part.

Now we're getting a bit off-topic. Should I make a seperate thread for SSE investigation and stuff?


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: PhantomWings on July 26, 2012, 02:21:36 PM
wow! I am amazed, you actually answer my question and now I am happy :happy:
and that information will be excellent help! I understand more about Epilog, Prolog, Bssoffsets and more about Relocation section thanks to you :3
I appreciate your help! x3

but there is one thing that still bugs me, about nameOffset.
often when it is a Offset, it's most of the time 4-8 hex big and often ends on either 0-4-8-C but the nameOffset ends on almost every single hex that are known (0-F), mostly 6 and 1 :srs:
are they stored/load/created at the same way the Bss Memory are created in runtime?

planing to write completely a whole new Module file from scratch to understand more about it's struckture :kdance:
not this time :3

The name offset and size seems to be only used for debug purposes as it doesn't have any use during runtime (The revolution SDK makes reference to it though). As for why the offset isn't aligned to 0x4; that's because strings are stored in memory back to back without any alignment. Therefore, string pointers can end in any values from 0x0 to 0xF.


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: DoctorFlux(Mariodk) on July 26, 2012, 02:34:34 PM

PhantomWings posted afew times today
does that means he is back? (i hope so we can get extra char. slots or something impossible to be possible)


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: pikazz on July 26, 2012, 02:37:49 PM
The name offset and size seems to be only used for debug purposes as it doesn't have any use during runtime (The revolution SDK makes reference to it though). As for why the offset isn't aligned to 0x4; that's because strings are stored in memory back to back without any alignment. Therefore, string pointers can end in any values from 0x0 to 0xF.
so basically, the name offset and size doesn't do anything in the module except for the debug purpose??
after all this time :srs:
seriously!

Thanks for that answer! I am now very happy guy! :3
but sadly, I dont have any more questions to ask D: they might pop-up soon

PhantomWings posted afew times today
does that means he is back? (i hope so we can get extra char. slots or something impossible to be possible)
I believe he is taking a break from his break xD
and are happy that somebodies also parshing Module files, not only him


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: BlackJax96 on July 26, 2012, 02:52:50 PM
The formats are simple as heck, but as I stated in one of my previous posts, SSE have about 75 unique formats, and it's about trying to figure out what they do, which is the time-consuming part.

Now we're getting a bit off-topic. Should I make a seperate thread for SSE investigation and stuff?


That would be great if you could do that and write out as many formats in one place so I can just go and support all them at once. Parsing and rebuilding formats can go pretty fast if I know everything about them.


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: ♤♡◇♧ on July 26, 2012, 03:24:55 PM
Actually, that's easy if you have an USBGecko.
The code sets the pointer address to 0x80B27AC0, which is R.O.B.'s 'something' location and changes the string from 80914B88 (R.O.B.'s original value) to 80914B5C (Ike's value, which is located at 0x80B27ABC).
Though to be fair, most of the characters you just named are characters who contain more then 1 character inside their character module,  and therefor also have multiple file location paths, making them somewhat irreplaceable.


Title: Re: Let's look into Module Fíles (.rel) and parche it - One Step Closer
Post by: Sky Grounder on July 26, 2012, 03:45:43 PM
That would be great if you could do that and write out as many formats in one place so I can just go and support all them at once. Parsing and rebuilding formats can go pretty fast if I know everything about them.
I've made the thread, but right now, it contains very little info.


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: pikazz on July 28, 2012, 04:22:18 AM
Created the first Module file from scratch and I am proud over myself :D
and you can open it in both PW's Module Editor 3 and brawlbox without a freeze anywhere!
and it has relocation data which I did all by myself! (all done with hex editior)

anyway! it's still a beta since you cant open it in Module Editor v2.1, saying the index is outside the matrix

believe I have messed up a little about it's "weight" (if it are any weights) and "names" like "stFinal" or "stClassInfoImpl<2, stFinal".
I would like PW take a look at it :3

also, I can say right now that it will NOT work ingame since I didn't made it to load anything, just some asm xD


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: KnightMario on July 28, 2012, 09:23:28 AM
can't we already get one extra slot? (MarioD)


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: Eternal Yoshi on July 28, 2012, 08:52:35 PM
I want to learn this stuff better so I can take specific props from SSE and apply them to normal Brawl stages.

Anyone got a cheat sheet or link or something that can help me with this?


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: KnightMario on July 31, 2012, 05:29:27 PM
Ah thanks sir. So, if I'm following this right would this code make Ike over Kirby?

Kirby has Ike's ...Something:
4A000000 80B27A1C
14000000 80914B5C
E0000000 80008000

It doesn't work though...my guess is because Kirby has other characters in him, the PSA moves and such?
who are you exactly?


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: Diddy Kong on July 31, 2012, 10:32:12 PM
Ah thanks sir. So, if I'm following this right would this code make Ike over Kirby?

Kirby has Ike's ...Something:
4A000000 80B27A1C
14000000 80914B5C
E0000000 80008000

It doesn't work though...my guess is because Kirby has other characters in him, the PSA moves and such?
this isnt about gecko codes that help the rel port, this is about reprogramming the rel entirely to the point that code isnt needed anymore


it will be the distant future though


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: Shinobu Nyan! on August 07, 2012, 01:12:49 PM
Alright my head just started spinning, we now know how a lot of the .rel file works right? But we don't have enough to make stage effects, like as stated a rolling rock? Or am I WAY off.


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: pikazz on August 07, 2012, 03:06:15 PM
Alright my head just started spinning, we now know how a lot of the .rel file works right? But we don't have enough to make stage effects, like as stated a rolling rock? Or am I WAY off.
that's correct, we knows it's struckture but we dont know how to rebuild asm


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: Shinobu Nyan! on August 07, 2012, 03:59:10 PM
that's correct, we knows it's struckture but we dont know how to rebuild asm
I know someone who might be able to do that.


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: pikazz on August 07, 2012, 06:06:51 PM
I know someone who might be able to do that.
now you got my eyes intrested


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: the98pika on August 07, 2012, 06:14:27 PM
I know someone who might be able to do that.
Who?


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: Shinobu Nyan! on August 07, 2012, 09:10:48 PM
He used to help me make codes using the USB Gecko, some codes required altering some assembly(ASM) and he showed me how to do it. He may or may not be still active haven't been to the wiiRD forums in a while


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: pikazz on August 08, 2012, 03:39:36 AM
He used to help me make codes using the USB Gecko, some codes required altering some assembly(ASM) and he showed me how to do it. He may or may not be still active haven't been to the wiiRD forums in a while
Write codes and Asm is one thing, rebuilding asm is a other thing


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: Sky Grounder on August 08, 2012, 03:54:09 AM
And rebuilding involves parsing the whole module.


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: Usery on August 08, 2012, 04:27:28 AM
Actually... Yeah I know ASM.. wrote many of C2 codes. Maybe I can help a little bit?


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: Shinobu Nyan! on August 08, 2012, 09:56:26 AM
Actually... Yeah I know ASM.. wrote many of C2 codes. Maybe I can help a little bit?
That you Deathwolf? I mean from wiiRD forums.
Edit: I contacted dcx2 and he hasn't replied yet, but he may be be able to do it. If Deathwolf is who I think he is he can be useful also.


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: Usery on August 08, 2012, 10:55:30 AM
Yes it's me from the WiiRd forum. dcx2 almost retired from the hacking scene... However, I'd like to help you guys with the ASM, I'll try my best.


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: Shinobu Nyan! on August 08, 2012, 02:52:43 PM
Yes it's me from the WiiRd forum. dcx2 almost retired from the hacking scene... However, I'd like to help you guys with the ASM, I'll try my best.
That would be great, thanks.


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: BlackJax96 on August 14, 2012, 07:02:01 PM
Some links I found useful for learning PPC asm.

http://webcache.googleusercontent.com/search?q=cache:w4LDer9GJ2EJ:www.cs.cornell.edu/Info/Courses/Spring-97/CS314/Topic_02.ps (http://webcache.googleusercontent.com/search?q=cache:w4LDer9GJ2EJ:www.cs.cornell.edu/Info/Courses/Spring-97/CS314/Topic_02.ps)

http://www.cs.uaf.edu/2011/fall/cs301/support/ppc/index.html (http://www.cs.uaf.edu/2011/fall/cs301/support/ppc/index.html)

http://www.csd.uwo.ca/~mburrel/stuff/ppc-asm.html (http://www.csd.uwo.ca/~mburrel/stuff/ppc-asm.html)

https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF778525699600719DF2/%24file/6xx_pem.pdf (https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF778525699600719DF2/%24file/6xx_pem.pdf)


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: PhantomWings on September 09, 2012, 12:31:31 PM
So it looks like I've found out where the raw assembly of each of the PSA commands are stored. Moreover, I've also found where inside the character module files the 0C series commands are stored.

A long time ago, I mentioned that I'd found out that the first byte of each PSA command represented one or more module inside Brawl. This was the list that I posted at the time:


Code:

02 soStatusModuleImpl
03 soModelModuleImpl
03 soModelModuleImplVariable
04 soMotionModuleImpl
05 soPostureModuleImpl
06 soCollisionAttackModuleImpl
06 soCollisionHitModuleImpl
06 soCollisionShieldModuleImpl
06 soCollisionCatchModuleImpl
06 soCollisionSearchModuleImpl
07 ftControllerModuleImpl
07 soControllerModuleLinkRef
08 soGroundModuleImpl
09 soSituationMoudleImpl
0A soSoundModuleImpl
0B soVisibilityModuleImpl
0C ft<charname>
0D soAnimCmdModuleImpl
0E soKineticModuleGeneric
0F soLinkModuleImpl
10 soGenerateArticleManageModuleImpl
11 soEffectModuleImpl
12 soWorkManageModuleImpl
13 soComboModuleImpl
14 ftAreaModuleImpl
15 soTerritoryModuleImpl
16 soTargetSearchModuleImpl
17 soPhysicsModuleImpl
18 soSlopeModuleImpl
19 soShadowModuleImpl
1A soCameraModuleImpl
1B
1C ftStopModuleImpl
1D soShakeModuleImpl
1E soDamageModuleImpl
1F soItemManageModuleImpl
20 soTurnModuleImpl
21 soColorBlendModuleImpl
22 soTeamModuleImpl
23 soSlowModuleImpl
64 ftCancelModuleImpl



I'm not sure why, but I never took this bit of information any further at the time. Anyways, it turns out that these modules are stored inside the the Common2 module (module id 1B). Moreover, each of these modules implement a specific interface soAnimCmdEventObserver. This interface is what allows the module to communicate with the instruction set used by PSA.

In order to find the methods used by the soAnimCmdEventObserver interface I needed to update the old Module Viewer 2. As it turns out, a small quirk in the method table which I was previously ignoring actually corresponded to which interfaces they belong to. It was just a dirty fix, so it's not anything fancy, but you'll need it if you want to find any of the PSA assembly code.

[Download] (http://www.mediafire.com/?v8xmy4jjdom21a6)

I guess I should warn everyone ahead of time, that in order to find the assembly of a specific PSA action, you'll need a really good understanding of assembly and a lot of patience - it also helps if you decide on what you're looking for beforehand.



For this example, I'll be looking for the Basic Variable Increment command - given by the PSA id 12030100.

Using the list up above, the first byte of this command (0x12) corresponds to soWorkManageModuleImpl. Start by opening up the common2 module in the new Module Viewer 2. Navigating through the object list to the soWorkManageModuleImpl object and opening up it's inheritance hierarchy, you'll spot the soAnimCmdEventObserver as well as its base; the soEventObserver<soAnimCmdEventObserver>. Observe that the Unknown value of both of them are 16. I'm not sure exactly what this value means, but what's important right now is that it seems to indicate the objects position in the inheritance hierarchy.

The method list has been reorganized so that the first index sorts the methods by inheritance and the second index distinguishes the individual methods. The higher the Unknown value of the inherited object, the higher the first index is for its corresponding methods. In this case, the soAnimCmdEventOberver's events are Method[1][0] to Method[1][5] (just remember that it will likely be different for each module).

The soAnimCmdEventObserver methods usually have a pretty consistent layout. soAnimCmdEventObserver.Method[0] (Method[1][0] in this case) seems to be some sort of initializer or hook function, but it isn't really all that interesting - the interesting ones are the two after it. soAnimCmdEventObserver.Method[1] is an identifier function which returns a boolean value depending on whether the first byte of the PSA command passed to it is equal to 12. If that function returns true, then the soAnimCmdEventObserver.Method[2] is called. This is the function that handles the rest of the PSA command.

As it turns out, Method[1] and Method[2] actually call Method[3] and Method[4] in this case so to get at the actual assembly, you'll have to look at those two instead. Just remember that it isn't always this way as things will vary wildly depending on what module you are looking at.

Anyways, if you open up Method[4] (Method[1][4]) - the main handler for the PSA commands starting with 0x12 - you'll be confronted with a ton of assembly you'll need to wade through. You're pretty much on your own here. However, it may help to know that the lines:

lwz r12,16(r12)   
mtspr ctr,r12   
bctr    
extsb r0,r3   

will put the second byte of the PSA command into r0. From here, you can follow the code through until you find the handler you're looking for - in this case we would be looking for a branch when r0 = 0x03.




Hey, I didn't say it was simple, and I can't really say it's all that useable for most people either. But this sort of knowledge could lead to a lot of potential. Mainly that using this could allow custom assembly scripts to be ran during gameplay whenever a certain PSA command is triggered.

A few other notes:

Some command set series draw upon multiple modules - such as the 06 series commands (hitboxes and such). In particular, the 0C series draws upon not only the ft<character>.rel, but also a bunch of other unidentified modules.

When it comes to finding the character specific 0C series commands, you'll need to open the character's .rel file and navigate to the ft<FighterName> object. The main handlers there are actually Method[3][14] and Method[3][15].

Inside the Common2 module there's an object call soAnimCommandInterpreter or something. If I had to venture a guess, I'd say that's what is responsible for parsing PSA commands during gameplay.




That's about it for now. I haven't done any testing on it, so it's all pretty much theory until someone decides to try something with it and proves it - but for now, it seems pretty sound.





Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: DarkPikachu on September 09, 2012, 02:17:39 PM
glad the logic->script links were found =D

Of course though this is only my 2nd time reading this since it`s creation...

I`ll be looking into this a little more often now as I`d like to start work on an REL2PY decompiler for blender...

Of course though this means I`ll have to study classes XD

But I think I know enough about them now...
Classes are basically the same as a module written with functions...
Local vars are self.var

I`m not continuing as I`m quite sure you don`t want to hear any of this XD


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: Dantarion on September 09, 2012, 03:03:45 PM
PW, I actually coded a module rebuilder in python that uses automated comments to adjust the relocations in the ASM block! PM me if you want to see it!

That information you just posted will come in handy.
I am going to be adjusting my code to rip objects/function locations, but until then...I guess ill be using this!


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: PhantomWings on September 10, 2012, 07:09:28 PM
Nice job Dant. I'm not really much of a python guy so I'm not sure how valuable my input would be, but it's cool to know that you're still working on the modules.

If you're looking to parse the object data, then you'll probably need to use these wrappers. There's not much organization to the object data otherwise.

Code:

Virtual Function Table:
0x00 (ptr)   Declaration
0x04 (int)   Scope Level
0x08 (ptr[]) Functions (no termination)

Declaration:
0x00 (string*)        Name
0x04 (Inheritance[]*) Inheritance (0x00000000 terminated)

Inheritance:
0x00 (ptr) Declaration
0x04 (int) Scope Level


Just remember that it's possible for an object to have more than one Virtual Function Table depending on how many unique scope levels there are in it's inheritance hierarchy. I should note also, that while I call them Scope Levels for the time being, I don't really know exactly what their values represent - all I know is that for every unique value, there's usually an additional Virtual Function Table.

Goodluck Dant.


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: Shinobu Nyan! on September 11, 2012, 11:05:23 AM
I'm still somewhat new to programming and looking at code, but I want to help as to make a contribution to the community. Is there anything I can do to help?


Title: Re: Let's look into Module Fíles (.rel) - The First Own Module Created from Scratch
Post by: pikazz on September 17, 2012, 11:16:55 AM
wow, I miss alot when I am taking a break a short time

wow, that's really great information PW :D I will look more into those to see for myself!
but what exactly is the new thing on "Module Editior 2.2"?

and that's great Dant you still doing about modules :3

EDIT: found some modules in common2!
it's from Miscdata[11]  - [17]
the funny part is that the "Sora_Melee" module is Miscdata[11] (they have the same ModuleID)

why have doubles of everything o.o


Title: Re: Let's look into Module Fíles (.rel) - More info from PW and Dant
Post by: ♤♡◇♧ on September 20, 2012, 03:31:36 AM
It's because those modules have to be loaded into memory all the time, as they contain the general information to get the game actually running.


Title: Re: Let's look into Module Fíles (.rel) - More info from PW and Dant
Post by: pikazz on September 20, 2012, 04:35:07 AM
It's because those modules have to be loaded into memory all the time, as they contain the general information to get the game actually running.
that makes me wonder what happen if we change Sora_Melee.rel but we leave Miscdata[11] untouched and vise verca. I wonder which file is the "priority"


Title: Re: Let's look into Module Fíles (.rel) - More info from PW and Dant
Post by: ♤♡◇♧ on September 20, 2012, 07:07:52 AM
The common2, 3 and 5 files always take priority, as for the common and common4 files, they are probably used for character transformation sequences, as the motion files located in them are of characters who transform by unloading and loading different motion files (except Kirby, of which I don't why he has a duplicate of his motion file in the common files).

Also, common files differ somewhat between NTSC and PAL, but that's a different subject altogether...


Title: Re: Let's look into Module Fíles (.rel) - More info from PW and Dant
Post by: Dantarion on September 21, 2012, 03:54:19 AM
PW. i was able to parse the stuff successfully.
Seems like that number you called scope can be used to link up the interface list to the methods....but sometimes there are missing values....
Does that make sense to you?


Title: Re: Let's look into Module Fíles (.rel) - More info from PW and Dant
Post by: pikazz on November 12, 2012, 04:21:51 PM
*reviving this thread*

I found out something awesome and should be pretty easy to do
http://forums.kc-mm.com/index.php?topic=53327.0 (http://forums.kc-mm.com/index.php?topic=53327.0)

those hitboxes seems not be stored on a special way instead for the otherones in other stages.
I get a feeling it's around 10 lines to code that hitbox. either in Sora_Melee or in the stage module itself

EDIT: been fooling around in REL and made 2 things! one by my thoughs and one by mistake!

first one! I made that final destination loads 5 modeldatas instead for the original 4! meaning that you can put something in the modeldata instead for make it share in on the other Modeldata!
Pics~
(http://i47.tinypic.com/behq9v.png)

(http://i48.tinypic.com/2duw1te.jpg)
Ingame
next thing I doing which is stage is to make the spring act like a spring!
but I know I can't do that for the moment, I need to know first how add functions and add methods to the REL file!

PW, if you watching this I would like need your help D:

The second one! I tried to make the jigglypuff rel load a collusion data! (that gives him walls of shield and a floor which opponent can stand on)
but I got this:

(http://i46.tinypic.com/o55og7.jpg)
he is acting like a ghost, you can't push him by simply walk into him! you walk right through him!
but he still can be attacked and attack!


Title: Re: Let's look into Module Fíles (.rel) - 5 Modeldatas instead for 4 in FD
Post by: Sky Grounder on November 13, 2012, 12:54:47 AM
EDIT: been fooling around in REL and made 2 things! one by my thoughs and one by mistake!

first one! I made that final destination loads 5 modeldatas instead for the original 4! meaning that you can put something in the modeldata instead for make it share in on the other Modeldata!
Pics~
([url]http://i47.tinypic.com/behq9v.png[/url])

([url]http://i48.tinypic.com/2duw1te.jpg[/url])
Ingame
Finally more ModelDatas in FD :happy:


Title: Re: Let's look into Module Fíles (.rel) - 5 Modeldatas instead for 4 in FD
Post by: pikazz on November 13, 2012, 02:09:04 AM
find something instresting and yet unbelievable at first.
in ALL rels, in the object section after the names, it's something that "starts" at 00 20 AF 30 and to the end of the section is the EXACTLY the same in ALL Rels!
exactly the same hex, exactly same ledght and it's always 18C0 long!
ALWAYS.

found this wierd, looked at 9 RELS (including Sora_Melee, Stages and Character) and they all had it.

believe it's important "Filler" or something like that the polygon in MLD0 must be on a 0x20 0x40, 0x60 ect
Finally more ModelDatas in FD :happy:
it is! x3


Title: Re: Let's look into Module Fíles (.rel) - 5 Modeldatas instead for 4 in FD
Post by: Sky Grounder on November 13, 2012, 09:43:57 AM
If that section is the same on ALL modules, shouldn't we overlook it and look into what is different?

Also, if you could tell a bit about what you know about the modules, I could maybe start helping figuring stuffz out.
That is, if I can get back into brawl hacking :srs:


Title: Re: Let's look into Module Fíles (.rel) - 5 Modeldatas instead for 4 in FD
Post by: pikazz on November 14, 2012, 02:16:43 PM
okay, this is sad!
I know how to edit hitboxes on stationary stages completely!
and I know how they are stored (not sure but possible) and how to add it to another stage!
but, now I am stuck! all I get is the object is outside the index, there is something I miss to edit but where :c

If that section is the same on ALL modules, shouldn't we overlook it and look into what is different?

Also, if you could tell a bit about what you know about the modules, I could maybe start helping figuring stuffz out.
That is, if I can get back into brawl hacking :srs:
it's very hard to describe D: and my lack of english grammar makes it worse!


Title: Re: Let's look into Module Fíles (.rel) - 5 Modeldatas instead for 4 in FD
Post by: Carnage on November 14, 2012, 02:24:38 PM
okay, this is sad!
I know how to edit hitboxes on stationary stages completely!
and I know how they are stored (not sure but possible) and how to add it to another stage!
but, now I am stuck! all I get is the object is outside the index, there is something I miss to edit but where :c
it's very hard to describe D: and my lack of english grammar makes it worse!
pikazz you need to figure this out so all stages can get an update with hitboxs xD imagine a safron city with pokemons that attack you  , so many memories :P


Title: Re: Let's look into Module Fíles (.rel) - 5 Modeldatas instead for 4 in FD
Post by: pikazz on November 14, 2012, 02:29:56 PM
scratch that about I said I was sure, but I am almost there! I can almost sniff it!
I have found like 5-6 functions about hitboxes in Stage Builder Rel, one of them stood out so I will try that one!

also, I found out where to change "how many targets you need to brake in Break the Targets to complete"
pikazz you need to figure this out so all stages can get an update with hitboxs xD imagine a safron city with pokemons that attack you  , so many memories :P
that would be awesome but alot of work.
but the only thing I know right now is stationary hitbox like spikes! that means it's ALWAYS there, doesn't disappear or only for seconds. always there.
and you can only have one effect at time for now, meaning pokemon attacks with diffirent elements would be impossible for now D:


Title: Re: Let's look into Module Fíles (.rel) - 5 Modeldatas instead for 4 in FD
Post by: Carnage on November 14, 2012, 04:23:00 PM
scratch that about I said I was sure, but I am almost there! I can almost sniff it!
I have found like 5-6 functions about hitboxes in Stage Builder Rel, one of them stood out so I will try that one!

also, I found out where to change "how many targets you need to brake in Break the Targets to complete"that would be awesome but alot of work.
but the only thing I know right now is stationary hitbox like spikes! that means it's ALWAYS there, doesn't disappear or only for seconds. always there.
and you can only have one effect at time for now, meaning pokemon attacks with diffirent elements would be impossible for now D:
couldnt you comect the hitboxes to a bone? or an independant object?


Title: Re: Let's look into Module Fíles (.rel) - 5 Modeldatas instead for 4 in FD
Post by: pikazz on November 15, 2012, 02:48:04 AM
couldnt you comect the hitboxes to a bone? or an independant object?
nah, the hitboxes attachs to collusion, meaning it can't be on a bone.
but you can animate the collusion with be bones xD


Title: Re: Let's look into Module Fíles (.rel) - 5 Modeldatas instead for 4 in FD
Post by: Carnage on November 15, 2012, 04:09:35 AM
nah, the hitboxes attachs to collusion, meaning it can't be on a bone.
but you can animate the collusion with be bones xD
then you can make the hitbox go away by making the object with the collision banish? like for example we make a platform disapear?


Title: Re: Let's look into Module Fíles (.rel) - 5 Modeldatas instead for 4 in FD
Post by: DSX8 on November 15, 2012, 04:24:21 AM
pretty much, if u make the bone scale to 0,0,0   there will be no hitbox/collision till its back to 1.  if this can be done to FD.. then i can finally remake some stages of mine to have hit box's :P


Title: Re: Let's look into Module Fíles (.rel) - 5 Modeldatas instead for 4 in FD
Post by: Carnage on November 15, 2012, 05:27:39 AM
pretty much, if u make the bone scale to 0,0,0   there will be no hitbox/collision till its back to 1.  if this can be done to FD.. then i can finally remake some stages of mine to have hit box's :P
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 :P


Title: Re: Let's look into Module Fíles (.rel) - 5 Modeldatas instead for 4 in FD
Post by: Sky Grounder on November 15, 2012, 07:50:25 AM
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 :P
Except the Bullet Bill/Pokémons doesn't even use collisions.


Title: Re: Let's look into Module Fíles (.rel) - 5 Modeldatas instead for 4 in FD
Post by: Carnage on November 15, 2012, 08:03:27 AM
Except the Bullet Bill/Pokémons doesn't even use collisions.
you can add them if they gonna have hitboxes  xD


Title: Re: Let's look into Module Fíles (.rel) - 5 Modeldatas instead for 4 in FD
Post by: PhantomWings on November 16, 2012, 08:07:56 PM
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.


Title: Re: Let's look into Module Fíles (.rel) - 5 Modeldatas instead for 4 in FD
Post by: pikazz on December 11, 2012, 09:24:43 AM
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 (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:
(http://i48.tinypic.com/20kayjl.png)
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!
(http://i47.tinypic.com/2620htf.jpg)

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<


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: PhantomWings on December 11, 2012, 07:39:37 PM
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.


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: pikazz on December 12, 2012, 04:51:06 AM
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.
(http://i48.tinypic.com/34ni24z.jpg)

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?


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: PhantomWings on December 12, 2012, 10:14:09 AM
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)
(http://i46.tinypic.com/2monh1v.jpg)

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.


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: pikazz on December 12, 2012, 11:56:26 AM
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)
([url]http://i46.tinypic.com/2monh1v.jpg[/url])

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


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: PhantomWings on December 12, 2012, 02:41:40 PM
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)


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: pikazz on December 12, 2012, 03:05:58 PM
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


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: PhantomWings on December 12, 2012, 04:03:37 PM
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.

(http://i48.tinypic.com/166i3vd.jpg)

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.


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: pikazz on December 13, 2012, 12:33:15 AM
aah, I see now :3
that's was easier than expected!

and sure, let me send to you through PM!


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: pikazz on December 17, 2012, 03:11:17 PM
PW: I found something useful, I did PM you about what I found out!


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: PhantomWings on December 18, 2012, 05:34:30 PM
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].


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: pikazz on December 19, 2012, 01:07:03 AM
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 :D 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!
(http://i48.tinypic.com/534wsp.jpg)
now jigglypuff can grab! :D

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 (http://www.youtube.com/watch?v=J4IE7oVN4pY#)
did a short video! some are glitchy but that isn't modules doing, it's my choice of actions :/


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: PhantomWings on December 19, 2012, 05:21:32 PM
Wow, nice job!

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?



Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: DoctorFlux(Mariodk) on December 19, 2012, 11:51:57 PM
1 thing i will love if it gets discovered:
port articles to others(even if it means replacing articles):
like port pikmins from olimar to ike and replace Ike´s sword article

if special grap with module is possible i think this will be possible to but maybe 200% harder to do


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: pikazz on December 20, 2012, 12:24:54 AM
Wow, nice job!

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?


the spin was something I added just to show it followed the grab and for a nice touch :P
but the glitch when jigglypuff is looking at the screen after the grab was just a bad action choice, used one of it's "Rollout Action" D:

no, I haven't but I am pretty sure it also contains Captain Falcons Final Smash data.
will try to add/replace Ganon and Bowsers Grabs over some to see it work or something else happens!
also, I wonder where the "switch" is for the character who switchs character o.o

1 thing i will love if it gets discovered:
port articles to others(even if it means replacing articles):
like port pikmins from olimar to ike and replace Ike´s sword article

if special grap with module is possible i think this will be possible to but maybe 200% harder to do
articles will be REALLY hard work. but I think I know how it's called!

EDIT: I believe I know how both the "Switchable" character works and how Attributes to special actions gets load to game!
it's just a therody! I will try to give mario's final smash jigglypuff's finalsmash attribute which will make him "grow" 12 sizes of his own size!

Post Merge: December 21, 2012, 05:58:51 PM
I have looked some more onto articles and attributes to specials.

I have theories about how everythings working, it will be pain in the ass to add articles.
but I think we can add Counter, Reflect AND Absorbing pretty soon! That's something awesome!
yet, it still theories... no actual evidence or something like that D:


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: DoctorFlux(Mariodk) on December 22, 2012, 10:36:11 AM
counter is possible over anyone with PSAing and reflect i think also


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: pikazz on December 22, 2012, 04:37:32 PM
counter is possible over anyone with PSAing and reflect i think also
I mean the "real" way, the damage gets double that you get and can give 999% ect :srs:


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: Carnage on December 22, 2012, 04:40:17 PM
I mean the "real" way, the damage gets double that you get and can give 999% ect :srs:
you can do all that in psa also since you can see how much damage you took and decide what to give the opoenent


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: pikazz on December 22, 2012, 04:49:13 PM
you can do all that in psa also since you can see how much damage you took and decide what to give the opoenent
meh :srs:


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: DSX8 on December 22, 2012, 04:50:52 PM
meh :srs:
he means srs business gais :o


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: Carnage on December 22, 2012, 04:52:13 PM
meh :srs:
counter is preety much psaable i doubt anyne would go to the trouble of module editing to add a counter or a refect to a char what we want are stuff like projectiles, minions and etc that we cant make by psa yet atleast so far since fake projectyles cant be reflected at all :S


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: pikazz on December 22, 2012, 05:13:52 PM
he means srs business gais :o
that made me laugh! last time I checked on counter, it was impossible to do! including perfect reflect and absorb D:

counter is preety much psaable i doubt anyne would go to the trouble of module editing to add a counter or a refect to a char what we want are stuff like projectiles, minions and etc that we cant make by psa yet atleast so far since fake projectyles cant be reflected at all :S
but there is ALOT to add just one little single article :srs: especially doing it without the rebuilder!
but I will look more into it


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: DoctorFlux(Mariodk) on December 24, 2012, 07:46:38 AM
I checked on counter, it was impossible to do! including perfect reflect and absorb D:
PSAs with counter attacks: Goku(almost Lucario´s), Shadow over DK, Scott Pilgrim, a DK PSA i found with a .gif image that shows the counter works, Waluigi over pit/diddy, possible more


PSAs with refle/absorbs: idk any but KJP discovered it and it worked over a char. who dont got refle/absorbs

so it is possible without module editing


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: KingJigglypuff on December 24, 2012, 07:56:22 AM
PSAs with refle/absorbs: idk any but KJP discovered it and it worked over a char. who dont got refle/absorbs

so it is possible without module editing
I never recall doing that on a PSA of mine. Which character did I do that on?


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: DoctorFlux(Mariodk) on December 24, 2012, 08:50:59 AM
I never recall doing that on a PSA of mine. Which character did I do that on?
i dont remember but you did discovered it and made a guide for it


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: KingJigglypuff on December 24, 2012, 09:31:29 AM
i dont remember but you did discovered it and made a guide for it
Oh.

That was back when I didn't know much about PSA.

And that guide will only work for characters with attacks that react to projectiles. Those characters are as followed: Fox/Falco/Wolf (Reflector), Ness/Lucas (Psy Magnet and Lucas' Side Smash), Zelda (Nayru's Love), Mario (Cape), Pit (Angel Ring and Mirror Shield), and R.O.B. (Arm Rotor). Also maybe Mr. Game & Watch (Oil Panic) as well.

Other characters can use the reflection coding, but it's not always reliable. When activated in-game, it sometimes works, but sometimes it doesn't work. But it does seem to work often when the character is in the Intangible state.


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: PhantomWings on December 30, 2012, 01:50:19 PM
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:

r3=this
r4=Fighter.soModuleAccessor
r5=current action



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


Module Methods:
Code:

soModelModuleImpl (0x04)
Method[24] BindToBone? (r3=this, r4=id, r5=unk)
Method[33] GetBone (r3=this, r4=id)
Method[34] Unk (r3=this, r4=unk)
Method[72] Unk (r3=this, r4=unk, r5=unk)

soPostureModuleImpl (0x0C)
Method[4] Unk @Tethers (r3=unk, r4=this)

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

soLinkModuleImpl (0x54)
Method[10] Unk @Samus (r3=this, r4=unk)
Method[16] Unk @Ike (r3=this, r4=?, r5=stack frame, r6=?)
Method[18] Unk @Samus (r3=this, r4=unk)
Method[75] Unk @Samus (r3=this, r4=?, r5=bone, r6=?, r7=?, r8=?)
Method[87] Unk @Samus (r3=this, r4=unk)

ftControllerModuleImpl (0x5C)
Method[16] Unk @Link (r3=this)
Method[27] Unk @Link (r3=this)
Method[55] Unk @Samus (r3=this, r4=?, r5=?, r6=?, r7=?)

soWorkManageModuleImpl (0x64)
Method[4] Get? @Ike (r3=this, r4=identifier)
Method[5] SetValue (r3=this, r4=value, r5=identifier)
Method[7] IncValue (r3=this, r4=identifier)
Method[8] DecValue (r3=this, r4=identifier)
Method[9] AddValue (r3=this, r4=value, r5=identifer)
Method[10] SubValue (r3=this, r4=value, r5=identifier)
Method[12] GetFloat (r3=this, r4=identifier)
Method[13] SetFloat (r3=this, r4=identifier, f1=value)
Method[15] AddFloat (r3=this, r4=identifier, f1=value)
Method[16] SubFloat (r3=this, r4=identifier, f1=value)
Method[17] Get? @Link (r3=this, r4=identifer)
Method[18] SetBit (r3=this, r4=identifier)
Method[19] ClearBit (r3=this, r4=identifier)


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

soGenerateArticleManageModuleImpl (0x84)
Method[16] Unk @Mario (r3=this, r4=ptr, r5=unk)
Method[18] GetArticleExists? (r3=this, r4=id)
Method[24] GenerateArticle? (r3=this, r4=id)


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.


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: pikazz on December 31, 2012, 03:13:06 AM
wow! that's great information indeed :D

I will start to play and test those things ASAP! but right now, I am at my girlfriend and will celebrate new year and can't do much until 7-8 jan :/
but I will look more and start to test about that when I get spare time! x3


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: DarkPikachu on December 31, 2012, 06:11:18 PM
on wii, no kbd, thumb hurts... :P

working on REL template for HexEdit...

anyone have any format documentation??

btw I know how to remove that popup in HE-Pro if anyone's interested... <_<


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: SonicBrawler on December 31, 2012, 10:34:40 PM
This has to do with .rels, So i guess i should post here:

http://www.youtube.com/watch?v=ZhaksbecPFU


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: DarkPikachu on December 31, 2012, 11:33:46 PM
I finally got to upload my image:
(https://cloud.fernode.de/index.php/s/PB8A32wiHC46ZRw/preview)

the import commands are too long, so I didn't expand them.

template link coming soon...


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: Carnage on January 01, 2013, 03:51:41 AM
sonicbrawler that is amazing i wanted a mewtwo rel for so long xD  we can fix the gfx more or less in psa :P but it wont be the same thats how far dantarian went with lucario port i remnber he didnt get the gfx to appear when fighting lucario too i hope you can find the fix if you cant i hope you still release this even if the gfx doesnt appear :P


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: SonicBrawler on January 01, 2013, 08:25:45 AM
sonicbrawler that is amazing i wanted a mewtwo rel for so long xD  we can fix the gfx more or less in psa :P but it wont be the same thats how far dantarian went with lucario port i remnber he didnt get the gfx to appear when fighting lucario too i hope you can find the fix if you cant i hope you still release this even if the gfx doesnt appear :P

The ONLY problem is it only works against lucario. (and the arua sphere doesnt load but i imagine that is because the real lucario "takes" it)


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: DarkPikachu on January 01, 2013, 10:00:20 AM
it sounds like it's a linkage issue...

think of each character as having an allocated "slot" in the wii memory.
you would have to have each character's accessories in, I'm guessing the folder it's expected to load from...


... btw, I can't upload the REL template with a PS3 >_<


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: pikazz on January 02, 2013, 04:07:11 AM
This has to do with .rels, So i guess i should post here:

[url]http://www.youtube.com/watch?v=ZhaksbecPFU[/url]

that looks like the ike I tried to do on marth long ago and they only worked if both was ingame, otherwise it freeze

I finally got to upload my image:
([url]http://lh6.ggpht.com/-Wfz4pfLxtGM/UOJ_Zr-9lnI/AAAAAAAAEQo/SnDQSeQryi0/s800/first%2520progress.PNG[/url])

the import commands are too long, so I didn't expand them.

template link coming soon...

might be useful but still confusing


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: Carnage on January 02, 2013, 07:02:16 AM
The ONLY problem is it only works against lucario. (and the arua sphere doesnt load but i imagine that is because the real lucario "takes" it)
thats really a shame that only works against lucario :S


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: Battleon469 on January 03, 2013, 05:01:07 AM
have you figured why lucario port can't vs anyone except for himself?


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: PhantomWings on January 03, 2013, 09:23:48 AM
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.


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: pikazz on January 03, 2013, 09:46:25 AM
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.
that's pretty sad about your Wii Disc drive kick it D:

dont know how to merge it o.o and the threads seems to be one about just porting while this thread is more discovering and parshing it piece by piece!


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: ♤♡◇♧ on January 03, 2013, 12:58:37 PM
As Pikazz explained, merging the threads would be a bad idea, as they go into different sections of module editing.

The Lucario stuff should have been posted in the module porting thread though.


Title: Re: Let's look into Module Fíles (.rel) - Special Throw, Module Way!
Post by: pikazz on January 08, 2013, 02:31:38 PM
PW, I haven't looked and test soStatusUniqProcess yet. do you mean instead Method[3][16] or in somewhere or any soStatusUniqProcess cause I was confused this morning when I read your post of that thing!

also, I took my time to look into soArticleMediatorImpl to learn more of how Articles are stored.
Found this:
(http://i45.tinypic.com/2eogrx4.jpg)
(http://i45.tinypic.com/15gqi3b.jpg)
(http://i48.tinypic.com/20gyy55.jpg)
(http://i49.tinypic.com/ak8uat.jpg)
a ridiously easy article item swap since the "item" and its PSA is Common3 instead inside the characters PSA and MotionEct.
but that gives me more information about looking inside soArticleMediatorImpl


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: PhantomWings on January 08, 2013, 11:04:43 PM
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:

(http://i49.tinypic.com/2ltfvwi.jpg)

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:

(http://i46.tinypic.com/2wggq2p.jpg)

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 (http://en.wikipedia.org/wiki/Thunk_%28programming%29) 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.


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: pikazz on January 09, 2013, 01:47:19 AM
I see it now! will start to look and test things in there.
I have a theory about those StatusUniqProgress! I believe some of them are loading attributes from the FitChar.pac like the special attributes "how fast movement in X" or "how many frames before X is done loading"

also, it's inside Method[0][1]
(http://i46.tinypic.com/36ayw.png)
this is the link bomb item! Li r3 85
but I dont know how it's get called to links B-Down Action, perhaps through FitLinkStatusUniqProgressSpecialBomb?

EDIT: I did look a bit in those, it was quite a mess :/
some SpecialUniqProgress has actions thats "do this actions first, if the animation is end do this one" while some doesn't have any actions at all (they maybe are wellhidden or using Float/Bit/Random Variables instead)

I believe that you said about Method[1-3] is true, but it seems that some also using method[7]. jigglypuffs final smash specialuniqprogress used Method[7], when I edited something in that method[7], I got a forever growing jigglypuff without an end on his final smash :srs:

also, links Wait SpecialUniqProgress has it's [1] and [3] located at the same hexbyte O.o meaning they do exactly the same.
haven't looked into the initialieser yet but I will soon

there is one thing that gets me confused:

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

what exactly did you mean with those methods? O.o inside each objects that's using soStatusModuleImpl or anything else?


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: PhantomWings on January 09, 2013, 05:18:32 PM
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.)
(http://i47.tinypic.com/4he3c6.jpg)

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:

soArticleMediatorImpl:
Method[0][0] finalizer (r3=this, r4=size)
Method[0][1] create_article (r3=this, r4=article_id, r5=Fighter.soModuleAccessor)
Method[1][0] soArticleOperator_Method[0][0]_thunk
Method[1][1] soArticleOperator_Method[1][8]_thunk
Method[1][2] clear_article_instances? (r3=this)
Method[1][3] unk (r3=this, r4=Fighter.soModuleAccessor, r5=article_id)
Method[1][4] unk (r3=this, r4=Fighter.soModuleAccessor, r5=article_id)
Method[1][5] unk (r3=this, r4=article_id)
Method[1][6] get_article_count (r3=this)
Method[1][7] unk (r3=this, r4=unk)
Method[1][8] find_article_instances? (r3=this, r4=unk, r5=unk)

There's a bunch of interesting stuff here.

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.


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: pikazz on January 10, 2013, 04:07:02 AM
it sounds like adding article isn't impossible no more! I will take more look into inialiazer to soStatusUniq and soArticleMediator.

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?

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


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: Carnage on January 10, 2013, 05:13:51 AM
we sure need to be able to add some true projectiles i would love the possibility of adding lucario aura sphere to several psas


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: DoctorFlux(Mariodk) on January 10, 2013, 07:43:40 AM
we sure need to be able to add some true projectiles i would love the possibility of adding lucario aura sphere to several psas
i know you mainly thinking on make mewtwo over someone then you say:
"i would love the possibility of adding lucario aura sphere to several psas"
but yeah i will also love that (or port pikmins article or make something like pikmin articles to over someone else like ike like replace the sword acticle with pikmins)


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: Carnage on January 10, 2013, 08:05:14 AM
i know you mainly thinking on make mewtwo over someone then you say:
"i would love the possibility of adding lucario aura sphere to several psas"
but yeah i will also love that (or port pikmins article or make something like pikmin articles to over someone else like ike like replace the sword acticle with pikmins)
but pikmins are diferent since they are in the pcs so i bet simple articles located in the fitmotion should be easier module wise but that is just a theory


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: pikazz on January 10, 2013, 10:33:46 AM
to be honest, if we continue to parche Module files at this speed, we may be able to add articles like next months and that's a good sign!


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: PhantomWings on January 10, 2013, 10:44:16 AM
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).


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: DoctorFlux(Mariodk) on January 10, 2013, 10:54:31 AM
to be honest, if we continue to parche Module files at this speed, we may be able to add articles like next months and that's a good sign!
but we needing also a add article button in brawlbox´s PSA for make this possible aswell


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: pikazz on January 10, 2013, 01:39:24 PM
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.

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).
that's great information!
I was cursious about the first thing you said about how it gets create but both of the you said was great information :3

hm, closer to ftFighter huh? that makes me curious, since ftFighter stands for loading what's inside the pacs like ModelData, TextureData. is it any chance the wnArticleName does the same thing? I mean loading it's ModelData, Texturedata, AnimationsData Ect for the article itself?
or does FtFighterName loads exactly everything in the PACs and PCS?
I think that the wnArticleName are standing for loading everything it needs cause that sounds most logical to me

got little confused about you said about the Articles Item Swap, do you mean it's stable or not? o.o

I will try to test things inside articles and more in soStatusUniq for more information.

but we needing also a add article button in brawlbox´s PSA for make this possible aswell
I gave him that request one week ago for articles testing, he said he would do it and I believe his words!



EDIT: I have looked into more of modules. Marth is the ONLY one that doesn't have an article! thats old news but he doesn't have a soArticleMediator.
you might say "jiggzlypruff dozn't haf articrul Duuuh" but Jigglypuff has actually ONE article (Jigglypuff Green Sleephat) so its using soArticleMediator.

PW, I dont think ftClassInfoImpl.Method[0][2] makes the soArticleMediator loads, the only thing I found was the FtChar gets load so I keep looking how soArticleMediator gets created! I believe it is something that you can turn on and off just like we did that to method[3][16]

more notes, I have found some more instresting things.
in FtMarth, Method[17][42] its refering to his final smash on his "Dash" action and "Hit" action, meaning that once he hit someone he goes to the "Hit" action (action 286 and 288)
Haven't test it but it's a therody

in FitLink, Method[17][52-53] are refering to his final smash on FinalStart! haven't find something more about it, just his finalstart! (Action 278)


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: Battleon469 on January 11, 2013, 11:43:35 AM
I know this sounds noobish but im not understand   :srs:


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: pikazz on January 11, 2013, 02:02:47 PM
I know this sounds noobish but im not understand   :srs:

trust me! it is confusing and I am not the guy who can teach about stuff on a good way :/

EDIT: Been fooling around
(http://i47.tinypic.com/10com5t.jpg)
(http://i48.tinypic.com/2u90cwh.jpg)

you can generate ANYTHING as a ITEM like this staryu bomb! but brawl/stage HAS to load it first if it isn't in Common3 or in your FitName/FitNameMotionEct as a Article Item before you can use your own.

means it needs to have a active staryu on stage before you can use your own! doesn't freeze if it are any staryus however


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: Eternal Yoshi on January 11, 2013, 05:34:08 PM
That looks cool.

Question: I remember you changing what .brres Final destination reads. Can you show me how I can change where an article is loaded?

Basically I want a specific article to be read from the costume files(FitSnake00.pac) instead of the motion file(FitSnakeMotionEtc.pac)


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: Carnage on January 11, 2013, 07:17:06 PM
That looks cool.

Question: I remember you changing what .brres Final destination reads. Can you show me how I can change where an article is loaded?

Basically I want a specific article to be read from the costume files(FitSnake00.pac) instead of the motion file(FitSnakeMotionEtc.pac)
that would be very inetresting also so we could have one slot articles gfx like mario psas having a fire ball for mario costumes,green fireball for luigi costumes and a pill for doctor mario costumes  just as an example but not sure if pikazz has found a way to make the that possible yet.


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: pikazz on January 12, 2013, 03:03:28 AM
That looks cool.

Question: I remember you changing what .brres Final destination reads. Can you show me how I can change where an article is loaded?

Basically I want a specific article to be read from the costume files(FitSnake00.pac) instead of the motion file(FitSnakeMotionEtc.pac)
the only problem is I dont know how to change between FitName00 and FitNameMotionEct, I know there are some Articles in FitName00 so it should be possible!
and I haven't found how its load yet! I dont know if everything loads from REL, I will try another therody of mine.

If it are possible, we need to first "where" it's loads ingame and how it get load/create


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: DoctorFlux(Mariodk) on January 12, 2013, 04:18:09 AM
awesome if this gets possible:
oneslot super sonic(but i dont think that will be possible cuz of filesize of FitSonicxx.pac/pcs)
or make a article that use only GFX model in the Fit"insert char. here".pac(like lucario´s aura sphere) to load the model/texture from Fit"insert char. here"XX.pac/pcs

so oneslot aura sphere got possible or other oneslot GFX models


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: pikazz on January 12, 2013, 05:13:21 AM
awesome if this gets possible:
oneslot super sonic(but i dont think that will be possible cuz of filesize of FitSonicxx.pac/pcs)
or make a article that use only GFX model in the Fit"insert char. here".pac(like lucario´s aura sphere) to load the model/texture from Fit"insert char. here"XX.pac/pcs

so oneslot aura sphere got possible or other oneslot GFX models
time for being opimist, I THINK it is possible to make super sonic load from FitChar00 but it might be more challanging to do that cause it loads from FitSonicFinal.pac instead for FitSonicMotionEct.
but I might be wrong, it might be easier to do that!

dont like to tell so much about this cause I still dont have clue how articles gets load (like the models, textures and animations), if it are from FitChar00 or FitCharMotionEct and more

but yeah, diffirent models on same "articles" would be pretty awesome


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: Battleon469 on January 13, 2013, 04:48:35 AM
does that mean that sonic could transform into supersonic just by taunting a bit like SMBZ mario?


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: Carnage on January 13, 2013, 06:03:44 AM
pikazz i hope you find a way so we can change the place where the article loads the gfx/animation but adding articles would still be better imo but go for the thing you are closest of finding how


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: pikazz on January 13, 2013, 06:52:59 AM
does that mean that sonic could transform into supersonic just by taunting a bit like SMBZ mario?
no, it means on one slot it can be supersonic, the otherslot it can be supershadow and next slot can be supersilvet ect if all 3 is over sonic. but the same time it is the same final smash! just diffirent models on the article


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: Carnage on January 13, 2013, 07:55:09 AM
no, it means on one slot it can be supersonic, the otherslot it can be supershadow and next slot can be supersilvet ect if all 3 is over sonic. but the same time it is the same final smash! just diffirent models on the article
and every projectile could also be one slot since the gfx is usually on the motion


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: pikazz on January 13, 2013, 07:59:33 AM
and every projectile could also be one slot since the gfx is usually on the motion
only the model would be oneslot cause the GFX it's using is from FitChar.pac, it tells "use this GFX and that" on each subactions, so it's not actually "pure" oneslot, only oneslot for the modelpart


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: Carnage on January 13, 2013, 10:10:19 AM
only the model would be oneslot cause the GFX it's using is from FitChar.pac, it tells "use this GFX and that" on each subactions, so it's not actually "pure" oneslot, only oneslot for the modelpart
yeah i meant the model  my guess is the info where to get the model should be on the rel becuase the move is called in moveset and the model is on another file


Title: Re: Let's look into Module Fíles (.rel) - Article "Item" Swap
Post by: pikazz on January 14, 2013, 02:48:56 PM
hm, things are getting complex now. some but not all articles using SoArticleMediatorNull.
dont know it's function. perhaps it's nulling the SoArticleMediatorImpl?

EDIT: look what I did!
Module File Hacking (http://www.youtube.com/watch?v=9mBP9Jka73o#ws)

successfully gave target test lv 5 a spring!
lv5 doesn't have a spring, the lv3 has!

also, you might notice there is 2 springs! the one on the left side doesn't work, only the one in the spike does!
and I dont know how to move spring model, I know it's somewhere in the module file where it would be but I haven't found it yet! and no, it didn't work with animations!

I am trying to get a thumb of how gimmick objects works on stages! this was pretty awesome

soon we will be able to add springs and other stuff to other stages like water, hitboxes ect!


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: Carnage on January 14, 2013, 04:50:32 PM
i think we can already add true water for a long time pikazz


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: Gamma Ridley on January 14, 2013, 05:26:37 PM
i think we can already add true water for a long time pikazz

Nope. Not yet.

Great work again, pikazz. Though I'll get real hype when I see these things implemented in an actual stage. XD


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: Carnage on January 14, 2013, 05:58:10 PM
Nope. Not yet.

Great work again, pikazz. Though I'll get real hype when I see these things implemented in an actual stage. XD
everyone seems to have true water in every stage so i just tough so lol


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: Sky Grounder on January 14, 2013, 10:49:38 PM
everyone seems to have true water in every stage so i just tough so lol
That's usually stages that are rel-ported over Jungle Japes though.


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: ForOhFor Error on January 15, 2013, 12:04:55 PM
That's usually stages that are rel-ported over Jungle Japes though.
Pretty much always, in fact. All the other water stages have weird quirks.


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: pikazz on January 15, 2013, 03:16:26 PM
not many of you understand but look what I did!

(http://i50.tinypic.com/1251gzb.png)

added a extra Inheritance named [censored]lol! I dont know what Inheritance does exactly but I believe it's something about loading stuff from Sora_Melee.
this is actually nessecary to add because all grGimmick things are using 5 Inheritance with a "special" Inheritance as the "fifth" place on the Inheritance list!

haven't TEST ingame, would be really surprised if it works!

will also try to add a new object later, I know exactly how I should do it!
just one problem, I dont know how to make that new object load ingame

EDIT: tested ingame, a instresting result! it froze exact the same time as the announcer saying "GO"
the whole stage gets loaded and even the characters but just at the "GO", everything freezes!


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: ForOhFor Error on January 15, 2013, 07:13:53 PM
Doing that in Final Destination?


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: pikazz on January 16, 2013, 06:57:20 AM
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!


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: PhantomWings on January 16, 2013, 11:42:00 PM
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")

0xCC BSSList.add(r3=obj, r4=finalizer, r5=new_node)
0xD8 BSSList.clear() (this is actually module finalizer[0])
0x13C ftLucario.ctor(r4=?, r5=?, r6=?, r7=?)

0xD388 ftLucarioExtendParamAccesser.ctor()
0xD3D0 ftClassInfoImpl.ctor()

0x11928 wnLucarioQigong.ctor(r4=?, r5=stack_data, r6=.pac_resource)
0x9B18 create_wnLucarioQigong_instance(r4=?)

0x8ECC init_ftLucarioTransactor()

Module Constructors:
0x712C soResourceModuleImpl.ctor(r4=owner, r5=?, r6=?, r7=soModuleAccessor)
0x7194 soModelModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?)
0x721C soMotionModuleImpl.ctor(r4=soModuleAccessor, r5=?)
0x73F0 soPostureModuleImpl.ctor(r4=soModuleAccessor, r5=?)
0x7460 soGroundModuleImpl.ctor(r4=soModuleAccessor)
[BASE] soSituationModuleImpl.ctor
0x6D0C soTeamModuleImpl.ctor(r4=?, r5=soModuleAccessor)
0x74C4 soCollisionAttackModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?, r7=?)
0x7588 soCollisionHitModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?, r7=?)
0x764C soCollisionShieldModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?)
0x7720 soCollisionShieldModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?)
[NULL] soCollisionShieldModuleNull
0x77F4 soCollisionCatchModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?)
[NULL] soCollisionSearchModuleNull
0x788C soDamageModuleActor.ctor(r4=soModuleAccessor, r5=?)
[BASE] soCatchModuleImpl.ctor
[BASE] soCaptureModuleImpl.ctor
[BASE] ftStopModuleImpl.ctor
[BASE] soTurnModuleImpl.ctor
0x78F8 soShakeModuleImpl.ctor(r4=soModuleAccessor, r5=?)
0x7954 soSoundModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?)
0x79E4 soLinkModuleImpl.ctor(r4=soModuleAccessor)
[BASE] soVisibilityModuleImpl.ctor
0x7A38 ftControllerModuleImpl.ctor(r4=soModuleAccessor, r5=?)
0x7AA8 soCameraModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?, r7=?)
[BASE] soWorkManageModuleImpl.ctor
[NULL] soDebugModuleNull
0x7B14 soAnimCmdModuleImpl.ctor(r4=?)
0x7B58 soStatusModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?)
[NULL] ftGeneralTermDisideModuleNull
[NULL] ftSwitchDecideModuleNull
0x8010 soKineticModuleGenericImpl.ctor(r4=soModuleAccessor)
[BASE] soEventManageModuleImpl.ctor
0x8440 soGenerateArticleManageModuleImpl.ctor(r4=soModuleAccessor)
0x863C soEffectModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?, r7=?, r8=?, r9=?)
[BASE] ftComboModuleImpl.ctor
0x8708 ftAreaModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?)
[NULL] soTerritoryModuleNull
[NULL] soTargetSearchModuleNull
0x87A0 soPhysicsModuleImpl.ctor(r4=soModuleAccessor, r5=?)
[BASE] soSlopeModuleImpl.ctor
[BASE] soShadowModuleImpl.ctor
0x8800 soItemManageModuleImpl.ctor(r4=soModuleAccessor, r5=?)
[BASE] soColorBlendModuleImpl.ctor
[BASE] soJostleModuleImpl.ctor
[BASE] ftAbnormalModuleImpl.ctor
[BASE] soSlowModuleImpl.ctor
[NULL] soReflectModuleNull
[BASE] soHeapModuleImpl.ctor
0xD67C ftLucarioParamCustomizeModule.ctor(r4=?)
[BASE] ftGlowModuleImpl.ctor

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


0x1257EC Fighter.base_ctor(r4=?, r5=id, r6=?, r7=?)

0x192D4C ftFighterBuildData.base_ctor(r4=?, r5=id, r6=?, r7=?, r8=?, r9=?)

0xD8E28 soInstanceManagerFixedSimple.base_ctor()

0x68598 soModuleAccessor.base_ctor(r4=owner, r5-r10=modules, r1=modules)

0x6F850 soResourceModuleImpl.base_ctor(r4=?, r5=?, r6=?)
0x77DC soModelModuleImpl.base_ctor(r4-r8=?)
0x13844 soMotionModuleImpl.base_ctor(r4=soModuleAccessor, r5=?)
0x23364 soPostureModuleImpl.base_ctor(r4=soModuleAccessor, r5=?)
0x2556C soGroundModuleImpl.base_ctor(r4=soModuleAccessor)
0x3513C soSituationModuleImpl.base_ctor(r4=?, r5=soModuleAccessor, r6=?)
0xB5048 soTeamModuleImpl.base_ctor(r4-r8=?)
0x39590 soCollisionAttackModuleImpl.base_ctor(r4-r10=?)
0x42AA4 soCollisionHitModuleImpl.base_ctor(r4-r10=?)
0x48A1C soCollisionShieldModuleImpl.base_ctor(r4-r10=?)
0x48A1C soCollisionShieldModuleImpl.base_ctor(r4-r10=?)
[NULL] soCollisionShieldModuleNull
0x4B184 soCollisionCatchModuleImpl.base_ctor(r4-r10=?)
[NULL] soCollisionSearchModuleNull
0x61454 soDamageModuleActor.base_ctor(r4-r8=?)
0x64C8C soCatchModuleImpl.base_ctor(r4=soModuleAccessor, r5=?)
0x65EE4 soCaptureModuleImpl.base_ctor(r4=soModuleAccessor)
0x154088 ftStopModuleImpl.base_ctor(r4=soModuleAccessor)
0x693F4 soTurnModuleImpl.base_ctor(r4=soModuleAccessor)
0x68888 soShakeModuleImpl.base_ctor(r4=?, r5=?, r6=?)
0x561E0 soSoundModuleImpl.base_ctor(r4-r9=?)
0x6A244 soLinkModuleImpl.base_ctor(r4=?, r5=?)
0x5B248 soVisibilityModuleImpl.base_ctor(r4=soModuleAccessor, r5=?, r6=?)
0x150320 ftControllerModuleImpl.base_ctor(r4-r7=?)
0xB215C soCameraModuleImpl.base_ctor(r4-r8=?)
0xA1DA4 soWorkManageModuleImpl.base_ctor(r4=soModuleAccessor, r5=?)
[NULL] soDebugModuleNull
0x1AB96C soAnimCmdModuleImpl.base_ctor(r4=?)
0x73930 soStatusModuleImpl.base_ctor(r4-r10=?)
[NULL] ftGeneralTermDisideModuleNull
[NULL] ftSwitchDecideModuleImplNull
0xB6DBC soKineticModuleGenericImpl.base_ctor(r4=?, r5=?, r6=?)
0x8EBF0 soEventManageModuleImpl.base_ctor(r4=owner)
0x92F10 soGenerateArticleManageModuleImpl.base_ctor(r4-r7=?)
0x9747C soEffectModuleImpl.base_ctor(r4-r10=?)
0x14FBD8 ftComboModuleImpl.base_ctor(r4=soModuleAccessor)
0x14DFE4 ftAreaModuleImpl.base_ctor(r4-r10=?)
[NULL] soTerritoryModuleNull
[NULL] soTargetSearchModuleNull
0x10158 soPhysicsModuleImpl.base_ctor(r4-r7=?)
0xACAC4 soSlopeModuleImpl.base_ctor(r4=soModuleAccessor, r5=?, r6=?, r7=?)
0xB62E4 soShadowModuleImpl.base_ctor(r4=soModuleAccessor, r5=?, f1=?)
0xB7E20 ItemManageModuleImpl.base_ctor(r4-r9=?)
0xBEBB4 soColorBlendModuleImpl.base_ctor(r4=soModuleAccessor, r5=?, r6=?)
0xC20D8 soJostleModuleImpl.base_ctor(r4=soModuleAccessor, r5=?, r6=?, r7=?)
0x196664 ftAbnormalModuleImpl.base_ctor(r4=soModuleAccessor)
0x5BED0 soSlowModuleImpl.base_ctor(r4=soModuleAccessor)
[NULL] soReflectModuleNull
0x649FC soHeapModuleImpl.base_ctor(r4=?, r5=?, r6=?, r7=?)
0x14B5F8 ftParamCustomizeModuleImpl.base_ctor(r4=?)
0x14CCEC ftGlowModuleImpl.base_ctor(r4=soModuleAccessor)

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


0x39BDA8 wnLucarioAuraBall.ctor(r4=?, r5=stack_data, r6=.pac_resource)
0x39B0A8 create_wnLucarioAuraBall_instance(r4=?, r5=?)

0x39A924 ftLucarioTransactor.ctor()


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.


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: pikazz on January 17, 2013, 08:40:58 AM
ooooh! nice information you got there, you need to get a promotion!
YOU'RE GETTING A PROMOTION! (http://www.youtube.com/watch?v=I9AHEXAcwao#)

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


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: Battleon469 on January 18, 2013, 04:45:08 AM
ok seriously WTF? Dr eggman said he's giving a promotion but he gets one himself???


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: PhantomWings on January 18, 2013, 04:18:20 PM
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 (https://www.dropbox.com/s/9j7324oupmz8gvm/Module%20Editor%20v1.zip)


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: pikazz on January 18, 2013, 05:00:23 PM
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 (https://www.dropbox.com/s/9j7324oupmz8gvm/Module%20Editor%20v1.zip)
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


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: SonicBrawler on February 01, 2013, 05:15:34 PM
*Reads PW's Post*

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

Hopefully someone else understood it.


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: pikazz on February 01, 2013, 05:26:37 PM
*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 :/


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: SonicBrawler on February 01, 2013, 05:47:35 PM
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


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: pikazz on February 07, 2013, 12:30:02 PM
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!


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: DarkPikachu on February 10, 2013, 08:02:02 AM
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 :)


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: pikazz on February 11, 2013, 04:43:53 PM
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 (http://forums.kc-mm.com/index.php?topic=49878.msg1011427#msg1011427)


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: DarkPikachu on February 13, 2013, 08:07:59 AM
@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...


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: Dantarion on February 13, 2013, 02:49:51 PM
Hello PhantomWings
http://opensa.dantarion.com/module2013/ (http://anonym.to/?http://opensa.dantarion.com/module2013/)


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: SonicBrawler on February 13, 2013, 04:12:44 PM
Hello PhantomWings
[url]http://opensa.dantarion.com/module2013/[/url] ([url]http://anonym.to/?http://opensa.dantarion.com/module2013/[/url])

That seems pretty helpful.


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: pikazz on February 13, 2013, 05:36:20 PM
Hello PhantomWings
[url]http://opensa.dantarion.com/module2013/[/url] ([url]http://anonym.to/?http://opensa.dantarion.com/module2013/[/url])

thats awesome :D
now it easy to compare how they are linked with the methods to the memory and m1B :3


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: DarkPikachu on February 13, 2013, 08:05:05 PM
well someone's been busy...

nice work Dant


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: Dantarion on February 14, 2013, 02:30:03 PM
http://i.imgur.com/U9ziKx2.png (http://i.imgur.com/U9ziKx2.png)
Testing module rebuilder huehuehuehuehuehuehue


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: DarkPikachu on February 14, 2013, 06:23:22 PM
"pyREL"?


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: pikazz on February 14, 2013, 11:59:46 PM
[url]http://i.imgur.com/U9ziKx2.png[/url] ([url]http://i.imgur.com/U9ziKx2.png[/url])
Testing module rebuilder huehuehuehuehuehuehue

where have you been :srs:

it looks awesome however! :D it also look that we can merge module files together O.o


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: BlueBrain on February 18, 2013, 12:29:19 PM
random question.

alloys, is their hardcoding (no hanging, no specials) stored in their .rel files?
if so, would it be possible to .rel port a character over an alloy?
if so, would there be any way of giving him more slots? (like how G&W has one file, but different slots)


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: pikazz on February 18, 2013, 02:31:31 PM
random question.

alloys, is their hardcoding (no hanging, no specials) stored in their .rel files?
if so, would it be possible to .rel port a character over an alloy?
if so, would there be any way of giving him more slots? (like how G&W has one file, but different slots)
it must be! somehow, G&W must have something that has a script that loads the slots through his one slot instead
I know I have seen something like this in Sora_melee about slots like Kirby instances and IC flag but I dont remember it quite well if it were actually "player slots"

the Alloys however seems to be load from "flags" to say "which one is which", seen the same in the Break the Target rel. if you make it over one other stage, it will always result at the Lv5 stage!


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: BlueBrain on February 18, 2013, 02:57:32 PM
so, if i understood that correctly, alloys work as the always dreamed for...
PSA-per slot?

it would be cool if alloys could make for new slots...


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: ♤♡◇♧ on February 18, 2013, 03:11:35 PM
Except they aren't PSA per costume slot...
Rather, they are grouped together inside one module for convenience sake.


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: pikazz on February 18, 2013, 03:17:45 PM
well, the alloys are stored in separed folders in one Module file so "yes". that "does" mean it is "one" slot psas! but still they are not!
sadly, they dont have B attack, entry, losing and winning actions inside their module file
and we dont know yet how to change between those 4 yet D:


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: pikazz on March 19, 2013, 04:45:31 PM
okay! here is some news about adding gimmicks to stages!

well, I dont have succeeded but the nearest I have come is that the wii is freezing with a loud PEEP noise! instead for all the other times it was just a silent freeze! I know I am close so I can smell it! want a "ball planket" to toss ideas with ;_;

however, some positive news! it might be small but all well, I successfully disable the spring gimmick in Stage Builder! I dont know if it will work on any other gimmick such as water or hitboxes. I will try to disable the water on Jungle Japes to make the stage more "melee" just to test things out

also I can make a character be totally oneother character in sora_melee thanks by Dant! example if you select rob you will be Lucario! it's damn perfect but too perfect! it still loads from Lucarios folder meaning it's not a clone, it's a perfect "original" character over a diffirent slot meaning it still share the same PSA! if you edit the PSA inside the Lucario folder, both lucario gets it

if we can find out how to make the Lucario over Rob slot loads it's data from the Rob Folder instead for the Lucario folder, that would mean we can to perfect "Clones" with articles and everything


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: BlueBrain on March 19, 2013, 08:01:43 PM
that's pretty interesting indeed, so instead of porting a character's rel, u'd do adjustments in a common file? i can see noob trouble coming... a lot of it... xD


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: pikazz on March 20, 2013, 01:08:23 PM
that's pretty interesting indeed, so instead of porting a character's rel, u'd do adjustments in a common file? i can see noob trouble coming... a lot of it... xD
I do it in Common2 in Miscdata[11] since it's the same relfile as sora_melee itself!

more progress! I am pretty sure I have done things right, but now it comes the tricky one. it seems I need to call the gimmick more through the main object in the module file which is in this case "stFinal".
but it's tricky and I am pretty much confused about this part!


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: PhantomWings on April 09, 2013, 11:38:21 PM
Well, well, what have we here?

(http://i49.tinypic.com/2zhkryw.jpg)

Now before the hype bandwagon gets kicked into high gear, there's a couple of things to note:


This is a very unstable test - a lot of what you see in the screenshot is the result of heavy modification of the game while it was running. The game also crashes when you exit the match.

Rob must be in the match to have the laser effect.

It is possible to load up Mario's fireball effect in place of the laser effect; this results in an odd merge between both articles. Mario shoots out a projectile that travels horizontally like a laser, but has the speed, hit effect, and damage of a fireball.

The laser was easy to copy into Mario's article bank because wnRobotLaser.ctor and ftRobotTransactor.instantiate_robot_laser are both stored as global functions in sora_melee due to Rob's laser being copyable by Kirby. Other articles are harder to replicate as their primary functions are stored inside the owner character's module file.




However, progress is progress, so I thought I'd report on it here. Here's hoping we can use this to generate more sophisticated custom characters.


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: Ultraxwing on April 10, 2013, 12:37:08 AM
 That's... just... amazing...

progress is progress; that's amazing


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: DoctorFlux(Mariodk) on April 10, 2013, 12:48:33 AM
Well, well, what have we here?

([url]http://i49.tinypic.com/2zhkryw.jpg[/url])

Now before the hype bandwagon gets kicked into high gear, there's a couple of things to note:


This is a very unstable test - a lot of what you see in the screenshot is the result of heavy modification of the game while it was running. The game also crashes when you exit the match.

Rob must be in the match to have the laser effect.

It is possible to load up Mario's fireball effect in place of the laser effect; this results in an odd merge between both articles. Mario shoots out a projectile that travels horizontally like a laser, but has the speed, hit effect, and damage of a fireball.

The laser was easy to copy into Mario's article bank because wnRobotLaser.ctor and ftRobotTransactor.instantiate_robot_laser are both stored as global functions in sora_melee due to Rob's laser being copyable by Kirby. Other articles are harder to replicate as their primary functions are stored inside the owner character's module file.




However, progress is progress, so I thought I'd report on it here. Here's hoping we can use this to generate more sophisticated custom characters.
is it now possible to port articles?
like having olimar´s Pikmins over Ike´s sword(i know 2 ppl here on kc-mm needing that for a PSA)


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: pikazz on April 10, 2013, 08:04:07 AM
Well, well, what have we here?

([url]http://i49.tinypic.com/2zhkryw.jpg[/url])

Now before the hype bandwagon gets kicked into high gear, there's a couple of things to note:


This is a very unstable test - a lot of what you see in the screenshot is the result of heavy modification of the game while it was running. The game also crashes when you exit the match.

Rob must be in the match to have the laser effect.

It is possible to load up Mario's fireball effect in place of the laser effect; this results in an odd merge between both articles. Mario shoots out a projectile that travels horizontally like a laser, but has the speed, hit effect, and damage of a fireball.

The laser was easy to copy into Mario's article bank because wnRobotLaser.ctor and ftRobotTransactor.instantiate_robot_laser are both stored as global functions in sora_melee due to Rob's laser being copyable by Kirby. Other articles are harder to replicate as their primary functions are stored inside the owner character's module file.




However, progress is progress, so I thought I'd report on it here. Here's hoping we can use this to generate more sophisticated custom characters.

okay! you just smash my head with a hammer! stop being so awesome and tell me what you did :srs:

well, dont stop being awesome and share some information of how you did! that might help alot!


Title: Re: Let's look into Module Fíles (.rel) - Almost Perfect Spring
Post by: DarkPikachu on April 10, 2013, 02:42:27 PM
well... I'm impressed :)
didn't think we'd get so far so fast ^_^


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: PhantomWings on April 11, 2013, 04:21:00 PM
okay! you just smash my head with a hammer! stop being so awesome and tell me what you did :srs:

well, dont stop being awesome and share some information of how you did! that might help alot!

Well, the whole process was rather lengthily, but I'll try to break it down the best I can.

It all starts in your target character's ctor function. For my case, I used ftMario.ctor. ftMario.ctor is located at file offset 0x13C. In one of my earlier posts I discussed how ftCharacter.ctor is responsible for creating the whole character memory object as well as all the module objects associated with it. In particular, we are interested in soGenerateArticleManageModuleImpl which is responsible for generating and manipulating character articles (characters without any articles will not implement this modules). Most ftCharacter.ctor functions generally take the same shape. This means that for most module files, the part of ftCharacter.ctor that calls soGenerateArticleManageModuleImpl.ctor is usually around file offset 0x850. As it turns out, the constructor call for Mario's article module is located at file offset 0x838. Following this call we find out that the soGenerateArticleManageModuleImpl.ctor function is located at file offset 0x5A74 inside ft_mario.rel

Before I go into the soGenerateArticleManageModuleImpl.ctor function, I want to explain how the soGenerateArticleManageModuleImpl object is stored in memory. It is difficult to describe it using memory offsets, so I'll describe it as a basic C++ definition.

Code:

struct soGenerateArticleManageModuleImpl
{
    soArrayVector<wnArticle *, N> (size: 0xC + N * 0x4)
    soArrayVector<wnArticleEventObserver, N> (size: 0xC + N * 0x10)

    struct soArticleMediatorImpl
    {
         soInstancePool<...>
         soInstancePoolSub<...>[N]
    }
}


It may not make a whole lot of sense as it's just a definition, but try to keep it in mind when reading about the constructor function.



For Mario, the constructor function performs the following actions at the associated file offsets:

0x5A94 soArrayVector<wnArticle *, 5>.ctor(this)
0x5AA4 soArrayVector<wnArticleEventObserver, 5>.ctor(this + 0x20)
0x5AB4 [this + 0x7C] = soArticleMediatorImpl.declaration
0x5AA8 var soArticleMediator_ptr = this + 0x7C


Notice that the offsets 0x20 and 0x7C are equal to the summed sizes of the previous elements. That is:

0xC + 5 * 0x4 = 0x20
0xC + 5 * 0x10 = 0x5C

0x20 + 0x5C = 0x7C

This is important as you must make sure all you objects are not overlapping with other objects in memory when it comes to adding your own articles.

After these 3 base actions have been performed, there's two ways the function can go about creating articles. The first is the most basic; the constructor function does this starting at 0x5AC4:

0x5AC0 var soInstancePool<...>_ptr = this + 0x84
0x5ACC [this + 0x84] = soInstancePool<...>.declaration
// [this + 0x84] == [soArticleMediator_ptr + 0x8]

0x5AD8 [this + 0x88] = soInstancePoolSub<wnMarioHugeFlame, ...>.declaration
// [this + 0x88] == [soInstancePool<...>_ptr + 0x4]

0x5ADC var wnInstanceHolder<...>_ptr = soArticleMediator + 0xC
0x5AE8 [this + 0x90] = wnInstanceHolder<wnMarioHugeFlame, ...>.declaration
// [this + 0x90] == [wnInstanceHolder<...>_ptr + 0x00]

0x5B2C ftDataProvider.get_wnMarioHugeFlame_.pac_data(character_id = 0)
0x5B40 wnMarioHugeFlame.ctor(wnInstanceHolder<...>_ptr + 0x4, ...)

That's probably a lot of information to take in there, but suffice it to say, those 7 primary instructions are responsible for creating the wnMarioHugeFlame object - Mario's Final Smash. Whenever you want to create an article that only appears as a single instance onscreen, then this is the structure that gets used. Besides the offsets and function references, the structure mostly stays the same.

The second method for generating articles is used for articles that appear as multiple instances onscreen - such as Mario's fireballs. They get created starting at 0x5BBC:

// update the soInstancePool declaration with a new one containing the articles we're going to add.
0x5BC4 [this + 0x84] = soInstancePool<...>.declaration
0x5AC0 var temp = this + 0x20000
// [this + 0x84] == [soArticleMediator_ptr + 0x8]
// temp is used due to limitations in PowerPC's adding capabilities

0x5BD4 [temp - 0x5600] = soInstancePoolSub<wnMarioFireball, ...>.declaration
0x5BD8 var soInstancePools_ptr = temp - 0x5FFC
0x5BE4 [temp - 0x5FFC] = soInstancePoolSub<wnMarioFireball, ...>.declaration
0x5BF0 [temp - 0x5FF8] = soInstancePoolSub<wnMarioFireball, ...>.declaration
0x5C00 [temp - 0x5FF4] = soInstancePoolSub<wnMarioFireball, ...>.declaration
0x5C0C [temp - 0x5FF0] = soInstancePoolSub<wnMarioFireball, ...>.declaration
// These are written immediately following the previously created article.

0x5C18 Create_wnMarioFireball_holder_and_article(soInstancePools + 0xC, ...)
0x5C24 Create_wnMarioFireball_holder_and_article(soInstancePools + 0x1F54, ...)
0x5C30 Create_wnMarioFireball_holder_and_article(soInstancePools + 0x3EA4, ...)
0x5C3C Create_wnMarioFireball_holder_and_article(soInstancePools + 0x5DEC, ...)
0x5C48 Create_wnMarioFireball_holder_and_article(temp + 0x2738, ...)
// Once again, these offsets are immediately following the soInstancePoolSubs we just created.


The Create_wnMarioFireball_holder_and_article is another function inside ft_mario.rel - it can be found at file offset 0x7AF4. The function does exactly what it says.



So to summarize, the first method for creating articles has you updating the instance pool; creating the instance pool sub and instance holder; obtaining the .pac data; and creating the article all in the main function. The second method involves updating the instance pool, creating the instance pool subs and then calling the helper function to actually create the instance holder, obtain the .pac data, and create the article.



When it came to me adding ROB's laser, I replaced Create_wnMarioFireball_holder_and_article's wnMarioFireball.ctor and ftDataProvider.get_wnMarioFireball_.pac_data calls with calls to wnRobotBeam.ctor and ftDataProvider.get_wnRobotBeam_.pac_data. This wasn't a problem because both articles are Kirby-Copy articles meaning these functions were stored in sora_melee. When replacing the get .pac data function, it is also necessary to change the id being passed to it (or you can leave Mario's get .pac data function and end up with a weird mixture of both of them like I mentioned above).

I should also mention that the actual wnInstanceHolder and soInstancePoolSub declarations don't need to be changed as they are just primitive data structures that all have exactly the same shape and functionality.

Additionally, I removed all but the first call to Create_wnMarioFireball_holder_and_article as wnRobotBeam is actually larger in size than wnMarioFireball and - like I said ealier - you can't have objects overlapping in memory (you can find the size of wnMarioFireball by subtracting the offsets that are passed to Create_wnMarioFireball_holder_and_article).

Finally, I had to change the article count references and the call to ftMarioTransactor.instantiate_wnMarioFireball located inside soArticleMediatorImpl. If these count values weren't changed, then the game will crash by trying to access the other 4 article instances which I removed.

I've listed the basic details on that in one of my earlier posts, but to find everything you'll need to know the function listing of soArticleMediatorImpl:

Code:
soArticleMediator : soArticleGenerator, soArticleOperator

soArticleGenerator
Method[0][0] Finalizer
Method[0][1] GenerateArticle(r4=id, r5=soModuleAccessor)
soArticleOperator
Method[1][0] Method[0][0] Thunk
Method[1][1] Method[1][8] Thunk
Method[1][2] ClearInstances()
Method[1][3] ClearInstances(r4=soModuleAccessor, r5=id)
Method[1][4] GetInstanceCount(r4=soModuleAccessor, r5=id)
Method[1][5] GetInstanceCap(r4=id)
Method[1][6] GetArticleCount()
Method[1][7] SetEnabled(r4=val)
Method[1][8] PSA_Event_1001(r4=soModuleAccessor, r5=soArticle)




A lot of this was trial and error and there isn't really a consistent way of finding everything. Even after doing all that, there were still a couple of bugs which I had to resolve using WiiRD - and I'm not even sure what exactly was causing it.

Anyways, make of it what you will. Hopefully you'll be able to work something out with it. Like I said before: it's pretty complicated.


... Long post is long.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on April 11, 2013, 04:32:03 PM
[censored], I thought it was more information xD

but that looks pretty easy when you describe it so I will try to make that aswell with fireball and robs laser! will also try to find something else to do like Lucas PKFreeze or Aura Sphere

but thank you really much to put that giant information! it will really come in handy!


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: KnightMario on April 11, 2013, 04:32:38 PM
...Whoa
Mind... blown


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: PhantomWings on April 25, 2013, 10:23:17 PM
Well, Rob's laser has been successfully ported over to Mario. It turns out I forgot to change the calls for wnMarioFireball.dtor to wnRobotLaser.dtor. There's also an oddity in the instantiation function which seems to use Mario's FLUDD charge time (viewable in BrawlBox) as a bone index for where the laser should be generated. As Mario's model doesn't contain a Bone 90, the game was crashing whenever it tried to create one.

Aside from that, Mario's Article1 parameters are now used as parameters for Rob's laser. The laser functions as it should including its ricochet behavior - however I still haven't found a way to allow Mario to aim it when shooting it. There is also a problem in that the laser uses Rob's laser effect meaning that if Rob isn't in the match, it will only appear a white polygon trail - I think BrawlBox's latest REFT editor should be able to fix that though.

I've learned a lot about articles and their constructors from this experiment. For the most part, articles are constructed almost identically aside from a few minor tweaks to the resulting object. Another interesting thing to note is that articles are also constructed nearly identically to actual characters - meaning it may be possible sometime in the future to use a character as an article.


I've also been experimenting a little bit with using menu_selchar.rel and menu_selchar_access.rel to implement the custom CSS code and include localized (and extendable) character color and icon options (think Brawl Masquerade) - but I think it would be better if I found a way to load a custom extension module file instead which all main game modifications can be pooled inside.




Anyways, here's the Laser Mario files. Right now you can only shoot one laser at a time because I only made one instance holder for it. Adding multiple instance holders - while possible - would take a substantial amount of manual hex editing that's not really necessary for the sake of this experiment.

I've also made a couple of cosmetic changes to the laser's behavior - that was mostly just for fun.

Laser Mario (https://www.dropbox.com/s/hkyyd1qhcen5jvx/Laser%20Mario.zip)


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: Ultraxwing on April 25, 2013, 11:17:01 PM
 Characters that could be modules in themselves? only phantomwings. only you... could even concieve of such a thought...

this little experiment was to situate how "articles" were loaded? so in essence if enough research is done we might be able to make our own fully functional original articles


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on April 25, 2013, 11:19:45 PM
you sure are just simply amazing! but saying you are amazing are disrespectful!

you are phantomtastic :srs:

I will look into your work to save notes, this is simply just amazing! that was a huge step for future articles!


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: Eternal Yoshi on April 25, 2013, 11:20:00 PM
Excellent.

Would you err.. be able to help me gather data on adding actions/subactions to articles safely?
Or adding special action grabs to characters like Snake?

My movesets kinda demand it at this point.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: Ultraxwing on April 25, 2013, 11:25:16 PM
Excellent.

Would you err.. be able to help me gather data on adding actions/subactions to articles safely?
Or adding special action grabs to characters like Snake?

My movesets kinda demand it at this point.

haven't seen you in a while, which i guess might be the character that has tentacles. you had problems getting him to grab.

this sounds interesting.

i'm just awaiting the day of true perfect .rel ports or a decent clone engine, and Phantomwings mentioned external modifications of newer .RELS the game loads. plugins? i can't wait for what's in store


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: Carnage on April 26, 2013, 02:13:44 AM
Now we only need a tool that would let us port articles on to the chars fitchar.pac xD i would love to be able to port chars articles around.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: Ultraxwing on April 26, 2013, 03:46:29 AM
Now we only need a tool that would let us port articles on to the chars fitchar.pac xD i would love to be able to port chars articles around.

 as though this would be super omg sexy. wouldn't Brawl Modding be easy? i mean i would like it to be easy so when i finally make one of the few hacks i have planned (after model updates =/) I mean wouldn't we be too busy getting used to the idea of just having articles rather than having unique work arounds like we've been doing. though making a character truly functional in every sense including reflectable projectiles and not so funky counters might be for the best.

i can see problems, but the positives outweigh the negatives by a large margin.

and again Thank you again Phantomwings you are our little Savior in this realm of modification


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: Moblin on April 26, 2013, 09:19:20 AM
I've also been experimenting a little bit with using menu_selchar.rel and menu_selchar_access.rel to implement the custom CSS code and include localized (and extendable) character color and icon options (think Brawl Masquerade)
I would pay money for this, no joke.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: Carnage on April 26, 2013, 09:46:50 AM
if we could add ppl instead of replacing brawl hacking would be an all new thing for sure.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: DoctorFlux(Mariodk) on April 26, 2013, 10:34:05 AM
if we could add ppl instead of replacing brawl hacking would be an all new thing for sure.
think about the filesize of the CSS file then its possible to add more slots
i think that will be a problem


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: BlueBrain on April 26, 2013, 10:35:23 AM
think about the filesize of the CSS file then its possible to add more slots
i think that will be a problem
are you serious?
look at stage expansion...
you just need to lower all images' resolution for more filesize


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: Shun_One on April 26, 2013, 11:01:46 AM
I've also been experimenting a little bit with using menu_selchar.rel and menu_selchar_access.rel to implement the custom CSS code and include localized (and extendable) character color and icon options (think Brawl Masquerade) - but I think it would be better if I found a way to load a custom extension module file instead which all main game modifications can be pooled inside.
I would imagine something like this would help with the bizarre Plug&Play .rels behavior in regards to costume slots. In case you weren't aware, I've found that if you port a character to another who has a FitChar## that the original does not, that costume can't be selected.

For me, I've got Roy over ROB and Mewtwo over Jiggs. Roy can't access FitRobot06, it loads FitRobot00 instead. Mewtwo can't get FitPurin03.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: PhantomWings on April 26, 2013, 02:02:28 PM
I would imagine something like this would help with the bizarre Plug&Play .rels behavior in regards to costume slots. In case you weren't aware, I've found that if you port a character to another who has a FitChar## that the original does not, that costume can't be selected.

For me, I've got Roy over ROB and Mewtwo over Jiggs. Roy can't access FitRobot06, it loads FitRobot00 instead. Mewtwo can't get FitPurin03.


The Plug&Play modules cover color restrictions as well to prevent crashing in case one of the original's colors aren't covered by the new character's. If you want to remove the color restrictions on Marth's module, just change the flags at 0xE6 in Section[8] of Marth's module.

The flags are documented here (http://anonym.to/?http://opensa.dantarion.com/wiki/Instance_Slots) under Costume Flags.

Just remember that you need to make sure that all interface elements including CSPs and battle portraits exist for the additional colors.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on April 26, 2013, 02:08:52 PM
okay, I have looks everywhere of how you did :srs: wanna port it to pal but I cant find how you did!

could you pm me of how you did and where you changed? cause it is just simply amazing!

if you have time and want that ofcourse!


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: Shun_One on April 26, 2013, 07:29:09 PM
The Plug&Play modules cover color restrictions as well to prevent crashing in case one of the original's colors aren't covered by the new character's. If you want to remove the color restrictions on Marth's module, just change the flags at 0xE6 in Section[8] of Marth's module.

The flags are documented here ([url]http://anonym.to/?http://opensa.dantarion.com/wiki/Instance_Slots[/url]) under Costume Flags.

Just remember that you need to make sure that all interface elements including CSPs and battle portraits exist for the additional colors.
Ah, I see now. Thanks for telling me that. I'll mess around with it some on my own now.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: PhantomWings on April 27, 2013, 08:47:09 PM
okay, I have looks everywhere of how you did :srs: wanna port it to pal but I cant find how you did!

could you pm me of how you did and where you changed? cause it is just simply amazing!

if you have time and want that ofcourse!

The main areas I changed - in broad terms - are as follows:

0x5C20: Removed all but one call to Create_wnMarioFireball_holder_and_article
0x7B60: Changed Create_wnMarioFireball_holder_and_article to call wnRobotBeam.ctor instead of wnMarioFireball.ctor.
0x7BB4: Changed wnInstanceHolder<wnMarioFireball>.Method[0][0] to call wnRobotBeam.dtor instead of wnMarioFireball.dtor
0x7C10: Removed all but the first call to soInstanceHolder<wnMarioFireball>.Method[0][0]
0xAEA4: Changed wnArticleMediator.Method[0][1] to only check the first instance holder when creating an instance of wnRobotBeam
0xAFB0: Changed wnArticleMediator.Method[0][1] to call wnRobotBeam.instantiate instead of wnMarioFireball.instantiate
0xB3D0: Changed wnArticleMediator.Method[1][3] to only try to clear 1 wnRobotBeam instance.
0xB6E8: Changed wnArticleMediator.Method[1][4] to only check 1 wnRobotBeam instance holder.
0xB950: Changed wnArticleMediator.Method[1][5] to return an instance cap of 1 for wnRobotBeam
0xBD80: Changed wnArticleMediator.Method[1][2] to only clear 1 wnRobotBeam instance.

Just for reference, the method listing for wnArticleMediator is as follows:

Code:
soArticleMediator : soArticleGenerator, soArticleOperator

soArticleGenerator
Method[0][0] Finalizer
Method[0][1] GenerateArticle(r4=article_id, r5=soModuleAccessor)
soArticleOperator
Method[1][0] Method[0][0] Thunk
Method[1][1] Method[1][8] Thunk
Method[1][2] ClearInstances()
Method[1][3] ClearInstances(r4=soModuleAccessor, r5=Article_id)
Method[1][4] GetInstanceCount(r4=soModuleAccessor, r5=article_id)
Method[1][5] GetInstanceCap(r4=article_id)
Method[1][6] GetArticleCount()
Method[1][7] SetEnabled(r4=val)
Method[1][8] PSAEvent1001(r4=soModuleAccessor, r5=soArticle)



It seems like a lot, but the actual number of instructions I changed is probably no more than 20. If you compare the modified module to the original Mario module, you should be able to get a good idea of what needs to be changed in the PAL version.




Concerning the file size limits: I think I may have stumbled upon a code that can be used to increase the amount of memory allocated towards stage icons. Unfortunately Brawl makes almost full use of the Wii's memory, so there's not a lot of room for expansion. However, it seems that you can safely increase the limit by approximately 510kb without causing the game to run out of memory.

Anyone care to test this for me? You'll need a sc_selmap.pac file that exceeds the normal size limit.

Code:

MenuResource Expansion (+510kb)
04422384 006E6700




Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: Shun_One on April 27, 2013, 09:20:37 PM
Concerning the file size limits: I think I may have stumbled upon a code that can be used to increase the amount of memory allocated towards stage icons. Unfortunately Brawl makes almost full use of the Wii's memory, so there's not a lot of room for expansion. However, it seems that you can safely increase the limit by approximately 510kb without causing the game to run out of memory.

Anyone care to test this for me? You'll need a sc_selmap.pac file that exceeds the normal size limit.

Code:

MenuResource Expansion (+510kb)
04422384 006E6700


It worked. I didn't want to push it too hard initially, so I went with a lower file-size to start with. Only .01 mb bigger than the limit, but the game didn't freeze.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: Eternal Yoshi on April 28, 2013, 04:57:37 AM
This looks cool. Would you be able to do that code for say characters? Samus and Zamus are characters that have notoriously strict memory limits and I think it would be amazing if there was a way to allocate at least 50 more kb than what Brawl has allocated for them.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on April 28, 2013, 09:54:01 AM
PW, you are so amazing :srs:
(http://i40.tinypic.com/34dmxyo.jpg)
(PAL version)

I will try to see if it are any more articles we can port to other one. I bet all articles thats used by the Special B can be ported like luigis fireball, samus Charge Beam ect


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: PhantomWings on April 28, 2013, 11:50:51 AM
This looks cool. Would you be able to do that code for say characters? Samus and Zamus are characters that have notoriously strict memory limits and I think it would be amazing if there was a way to allocate at least 50 more kb than what Brawl has allocated for them.

Memory heaps are allocated by player as opposed to character. Each player has 4 memory heaps allocated to them. For player 1, they are:

[00553400] Fighter1Resource
[00087C00] Fighter1Resource2
[00052000] Fighter1Instance
[00048500] OverlayFighter1

Judging from the sizes, I would say Fighter1Resource is used for the model and Fighter1Resource2 is used for movesets and effects. Fighter1Instance is used specifically for the runtime character instance and I know that OverlayFighter1 is used for storing and executing the character's module.

As a side note, because there are only 4 fighter slots, alloys are stored collectively inside the Fighter3 and Fighter4 heaps - they can get away with this because they are smaller.

As far as increasing the size of these goes, we only have 510kb to work with - so if we were to distribute them over the 4 Resource2 heaps, it would only be an increase of about 128kb each.


I will try to see if it are any more articles we can port to other one. I bet all articles thats used by the Special B can be ported like luigis fireball, samus Charge Beam ect

The hardest part is finding the article ctor and dtor functions as well as the instantiation function. If you can find those 3 functions and the proper parameters to pass in when calling them, then porting them shouldn't be a problem.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: BlueBrain on April 28, 2013, 11:57:29 AM
on the filesize issues, i found out by experience that the costume and PSA/animations work all together in setting a limit, i noticed because i made a small PSA and animation edit for akuma, and it froze with my import, but worked perfectly with ganon's regular outfits


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on April 29, 2013, 12:37:13 PM
PW! I found something intresting! character that has 2 or more character example Samus/ZZS (especially Samus) seems to have all their articles in Sora_melee, somehow I found its Ctor but I cant find it again ;_;

dont quite understand how to find Ctor, is it when a offset subtract itself? example at wnAuraBall in sora_melee, it substract itself! the Ctor of wnAuraBall is 39 CC 3C and that offset in sora_melee subtract itself with "39 CC 38".

and do you know how to find Dtor? some is easy to spot cause they are relocationdata'd to sora_melee, to a weapons Method[0][22] offset - 0x8! example to "wnSamusCShot" but some seems just impossible to find D:

last question! do you know a way to find the Ctor part to change in offset easier? example the offset at 7B60 in ft_mario.

(yeah, kinda noobish question D: sorry)


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: PhantomWings on May 01, 2013, 01:53:32 PM
I've found that the best way to find the location of an article's ctor is to look for the place where the game ordinarily calls it. For this case, all articles' ctors are called from soGenerateArticleManageModuleImpl. Finding the soGenerateArticleManageModuleImpl.ctor function is probably the hardest part as the only suggestion I can make is that it's usually around 0x850 inside the file (For Samus' case, soGenerateArticleManageModuleImpl.ctor is called at 0x830 and the actual function starts at 0x8434).

Once inside the soGenerateArticleManageModuleImpl.ctor, I primarily work visually. When searching for article ctors, I usually look for routines that look like one of the following two possibilities:


(http://i39.tinypic.com/oida8x.jpg)

(http://i40.tinypic.com/2s9pxyc.jpg)


For the above two examples, the selected functions are calling wnSamusGBeam.ctor and Create_wnSamusCShot_holder_and_article. In the second case, Create_wnSamusCShot_holder_and_article is called 4 times for each of the 4 ChargeShot instances that Samus is allowed on screen at one time. If you want to find the actual wnSamusCShot.ctor, just go into Create_wnSamusCShot_holder_and_article and you'll find it at a point that looks like this:


(http://i40.tinypic.com/c8d39.jpg)


Note that in these two cases, wnSamusGBeam.ctor and wnSamusCShot.ctor are both contained in sora_melee. However, in some cases, they may be contained within the owner character's module - even if there exists a similar ctor in sora_melee.

Also, it's difficult to determine which .ctor belongs to what object just by examining the function call. But there's an easy way to find out if you look at the wnInstanceHolder<...> that is created before it. If you look a little bit above the function call in either of the two above cases, you'll find:


(http://i39.tinypic.com/33bh72x.png)


Which tells you the instance holder of the article is being created. Alternatively, it seems like the articles are generated in reverse order to how the wnInstanceHolder objects are listed when viewing the module in Module Editor 2.



Finding the .dtors is a bit easier. Like you said, the article's Method[0][22] is usually the article's .dtor - but you can also check the wnInstanceHolder<...>.Method[0][0] which is also responsible for calling the article's .dtor:


(http://i41.tinypic.com/15dquzc.jpg)



That's about it. There's a small bit on finding the wnSamusCShot.instantiate and wnSamusGBeam.instantiate functions, but for that, you'll mostly be using the same basic principles inside soArticleMediator.Method[0][1] for the calls to both of those functions.

As for why Samus/ZSS have all their articles stored in sora_melee is most likely so that when they transform, existing articles onscreen don't get unloaded when the old character gets replaced by the new one. That's more helpful for us though as we should be able to generate those articles on any character we like.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on May 03, 2013, 06:47:03 PM
amazing work as always PW!

almost successfully made samus charge shot work on mario! it doesnt freeze ingame but yet it are invisble ingame, doesnt deal or flinch and freeze when you end a match! I believe I got the "charge up" charge beam O.o will try diffirent instance slot or samus missile!

EDIT: it appears that I forgot about the instiance :/ cant find it but I except where it is!
I believe the instiance is just before the characters initializer in sora_melee, meaning that samus initializer would be between initializer[224] and [223]. cause as far I have seen, they like to be before it! it's worth a try!


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: PhantomWings on May 03, 2013, 10:59:47 PM
Finding the article instantiators requires a little bit of leg work, but as long as you know where to look, it's not that hard. Start from soArticleMediator<...>.Method[0][1]. From there:


(http://i40.tinypic.com/346uk5d.png)


In this case, wnSamusCShot.instantiate is contained within ftSamus.rel at Section[1] +0x94F0. As you suggest, there is also most likely another wnSamusCShot.instantiate function stored in sora_melee to be used by Kirby, but unfortunately I haven't found a reliable way of finding Kirby's instantiator functions yet.

Fortunately, I took a look at the wnSamusCShot.instantiate function stored in ftSamus.rel and it seems to be mostly self-contained. So it shouldn't be too hard if you want to try to copy it over to ftMario.rel and call it from there.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on May 04, 2013, 03:02:55 AM
Finding the article instantiators requires a little bit of leg work, but as long as you know where to look, it's not that hard. Start from soArticleMediator<...>.Method[0][1]. From there:


([url]http://i40.tinypic.com/346uk5d.png[/url])


In this case, wnSamusCShot.instantiate is contained within ftSamus.rel at Section[1] +0x94F0. As you suggest, there is also most likely another wnSamusCShot.instantiate function stored in sora_melee to be used by Kirby, but unfortunately I haven't found a reliable way of finding Kirby's instantiator functions yet.

Fortunately, I took a look at the wnSamusCShot.instantiate function stored in ftSamus.rel and it seems to be mostly self-contained. So it shouldn't be too hard if you want to try to copy it over to ftMario.rel and call it from there.

damn, that would be hard D: I am not that good at ASM codes to copy it over from Samus to Mario :c but I can try!

if you can show me how you did found out Robs Instiance code (that mario uses) and where it was in the ftRobot, that might give alot of clues!


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: PhantomWings on May 05, 2013, 10:08:43 AM
I found Rob's wnRobotBeam instantiator using the exact same method as I showed you above. It gets called at file offset 0xA1FC. Unlike wnSamusCShot.instantiate which is located in ft_Samus.rel, wnRobotBeam.instantiate is located in sora_melee at m1b[1] +0x3A313C

I actually got a little bit lucky with wnRobotBeam.instantiate because the one Rob normally calls requires an extra parameter that most characters don't usually have available in their soArticleMediator.Method[0][1]. However, it turns out that the Kirby version of wnRobotBeam.instantiate is located just before the normal one at m1b[1] +0x3A3048. The kirby version doesn't require the extra parameter, so that's the one I used for Mario.

As far as what you can do for wnSamusCShot.instantiate, you can either try to find the sora_melee Kirby version of the function or you can try to copy the ft_Samus.rel version of the function. If you want to try to copy the ft_Samus.rel version of the function, then you'll mostly just be doing the same thing you did when you tried to port Special Grabs to other characters.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on May 05, 2013, 11:39:35 AM
hm, the copy from samus to mario seems easy cause we did that to special grab! however, the instantiate seems more "advance" than the special grab :/ I wonder if it has any special/hidden relocationdata like special grab had inside a diffirent method.

can try that if I fail to find Kirby version!

edit: I think I will copy for testing! however, I do not quiet understand one thing.
I followed you guide on how to find the instantiate on both mario and samus! it seems that boths are just under both "mr" command. however, now the thing I do not understand (and probely a stupid question cause I am tired)
Mario has its instantiate as "bl 9DE4", does this mean that the whole method at offset 9DE4 in the file its instantiate?

so we can basically change the instantiate to simply redirect the "bl 9DE4" to something like "bl DEADBEEF"/"bl 10234C" and have the copied instantiate on the offset that bl are calling?


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: PhantomWings on May 06, 2013, 09:36:27 AM
I think I will copy for testing! however, I do not quiet understand one thing.

I followed you guide on how to find the instantiate on both mario and samus! it seems that boths are just under both "mr" command. however, now the thing I do not understand (and probely a stupid question cause I am tired)
Mario has its instantiate as "bl 9DE4", does this mean that the whole method at offset 9DE4 in the file its instantiate?

so we can basically change the instantiate to simply redirect the "bl 9DE4" to something like "bl DEADBEEF"/"bl 10234C" and have the copied instantiate on the offset that bl are calling?

Yeah, I think you've summed everything up pretty well. The bl operation is essentially a function call similar to how you might call a method from an object such as soArticleMediator (however, those kinds of calls will more often use bctrl which is slightly different).

Just remember that the  bl operation uses a relative offset from its position meaning that the file offset you see in Module Editor will actually be the sum of the bl operation's position + the relative offset stored inside the bl operation. Alternatively, you can place a relocation (type 0xA) ontop of the bl operation which will automatically set the destination to where the relocation points to.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on May 06, 2013, 12:42:03 PM
well, I tried but failed xD I tried with a new section but yet it were same problem and froze on generating article ingame!
I might have done the otherstuff wrong together with the instantiate :/

or it dont like new sections and prefer those things in section1 :/, damn I can smell the flowers but they are miles away


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: BlueBrain on May 18, 2013, 08:49:54 AM
just thought, do the transforming characters load eachother because of their rel?
and if so, would it be possible to make .rels for transforming characters so they ONLY load their own files?


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on May 18, 2013, 09:11:39 AM
just thought, do the transforming characters load eachother because of their rel?
and if so, would it be possible to make .rels for transforming characters so they ONLY load their own files?
its because the all the transforming characters have 2 rels in one rel file, yet it using 2 diffirent IDs! if you look into zeldas module, you can see that it also have the whole sheik in it!

I am possible sure that you cant transform between 2 modules however :/


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: BlueBrain on May 18, 2013, 09:19:10 AM
oh, that seems to be a pain...
so there is no way to separate them?
mainly for filesize purposes, since most PSAs dont eve have a companion PSA


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: E-scope12 on January 14, 2014, 10:42:58 AM
Do brawl stage .rels have something similar to VIS0?


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: PhantomWings on January 14, 2014, 12:45:21 PM
Do brawl stage .rels have something similar to VIS0?


I don't think there is any similarity to the VIS0 files and stage modules. For that matter, modules in general are considerably different from most other resource files. This is partially why BrawlBox had so much trouble supporting them.



On another note, if anyone's interested in looking further into transforming characters, all I really know is that all transforming characters (except for the Pokèmon trio) can transform on demand using the PSA command 0C050000 (tagged by PSA as "Terminate Instance"). The code for 0C05 references assembly inside the character's module itself, so this command does not work for regular characters. However, if anyone's interested, the assembly code behind the 0C05 command can be found using the Module Editor 2 inside ft<fighter>.Method[3][15]

(http://i40.tinypic.com/2d6pij9.png)

The code is nearly identical for all transforming characters and exclusively references methods and addresses in sora_melee. So I don't think porting it to other characters should be too difficult. On the other hand, I couldn't find anything determining which character they transformed into - it's possible that that kind of configuration could be located elsewhere or be determined by their Slot configuration.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: BlazingFury on January 14, 2014, 12:47:47 PM
PW can you please give me the meta knight plug play rel?   :oshi:


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on January 14, 2014, 01:00:13 PM
huge post
I don't think there is any similarity to the VIS0 files and stage modules. For that matter, modules in general are considerably different from most other resource files. This is partially why BrawlBox had so much trouble supporting them.



On another note, if anyone's interested in looking further into transforming characters, all I really know is that all transforming characters (except for the Pokèmon trio) can transform on demand using the PSA command 0C050000 (tagged by PSA as "Terminate Instance"). The code for 0C05 references assembly inside the character's module itself, so this command does not work for regular characters. However, if anyone's interested, the assembly code behind the 0C05 command can be found using the Module Editor 2 inside ft<fighter>.Method[3][15]

([url]http://i40.tinypic.com/2d6pij9.png[/url])

The code is nearly identical for all transforming characters and exclusively references methods and addresses in sora_melee. So I don't think porting it to other characters should be too difficult. On the other hand, I couldn't find anything determining which character they transformed into - it's possible that that kind of configuration could be located elsewhere or be determined by their Slot configuration.

wow! thats really great! I had my suspisions about that [3][15] when I ported special grabs to other ones when I looked at transforming character! but you found out exactly how it worked xD

however, porting that function to other character would be easy but porting so 2 characters are inside one module will take more time, not impossible but very hard and time-comsuning! will take a closer look at it later!

and PW! some question, can you teach me of how to port character with Article to the BrawlEx? I ported Jigglypuff + Metaknight (and a Giga Bowser is made too) but I would love to be able to do it with the one that has articles too!


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: Sammi Husky on January 14, 2014, 01:27:53 PM
would anyone happen to have a link to the module editor 2? i've looked pretty much everywhere Dx


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on January 14, 2014, 01:47:58 PM
saw your edit PW, do you think that 2 characters need to share the same Module? otherwise it looks like only needing the [3][15] plus some tweeks in the slot.dat
would anyone happen to have a link to the module editor 2? i've looked pretty much everywhere Dx

you havent looked hard enough: http://www.mediafire.com/download/v8xmy4jjdom21a6/Module+Editor+2.2.zip (http://www.mediafire.com/download/v8xmy4jjdom21a6/Module+Editor+2.2.zip)


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: PhantomWings on January 14, 2014, 02:04:34 PM
PW can you please give me the meta knight plug play rel?   :oshi:


Eternal Yoshi posted a link to it in this thread (http://forums.kc-mm.com/index.php?topic=65218.0), but people are reporting that it sometimes crashes at the results screen, so use it with caution.


saw your edit PW, do you think that 2 characters need to share the same Module? otherwise it looks like only needing the [3][15] plus some tweeks in the slot.dat


I don't believe two characters actually require to be in the same module to be able to transform. If you rename the module reference for someone like Sheik to some other name besides ft_zelda.rel, the game will try to load up that module alongside ft_zelda.rel when you select Zelda from the CSS. This implies that the fact that the two characters are run by the same module is coincidental and isn't necessary for them to run.

All interaction with character modules are mainly done through the ftClassInfo objects which are created and stored in a table regardless of where they come from. I think the fact that both ftClassInfo<ftZelda> and ftClassInfo<ftSheik> come from the same module is irrelevant.

On the other hand, there  is significant overhead in loading two separate modules into a single fighter's module resource pool. If the two modules are too large, the game will likely run out of memory for them and crash.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on January 14, 2014, 02:33:59 PM
so basically, renaming the module reference for shiek to example ft_plastpase.rel, it will try to load both ft_zelda.rel and ft_plastpase.rel on the CSS!

it makes me thinking, what if we change CSS's Zeldaslot to load to 2 already existing modules instead for fl_zelda and ft_sheik + thats not big + that is BrawlEx together with the edited [3][15] + the PSA command somewhere in the FitFighter.pac, it will actually work if you are correct!

I am already on the case!


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: Sammi Husky on January 14, 2014, 02:41:45 PM
so basically, renaming the module reference for shiek to example ft_plastpase.rel, it will try to load both ft_zelda.rel and ft_plastpase.rel on the CSS!

it makes me thinking, what if we change CSS's Zeldaslot to load to 2 already existing modules instead for fl_zelda and ft_sheik + thats not big + that is BrawlEx together with the edited [3][15] + the PSA command somewhere in the FitFighter.pac, it will actually work if you are correct!

I am already on the case!

thanks for the link pikazz, google why you fail me lol >.>

anyways, you can actually get the game to load a second module by setting the edit level in the slot config to 2 and specifying 1st and 2nd character to load.

then editing the module like PW said should allow the switch. though there may be more things that need to be done, since actually trying to play after it loads both modules give an error in dolphin. though that may have been because the size of the modules


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: E-scope12 on January 15, 2014, 04:45:39 AM
I don't think there is any similarity to the VIS0 files and stage modules. For that matter, modules in general are considerably different from most other resource files. This is partially why BrawlBox had so much trouble supporting them.



On another note, if anyone's interested in looking further into transforming characters, all I really know is that all transforming characters (except for the Pokèmon trio) can transform on demand using the PSA command 0C050000 (tagged by PSA as "Terminate Instance"). The code for 0C05 references assembly inside the character's module itself, so this command does not work for regular characters. However, if anyone's interested, the assembly code behind the 0C05 command can be found using the Module Editor 2 inside ft<fighter>.Method[3][15]

([url]http://i40.tinypic.com/2d6pij9.png[/url])

The code is nearly identical for all transforming characters and exclusively references methods and addresses in sora_melee. So I don't think porting it to other characters should be too difficult. On the other hand, I couldn't find anything determining which character they transformed into - it's possible that that kind of configuration could be located elsewhere or be determined by their Slot configuration.
I see. I was wondering because I notice Some of the buildings disappear when you're fighting in some areas of Delfino Plaza.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on January 15, 2014, 05:49:32 AM
I think it will work if we use 2 modules that has the least size will work! I know if we using both Marth + Jigglypuff modules, it will have less space than Lucas module!

also, I believe your therody PW, but I have a therody what they can link to in the Sora_melee!

the transformation setup with grapfics! I tested put the transformation command on Samus's Second jab. as soon it hit the command, her Transformation grapfic appeared straight away! so my guess is that it happens for everyone!

also, I know that every transforming character has a delay on transforming because the disc loads the things it need, excluding one chaaracter and that's bowser! he transform to giga bowser before you can even blick! how does that work? that he loads everything already from the beginning?


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: BlueBrain on January 15, 2014, 06:05:20 AM
giga bowser is being loaded when bowser is growing through his animation i suppose...
just like warioman and zss are probably being loaded during the transformation animation...


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: DSX8 on January 15, 2014, 07:05:04 AM
what i'd like to know is how to make models use a single CLR0 file (besides the Dark CLR0) inside characters fitmotion files.. would u happen to know anything about that PW?


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on January 15, 2014, 07:37:38 AM
Hey PW! I hope you are proud of me!

I made that instead for Samus it loads Jigglypuff and instead for Zero Suit Samus it loads Marth! and Suprise! it can load both modules!
if you just select "Samus", it will load Jigglypuff at the SSS, but if you hold on "R", it will load Marth instead on SSS (you can see it by the icon!)

everything is working perfectly, every attacks and final smashes and stuff

well... except the transforming part :/ the attack I put it on will not activate, no freeze or something!

but I believe it is something I missed cause I gave both the module the [3][15] part (the Samus part to jigglypuff and the ZSS part to Marth)
like that nasty calling offsets that was inside the [3][1] to load the [3][16] when I ported the special grabs!

will also try to put those over Zelda and Sheik if it would make any diffirent!


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: Sammi Husky on January 15, 2014, 11:47:17 AM
if you just select "Samus", it will load Jigglypuff at the SSS, but if you hold on "R", it will load Marth instead on SSS (you can see it by the icon!)

That's an idea i was actually gonna experiment with, glad you got it to work for the most part


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: HaloFanODST on January 15, 2014, 01:01:20 PM
Samus loads Jiggs?
What a wierd thing. XP


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: PhantomWings on January 15, 2014, 10:43:33 PM
Hey PW! I hope you are proud of me!

I made that instead for Samus it loads Jigglypuff and instead for Zero Suit Samus it loads Marth! and Suprise! it can load both modules!
if you just select "Samus", it will load Jigglypuff at the SSS, but if you hold on "R", it will load Marth instead on SSS (you can see it by the icon!)

everything is working perfectly, every attacks and final smashes and stuff

well... except the transforming part :/ the attack I put it on will not activate, no freeze or something!

but I believe it is something I missed cause I gave both the module the [3][15] part (the Samus part to jigglypuff and the ZSS part to Marth)
like that nasty calling offsets that was inside the [3][1] to load the [3][16] when I ported the special grabs!

will also try to put those over Zelda and Sheik if it would make any diffirent!

Nicely done Pikazz.

It seems you hit the nail on the head. Method[2][2] is responsible for calling Method[3][15], but for characters that don't have a Method[3][15] by default, it uses a regular generic implementation. If you update the instruction in Method[2][2] to jump to your new function it should work I think.


Title: Re: Let's look into Module Fíles (.rel) - PW is amazing!
Post by: pikazz on January 16, 2014, 08:35:08 AM
and it works almost perfect!
Lets the Swap begin! [beta] (http://www.youtube.com/watch?v=2iGzsL2hjzM#ws)

as you can see in the video, I used a modified Jigglypuff and Marth Modules to make them able to switch between eachother! as you see in the end of the video, they switch but they dont appear on the stage :/
thats the only thing missing! and i think I know whats cause the error!


Title: Re: Let's look into Module Fíles (.rel) - "Swapping" Is almost here
Post by: Carnage on January 16, 2014, 08:50:33 AM
dont they need actions to reapear on the stage like smaus/zss,zelda sheik and the likes?


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin!
Post by: pikazz on January 16, 2014, 04:59:32 PM
Le done~
Let the Swap begin! [Advanced Brawl Hack] (http://www.youtube.com/watch?v=BHcEbx_Ponk#ws)

100% working, yet 2 glitches! one major and minor D: really need to fix the major glitch!

the solution was inside <fighter>.Method[17][26]. however I dont know how to fix the "transport to middle" :/ believe it gets like that when they switch the Module file!


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin!
Post by: Large Leader on January 16, 2014, 06:02:59 PM
Great job, man!

Looks awesome!


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin!
Post by: pikazz on January 19, 2014, 01:24:36 PM
found the problem, it was reaaaally easy

Only needs perfection (http://www.youtube.com/watch?v=5bsrDfWGXNE#ws)

its only perfection left until I release a guide of how to create a transforming character!
with perfection, I mean being able to switch Graphic and Action with ease! right now it using Warios Transformation grapfic which is located in Sora_melee :/ need to find how to switch it!


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: KingJigglypuff on January 19, 2014, 01:34:51 PM
I am so looking forward to this!

(http://abload.de/img/blastoise9ak3p.gif)


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: HaloFanODST on January 19, 2014, 01:48:24 PM
found the problem, it was reaaaally easy

Only needs perfection ([url]http://www.youtube.com/watch?v=5bsrDfWGXNE#ws[/url])

its only perfection left until I release a guide of how to create a transforming character!
with perfection, I mean being able to switch Graphic and Action with ease! right now it using Warios Transformation grapfic which is located in Sora_melee :/ need to find how to switch it!


Can't wait to see the tut.


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: BlueBrain on January 20, 2014, 01:47:08 AM
why dont the name and portrait change though?


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: pikazz on January 20, 2014, 02:06:21 AM
why dont the name and portrait change though?
its a glitch, it only works if you using Samus or Zeldas slots. believe something is special with their slot to be able to switch name and portrait


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: BlueBrain on January 20, 2014, 02:49:31 AM
oh well, i can live with it xD
freaking epic job btw.


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: Carnage on January 20, 2014, 03:13:44 AM
i think its better to use only one portrait and such less stuff to add to the cosmeticonfig xD


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: BlueBrain on January 20, 2014, 08:37:36 AM
you would still need marth's stuff if you want to start with him by pressing L or R before the SSS...


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: pikazz on January 20, 2014, 09:26:13 AM
today is not my day! I trying to perfect it, but the only problem is that there is one easy way and one harder way and both has their flaws.
the easy way is 100% working but you lose the ability so select what Grapfic you want. it will always be wario change flash if its so!
the Hard way has the ability to select what transformation grapfic will be shown, but now the glitch that always appearing in the middle of the stage again D:

want to ask someone that knows ASM pretty well for some questions!
you would still need marth's stuff if you want to start with him by pressing L or R before the SSS...
that function only worked when you used it over samus (ID 3 and 17), when its over a new slot it will not work D:
but its safe to keep them
i think its better to use only one portrait and such less stuff to add to the cosmeticonfig xD
I havent test without but the cosmetic does contain some information about the characters (both jigglypuff and marth!)


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: LCCoolJ95 on January 20, 2014, 09:37:30 AM
the easy way is 100% working but you lose the ability so select what Grapfic you want. it will always be wario change flash if its so!
Honestly, Wario's transformation animation is pretty good. I mean, you said it's 100% working, and I'll take that any day. But this:
the Hard way has the ability to select what transformation grapfic will be shown, but now the glitch that always appearing in the middle of the stage again D:

That would annoy the heck out of me.


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: pikazz on January 20, 2014, 09:49:28 AM
Honestly, Wario's transformation animation is pretty good. I mean, you said it's 100% working, and I'll take that any day. But this:
That would annoy the heck out of me.
let me be more speficik, the wario grapfic ONLY loads when wario himself is loaded AKA is in the match! when you trying to transform without wario there you go completely invisible and poof you are transformed!

thats what I am trying to fix so you can use your own grapfic that loads with your character, not warios


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: KingJigglypuff on January 20, 2014, 09:53:29 AM
let me be more speficik, the wario grapfic ONLY loads when wario himself is loaded AKA is in the match! when you trying to transform without wario there you go completely invisible and poof you are transformed!

thats what I am trying to fix so you can use your own grapfic that loads with your character, not warios
Could you possibly use PSA commands to delete Waro's GFX, and then put in your own GFX commands?


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: pikazz on January 20, 2014, 09:55:35 AM
Could you possibly use PSA commands to delete Waro's GFX, and then put in your own GFX commands?
I doubt it since it loads with the Module, or precisely, the Sora_Melee itself directly when its switching character there you cant use PSA! believe the grapfic will disappear if you trying to add stuff with PSA to the transformation :/

basically what I need to do is to write a ASM code inside the module that can replace those value that makes it load your grapfic instead or get the "hard way" working 100%

if anyone knows how to make that ASM code, I would love some help!


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: Carnage on January 20, 2014, 12:14:23 PM
pikazz any chance you investigate how we can change the effects ids trough Hex? for example i know if you open lets say Fitlucario.pac and replace teh lucarioeffect.pac with waluigi effect.pac then you can start adding gfx and in the psa you call for the waluigi ID instead of lucario id for graphics, i would like to know what i would need to edit on the effect pack to give it a diferent id and then change the ids in psa so no more clone gfx problems except woth the assist trophys


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: Sammi Husky on January 20, 2014, 12:26:36 PM
To load the other fighters portraits and whatnot when you transform, set the edit level in the cosmetic config to 1. Then change the secondary charaster ID to the id of the character your transforming into


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: pikazz on January 20, 2014, 12:38:50 PM
To load the other fighters portraits and whatnot when you transform, set the edit level in the cosmetic config to 1. Then change the secondary charaster ID to the id of the character your transforming into
already did, but they dont change still :c


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: Sammi Husky on January 20, 2014, 01:07:33 PM
Hmmmm :/ it may be the css config then. It also has the primary and secondary character stuff.

If not, it must have to do with the modules or sora_melee..hmm..


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: pikazz on January 20, 2014, 01:32:42 PM
Hmmmm :/ it may be the css config then. It also has the primary and secondary character stuff.

If not, it must have to do with the modules or sora_melee..hmm..
it must be something with Sora_melee, since it work perfect to switch when its over zelda or Samus

also, I believe I found the solution now! needs testing

EDIT: It was the solution! but now something else appeared! it works great when you transform on ground, can select effects and everything, but in air, you will either skyrocket upward or downward really fast >:C

oh god, its just that little piece thats needed to be 100% working with grapfic and everything!


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: Sammi Husky on January 20, 2014, 04:00:42 PM
interesting. you think there may be a seperate method for the in air state? i don't know too much about modules, but i think that could be it the game may just set your on ground/in air state to on ground even if your in the air.

maybe...lol

can't wait for that guide! soon as it comes out and i fully understand it, i'll make a video tutorial for everyone that can't understand complicated stuff and give you the credit for everything :P


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! needs some Perfection
Post by: pikazz on January 22, 2014, 12:38:39 AM
Almost Perfect (http://www.youtube.com/watch?v=nhA8MgtmetY#ws)

everything works now! now you can select what Action will appear together with its grapfic! (I gave the grapfic to their PSA)
but 2 minor glitch, first is smashball doesnt want to spawn if you swap characher! I think I know whats wrong!
second if when the swap is done, it also want to load the first ModelData in the grapfic section, in the video is jigglypuffs sing and marths sword glow! dont know the solution for that one :/


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! The last 1% left
Post by: Sammi Husky on January 22, 2014, 12:29:11 PM
Hey great work pikazz! I think the graphic for the sing is actually still being called somewhere in the PSA. It may be because it's on her up-b. Because it seems like it's continuing the sing animation after the characters swap, even though the graphic was changed to something else...maybe try changing jigglypuffs transformation command to her taunt instead? If it still loads her song graphic, then it's something in the module :P

Yay for troubleshooting lol


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! The last 1% left
Post by: pikazz on January 22, 2014, 12:44:37 PM
https://www.youtube.com/watch?v=Z77UL_4Gyco (http://www.youtube.com/watch?v=Z77UL_4Gyco#ws)

Let the Swap Begin!
Hey great work pikazz! I think the graphic for the sing is actually still being called somewhere in the PSA. It may be because it's on her up-b. Because it seems like it's continuing the sing animation after the characters swap, even though the graphic was changed to something else...maybe try changing jigglypuffs transformation command to her taunt instead? If it still loads her song graphic, then it's something in the module :P

Yay for troubleshooting lol

I found out whats the problem, but it was not that you said xD


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: Sammi Husky on January 22, 2014, 12:57:34 PM
Haha I see xD well, doesn't this make it 100% working? Can't wait to get my hands on the tut!

Seriously though great work pikazz, thanks to your work we are 1 step closer to having brawl almost 100% customizable!


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: pikazz on January 22, 2014, 01:00:29 PM
Haha I see xD well, doesn't this make it 100% working? Can't wait to get my hands on the tut!

Seriously though great work pikazz, thanks to your work we are 1 step closer to having brawl almost 100% customizable!
this is now 100% working! dont know about the sound effect but nah, it shouldn't be problem xD

I am worried about doing the tutorial ;-; it will be long and quite hard for those who dont understand modules


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: Sammi Husky on January 22, 2014, 01:03:26 PM
Don't worry bout the length or complexity xD as long as SOME people can get it, that's awesome!  Besides I think I should be able to get it! Then I'll make a video tutorial for all of the people that don't jnderstand :P


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: KnightMario on January 22, 2014, 03:54:57 PM
I just wanted to say nice job, we've come through with a few cool hacking things lately.


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: Sammi Husky on January 22, 2014, 04:11:20 PM
The only groundbreaking thing left in brawl modding really is...well adding sounds without replacing any, and porting or adding articles.

er actually stage hazards too now that i think about it. :P

i know PW did work on porting articles, but wasn't that fairly buggy and complicated? :o


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: pikazz on January 22, 2014, 04:14:46 PM
The only groundbreaking thing left in brawl modding really is...well adding sounds without replacing any, and porting or adding articles.

er actually stage hazards too now that i think about it. :P

i know PW did work on porting articles, but wasn't that fairly buggy and complicated? :o

been actually in some of that areas!
porting articles is hard + buggy, it freezes as soon you end the battle

stage hazards is another thing:
Module File Hacking (http://www.youtube.com/watch?v=9mBP9Jka73o#ws)

old attemd to port the spring to final destination! so I tried to see what the spring does in Target lv 5


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: Sammi Husky on January 22, 2014, 04:16:40 PM
:O that's awesome!


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: BlueBrain on January 23, 2014, 07:20:21 AM
so, have you found a way yet to make this work for two brawlEx characters, or is that the next step?


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: pikazz on January 23, 2014, 07:50:55 AM
so, have you found a way yet to make this work for two brawlEx characters, or is that the next step?
this only WORKS with brawlex characters since we can edit the slots which is important!


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: BlueBrain on January 23, 2014, 07:54:34 AM
this only WORKS with brawlex characters since we can edit the slots which is important!

oh, ok, i thought you were just editting samus and zss to make this work...
AWESOME!


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: Sammi Husky on January 23, 2014, 11:51:40 AM
No no this will work with any character who doesn't already transform. The reason behind that is the modules for transforming chars are double the size of others. If the fighter memory heap is too big the game will crash, so we would need to detangle shiek from Zelda into desperate modules in order for us to be able to use one of them with a homemade transforming character. Otherwise it will load your fighter, Zelda, AND shiek. Which is too much :/


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: pikazz on January 23, 2014, 12:24:22 PM
No no this will work with any character who doesn't already transform. The reason behind that is the modules for transforming chars are double the size of others. If the fighter memory heap is too big the game will crash, so we would need to detangle shiek from Zelda into desperate modules in order for us to be able to use one of them with a homemade transforming character. Otherwise it will load your fighter, Zelda, AND shiek. Which is too much :/
I believe you actually can do it to replace zelda/sheik with a brawlex character! only problem is that we need to givethe other one someone else ID so it will not be in the way


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: Sammi Husky on January 23, 2014, 12:36:19 PM
Really? If u think so then it may be possible. The only problem I see is that inside the module for Zelda and shiek, they explicitly call for each other in section 1 don't they? :0 wouldn't that be a problem? I mean we could just change the slot config a bit and have it load another character,  but then the file size becomes an issue since it will load Zelda's module and someone else's. And Zelda's is roughly double the size :0


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: BlueBrain on January 23, 2014, 12:46:59 PM
so now it's posible for a ganondorf final smash that turns into ganon from OoT... ala bowser and wario!


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: Dantarion on January 23, 2014, 12:49:35 PM
pikazz, I need to work with PW to allow transforming characters to work for slots other than the ones that transform right now.


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: Sammi Husky on January 23, 2014, 12:58:30 PM
Hey there Dant :P and really? Pikazz, I thought u weren't using Zelda's module for this? :0  I thought u were modifying an exmodule with code from Zelda's module right?

Now I'm kinda confused on What's going on lol


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: pikazz on January 23, 2014, 01:00:42 PM
so now it's posible for a ganondorf final smash that turns into ganon from OoT... ala bowser and wario!
as long when there is a Ganondorf BrawlEx module, so yes!
pikazz, I need to work with PW to allow transforming characters to work for slots other than the ones that transform right now.
and how do you mean by that? o.o I got everything fully working except for the portrait change in battle! from my perspective, it did sound like I am trying to fool you all but you got evidence right before your eyes! or will you help with that portrait change! I am very confused of what you wrote

and no! I arent using zeldas module! I will actually release both Jigglypuff and Marth soon!


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: Sammi Husky on January 23, 2014, 01:08:43 PM
That's what I thought @.@ what Can't said confuzzled me. I can't think of anything that could be broken


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: pikazz on January 23, 2014, 03:12:36 PM
http://forums.kc-mm.com/Gallery/BrawlView.php?Number=35845 (http://forums.kc-mm.com/Gallery/BrawlView.php?Number=35845)

the link to everything of the transformation Jigglypuff and Marth!

and I know what I should do, I will actually port every module thats for BrawlEx being able to transform and very easy to customize and upload them like PW did with the BrawlEx Modules instead of doing a tutorial of how to create a own from scratch!


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: WintersAssassin on January 23, 2014, 03:40:35 PM
Well so far you're making amazing progress pikazz, a practical use I could see with this is a fully functional Majora's Mask Young Link with each of his forms being on a taunt, that being said it'd probably overload the Wii's memory loading 5 modules at once (Link, Zora, Deku, Goron, and a Fierce Diety final smash).

All this progress really makes me want to try my hand at some custom characters, though I don't know where exactly to start,


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: Sammi Husky on January 23, 2014, 04:50:45 PM
Aww...i was really looking forward to the tutorial :0 hmm..I honestly think it would be less work to just make a tut. Then if everyone still doesn't understand after your tut and my video tut, then i or you could always take requests for transforming modules :P


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: pikazz on January 23, 2014, 04:55:09 PM
Aww...i was really looking forward to the tutorial :0 hmm..I honestly think it would be less work to just make a tut. Then if everyone still doesn't understand after your tut and my video tut, then i or you could always take requests for transforming modules :P
I think this is the best, but I will still do a tutorial of how to set it up and customize the module to load right Grapfic, Action after transform, the right way to set up Slot ect!

but if you guys REALLY want a tutorial of how to make one from scratch, I can put up one


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: Sammi Husky on January 23, 2014, 05:13:46 PM
honestly, it's probably just me that wants it XP so you don't have to if you don't wanna. but yea that sounds like a great idea.


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: pikazz on January 24, 2014, 08:30:39 AM
tried to transform between 3, doesnt look bright :/ cant make the second transform to third ;-; it will transform back to one again!


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: KingJigglypuff on January 24, 2014, 08:31:46 AM
Darn. ;-;

Maybe someone like Dant or PW could attempt to help.


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: pikazz on January 24, 2014, 08:39:27 AM
Darn. ;-;

Maybe someone like Dant or PW could attempt to help.
from that I read, dant and/or PW would try to do slots thats for transforming character. I hope they found how to increase the module memory, its quite small D:


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: Sammi Husky on January 24, 2014, 12:02:34 PM
You may want to take a looksee at the pokemon trainers module and psa in order to see if there are any major differences. :/ it may have something to do with the individual pokemon's methods inside the ft_poke.rel or something inside the individual pokemon's psa


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: Dantarion on January 24, 2014, 12:53:43 PM
pikazz, what slot are you using to try to do triple transform?
I think you will have to use PT's...


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin! Tutorial Soon!
Post by: pikazz on January 24, 2014, 03:29:31 PM
pikazz, what slot are you using to try to do triple transform?
I think you will have to use PT's...
I tried with a extra slot. I will test with the PT slot!

EDIT: I was quite afraid of this, but thanks by ssbb's low module memory, it is very hard to do transformation characters. it seems that if 2 modules together are over 360kB, it will freeze on a special way. ready on 282kB can be on its peak!

the reason why Jigglypuffs and Marths Module work was they only reached to 209kB, which is the same module size as Marios!

so until when we can either find a way to comprass modules or increase the moduel memory, the Project "Let the Swap Begin" is on ice!


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin is on Ice
Post by: BlueBrain on January 25, 2014, 09:34:54 AM
marth to marth could work perfectly fine, right?
so marth-roy tag team could be possible... xD


Title: Re: Let's look into Module Fíles (.rel) - Let the Swap Begin is on Ice
Post by: pikazz on January 25, 2014, 10:17:07 AM
marth to marth could work perfectly fine, right?
so marth-roy tag team could be possible... xD
yes, Marth to Marth would work perfectly! cause Jigglypuff + Jigglypuff worked perfectly!


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: pikazz on February 11, 2014, 01:00:35 PM
so, I took a little closer look at the PSA Command "Defensive Hitbox" which makes the character being able to either reflect or destroy incoming Articles!
example is Marios Cape or Links Shield on his Wait1 or SquatWait

I have almost all information to make it workable! there is only thing that missing to make it work on other character. here is all the information I have so far:
<fighter>.Method[2][2] is the main thing that calls up the other Methods!

<fighter>.Method[17][43] appears to be of sound effect and grapfics
<fighter>.Method[17][45] is currently unknown, but seems to relate to Hitstun + movement (example Links shield gets hit by a fully Charge beam and he slides away a bit with hitstun)
<fighter>.Method[17][46] unknown, but appears to be what kind of defensive hitbox it will be. all who can reflect has this but Link + Toon Link hasn't
<fighter>.Method[17][48] appears to controll what action will play if it gets hit! example is Wolfs action there he uses another Action once hit

there is something thats missing, I know it! tried to give jigglypuff the information, but it only reflectable (with franklin badge hitsound) the first time in the game until you change subaction/action

also, PW! remember when you asked me how Links defensive hitbox gets load with the LA-Bit command? I found out how <w<


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: Sammi Husky on February 11, 2014, 01:55:40 PM
This is great! Your really great at figuring this module stuff out pikazz! Also, I know project let the swap begin is on ice, due to the fighter overlay's memory limitations..but I would really like to see a tutorial on how to reproduce your results :D that way I can mess around and see if I can maybe increase the memory allocated to it, or reduce the size of the .rels.

Or you could PM me a quick overview of the process.. :3 i'd love to be able to help figure this out


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: pikazz on February 11, 2014, 02:32:22 PM
This is great! Your really great at figuring this module stuff out pikazz! Also, I know project let the swap begin is on ice, due to the fighter overlay's memory limitations..but I would really like to see a tutorial on how to reproduce your results :D that way I can mess around and see if I can maybe increase the memory allocated to it, or reduce the size of the .rels.

Or you could PM me a quick overview of the process.. :3 i'd love to be able to help figure this out
sure, I will send you a quick PM a easy overview of it!

EDIT: a small update on Let the Swap begin, I did manage to do Metaknight and successfully swap Metaknight - Metaknight, but the wierd thing is if I trying with a diffirent character like Jigglypuff, it goes into a silent freeze when stage is selected

same error on Pit + someone else, but Pit + Pit is more memory than the Wii can handle D:


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: PhantomWings on January 03, 2015, 12:11:27 PM
This goes under module research, so I guess I'll post it here.

At the request of BronzeGreekGod, I thought I'd try and do a bit of work with character modules and articles. The following module file will allow Lucario to have up to 8 Aura Spheres on screen at once. Besides that, everything else is the same. I've packaged a small sample moveset that allows Lucario to use his Aura Spheres faster so anyone can test it out if they want to, but the moveset changes aren't necessary - just the module.

[Lucario Aura 8.zip] (https://www.dropbox.com/s/cu3ls05iqsknvr1/Lucario%20Aura%208.zip?dl=0)

When I get some time, I'll see about adding some info about the procedure up onto the OpenSA website.


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: pikazz on January 03, 2015, 12:19:24 PM
This goes under module research, so I guess I'll post it here.

At the request of BronzeGreekGod, I thought I'd try and do a bit of work with character modules and articles. The following module file will allow Lucario to have up to 8 Aura Spheres on screen at once. Besides that, everything else is the same. I've packaged a small sample moveset that allows Lucario to use his Aura Spheres faster so anyone can test it out if they want to, but the moveset changes aren't necessary - just the module.

[Lucario Aura 8.zip] (https://www.dropbox.com/s/cu3ls05iqsknvr1/Lucario%20Aura%208.zip?dl=0)

When I get some time, I'll see about adding some info about the procedure up onto the OpenSA website.
Wow! Thats great 8D Will test that out!

Also, did you get My PM i sent to you?


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: HaloFanODST on January 03, 2015, 12:22:14 PM
This goes under module research, so I guess I'll post it here.

At the request of BronzeGreekGod, I thought I'd try and do a bit of work with character modules and articles. The following module file will allow Lucario to have up to 8 Aura Spheres on screen at once. Besides that, everything else is the same. I've packaged a small sample moveset that allows Lucario to use his Aura Spheres faster so anyone can test it out if they want to, but the moveset changes aren't necessary - just the module.

[Lucario Aura 8.zip] (https://www.dropbox.com/s/cu3ls05iqsknvr1/Lucario%20Aura%208.zip?dl=0)

When I get some time, I'll see about adding some info about the procedure up onto the OpenSA website.

This might be dumb, but why 8 spheres for Lucario?


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: BlueBrain on January 03, 2015, 12:34:09 PM
This might be dumb, but why 8 spheres for Lucario?
to prove it's possible to edit the article's properties...


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: PhantomWings on January 03, 2015, 04:23:53 PM
This might be dumb, but why 8 spheres for Lucario?

Mainly because 8 felt like a good number to me. The original request was actually only for 5.

As for why its important: increasing the number of articles allowed on screen is by no means an easy feat. It's a lot more than just upping a number from 3 to 8 as each article needs to have memory allocated for it, and instance holder created for it, and a destructor call for that article for when the match ends. Moreover, all this needs to be added without disrupting the delicate memory organization of the existing systems already in place for the character.

Moreover, this proves that it's not just possible to replace articles such as Mario's fireballs with Rob's laser, but it's also possible to add new articles. With this knowledge, it should be possible to develop articles for characters who don't normally have them. For example, it may become possible to give Marth the Cutter Kirby shockwave when he does his forward smash.

Most of that's for the future though, as we still don't have enough control over the module files to make this sort of editing efficient.


Wow! Thats great 8D Will test that out!

Also, did you get My PM i sent to you?

Hey Pikazz, it's good to see you still around here. I've been going through my backlog of messages, but I think I missed yours. I'll see if I can dig it up and get back to you on it.


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: Sammi Husky on January 03, 2015, 06:14:53 PM
Hmm. This may be somewhat relevant to this thread, but now that I've programmed bbox to keep track of all branch commands, it's probably possible to do some magic and recalc hardcoded branch offsets when memory is added. This still doesn't fix some of the more intrinsically complex issues faced when editing modules, but it sure would make things easier.

BBox is becoming more and more useful for module editing now that it displays methods, similar to Module Editor 2. And whats more, if you select a branch location, you can actually click a button to jump to the branch destination. And lastly, per Pikazz's request, I've implemented a way to see where branch offsets are without actually having one selected. Just like how a Relocation destination is painted with a red font, these are painted blue. It may also be worth noting that branch commands are painted with the background color purple.

(http://i.imgur.com/eFLwgLW.png)
(http://i.imgur.com/q8atQOg.png)

I mainly started these kinds of improvements to help with whatever i was doing at the time, which as of late has been with editing the item system...maybe to get some custom items loaded and working. I've not spent too too much time on it yet, but in my time messing around in dolphin (And thanks to some info from PW) I've found a few cool tidbits of information. Nothing notable to show yet, but i am starting to get a general picture as to how the items are generated. Unfortunately they are a bit more hardcoded than i had originally thought. No matter though, i never expected it to be easy ;)

Anyways..this lucario deal is pretty amazing. Imma pop it open and see if i can find what you changed  ;D


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: pikazz on January 04, 2015, 03:25:24 AM
Hey Pikazz, it's good to see you still around here. I've been going through my backlog of messages, but I think I missed yours. I'll see if I can dig it up and get back to you on it.
I just remembered that My PMs are kinda outdated and Old when i have got some new information so i Will update and send you one new PM this coming week

Also, it shouldnt be that hard to give marth an article since he doesnt have Any, but it Would be really time-consuming without a completely module rebuilder to make sure all offsets and branchs are right. I though to give it a go once a module rebuilder exists

Sammi: that awesome <3 now we can find all branches with ease!


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: PhantomWings on January 11, 2015, 02:36:19 PM
Hmm. This may be somewhat relevant to this thread, but now that I've programmed bbox to keep track of all branch commands, it's probably possible to do some magic and recalc hardcoded branch offsets when memory is added. This still doesn't fix some of the more intrinsically complex issues faced when editing modules, but it sure would make things easier.

BBox is becoming more and more useful for module editing now that it displays methods, similar to Module Editor 2. And whats more, if you select a branch location, you can actually click a button to jump to the branch destination. And lastly, per Pikazz's request, I've implemented a way to see where branch offsets are without actually having one selected. Just like how a Relocation destination is painted with a red font, these are painted blue. It may also be worth noting that branch commands are painted with the background color purple.

([url]http://i.imgur.com/eFLwgLW.png[/url])
([url]http://i.imgur.com/q8atQOg.png[/url])

I mainly started these kinds of improvements to help with whatever i was doing at the time, which as of late has been with editing the item system...maybe to get some custom items loaded and working. I've not spent too too much time on it yet, but in my time messing around in dolphin (And thanks to some info from PW) I've found a few cool tidbits of information. Nothing notable to show yet, but i am starting to get a general picture as to how the items are generated. Unfortunately they are a bit more hardcoded than i had originally thought. No matter though, i never expected it to be easy ;)

Anyways..this lucario deal is pretty amazing. Imma pop it open and see if i can find what you changed  ;D


That's awesome. I noticed that you guys are still using my old class crawler code from the Module Editor 2. I've since improved on it a bit.

[Code Crawler Source.zip] (https://www.dropbox.com/s/9g51gakws0amp1x/ModuleCrawler%20Source.zip?dl=0)

I was originally trying to develop a code visualizer tool for the module files, but I haven't worked on it in ages. You'll probably get a lot more use out of it than me. The main part you'll probably want to salvage is the CodeCrawler class located in BrawlModule->ModuleTools->Crawler. This code crawler will establish symbolic links between all the classes, methods, and method tables in a module file. It also records all the method calls, loops, branches, and constant references inside each method. There's a small part in the CodeCrawler.cs that still needs work regarding the bctr instructions, but besides that, it's pretty complete. There's an example on how to use it in the Form1 code of the main project.

You guys seem to have been doing a lot of work on the old code crawler too, so go ahead and use whichever one suits your needs best.



Also, as a side note, I've updated the Lucario Aura Sphere Expansion pack with a ProjectM version of the same module.

[Lucario Aura 8.zip] (https://www.dropbox.com/s/cu3ls05iqsknvr1/Lucario%20Aura%208.zip?dl=0)


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: pikazz on January 11, 2015, 03:39:39 PM
I sent you a new PM to you PW, I almost forgot about it!

and awesome with the code crawler! 8D sadly its just source and not the program itself, I cant look D;


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: Sammi Husky on January 12, 2015, 03:44:04 AM
That's awesome. I noticed that you guys are still using my old class crawler code from the Module Editor 2. I've since improved on it a bit.

I was originally trying to develop a code visualizer tool for the module files, but I haven't worked on it in ages. You'll probably get a lot more use out of it than me. The main part you'll probably want to salvage is the CodeCrawler class located in BrawlModule->ModuleTools->Crawler. This code crawler will establish symbolic links between all the classes, methods, and method tables in a module file. It also records all the method calls, loops, branches, and constant references inside each method. There's a small part in the CodeCrawler.cs that still needs work regarding the bctr instructions, but besides that, it's pretty complete. There's an example on how to use it in the Form1 code of the main project.

Great stuff! Yea i restarted using the old crawler as of late, pending a rewrite to the way that BBox handles modules as a whole. This should definitely come in handy, so thanks a bunch!

Pikazz, just wondering, but have you taken a look at the 8 aura sphere lucario that PW has uploaded? It's quite interesting. If i find anything that i can easily explain, i'll let you know over skype, but for now i was mainly asking because i just haven't had enough time to dig into it as much as i'd like to :P


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: pikazz on January 12, 2015, 05:44:11 PM
Great stuff! Yea i restarted using the old crawler as of late, pending a rewrite to the way that BBox handles modules as a whole. This should definitely come in handy, so thanks a bunch!

Pikazz, just wondering, but have you taken a look at the 8 aura sphere lucario that PW has uploaded? It's quite interesting. If i find anything that i can easily explain, i'll let you know over skype, but for now i was mainly asking because i just haven't had enough time to dig into it as much as i'd like to :P
I havent "yet" cause been quite busy with my own projects D: but still cant get enought with the mystery of the modules and its powers!

also PW, are you getting my PMs? o:


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: PhantomWings on January 12, 2015, 08:08:37 PM
I havent "yet" cause been quite busy with my own projects D: but still cant get enought with the mystery of the modules and its powers!

also PW, are you getting my PMs? o:

No worries, I've got them. Just give me a few minutes and I'll get back to you as soon as I can.


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: Mawootad on February 14, 2015, 08:57:29 AM
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?


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: PhantomWings on February 24, 2015, 10:58:35 PM
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.


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: Sammi Husky on February 25, 2015, 03:32:22 AM
Oh, hey Maw. Didn't know you ever posted around these parts. :P Im glad you brought that up, as i'm interested as well. (Also, Sorry i haven't been on Skype, i've been quite busy and don't have access to skype atm. Tell the rest of the Minus dudes for me if you get the chance.)

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.

Good to see you PW! I did take a little time to look the Lucario module as well, but i haven't had too too much time lately. Just enough time to briefly go over the changes and some of the main logic. In any case! I'm always willing to learn something new :) That and anything related to articles is always quite interesting lol


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: pikazz on February 25, 2015, 10:13:22 AM
havent been looking into modules that much recently thanks by my other projects D:
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.
I did noticed that o: but I can wait :3 I am a patient person


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: PhantomWings on February 28, 2015, 02:42:29 PM
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.

(http://i61.tinypic.com/2i73j12.png)

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:

(http://i58.tinypic.com/2wqhll3.png)

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.

(http://i57.tinypic.com/10gb900.png)

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:

(http://i58.tinypic.com/2zoy983.png)

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.

(http://i60.tinypic.com/24fbsb4.png)

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



Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: KingJigglypuff on February 28, 2015, 02:59:53 PM
(http://i.imgur.com/7drHiqr.gif)

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.


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: Sammi Husky on February 28, 2015, 05:49:51 PM
([url]http://i.imgur.com/7drHiqr.gif[/url])
So how are Article Floating Points handled?


Depends really. From the limited research i've done, they are for the most part done through the relevant ParamAccessor object. For example, Falco's wnFalcoBlasterBulletParamAccesser object handles accessing the blaster bullet's floating points from memory.


~snip~


Haven't read it yet because im at work, but this looks juicy :)


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: pikazz on February 28, 2015, 07:04:27 PM
oh god all that information on the articles! really awesome information so props to you! x3
I will take a closer look at it!

...tomorrow, its 3AM right now and tired as [censored]! couldnt even read what you wrote straight xD


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: PhantomWings on February 28, 2015, 07:11:04 PM
Continuing,

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

(http://i60.tinypic.com/23ksrc6.png)

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:

(http://i58.tinypic.com/dx1o2h.png)

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:


(http://i59.tinypic.com/b6vj3q.png)

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.

(http://i60.tinypic.com/wwf1vk.png)

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 (http://anonym.to/?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 g(http://i0.kym-cdn.com/photos/images/newsfeed/000/143/193/cad-20080602-358b1.jpg?1309710446)ed 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 (https://www.dropbox.com/s/gapzhjkqtr1p3vf/Changes.txt?dl=0)

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! (https://www.dropbox.com/s/ks8ppwy7nxdaf8p/Lucario%20Map.png?dl=0)


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.


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: KingJigglypuff on February 28, 2015, 08:09:16 PM
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?


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: Large Leader on February 28, 2015, 08:44:53 PM
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?

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?


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: Mawootad on February 28, 2015, 09:07:49 PM
Thank you very much for the info PW!  I'm gonna see if I can implement this on G&W.


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: Sammi Husky on February 28, 2015, 09:31:24 PM
Thanks very much indeed. I'll also be seeing about implementing this somewhere. If i do, i'll post about it here :)


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: PhantomWings on February 28, 2015, 09:43:30 PM
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


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: ASF1nk on February 28, 2015, 11:44:48 PM
Awesome information. Great work! =]


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: PhantomWings on March 01, 2015, 02:20:14 PM
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:

([url]http://oi59.tinypic.com/2upwtx3.jpg[/url])

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:


([url]http://i59.tinypic.com/zlajnm.jpg[/url])


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


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: pikazz on March 01, 2015, 03:12:30 PM
I actually did it for you o: been showing that gif of yours to Wip PSA Thread and one more thread inhere I think o:
been using the StatusUniq Swapping quite effectly 'w'

and super great info for all the articles! I want to see if I can create something from it!


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: Mawootad on March 01, 2015, 11:59:25 PM
So I was able to change g&w's projectile count using PW's info, but unfortunately the game crashes trying to generate the 9th onscreen projectile.  It doesn't seem to be due to issues with where the projectile is being loaded/instantized (as the game doesn't crash when any projectile other than the 9th is instantized into any of the constructed objects); I'm assuming it's a memory issue, although it seems kind of odd that that little extra loaded stuff could cause a crash.  I'll go ahead and post a g&w with 8 chef projectiles once I resize the cap and clean stuff up.  Also thanks for the awesome info PW!

Edit:  Yeah, it does seem like there's some crazy stuff going on behind the scenes that's causing stuff to behave oddly.  No idea how, but the 15 count had weird t-poses at the beginning of up-b (in addition to aforementioned crashing) and the 8 count somehow shaved off 90% of the la-float space that g&w had allocated (although maybe that just happens because la-floats end up writing into unused memory sections under normal circumstances and the change in object structure causes that memory to become unusable).  In any case though, definitely possible to implement this on other fighters.

Also, download link for anyone who's interested: https://www.dropbox.com/s/2yv6tgkst3mhp5e/ft_gamewatch.rel?dl=0 (https://www.dropbox.com/s/2yv6tgkst3mhp5e/ft_gamewatch.rel?dl=0)


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: Mawootad on March 06, 2015, 10:22:54 PM
Double post, but this doesn't fit with my previous post and is probably interesting enough to share:
Each fighter has 11 AnimCmd threads (projectiles can have less, which is why I believe concurrent infinite loops have such a range of thread types; articles don't always have the thread 9 that fighters use), with various types that are used for various things.  Threads are held in a fixed size array with the threads stored in a structure of [ soAnimCmdInterpreter thread, soAnimCmdAddressPackArraySeparate something, word threadID, halfword threadType ].  Thread id is directly referenced by at least some commands (flash overlays in probably behave slightly differently for thread A), but thread type affects how each thread processes stuff; it makes intangibility and charged move flashing not terminate on (sub)action change and ignore frame speed modifiers (type 0x10) or makes commands be run every frame instead of terminating when the action is finshed (type 0x4), and changing the thread type does cause them to gain the new thread type properties.  Some threads can be directly interacted with by psa commands (type 0x4 threads for instance), but I don't think all of them can.  In any case here's some info about how the threads generally look for fighters:
Thread ID - Thread Type (hex) - What thread is used for
0 - 1 - Action
1 - 2 - Subaction Main
2 - 40 - Subaction GFX
3 - 40 - Subaction SFX
4 - 2 - Subaction Other
5 - 20 - Unknown/Unused?
6 - 80 - Unknown/Unused?
7 - 80 - Unknown/Unused?
8 - 20 - Unknown/Unused?
9 - 4 - Concurrent Infinite Loops
A - 10 - Blinking Effects

Also, I found where 00 and 01 commands are run.  00 commands are handled starting at 0x801398c8 in memory (so somewhere in main.dol, I think) and 01 commands are handled starting from 0x706F8 in section 1 of sora_melee.  Oh, and if anyone wants to dig through PSA code soAnimCmdImpl's methods, which are used for accessing info about the current command, are almost all fully documented on the OpenSA wiki (only missing method
  • [10]).


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: pikazz on March 07, 2015, 05:50:33 AM
thats really good info of the soAnimCmd o:
so basically, Warios Wart/ROB laser is using a soAnimCmd Concurrent Infinite Loops to charge their attacks no matter what action is used? o:

really interested into soAnimCmd! do you have any more info about it? :3


Title: Re: Let's look into Module Fíles (.rel) - Defensive Hitbox/Reflected Articles soon?
Post by: Mawootad on March 07, 2015, 08:37:05 AM
The charging is probably done via asm, although that's probably something that's worth checking.


Title: Re: Let's look into Module Fíles (.rel) - Defensive Collision is now!
Post by: pikazz on April 18, 2022, 02:28:22 PM
Hello everyone.

I am going to be an evil mess and revive this topic I created years ago, so I am sorry in advance for the mods and the rules.

However, I have returned after 5 years of slumber from KC-MM.

Adding Defensive Collisions is now a thing:
I have been doing alot of work thanks to PW's notes about the internal Memory and shared most of my findings on Discord, but never here specifically.

So, I have been successfully added a reflect.
https://www.youtube.com/watch?v=DLN1m4T8Ihc (https://www.youtube.com/watch?v=DLN1m4T8Ihc)

also have added an absorb that heals.
https://www.youtube.com/watch?v=HKS5DPCN_rw&feature=youtu.be (https://www.youtube.com/watch?v=HKS5DPCN_rw&feature=youtu.be)

And now also a Counter defensive collision.
https://www.youtube.com/watch?v=FS1ezSPIR9w&ab_channel=pikamaxi (https://www.youtube.com/watch?v=FS1ezSPIR9w&ab_channel=pikamaxi)
Sadly this counter doesnt have the "damage multiplier" yet like Marth and Ike has.

And today, I just released a guide on how to add defensive collision!
Right now as I writing this, I have only added for Counter so far, but in the near future I will also add Reflect and Absorb to this document.

You can read the guide here:
https://docs.google.com/document/d/1RPk84JlxisPdEYvg0qGZpK4GYTkS-1fu4lr9mN7ocrs/edit# (https://docs.google.com/document/d/1RPk84JlxisPdEYvg0qGZpK4GYTkS-1fu4lr9mN7ocrs/edit#)


My mission is soon complete with figuring out the defensive collisions and find more ways to make the future PSA's more creative and being less limited.

Speaking of Limitation, my current interest is to find an effective way to add new Actions.
Right now, I have been 95% successful to add more actions to both Jigglypuff and Lucario, thanks to PWs memory notes.

There are some weird side effects as of right now.
Both works perfectly in the game (loads normally and can exit the stage normally)

But for Jigglypuff, only one of jigglypuff can be at the match! if any more jigglypuffs are spawned, only the last spawned one will be able to move while the others are stuck in t-pose.

For lucario, they cant respawn after death. They might also lack the "graphical hit effects" when they hit an opponent, if Aura does have an "graphical hit effect"

As soon as I am able to add new actions that are 100% free, I will make another guide.
But if anyone wanna help me to find out how and why these side effects are happening, please contact me on Discord, as I have been rarely logged in here.


Title: Re: Let's look into Module Fíles (.rel) - Defensive Collision is now!
Post by: Ricky (Br3) on April 19, 2022, 06:28:36 PM
Good job, not much else to say. Brawl modding has really been kicking the [censored] out of old hurdles lately.


Title: Re: Let's look into Module Fíles (.rel) - Adding Action is now!
Post by: pikazz on November 14, 2022, 11:56:41 PM
Hello again,

I have been now on a spree and figured out how actions works inside & out.

Maybe not exactly everything, but enough to figure out all the offsets and data that needs to be changed to increase the action count for all characters flawlessly.

There is not really much custom coding to fix it, as most of the offsets are static.
But the main issue is that its rather tedious: over 48 changes that you need to do to get it flawlessly.

Here is a guide on how to add actions to one character, with details and examples on every offsets that need to change:
https://docs.google.com/document/d/11Hq3RIDt9HvH87QEnnpjE6VMyEF9ab-FcIexqTnBsFg/edit#

Speaking off static: While all the offsets you need to change is pretty much static in their placement, the "code group" they are in usually is not.
It would be hella great to found a way to automatimize this progress, but I will sadly not be the one who will make such a thing


Title: Re: Let's look into Module Fíles (.rel) - Articles are now a thing!!
Post by: pikazz on January 04, 2023, 11:21:49 AM
Hello again dear thread.

I am once again bumping up this thread to say that I have been able to add one Article/Projectile to a character lacking any projectiles:

Marth has now an Article!
http://www.youtube.com/watch?v=IQn45KT39uM

Well not 100%
Its 100% added through the Module side of things, but with how hard it is to add any custom data sections/articles/Paramnodes in a PSA file. I had to use the FitIke.pac file as a base for this to work ingame.
As soon as we can add articles through PSA (like PSACompressor) or another standalone program, adding these would be much easier.
Heck, I would even pay someone to make such a program for me just so we can get forward in the Article department.

Right now I am currently in the making of "replacing" an existing article with another article.
Like replacing Ness PK Fire to like Sonics Spring would be a huge step in this department.
But this is currently on halt due the PSA rebuilder problem.

I did something similar with an "Item Article", by replacing Jigglypuffs Sleephat with an "Null Article" with toonlinks bomb attached to it. The "Article bomb" spawns in the middle of the stage, while the "item Bomb" spawns in Jigglypuffs hand.
http://www.youtube.com/watch?v=W65rPxPGSWY
But I wanna try with a real article

Thats not all folks!
I have also dug deeper onto how soStatusUniq works and ported these over to other characters to see how well they work. I also successfully added a "Search Collision" to characters ("Inert" according to PSA)
I was able to port over Zeldas Final Smash of 99% working, Ikes Final Smash 99% working, Lucarios Final Smash AND Up B fully working.
You can check out the result down here.

http://www.youtube.com/watch?v=MpD_007OGNg
http://www.youtube.com/watch?v=2HdXCtWhDNQ
http://www.youtube.com/watch?v=gyhsdjodcl4
http://www.youtube.com/watch?v=y47AggVOiN0