Final Fantasy Hacktics

So a while back I wanted to be able to use jobs 3A and 3B for some characters, and not have to go through the process of using another character's job like Simon's, replacing 3A with Simon, replacing Simon with my character, making the ENTD edits, etc. Much easier if I can just use jobs 3A and 3B, and point them to unused entries in unit.bin and wldface.bin (Like 08 or 09).

In the help section I whipped up this patch, which is a quick and dirty way to get exactly that (Job 3A uses 08, Job 3B uses 09). 
(EDIT: Included the entry for the REQUIRE.OUT table.)



But then we figured it'd be useful to be able to change these entries for any job. So we discussed making a spreadsheet for it. Raven was going to write one, but then it seems I pre-empted him.

This spreadsheet should allow you to change which entries in unit.bin and wldface.bin are used for each base job. So, if you want to make Gafgarion's guest job (0x17) look like Reis in the formation screen, job wheel, battle prepation screens, etc? Just change the his entry from 0D to 07. Want to overwrite unused entries in unit.bin/wldface.bin and tie them to specific base jobs? Sure.

Attached is the spreadsheet. Basically you just edit the yellow column, then copy the XML from the XML tab into a .XML file in the same directory as FFTorgASM and use it to apply the patch.

I labelled the base jobs in the spreadsheet with what they're used for in the game currently, but interestingly, I couldn't figure out what jobs 0x35 - 0x39 are actually used for, if anything. Are those all unused? That might open up some possibilites for adding more characters without having to take jobs that are in use.

EDIT (8/28/2018): Attaching new version of the spreadsheet!  Fixes a problem with default values, notably for Holy Dragon Reis.

Heh - just noticed, the XML is malformed.

Insert a </Patch> between the </Location> and </Patches>.

You just paste the XML into Notepad or some other text editor. Don't use a special program to do it; sounds like it's giving you problems. As long as the .XML file is in the same directory as FFTorgASM, it'll find it. Just look for the patch name "Dragon Gift no longer requires dragon".

Glad to have been helpful

Looks like you figured out how to produce the correct hex, and it does indeed have to use the RAM offset. The code has to refer to the correct addresses at runtime, and it's run from RAM. What we're doing at this step is producing the right code -- it doesn't matter how the code gets into RAM.

(The RAM starting address is important for encoding the ASM, because certain branch instructions are encoded as a branch over a certain number of statements, rather than to an absolute address, so the same statement would actually branch to a different location if it was elsewhere in the code.)

FFTorgASM patches the files, so it wants the file offsets. This is where you use the BATTLE.BIN offset.

EDIT: And yeah, PSX wants little endian encoding.

I suppose I'll jump in and add a few things. I also started with formulas...

As far as the formula hacking article: What's being listed there are offsets from a pointer to unit data. A few useful memory locations when you're dealing with formulas:

0x80192d94 "Caster" unit (the one using the ability)
0x80192d98 Target unit

So for example, if you see code like:

lui r3,0x8019
lw r3,0x2d98(r3)

r3 is now a pointer to the target unit of the ability. Then if you see something like this:

lbu r2,0x0030(r3)

r2 now contains the "Original PA" that you mentioned in the first post, of the target unit. (0x0030 offset from target unit pointer).

For a lot of the "data locations", they're just memory locations and what they contain. One of the difficult parts of analyzing ASM is that you'll see stuff like... well, look at my r3 example from earlier.

r3 = memory at 0x80192d98? If I don't know what that is, then it's just... okay? No idea what to make of it. r3 equals some memory somewhere! Lovely!

So the listing of data locations basically helps you figure out where the game is storing certain variables. It's always the same. If I know 0x80192d98 is a pointer to the target unit, suddenly it makes sense.

There are three main program files in FFT:
SCUS_942.21: Main program. Always in memory, but delegates most of its tasks to the other two programs. (The SCUS text file refers to routines within this file)
BATTLE.BIN: Program for battles/pre-battles/cutscenes.
WORLD.BIN: Program for the world map/formation screen/etc.

