|
|
« Reply #227 on: January 16, 2013, 11:42:00 PM » |
|
Alright, Info Dump time! It looks like modules aren't so chaotically structured after all. There's actually quite a bit of coherence to them if you know where to look. First of all, here's a mapping of some of the more important functions in ftLucario.rel: ( "ctor" is short for "constructor") 0xCC BSSList.add(r3=obj, r4=finalizer, r5=new_node) 0xD8 BSSList.clear() (this is actually module finalizer[0]) 0x13C ftLucario.ctor(r4=?, r5=?, r6=?, r7=?)
0xD388 ftLucarioExtendParamAccesser.ctor() 0xD3D0 ftClassInfoImpl.ctor()
0x11928 wnLucarioQigong.ctor(r4=?, r5=stack_data, r6=.pac_resource) 0x9B18 create_wnLucarioQigong_instance(r4=?)
0x8ECC init_ftLucarioTransactor()
Module Constructors: 0x712C soResourceModuleImpl.ctor(r4=owner, r5=?, r6=?, r7=soModuleAccessor) 0x7194 soModelModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?) 0x721C soMotionModuleImpl.ctor(r4=soModuleAccessor, r5=?) 0x73F0 soPostureModuleImpl.ctor(r4=soModuleAccessor, r5=?) 0x7460 soGroundModuleImpl.ctor(r4=soModuleAccessor) [BASE] soSituationModuleImpl.ctor 0x6D0C soTeamModuleImpl.ctor(r4=?, r5=soModuleAccessor) 0x74C4 soCollisionAttackModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?, r7=?) 0x7588 soCollisionHitModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?, r7=?) 0x764C soCollisionShieldModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?) 0x7720 soCollisionShieldModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?) [NULL] soCollisionShieldModuleNull 0x77F4 soCollisionCatchModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?) [NULL] soCollisionSearchModuleNull 0x788C soDamageModuleActor.ctor(r4=soModuleAccessor, r5=?) [BASE] soCatchModuleImpl.ctor [BASE] soCaptureModuleImpl.ctor [BASE] ftStopModuleImpl.ctor [BASE] soTurnModuleImpl.ctor 0x78F8 soShakeModuleImpl.ctor(r4=soModuleAccessor, r5=?) 0x7954 soSoundModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?) 0x79E4 soLinkModuleImpl.ctor(r4=soModuleAccessor) [BASE] soVisibilityModuleImpl.ctor 0x7A38 ftControllerModuleImpl.ctor(r4=soModuleAccessor, r5=?) 0x7AA8 soCameraModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?, r7=?) [BASE] soWorkManageModuleImpl.ctor [NULL] soDebugModuleNull 0x7B14 soAnimCmdModuleImpl.ctor(r4=?) 0x7B58 soStatusModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?) [NULL] ftGeneralTermDisideModuleNull [NULL] ftSwitchDecideModuleNull 0x8010 soKineticModuleGenericImpl.ctor(r4=soModuleAccessor) [BASE] soEventManageModuleImpl.ctor 0x8440 soGenerateArticleManageModuleImpl.ctor(r4=soModuleAccessor) 0x863C soEffectModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?, r7=?, r8=?, r9=?) [BASE] ftComboModuleImpl.ctor 0x8708 ftAreaModuleImpl.ctor(r4=soModuleAccessor, r5=?, r6=?) [NULL] soTerritoryModuleNull [NULL] soTargetSearchModuleNull 0x87A0 soPhysicsModuleImpl.ctor(r4=soModuleAccessor, r5=?) [BASE] soSlopeModuleImpl.ctor [BASE] soShadowModuleImpl.ctor 0x8800 soItemManageModuleImpl.ctor(r4=soModuleAccessor, r5=?) [BASE] soColorBlendModuleImpl.ctor [BASE] soJostleModuleImpl.ctor [BASE] ftAbnormalModuleImpl.ctor [BASE] soSlowModuleImpl.ctor [NULL] soReflectModuleNull [BASE] soHeapModuleImpl.ctor 0xD67C ftLucarioParamCustomizeModule.ctor(r4=?) [BASE] ftGlowModuleImpl.ctor
Next, here's a mapping for a few constructor functions in sora_melee. 0x1257EC Fighter.base_ctor(r4=?, r5=id, r6=?, r7=?)
0x192D4C ftFighterBuildData.base_ctor(r4=?, r5=id, r6=?, r7=?, r8=?, r9=?)
0xD8E28 soInstanceManagerFixedSimple.base_ctor()
0x68598 soModuleAccessor.base_ctor(r4=owner, r5-r10=modules, r1=modules)
0x6F850 soResourceModuleImpl.base_ctor(r4=?, r5=?, r6=?) 0x77DC soModelModuleImpl.base_ctor(r4-r8=?) 0x13844 soMotionModuleImpl.base_ctor(r4=soModuleAccessor, r5=?) 0x23364 soPostureModuleImpl.base_ctor(r4=soModuleAccessor, r5=?) 0x2556C soGroundModuleImpl.base_ctor(r4=soModuleAccessor) 0x3513C soSituationModuleImpl.base_ctor(r4=?, r5=soModuleAccessor, r6=?) 0xB5048 soTeamModuleImpl.base_ctor(r4-r8=?) 0x39590 soCollisionAttackModuleImpl.base_ctor(r4-r10=?) 0x42AA4 soCollisionHitModuleImpl.base_ctor(r4-r10=?) 0x48A1C soCollisionShieldModuleImpl.base_ctor(r4-r10=?) 0x48A1C soCollisionShieldModuleImpl.base_ctor(r4-r10=?) [NULL] soCollisionShieldModuleNull 0x4B184 soCollisionCatchModuleImpl.base_ctor(r4-r10=?) [NULL] soCollisionSearchModuleNull 0x61454 soDamageModuleActor.base_ctor(r4-r8=?) 0x64C8C soCatchModuleImpl.base_ctor(r4=soModuleAccessor, r5=?) 0x65EE4 soCaptureModuleImpl.base_ctor(r4=soModuleAccessor) 0x154088 ftStopModuleImpl.base_ctor(r4=soModuleAccessor) 0x693F4 soTurnModuleImpl.base_ctor(r4=soModuleAccessor) 0x68888 soShakeModuleImpl.base_ctor(r4=?, r5=?, r6=?) 0x561E0 soSoundModuleImpl.base_ctor(r4-r9=?) 0x6A244 soLinkModuleImpl.base_ctor(r4=?, r5=?) 0x5B248 soVisibilityModuleImpl.base_ctor(r4=soModuleAccessor, r5=?, r6=?) 0x150320 ftControllerModuleImpl.base_ctor(r4-r7=?) 0xB215C soCameraModuleImpl.base_ctor(r4-r8=?) 0xA1DA4 soWorkManageModuleImpl.base_ctor(r4=soModuleAccessor, r5=?) [NULL] soDebugModuleNull 0x1AB96C soAnimCmdModuleImpl.base_ctor(r4=?) 0x73930 soStatusModuleImpl.base_ctor(r4-r10=?) [NULL] ftGeneralTermDisideModuleNull [NULL] ftSwitchDecideModuleImplNull 0xB6DBC soKineticModuleGenericImpl.base_ctor(r4=?, r5=?, r6=?) 0x8EBF0 soEventManageModuleImpl.base_ctor(r4=owner) 0x92F10 soGenerateArticleManageModuleImpl.base_ctor(r4-r7=?) 0x9747C soEffectModuleImpl.base_ctor(r4-r10=?) 0x14FBD8 ftComboModuleImpl.base_ctor(r4=soModuleAccessor) 0x14DFE4 ftAreaModuleImpl.base_ctor(r4-r10=?) [NULL] soTerritoryModuleNull [NULL] soTargetSearchModuleNull 0x10158 soPhysicsModuleImpl.base_ctor(r4-r7=?) 0xACAC4 soSlopeModuleImpl.base_ctor(r4=soModuleAccessor, r5=?, r6=?, r7=?) 0xB62E4 soShadowModuleImpl.base_ctor(r4=soModuleAccessor, r5=?, f1=?) 0xB7E20 ItemManageModuleImpl.base_ctor(r4-r9=?) 0xBEBB4 soColorBlendModuleImpl.base_ctor(r4=soModuleAccessor, r5=?, r6=?) 0xC20D8 soJostleModuleImpl.base_ctor(r4=soModuleAccessor, r5=?, r6=?, r7=?) 0x196664 ftAbnormalModuleImpl.base_ctor(r4=soModuleAccessor) 0x5BED0 soSlowModuleImpl.base_ctor(r4=soModuleAccessor) [NULL] soReflectModuleNull 0x649FC soHeapModuleImpl.base_ctor(r4=?, r5=?, r6=?, r7=?) 0x14B5F8 ftParamCustomizeModuleImpl.base_ctor(r4=?) 0x14CCEC ftGlowModuleImpl.base_ctor(r4=soModuleAccessor)
Finally a few more functions which are relevant to Lucario in the sora_melee module: So what is the significance of all this? Well, I'll try to explain it the best I can. All interfacing with the character modules are primarily done through the ftClassInfoImpl objects. In particular, whenever the game needs an instance of Lucario, it calls ftClassInfoImpl<33, ftLucario>.Method[0][2]. This function simply calls ftLucario.ctor. ftLucario.ctor calls Fighter.base_ctor, ftFighterBuildData.base_ctor, soInstanceManagerFixedSimple.base_ctor, soModuleAccessor.base_ctor and each of the module constructors. Most character modules will usually create derived versions of the modules so they will implement their own constructors which will generate part of the object and then call the sora_melee version of the constructor. Sometimes though the character module will instead just opt to call the base constructor on its own as all it needs is the base functionality of the sora_melee version. Other times, a null placeholder will be loaded up in place of the module instead. I haven't mapped all the functions that ftLucario.ctor calls yet, but that much on its own is pretty interesting. Of particular interest is the soGenerateArticleManageModuleImpl.ctor function. Characters who don't use articles will fill the soGenerateArticleManageModuleImpl spot with a null placeholder, but characters who do use articles will have this function implemented. In addition to creating the base soGenerateArticleManageModuleImpl object, the implemented constructor will also create create soInstancePool, soInstancePoolSub and wnInstanceHolder objects inside of the soGenerateArticleManageModuleImpl object. Additionally, it will also call the constructor functions for the articles ( in Lucario's case, it calls wnLucarioQigong.ctor and wnLucarioAuraBall.ctor). Essentially, this function sets up all of Lucario's articles for use. Later on when we want to create instances of the articles, we call soArticleMediatorImpl.Method[0][1] which in turn calls either create_wnLucarioQigong_instance or create_wnLucarioAuraBall_instance. On a side note, the reason the wnLucarioAuraBall constructor and instance generator functions are in sora_melee is because Kirby can copy Lucario's AuraBall. There are other points of interest to this information too. When cloning modules, the places that cause difficulties in the cloning process are mainly the article constructors. Both wnLucarioQigong.ctor and wnLucarioAuraBall.ctor require a .pac_resource pointer. Cloned modules will usually try to retrieve the original's .pac_resource pointer which causes a crash if the original isn't loaded. Lucario's create_wnAuraBall_instance function also references a .pac_resource pointer. The ftLucarioExtendParamAccessor.ctor and ftClassInfoImpl<33, ftLucario>.ctor functions both statically reference the module id - both need to be changed when cloning. Fighter.base_ctor and ftFighterBuildData.base_ctor also reference the module id - when they are called in ftLucario.ctor, the passed id needs to be changed. Finally, there some spots here and there which needs to gain access to the ftClassInfoImpl object. this is usually done by calling a specific sora_melee function and passing in the module id. One of the places that needs to call this function is near the end of ftLucario.ctor ( this is the same for all characters). For Lucario's module, there are two other places which does this: ftLucario.Method[17][16] and ftLucario.Method[0][3]. I'm not sure the significance of these two functions, but their use doesn't seem to be universal. Anyways, I think this information will prove useful not just for cloning characters, but for adding additional functionality to existing characters as well. Unfortunately, there seems to be a lot of syntax to follow in order to ensure things run nicely - but hopefully that will come with time.
|