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.