BATTLE.BIN and WORLD.BIN are never loaded at the same time. At least I'm pretty sure. PSX doesn't have enough RAM to hold them both and SCUS.

As far as applying your own ASM, I'd actually do it with XML patches and FFTorgASM - then you don't have to worry about CDMage and extracting, etc. If you look at the format of those XMLs, it should be simple enough to figure out. The PSX expects ASM instructions in little endian byte order, but, of course, I wouldn't encode any ASM commands into hex by hand, not when we have programs like MassHexASM! (Sorry, shameless plug; but it is useful.)

Reused sprites don't count as part of the limit. So if there were two male squires, that's only one. Replacing one with a unique sprite to that map means you've added one to that distinct sprite count. It can't go over 9, or else you get... that.

The reason your units aren't lining up is probably because the event can't find them, as you changed the Unit IDs. You'd have to edit the event to put in your new IDs. I imagine EasyVent could do that rather easily?

Wrong ENTD; the correct one is 188. I know it's unlabeled.

I've been calling them 'tables', but that's kind of ambiguous; they're arrays. I'll refer to them as such from here on out. If I may use C-like syntax for a moment, the idea is:
array[base_job_index] = [unit_bin_index] (This is the same number as the wldface index)

I have some simple knowledge about what would have to be in this array. For example, because Ramza's three jobs correspond to 00/01/02 in UNIT.BIN, Delita's Squire (base job 4) corresponds to 03, and Algus (base job 7) is 04, I know that:
array[1] = 0; array[2] = 1; array[3] = 2; array[4] = 3; array[7] = 4.

Assuming a byte (in C, probably 'char') data type, we're looking for: 00 01 02 03 ?? ?? 04. Question marks are "don't cares"; they could be anything. The numbers have to be in that order because arrays are consecutive in memory. So, I opened WORLD.BIN in a hex editor and looked for that sequence. The search was just "00 01 02 03" and I just looked at the results to see if there was an 04 two away from the 03.

I actually only could find one instance of it, and it only affected the formation screen sprite, but not the palette or the portrait. That was the array at 0xADE34 in WORLD.BIN.

Eventually I finally thought of trying "00 00 01 00 02 00 03 00". There was nothing that said the array had to be a byte data type; this is the two-byte (halfword) equivalent. C's short int. That's how I found the 3 different locations in WORLD.BIN, and also how I found the one in ATTACK.OUT.

...Then I found out about Vanya's thread :O.

...

But anyhow, about what you need to edit, you just need to edit the proper locations in the same arrays. Essentially, you're just changing offsets. So, for that array, I edited 0xADE34 + 0x3A = 0xADE6E. Then I also edited the next location because 3A/3B are right next to each other. That's this:

    <Location file="WORLD_WORLD_BIN" offset="ADE6E">
      0809
    </Location>

For the ATTACK.OUT one, for example, which is one of the halfword arrays: (I think the array really starts at 0x16BB0)
0x16BB0 + (0x3A * 2) = 0x16C24. Once again, I edited the next value as well, because I was changing both 0x3A and 0x3B.

That was this one:

    <Location file="EVENT_ATTACK_OUT" offset="16C24">
      080009
    </Location>

So basically, for the locations you need to edit, you change 0x3A to whatever your base job is (and only edit one value).

Overall, there's 1 byte array in WORLD.BIN, 3 halfword arrays in WORLD.BIN, and a halfword array in ATTACK.OUT. That first change in the patch is actually a code change to tell FFT not to assume that our jobs have to be < 0x35. (Changed it to 0x3C, to allow using jobs 3A and 3B; otherwise the job wheel is messed up... anyway, that part doesn't need done again).

Yep, take 34 and 17, not the other two.

As for using 34 and 17... if you do it before Chapter 2, you'll need to edit the events where those units are dismissed from your party, like I mentioned in my last post. It just occurred to me that you might have to edit the other events those characters are in too, so you don't have multiple units with the same Unit ID the game is looking for. I'm actually not sure if that would be a problem or not, though. At worst you'd have to change the guests' ENTD Unit IDs and then change the events to use the new IDs. That's annoying, but so is waiting until after Chapter 2 to add characters, so who knows.

