Home Gallery Resources The Team Rules chat Login Register
Pages:  1 ... 4 5 6 [7] 8 9 10 ... 28
Author Topic: Let's look into Module Fíles (.rel) - Defensive Collision is now!  (Read 168793 times)
0 Members and 1 Guest are viewing this topic.
pikazz
Heroic Kitten
**
Offline Offline

Posts: 2286


Machinimator!

  • Awards Renowned Hacker Good Citizen Pin Collector Helping Hand

  • View Profile Awards
    « Reply #90 on: July 25, 2012, 05:51:26 PM »


    sneak, snea-

    ...

    Oh, who am I kidding.

    Hi everyone, Phantom Wings here. I haven't been by for a while now so I figured I'd drop by and pay my regards to the Brawl Hacking community. I notice that there's been a little bit of interest in the workings of .rels in this here thread so:

    [Download]

    [Source]

    I had this one on the backburner before I left the last time. It's not as intuitive as the Module Editor 2, but it does support editing blocks and relocations as well as saving - hope it helps.

    The app itself isn't that well put together, but the module library should be easy enough to salvage for use in BrawlBox - but as usual, don't expect any commenting in my source code.

    That's all for now. See you guys around.
    oooh! PW you came! 83

    and awesome with Module editor 3 >w<
    also, I need to ask you! do you know something about how the Relocation are linked to Objects and Assembly?

    and do you possible know exactly how NameOffset, PrologOffset, EpilogOffset and Unresolved Offset are linked? I just dont find it out how D:

    A huge thanks for the gift Cheesy
    « Last Edit: July 25, 2012, 05:58:36 PM by Peke~ » Logged

    Stupid Tinypic :C

    Sky Grounder
    Lol Kitten
    *********
    Offline Offline

    Posts: 978


  • Awards Heart Container Tutorial Writer

  • View Profile Awards
    « Reply #91 on: July 25, 2012, 07:43:01 PM »


    oooh! PW you came! 83

    and awesome with Module editor 3 >w<
    also, I need to ask you! do you know something about how the Relocation are linked to Objects and Assembly?

    and do you possible know exactly how NameOffset, PrologOffset, EpilogOffset and Unresolved Offset are linked? I just dont find it out how D:

    A huge thanks for the gift Cheesy
    Just reminding you that when PW arrives, he usually immediately dissappears after making a post D:
    Logged

    3DS FC: 5370-0958-4818
    Wii U NNID: Doraleus

    Shinobu Nyan!
    Lol Kitten
    *********
    Offline Offline

    Posts: 877


    How the Cool Kids Dance Once More!!

  • Awards Diamond in the Rough Hot Topic Warm Welcomer Heart Container

  • View Profile Awards
    « Reply #92 on: July 25, 2012, 08:38:10 PM »


    Just reminding you that when PW arrives, he usually immediately dissappears after making a post D:
    Lol, so true.
    Logged

    Click Sig For My Tutorial Thread

    I'm Just You're Friendly Forum Pseudo Narcissist
    This is Nyan. She He is indeed random and also definitely not a pervert.
    I Will Accept Everyone's Faults As Long As They're Not Annoying.

    PhantomWings
    Mega Kitten
    *****
    Offline Offline

    Posts: 167

  • Awards Super Saiyan Topic Featured

  • View Profile Awards
    « Reply #93 on: July 25, 2012, 11:17:49 PM »


    oooh! PW you came! 83

    and awesome with Module editor 3 >w<
    also, I need to ask you! do you know something about how the Relocation are linked to Objects and Assembly?

    and do you possible know exactly how NameOffset, PrologOffset, EpilogOffset and Unresolved Offset are linked? I just dont find it out how D:

    A huge thanks for the gift Cheesy

    Hmm, a lot of questions here. I guess I'll start from the beginning.

    When the module is first loaded into memory, the first thing the game does is call a function on it that links the module to each of the other modules loaded into memory. In the Revolution SDK, this function is called OSLink. When called on a module, it resolves all relocations inside the module and checks all existing modules for dependencies on it resolving them in the process.

    I won't go into too much detail on how the relocations are stored as you can find that in the Module Viewer 3 Source code, but one important thing to know is the relocation types:

    Code:

    Value = SectionOffset + Addend

    0x00 nop
    0x01 Write Word ( target u32 = Value )
    0x02 Set Long Branch Offset ( target u32 = (target u32 & ~0x03FFFFFC) | (Addend & 0x03FFFFFC) )
    0x03 Write Lower Half ( target u16 = Value & 0xFFFF )
    0x04 == 0x03
    0x05 Write Upper Half ( target u16 = (Value >> 16) & 0xFFFF )
    0x06 == 0x05
    0x07 Set Short Branch Offset ( target u32 = (target u32 & ~0xFFFC) | (Addend & 0xFFFC) )
    0x08 == 0x07
    0x09 == 0x07
    0x0A Set Long Branch Destination ( target long branch destination = Addend )
    0x0B Set Short Branch Destination ( target short branch destination = Addend )
    0x0C == 0x0B
    0x0D == 0x0B


    Once the module is linked, the _prolog function may be optionally called. In Brawl, the _prolog function is always called. The assembly code for the _prolog function can be found by going to the PrologOffset inside the section specified by PrologSection (the PrologSection is almost always the Section[1]). When called, it invokes the constructor for each of the top level objects inside the module. The pointers to these constructor functions are usually found in Section[2] of the module.

    Objects exist in multiple parts. All object declarations, inheritance values and  virtual function tables are usually stored in Section[5]. There isn't a whole lot of organization to the data, but there are a few basic structures that can be found if you know what to look for:

    Code:

    (because all pointers only exist once the module has been linked, you won't be able to see these values inside a regular hex viewer.
     They can be found using the Module Viewer 3's memory viewer though)

    Declaration (8 bytes)
    0x00 Name ptr
    0x04 Inheritance[] ptr

    Inheritance (8 bytes)
    0x00 Declaration ptr
    0x04 Unknown

    Virtual Function Table (8 bytes + 4 * numFunctions)
    0x00 Declaration ptr
    0x04 Blank
    0x08 Function[0] ptr
    0x__ Function[...] ptr


    Because everything is so unorganized, the only way you can really parse this section is if you use a code crawler like the Module Viewer 2 used. For the time being, Module Viewer 3 supports simple tagging, but hopefully there'll be a way to automate the process soon.

    As for the actual objects themselves; they are created by the constructor functions into the Bss Memory which in turn is created at runtime. The Bss Memory is accessed like the rest of the module sections and is usually found at Section[6] - while you can open it in the memory viewer, the actual section doesn't exist in the module and is only created at runtime.


    Beyond that, the _epilog function does the opposite of the _prolog function and is called right before the module is unlinked (The destructor function pointers are found in Section[3]). As for the _unresolved function; all external functions calls in the module are initially directed towards this function. That way, if a function doesn't get linked, the _unresolved function is called instead. For the most part, it does something along the lines of throwing an exception while reporting the module's source file (e.g. mo_fighter.cpp)



    That's about as much as I know about the module files - the rest of it you already posted in the link in the opening post.

    I'll be around, so if you have any other questions, go ahead and ask away.
    « Last Edit: July 25, 2012, 11:33:56 PM by PhantomWings » Logged

    pikazz
    Heroic Kitten
    **
    Offline Offline

    Posts: 2286


    Machinimator!

  • Awards Renowned Hacker Good Citizen Pin Collector Helping Hand

  • View Profile Awards
    « Reply #94 on: July 26, 2012, 12:04:00 AM »


    Hmm, a lot of questions here. I guess I'll start from the beginning.

    When the module is first loaded into memory, the first thing the game does is call a function on it that links the module to each of the other modules loaded into memory. In the Revolution SDK, this function is called OSLink. When called on a module, it resolves all relocations inside the module and checks all existing modules for dependencies on it resolving them in the process.

    I won't go into too much detail on how the relocations are stored as you can find that in the Module Viewer 3 Source code, but one important thing to know is the relocation types:

    Code:

    Value = SectionOffset + Addend

    0x00 nop
    0x01 Write Word ( target u32 = Value )
    0x02 Set Long Branch Offset ( target u32 = (target u32 & ~0x03FFFFFC) | (Addend & 0x03FFFFFC) )
    0x03 Write Lower Half ( target u16 = Value & 0xFFFF )
    0x04 == 0x03
    0x05 Write Upper Half ( target u16 = (Value >> 16) & 0xFFFF )
    0x06 == 0x05
    0x07 Set Short Branch Offset ( target u32 = (target u32 & ~0xFFFC) | (Addend & 0xFFFC) )
    0x08 == 0x07
    0x09 == 0x07
    0x0A Set Long Branch Destination ( target long branch destination = Addend )
    0x0B Set Short Branch Destination ( target short branch destination = Addend )
    0x0C == 0x0B
    0x0D == 0x0B


    Once the module is linked, the _prolog function may be optionally called. In Brawl, the _prolog function is always called. The assembly code for the _prolog function can be found by going to the PrologOffset inside the section specified by PrologSection (the PrologSection is almost always the Section[1]). When called, it invokes the constructor for each of the top level objects inside the module. The pointers to these constructor functions are usually found in Section[2] of the module.

    Objects exist in multiple parts. All object declarations, inheritance values and  virtual function tables are usually stored in Section[5]. There isn't a whole lot of organization to the data, but there are a few basic structures that can be found if you know what to look for:

    Code:

    (because all pointers only exist once the module has been linked, you won't be able to see these values inside a regular hex viewer.
     They can be found using the Module Viewer 3's memory viewer though)

    Declaration (8 bytes)
    0x00 Name ptr
    0x04 Inheritance[] ptr

    Inheritance (8 bytes)
    0x00 Declaration ptr
    0x04 Unknown

    Virtual Function Table (8 bytes + 4 * numFunctions)
    0x00 Declaration ptr
    0x04 Blank
    0x08 Function[0] ptr
    0x__ Function[...] ptr


    Because everything is so unorganized, the only way you can really parse this section is if you use a code crawler like the Module Viewer 2 used. For the time being, Module Viewer 3 supports simple tagging, but hopefully there'll be a way to automate the process soon.

    As for the actual objects themselves; they are created by the constructor functions into the Bss Memory which in turn is created at runtime. The Bss Memory is accessed like the rest of the module sections and is usually found at Section[6] - while you can open it in the memory viewer, the actual section doesn't exist in the module and is only created at runtime.


    Beyond that, the _epilog function does the opposite of the _prolog function and is called right before the module is unlinked (The destructor function pointers are found in Section[3]). As for the _unresolved function; all external functions calls in the module are initially directed towards this function. That way, if a function doesn't get linked, the _unresolved function is called instead. For the most part, it does something along the lines of throwing an exception while reporting the module's source file (e.g. mo_fighter.cpp)



    That's about as much as I know about the module files - the rest of it you already posted in the link in the opening post.

    I'll be around, so if you have any other questions, go ahead and ask away.

    wow! I am amazed, you actually answer my question and now I am happy Happy Face
    and that information will be excellent help! I understand more about Epilog, Prolog, Bssoffsets and more about Relocation section thanks to you :3
    I appreciate your help! x3

    but there is one thing that still bugs me, about nameOffset.
    often when it is a Offset, it's most of the time 4-8 hex big and often ends on either 0-4-8-C but the nameOffset ends on almost every single hex that are known (0-F), mostly 6 and 1 Im srs here
    are they stored/load/created at the same way the Bss Memory are created in runtime?

    planing to write completely a whole new Module file from scratch to understand more about it's struckture Kirby Dance

    Just reminding you that when PW arrives, he usually immediately dissappears after making a post D:
    not this time :3
    « Last Edit: July 26, 2012, 12:06:10 AM by Peke~ » Logged

    Stupid Tinypic :C

    Sky Grounder
    Lol Kitten
    *********
    Offline Offline

    Posts: 978


  • Awards Heart Container Tutorial Writer

  • View Profile Awards
    « Reply #95 on: July 26, 2012, 07:54:46 AM »


    I took the liberty to write down all the IDs in the module files using the module editor, in case it could be useful (for references):
    IDs:

    00 - main.dol?
    01 - sora_scene
    02 - sora_menu_main
    03 - sora_menu_tour
    04 - sora_menu_qm
    05 - sora_menu_edit
    06 - sora_menu_collect_viewer
    07 - sora_menu_replay
    08 - sora_menu_snap_shot
    09 - sora_menu_event
    0A - sora_menu_sel_char
    0B - sora_menu_sel_stage
    0C - sora_menu_game_over
    0D - sora_menu_intro
    0E - sora_menu_friend_list
    0F - sora_menu_watch
    10 - sora_menu_name
    11 - sora_menu_sel_char_access
    12 - sora_menu_rule
    13 - sora_menu_simple_ending
    14 - sora_minigame
    15 - sora_menu_time_result
    16 - sora_menu_boot
    17 - sora_menu_challenger
    18 - sora_menu_title
    19 - sora_menu_title_sunset
    1A - sora_fig_get_demo
    1B - sora_melee
    1C - sora_adv_menu_name
    1D - sora_adv_menu_visual
    1E - sora_adv_menu_sel_char
    1F - sora_adv_menu_sel_map
    20 - sora_adv_menu_difficulty
    21 - sora_adv_menu_game_over
    22 - sora_adv_menu_result
    23 - sora_adv_menu_save_load
    24 - sora_adv_menu_seal
    25 - sora_adv_menu_ending
    26 - sora_adv_menu_telop
    27 - sora_adv_menu_save_point
    28 - sora_adv_stage
    29 - sora_enemy
    2A - st_battles
    2B - st_battle
    2C - st_config
    2D - st_final
    2E - st_dolpic
    2F - st_mansion
    30 - st_mariopast
    31 - st_kart
    32 - st_donkey
    33 - st_jungle
    34 - st_pirates
    35 - st_oldin
    36 - st_norfair
    37 - st_orpheon
    38 - st_crayon
    39 - st_halberd
    3A - st_starfox
    3B - st_stadium
    3C - st_tengan
    3D - st_fzero
    3E - st_ice
    3F - st_gw
    40 - st_emblem
    41 - st_madein
    42 - st_earth
    43 - st_palutena
    44 - st_famicom
    45 - st_newpork
    46 - st_village
    47 - st_metalgear
    48 - st_greenhill
    49 - st_pictchat
    4A - st_plankton
    4B - st_dxshrine
    4C - st_dxyorster
    4D - st_dxgarden
    4E - st_dxonett
    4F - st_dxgreens
    50 - st_dxrcruise
    51 - st_dxbigblue
    52 - st_dxcorneria
    53 - st_dxpstadium
    54 - st_dxzebes
    55 - st_stageedit
    56 - st_otrain
    57 - st_heal
    58 - st_homerun
    59 - st_targetbreak
    5A - st_croll
    5B - ft_mario
    5C - ft_donkey
    5D - ft_link
    5E - ft_samus
    5F - ft_yoshi
    60 - ft_kirby
    61 - ft_fox
    62 - ft_pikachu
    63 - ft_luigi
    64 - ft_captain
    65 - ft_ness
    66 - ft_koopa
    67 - ft_peach
    68 - ft_zelda
    69 - ft_iceclimber
    6A - ft_marth
    6B - ft_gamewatch
    6C - ft_falco
    6D - ft_ganon
    6E - ft_wario
    6F - ft_metaknight
    70 - ft_pit
    71 - ft_pikmin
    72 - ft_lucas
    73 - ft_diddy
    74 - ft_poke
    75 - ft_dedede
    76 - ft_lucario
    77 - ft_ike
    78 - ft_robot
    79 - ft_toonlink
    7A - ft_snake
    7B - ft_sonic
    7C - ft_purin
    7D - ft_wolf
    7E - ft_zako

    Also, by looking in sora_adv_stage, I counted 75 unique SSE formats from one of the lists.
    There was also names such as "StActTrigger(name, such ResetStock)" which might describe the uses for the different formats. (I can't figure out which format they describes though.)
    Logged

    3DS FC: 5370-0958-4818
    Wii U NNID: Doraleus

    pikazz
    Heroic Kitten
    **
    Offline Offline

    Posts: 2286


    Machinimator!

  • Awards Renowned Hacker Good Citizen Pin Collector Helping Hand

  • View Profile Awards
    « Reply #96 on: July 26, 2012, 09:08:31 AM »


    I took the liberty to write down all the IDs in the module files using the module editor, in case it could be useful (for references):
    IDs:

    00 - main.dol?
    01 - sora_scene
    02 - sora_menu_main
    03 - sora_menu_tour
    04 - sora_menu_qm
    05 - sora_menu_edit
    06 - sora_menu_collect_viewer
    07 - sora_menu_replay
    08 - sora_menu_snap_shot
    09 - sora_menu_event
    0A - sora_menu_sel_char
    0B - sora_menu_sel_stage
    0C - sora_menu_game_over
    0D - sora_menu_intro
    0E - sora_menu_friend_list
    0F - sora_menu_watch
    10 - sora_menu_name
    11 - sora_menu_sel_char_access
    12 - sora_menu_rule
    13 - sora_menu_simple_ending
    14 - sora_minigame
    15 - sora_menu_time_result
    16 - sora_menu_boot
    17 - sora_menu_challenger
    18 - sora_menu_title
    19 - sora_menu_title_sunset
    1A - sora_fig_get_demo
    1B - sora_melee
    1C - sora_adv_menu_name
    1D - sora_adv_menu_visual
    1E - sora_adv_menu_sel_char
    1F - sora_adv_menu_sel_map
    20 - sora_adv_menu_difficulty
    21 - sora_adv_menu_game_over
    22 - sora_adv_menu_result
    23 - sora_adv_menu_save_load
    24 - sora_adv_menu_seal
    25 - sora_adv_menu_ending
    26 - sora_adv_menu_telop
    27 - sora_adv_menu_save_point
    28 - sora_adv_stage
    29 - sora_enemy
    2A - st_battles
    2B - st_battle
    2C - st_config
    2D - st_final
    2E - st_dolpic
    2F - st_mansion
    30 - st_mariopast
    31 - st_kart
    32 - st_donkey
    33 - st_jungle
    34 - st_pirates
    35 - st_oldin
    36 - st_norfair
    37 - st_orpheon
    38 - st_crayon
    39 - st_halberd
    3A - st_starfox
    3B - st_stadium
    3C - st_tengan
    3D - st_fzero
    3E - st_ice
    3F - st_gw
    40 - st_emblem
    41 - st_madein
    42 - st_earth
    43 - st_palutena
    44 - st_famicom
    45 - st_newpork
    46 - st_village
    47 - st_metalgear
    48 - st_greenhill
    49 - st_pictchat
    4A - st_plankton
    4B - st_dxshrine
    4C - st_dxyorster
    4D - st_dxgarden
    4E - st_dxonett
    4F - st_dxgreens
    50 - st_dxrcruise
    51 - st_dxbigblue
    52 - st_dxcorneria
    53 - st_dxpstadium
    54 - st_dxzebes
    55 - st_stageedit
    56 - st_otrain
    57 - st_heal
    58 - st_homerun
    59 - st_targetbreak
    5A - st_croll
    5B - ft_mario
    5C - ft_donkey
    5D - ft_link
    5E - ft_samus
    5F - ft_yoshi
    60 - ft_kirby
    61 - ft_fox
    62 - ft_pikachu
    63 - ft_luigi
    64 - ft_captain
    65 - ft_ness
    66 - ft_koopa
    67 - ft_peach
    68 - ft_zelda
    69 - ft_iceclimber
    6A - ft_marth
    6B - ft_gamewatch
    6C - ft_falco
    6D - ft_ganon
    6E - ft_wario
    6F - ft_metaknight
    70 - ft_pit
    71 - ft_pikmin
    72 - ft_lucas
    73 - ft_diddy
    74 - ft_poke
    75 - ft_dedede
    76 - ft_lucario
    77 - ft_ike
    78 - ft_robot
    79 - ft_toonlink
    7A - ft_snake
    7B - ft_sonic
    7C - ft_purin
    7D - ft_wolf
    7E - ft_zako

    Also, by looking in sora_adv_stage, I counted 75 unique SSE formats from one of the lists.
    There was also names such as "StActTrigger(name, such ResetStock)" which might describe the uses for the different formats. (I can't figure out which format they describes though.)
    that's great! I will add those in OP together with PW's Gift! x3

    also, I believe the StActTrigger is a function. not actually sure how Function works in ASM if it are any

    EDIT: added the ID list and PW's gift to OP!
    « Last Edit: July 26, 2012, 09:48:41 AM by Peke~ » Logged

    Stupid Tinypic :C

    Sky Grounder
    Lol Kitten
    *********
    Offline Offline

    Posts: 978


  • Awards Heart Container Tutorial Writer

  • View Profile Awards
    « Reply #97 on: July 26, 2012, 10:02:53 AM »


    that's great! I will add those in OP together with PW's Gift! x3

    also, I believe the StActTrigger is a function. not actually sure how Function works in ASM if it are any
    Yeah, but I meant functions connected to those formats Tongue

    I'll write down a bunch of those "triggers":

    StActTriggerGimmickStatus
    StActTriggerStockReset
    StActTriggerEffect
    StActTriggerQuake
    StActTriggerChangeScene
    StActTriggerCreateFixedItem
    StActTriggerMotionPathMove4Stop
    StActTriggerMotionPathMove4Start
    StActTriggerCameraDemo
    StActTriggerForceScrollOn
    StActTriggerScrollLockOff
    StActTriggerScrollLockOn
    StActTriggerStepJump
    StActTriggerCB
    StActTriggerEnemyPop
    StActTriggerSound
    StActTriggerAreaSound
    Ofcourse, all of the formats isn't necessarily "triggers", but I think these functions relate to some of the formats. (All SSE stages share the same module file.)
    Now... maybe I should go back to figuring out SSE files? I've already figured out how songs and stages are connected xP
    Logged

    3DS FC: 5370-0958-4818
    Wii U NNID: Doraleus

    Ultraxwing
    Holy Kitten
    *
    Offline Offline

    Posts: 1599


    Master of the Vault!

  • Awards Constructive Hot Topic KCMM Veteran Heart Container

  • View Profile Awards
    « Reply #98 on: July 26, 2012, 10:15:27 AM »


    From what the above looks like. if all the SSE stages refer to one .REL

    those look like things with code. like the ChangeScene one for example might refer to how when you enter a door. it changes the scene. (i don't think that's exactly it) so if one wanted to when it comes the time. when we understand 120% of the Modules. we can Edit SSE stages to do cool things. an idea might be another added in boss.

    and if we understand modules better. i bet the Clone Engine will be completely possible. seeing how alot of these things are .RELS and to get a clones character to work isn't just activating a slot and copy and pasting a character. it might involve an edited .REL and other things.

    and Phantomwings my man. you are amazing. +1Peachy for you and only for you.
    Logged


    Sky Grounder
    Lol Kitten
    *********
    Offline Offline

    Posts: 978


  • Awards Heart Container Tutorial Writer

  • View Profile Awards
    « Reply #99 on: July 26, 2012, 10:36:42 AM »


    From what the above looks like. if all the SSE stages refer to one .REL

    those look like things with code. like the ChangeScene one for example might refer to how when you enter a door. it changes the scene. (i don't think that's exactly it) so if one wanted to when it comes the time. when we understand 120% of the Modules. we can Edit SSE stages to do cool things. an idea might be another added in boss.

    and if we understand modules better. i bet the Clone Engine will be completely possible. seeing how alot of these things are .RELS and to get a clones character to work isn't just activating a slot and copy and pasting a character. it might involve an edited .REL and other things.

    and Phantomwings my man. you are amazing. +1Peachy for you and only for you.
    yknow, since all SSE stages use one common module file, it is pretty much possible to make our own SSE stages. It just involves figuring out those formats that are stored in BLOC files (SSE file container). If a file isn't present, it just won't be used, as simple as that.

    But I doubt I could get BJ to code support for those files though D:
    Logged

    3DS FC: 5370-0958-4818
    Wii U NNID: Doraleus

    pikazz
    Heroic Kitten
    **
    Offline Offline

    Posts: 2286


    Machinimator!

  • Awards Renowned Hacker Good Citizen Pin Collector Helping Hand

  • View Profile Awards
    « Reply #100 on: July 26, 2012, 10:45:14 AM »


    yknow, since all SSE stages use one common module file, it is pretty much possible to make our own SSE stages. It just involves figuring out those formats that are stored in BLOC files (SSE file container). If a file isn't present, it just won't be used, as simple as that.

    But I doubt I could get BJ to code support for those files though D:
    but we need to be prepared! coding ASM is way harder than Flash or C++, ASM is the closes  to the hardware than any other programming code and the hardest code to learn (but most effectently) so it wouldn't be a dance on flowers to do own SSE stages in REL.

    but the idea is lovely! <3

    also, thanks for PW's gift I have now seen how they are stored and how I can (possible) relocate them in hex so I will try to build one OWN module file from scratch in hex in soon future
    Logged

    Stupid Tinypic :C

    Sky Grounder
    Lol Kitten
    *********
    Offline Offline

    Posts: 978


  • Awards Heart Container Tutorial Writer

  • View Profile Awards
    « Reply #101 on: July 26, 2012, 11:00:35 AM »


    My point is: We can already do our own SSE stages without having to edit the main module. BUT, if we wanted to code a rolling rock that has a hitbox (already coded in the module, I think the format is called GMVA) or something else, we would have to edit the module file.

    But the thing is that we don't know what each of the SSE formats do or how they work. There's no way to edit them without hex either. That's pretty much why no one has made their own unique SSE stage.
    Logged

    3DS FC: 5370-0958-4818
    Wii U NNID: Doraleus

    BlackJax96
    Brawl Mod God
    Moderator
    ****
    Offline Offline

    Posts: 4612


  • Awards KCMM Veteran Sniper King for a Day Featured

  • View Profile Awards
    « Reply #102 on: July 26, 2012, 12:16:50 PM »


    But I doubt I could get BJ to code support for those files though D:

    Well as long as the file formats aren't gigantic, I could go on a programming spree for supporting minor file formats at some point in time. Since BRSAR is already fully known... I can make arrangements.
    Logged

    Sky Grounder
    Lol Kitten
    *********
    Offline Offline

    Posts: 978


  • Awards Heart Container Tutorial Writer

  • View Profile Awards
    « Reply #103 on: July 26, 2012, 02:17:25 PM »


    The formats are simple as heck, but as I stated in one of my previous posts, SSE have about 75 unique formats, and it's about trying to figure out what they do, which is the time-consuming part.

    Now we're getting a bit off-topic. Should I make a seperate thread for SSE investigation and stuff?
    Logged

    3DS FC: 5370-0958-4818
    Wii U NNID: Doraleus

    PhantomWings
    Mega Kitten
    *****
    Offline Offline

    Posts: 167

  • Awards Super Saiyan Topic Featured

  • View Profile Awards
    « Reply #104 on: July 26, 2012, 02:21:36 PM »


    wow! I am amazed, you actually answer my question and now I am happy Happy Face
    and that information will be excellent help! I understand more about Epilog, Prolog, Bssoffsets and more about Relocation section thanks to you :3
    I appreciate your help! x3

    but there is one thing that still bugs me, about nameOffset.
    often when it is a Offset, it's most of the time 4-8 hex big and often ends on either 0-4-8-C but the nameOffset ends on almost every single hex that are known (0-F), mostly 6 and 1 Im srs here
    are they stored/load/created at the same way the Bss Memory are created in runtime?

    planing to write completely a whole new Module file from scratch to understand more about it's struckture Kirby Dance
    not this time :3

    The name offset and size seems to be only used for debug purposes as it doesn't have any use during runtime (The revolution SDK makes reference to it though). As for why the offset isn't aligned to 0x4; that's because strings are stored in memory back to back without any alignment. Therefore, string pointers can end in any values from 0x0 to 0xF.
    Logged

    Pages:  1 ... 4 5 6 [7] 8 9 10 ... 28
    Print
    Jump to: