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

[pikazz]

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]

[Source]

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

[Sky Grounder]

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:

[Shinobu Nyan!]

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

Lol, so true.

[PhantomWings]

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 Select Expand



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 Select Expand



(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.

[pikazz]

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 Select Expand



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 Select Expand



(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

[Sky Grounder]

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):

Sorry but you are not allowed to view spoiler contents.

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.)

[pikazz]

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):

Sorry but you are not allowed to view spoiler contents.

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!

[Sky Grounder]

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":

Sorry but you are not allowed to view spoiler contents.

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

[Ultraxwing]

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 and only for you.

[Sky Grounder]

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 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:

[pikazz]

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

[Sky Grounder]

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.

[BlackJax96]

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.

[Sky Grounder]

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?

[PhantomWings]

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.