In order to get 3A and 17 to join your party, you just need to place them in an ENTD somewhere with Join After Event checked. Basically I'd recommend Raven's recommendation in your other topic, unless you feel like creating a new event, I suppose (The ENTD entry he's referring to is 188). That's if you add before Chapter 2; otherwise, you'd find another ENTD in the right place and add 'em in, I guess. For it to make sense you might want to add dialogue and the like... also, I think the Join After Event only works if the event does something specific at the end, which is why it's often easiest to use an ENTD where characters are already joining... but event editing could probably get around that.

Oh yeah, that's a good point; forgot about the fact that some of those units get auto-removed from party - but those are controlled by events, and we can just edit the events to change the DismissUnit command. So, essentially:

Zirekile:  DismissUnit(0x17) -> DismissUnit(0x11)
Lionel:    DismissUnit(0x34) -> DismissUnit(0x1E)

Raven's tool can probably do that just fine, but anyhow, it's event command {7A}.

Replacing 0A/0B in UNIT/WLDFACE is probably fine. The problem is finding unused jobs. 3A and 3B are nice and convenient because they're completely unused, but there's really nothing else that I can see that isn't used in some way or another, perusing the job list in FFTPatcher. There are a few blanks at the verrry end of the list, but those are probably assumed to be monster jobs, so it's hairy.

If it were me, I'd probably identify characters that have two jobs and think about replacing one of them. For example, Gafgarion has both 11 Dark Knight (enemy) and 17 Dark Knight (guest). You may be able to take, for example, 17, and always make Gafgarion 11. It requires editing the ENTD for every place that character shows up under the job you're taking, but afaik there are no unused slots left, so what can you do...

There are a bunch of characters that are this way; Agrias has 34 (guest) and 1E (join); Mustadio has 22 (guest) and 16 (join); etc. If you were going to replace one, you'd always want to switch them in the ENTD everywhere to the join/enemy version and then you'd be able to take the guest version and do whatever you want with it. Don't do it the other way around or I think there would be some issues with events not being able to find the correct units, because the Unit IDs that get loaded in from characters you field are their base job IDs.

Based on which jobs you decide to take and edit, you'd have to edit different entries in those tables in attack.out/world.bin to point to the proper places in unit.bin/wldface.bin.

Yeah, looks like you're figuring it out, but what's going on there is that the numbers in TacText are in decimal while the ones in Patcher are in hex. So for the case of, for example, jobs 3A and 3B, they're 58 and 59 in TacText, respectively, because 0x3A = 58 and 0x3B = 59.

Same with 23 Magic; 0x23 = 35. And yeah, it's Teta's skillset; good call on giving her a different one... I forgot that step.

20 Dark Sword -> 0x20 = 32; 27 Dark Sword; 0x27 = 39; etc, etc.

Anyhow, in case I wasn't clear before, before you edit any of that stuff in TacText, go to the Text menu and select QuickEdit; that'll change every relevant file the text is in. Without it, you'd have to edit every file in that list that contained that same text.

Glad to hear I've been helpful FFTacText is another program in the FFTPatcher suite. It takes some getting used to, I suppose, but using 'QuickEdit' in there should make things a bit easier.

This is all FFTPatcher territory. In the Jobs tab, the very first thing you can edit is "Skillset"...



You can change that to anything you want. Check the Skillsets tab to see what's available (and edit which abilities are in which skillset!) You might be able to get away with using a blank skillset and editing it, but it may be better to edit an existing one; there are a few unused/unnecessary ones. If you are going to create new skillsets for jobs 3A and 3B, I recommend taking/editing 23 Magic, which is unused, and 20 Dark Sword, which is a replica of 27 Dark Sword (Gafgarion's skillset). If you do take 20 Dark Sword, you'll need to change Gafgarion's 17 Dark Knight class to use 27 Dark Sword instead (Jobs tab, again).

