About OpenSA, and the PSA source release.

Now, some of you may know that I was working on a replacement for PSA dubbed OpenSA.

The main goal was to be able to decode the .pac files 100%, allowing for EVERYTHING to be edited. Well, I got really far, and made massive advancements in the understanding of .pac files, especially the mysterious Fighter.pac.

Heres some examples of things I have done with OpenSA and the knowledge gained from writing my OWN moveset parser that were not possible with PSA alone.

  1. Viewing of Fighter.pac
    For those that aren’t familar with PSA, Actions in PSA have logic in them that calls Subactions that do most of the real dirty work. However, anyone thats used PSA knows that the action #’s start at ~116. Why? Because actions 0-~116 are defined in Fighter.pac and are shared between all characters (For a somewhat accurate list of action ID’s, check out Amazing Ampharos’s action ID list) OpenSA was able to open this file and view these general actions.
  2. Patching of Fighter.pac
    Well, one problem with Fighter.pac is that it isn’t loaded by even the latest File Replacement Code (3.5.1 as of this writing). However, some of the availible codes already targeted the copy of Fighter.pac the game loads into memory, without the codemakers even realizing that they were in fact, modifying a moveset file. Stale move multipliers, for example, reside in Fighter.pac. With my newfound knoledge, I was able to make patches for Fighter.pac that did what I wanted. In fact, I made some of these BEFORE I even owned a USBGecko.
    Example:Replacing double jump animation with dizzy.
  3. Injection of PSA commands.
    The problem with the above is that it isn’t possible to insert lines into Fighter.pac using standard RAM modifying codes like we had been using. We were limited to simple variable changes and nop’ing out commands. So, I thought of something. After I obtained a USBGecko, I noticed that the loaded copies of .pac files have a big difference in the way they store offsets. Normally, .pac files contain relative offsets to other places inside the same .pac file. This means that you can’t reference outside of the pacfile, with the exception of External Subroutines.

    However, when Brawl loads the file, these files have the relative offsets replaced with absolute ones. This allows for a very complex method I created that allows you to insert lines. Basically, a command is replaced with a Goto instruction that makes the action execution jump outside of the file into a space in Brawl’s tmp place, where a custom subroutine is waiting(that contains the replaced function). Then subroutine then Goto’s back to the command after the replaced one, and all continues as normal.

    30 minutes after I thought about this method, I made this ledgetech code.

So, whats the point of this post? Well, its mostly for me to decide what I want to do with OpenSA now. The main reason that people wanted it, to edit Charizard/Squirtle/Ivysaur/DDD, has already been obtained by my PSAMod, which I was able to create less than 24 hours after PW release the PSA source released due to my extensive knowledge of the .pac files.

I’m not sure what to do. I haven’t made any progress on editing projectiles or articles, although poking around with a USBGecko has given me some results. I want to move on from coding PC-Side apps, and do more Wii hacking.

One Response to “About OpenSA, and the PSA source release.”

  1. .Fade says:

    I dunno if I’ve made this clear yet, but you are, indeed, my new hero. =)

    By any chance is it possible yet to shrink a .pac file? What I mean is being able to edit it and keep the .pac at relatively the same size.