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