If you want, you can even edit the abilities themselves in the Abilities tab... there are a few blank slots above Potion (but the last of those blank slots is reserved, as it's for normal attacks).

If you want to change the names of abilities/skillsets/jobs/what have you, that is all done in FFTacText.

That appears to be an old version of the FFTPatcher suite. The new one should be up on the site if you don't have it already here. The patcher, FFTorgASM, should come as part of the suite.

If you do use the patch, it should make all those edits I mentioned earlier, so no need to look at that thread unless you feel like it. You should be able to just copy/paste the XML into one of the XML files that comes with FFTorgASM and use it to apply the patch, then do the rest of it (replacing 08/09 unit/wldface stuff, using SSE, etc).

...Actually, what the heck. I just typed up a patch to make jobs 3A and 3B use the unused 08 and 09 entries in unit and wldface.bin, respectively. That way you should be able to just edit 08 for UNIT.BIN and WLDFACE.BIN with FFTEVGRP, replace the 39 Celia (Never Used) sprite in SSE with your character's spritesheet, and just have your character use job 3A.

Here 'tis. If you do decide to use it, let me know if it screws anything up. Backup ISO if you do use it, yadda yadda.

Not sure if any such lists are available.

The alternative to doing that would be to just take an unused job and then edit the tables in WORLD.BIN/ATTACK.OUT mentioned in the first post of this thread (click 'show') to have that unused job point to unused unit/wldface entries, and overwrite those unit/wldface entries with FFTEVGRP. Those tables are in order of base job/sprite set. That way you wouldn't have to make any ENTD edits.

If you do end up doing that and use job 3A or 3B, there'd be one other WORLD.BIN edit to fix the job wheel, which I could dig up.

fdc, it's worth a shot, but... they changed some things in the PSP version, so the source code is different, it's a different target processor, it's probably a different compiler, etc. The "same" routines aren't going to have the same ASM... I'd bet on it.

There are a lot of program files in FFT. Why is anyone's guess, but for a long time I've thought it would be really useful to be able to scan various files for program code (ASM). The problem is, the MIPS disassemblers you find online assume big endian byte ordering.

Enter LEDecoder, my newest program, that will decode files with a little endian option. You just select the input/output files and have it do its thing. This'll let us find the ASM in any FFT file. The output is very similar to what you'd see in the disassembly portion of the pSX debugger.

LEDecoder basically means 'little endian decoder', but of course, I couldn't call it LEDecoder without including an LED. A software LED, perhaps. ...Well, okay, maybe it's just a filled in circle. But anyway, it indicates the status of the program by its color. Most of the time it'll go orange and then green quite quickly when it's told to process. It's fine to run another decode as long as the LED isn't orange.

    Blue = Ready (Program start)
    Red = Decode failed (Usually if the input file/path is invalid)
    Green = Decode succeeded!
    Orange = Processing

So, what would be an interesting target file to run the decoder on? Say... perhaps an effect (animation) file?
...Yup, they've got ASM in them. Might explain why some work one way and others work another regardless of the graphics/palette/what have you!

EDIT: Version 2 added to fix some problems with the decoder... It didn't recognize srav, jalr, or break. This uses the MassHexASM decoder, so anytime I update that, I have to update this, basically. New version is attached.

EDIT: Version 3 added:
     * Fixed a problem where the program counter was incorrect, resulting in incorrect hex for branch instructions (thanks fdc)
     * Used a save file dialog for the output file, so now you should be able to just type in output filenames.

EDIT: Version 4 added:
     * When decoding, immediates will now properly show as signed or unsigned based on the instruction. These are the affected commands:
          Unsigned: andi, ori, xori, sltiu
          Signed: addi, addiu, slti

EDIT: Version 5 added: Check the MassHexASM thread's original post for details.  This now uses the same engine as MassHexASM.  (A shared DLL, not just copied functions between binaries!)

EDIT 1/11/2017: LEDecoder has now been rolled into MassHexASM.  The newest version is available in that thread.