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

Started by pikazz, May 04, 2012, 12:58:26 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

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!
Stupid Tinypic :C

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:

Sorry but you are not allowed to view spoiler contents.


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.

Quote from: PhantomWings on May 04, 2013, 04:59:47 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:

Sorry but you are not allowed to view spoiler contents.


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!
Stupid Tinypic :C

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.

May 05, 2013, 05:39:35 PM #289 Last Edit: May 05, 2013, 06:35:54 PM by pikazz
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?
Stupid Tinypic :C

Quote from: pikazz on May 05, 2013, 05:39:35 PM
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.

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
Stupid Tinypic :C

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?

Quote from: joke king on May 18, 2013, 02:49:54 PM
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 :/
Stupid Tinypic :C

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

Do brawl stage .rels have something similar to VIS0?

January 14, 2014, 07:45:21 PM #296 Last Edit: January 14, 2014, 07:46:42 PM by PhantomWings
Quote from: E-scope12 on January 14, 2014, 05:42:58 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]



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.

PW can you please give me the meta knight plug play rel?   :oshi:

Quote from: PhantomWings on January 14, 2014, 07:45:21 PM
huge post
Sorry but you are not allowed to view spoiler contents.

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!
Stupid Tinypic :C

would anyone happen to have a link to the module editor 2? i've looked pretty much everywhere Dx