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.

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

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

[spoiler]Quote: Friedslick6
you have been through a lot of hassle. I've watched every topic you posted on this, and most of them seemed to disintegrate gradually.
But the coolest part was that you didn't stop working on it despite that.

Quote: Internet Explorer
you're doing more with your life right now than probably most other people around you. You're a valuable asset to the Smash community. So yeah, you should be proud.

quote: Greg
You do have a gift which I've seen many developers use to their advantage. You can become a great coder, and with all of those ideas I think you can really build something great.

This has to do with .rels, So i guess i should post here:

[spoiler]http://www.youtube.com/watch?v=ZhaksbecPFU
Quotes:
Sorry but you are not allowed to view spoiler contents.

I finally got to upload my image:


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

template link coming soon...

[spoiler]Quote: Friedslick6
you have been through a lot of hassle. I've watched every topic you posted on this, and most of them seemed to disintegrate gradually.
But the coolest part was that you didn't stop working on it despite that.

Quote: Internet Explorer
you're doing more with your life right now than probably most other people around you. You're a valuable asset to the Smash community. So yeah, you should be proud.

quote: Greg
You do have a gift which I've seen many developers use to their advantage. You can become a great coder, and with all of those ideas I think you can really build something great.

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
Sorry but you are not allowed to view spoiler contents.

Quote from: Carnage on January 01, 2013, 10: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

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)
Quotes:
Sorry but you are not allowed to view spoiler contents.

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

[spoiler]Quote: Friedslick6
you have been through a lot of hassle. I've watched every topic you posted on this, and most of them seemed to disintegrate gradually.
But the coolest part was that you didn't stop working on it despite that.

Quote: Internet Explorer
you're doing more with your life right now than probably most other people around you. You're a valuable asset to the Smash community. So yeah, you should be proud.

quote: Greg
You do have a gift which I've seen many developers use to their advantage. You can become a great coder, and with all of those ideas I think you can really build something great.

Quote from: SonicBrawler on January 01, 2013, 05:34:40 AM
This has to do with .rels, So i guess i should post here:

[spoiler]http://www.youtube.com/watch?v=ZhaksbecPFU
that looks like the ike I tried to do on marth long ago and they only worked if both was ingame, otherwise it freeze

Quote from: Tcll on January 01, 2013, 06:33:46 AM
I finally got to upload my image:


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

template link coming soon...
might be useful but still confusing
Stupid Tinypic :C

Quote from: SonicBrawler on January 01, 2013, 03:25:45 PM
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
Sorry but you are not allowed to view spoiler contents.

have you figured why lucario port can't vs anyone except for himself?
[/url]

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.

Quote from: PhantomWings on January 03, 2013, 04:23:48 PM
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!
Stupid Tinypic :C

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.

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:
Sorry but you are not allowed to view spoiler contents.

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

January 09, 2013, 06:04:43 AM #194 Last Edit: January 09, 2013, 06:56:50 AM by PhantomWings
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:



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:



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