Final Fantasy Hacktics

Well... okay, I haven't done too much with this yet. I am starting to get a feel for the code here and there. I'm sorta interested in the current state of the stuff I have, though. (i.e. how it works, if things really fail). There's some weird discrepancies between what I've found and what FDC was saying, so I find that a bit odd. (I didn't have any compile-time errors to fix, FFTPatcher loads fine for me, etc). I don't have all the greatest test cases or what have you, so I figured I'd upload my compile in case anyone wants to test it and see what's working and what isn't.

Hopefully I've included everything needed. I took the Debug/ directories of each application's subdirectory; let me know if there are any more files needed to get these EXEs to run.

EDIT - The latest version is attached further down in the thread. Removing from this post.

That 'Learn with JP' flag only applies to the player; The AI just strolls right up and learns things with JP without even caring. The arrogance!

Totally agree about lowering the JP costs. Oddly, that's exactly what I did... lowered them by 2/3 of the original values.

You can set Chance to Learn to 0% for abilities you don't want the AI to learn. There are a bunch that don't give any benefit. These were the ones I had noticed:

Move-Find Item
Move-Get Jp
Move-Get Exp
Equip Change
Secret Hunt
Gained JP Up
Gained Exp Up
Gilgame Heart

There's probably quite a few more. Things like stealing gil, etc.

PGF, that will work for the unit's current class, however it won't get them tons of JP for other classes, so secondary/reaction/etc wouldn't have nearly as many options. If you want to be really hardcore, you almost want to KEEP the mime restriction to level 8 (and maybe make it require ALL classes at level 8), which makes it realllly hard to get, but also makes the AI have 9999 JP in all the prereqs.

Actually I recommend 9998 JP on the off chance that the AI learns a 9999 JP skill they're not supposed to have (Zodiac). May not be possible based on Chance to Learn, but not sure.

I have a patch that does this. Rather amusing. Bah, I should just ASM hack some way to do this without making a class absurdly hard to get.

As far as I know...

That's the job level for the unlocked job. The unit will have enough JP in the job to have it at that level. If I set job level 5 to require 1500 JP, and set the unit to have the job unlocked at level 5, then the unit will have >=1500 JP (probably not much more) in that job. The AI will then spend the JP to randomly learn abilities in the job (I think based on the Chance to Learn % for each ability). So yes, in a sense it affects how many abilities are learned.

The other big part of this is that which job is unlocked also affects what JP the unit has in other jobs; If the 'job unlocked' is Mime, then the unit will also have to have all the requirements; I could use that to force the AI to have level 8 Squire and level 8 Chemist, for example. If you made Mime require job level 8 in everything and made job level 8 require a huge amount of JP, and made the unit have Mime unlocked, you could get the unit to potentially have access to every single ability available to the generic classes (though they'll only equip one secondary, one reaction, etc, of course).

Very nice.

I sorta handwaved VB.NET and BASIC all together in one category. Hard to really give an algorithm without knowing the code you're dealing with, though.

But yes, I enjoy that change quite a bit. Good stuff!

Your example patch name is quite catchy! I believe we may share that trait. I find it comes with the territory of programming, though... you have to pay attention to detail.

The spacing between patches looks good. Come to think of it, I'd probably also do the <Description> tags as separate lines. Looks better if you've got a long description... Not sure about formatting the hex itself. Seems like the user's job (or they could paste from my encoder ), but as a matter of convenience, it might not be a bad idea.

Why use an infinite entry (dynamic expansion?) array, if you could do something along the lines of... (syntax may be a bit off here, as I'm a bit rusty with basic)

FOR i = 1 to txtHex.Text.Length
 ' (Maybe skip spaces or something; worry about formatting, whatever)
 Write txtHex.Text.Chars(i) to file (or string, or what have you)
 If (i Mod 8 = 0)
   Write newline to file (or string, or what have you)
NEXT i

The standard, as far as I've been able to tell, for those XML files, is to indent two spaces for each inner level. So:

<Patches>
  <Patch>
    <Description>Text</Description>
    <Location>
      Hex
    </Location>
  </Patch>
</Patches>

That'd be useful, to keep the correct formatting. Otherwise, I'd prefer doing it by hand. A big file of patches without any space indenting? D:

Hm. I actually suspect I've downloaded an old version; Patcher is showing v0.388. That would explain the missing forms, etc. I guess I need to find a new version. Not sure why I would have gotten an old version that way.

The problem is... I don't know where fdc got his files, and his zip seems to be missing some key components, or else I'm doing something terribly wrong. The build process is trying to find files that don't exist; I can't even get to the point where I could even try to build the code with those files.

If we could find a version to get started on, having some testing would, of course, be nice. That sort of thing never hurts. I'm basically just trying to get my bearings on this at this point though.

I suppose I'm going to try pasting the missing stuff from fdc's zip from the downloaded code into fdc's files and see where that gets me. Those files didn't seem like the type to really change ever (or were just text files), so hopefully they'll be the same, regardless of the Patcher version.

EDIT: I did get it to compile! I had to mess with a batch file, which hopefully didn't mess anything up! Patcher loads up okay, but calls itself v0.457. The current patcher is v0.478. Augh, is this another old version?

EDIT 2: Okay, melonhead's newest changes are in branches/imageEditorv2/ and not trunk/ which, I believe, is why I got the old version. I'll have to see what I can do with this.

EDIT 3: This seems to compile fine. Patcher=v0.457

So, I did a Subversion checkout of the FFTPatcher, etc code at the Google Code page for it. To clarify, Subversion is source control (like SourceSafe or TFS or what have you). It lets you check in files, check out files, all that sort of jazz, but we don't really need it for anything other than just doing an initial download of what's there.

I grabbed the top download here (requires registration, which is annoying): http://www.open.collab.net/downloads/subversion/
Then was able to open a command prompt and use the command shown on the "Checkout" part of the Google Code page, namely:
svn checkout http://lioneditor.googlecode.com/svn/trunk/ lioneditor-read-only (It'll create its own subdirectory for the code in the directory you ran the prompt in)

What's interesting about this is that there were only three compile-time errors, all relating to a certain parameter (Something to do with PSP info) not being passed in to various methods. I added those in and am getting running versions of everything (Patcher, ASM, TacText, SSE). Navigate to (Project)/(x86, if necessary)/bin/Debug to find the appropriate executables. Patcher's missing two tabs (Propositions and Animations); not sure why. SSE also appears to have been reworked to have its own change files (like .fftpatch?) that you just apply to ISOs?

I'll check it out, though the problem is that the current descriptions of problems (patching incorrectly, etc) are really vague and may be hard to track down.

That will change the color of the ability animation, but I don't believe it would change the coloring of the actual sprite.

Oh my, what's this doing in here?


In the patch I tested this with, enemies have tons of stuff unlocked, which is why there are so many abilities to inherit. On a sidenote, it seemed to generate the crystal correctly, even though it was an event. Usually Gaf probably just doesn't have any jobs unlocked but Dark Knight which you're not allowed to inherit from.

...Or at least, not without this patch! It removes a check found in the code that generates crystals in BATTLE.BIN that wouldn't allow inheriting of abilities from a base job unless the crystal unit and the inheriting unit had the same base job.

In order to inherit an ability like Night Sword, however, you will have to:
1. Put the ability in your own base class (In this case, I gave it to Ramza's Guts skillsets)
2. Ensure that the unit that you're inhereting the ability from has that ability at the same slot in the skillset.

For this test, I modified Ramza's squire and Gaf's Dark Sword skillset to have Night Sword in the tenth slot. There's nothing wrong with having a bunch of empty slots in a skillset, so I imagine this sort of thing shouldn't be too cumbersome. It also gives you a measure of control over whether you want abilities to be inherited through crystal or not (if not, put them in a different slot from whoever would be inheriting the crystal).

I wrote a routine in kanji space to determine if the skillset slots of the two different base jobs actually contain the same ability. FFT's normal code doesn't ever check this... if you're the same job, you must have the same skillset; therefore, it only looks at the slots, not the actual ability IDs. That wasn't going to work if you were inheriting between different base jobs.

Those generics don't seem to have Save Formation checked though (ENTD 188?) so how would it be the same set of flags? Delita does, but we already know he's a guest.

Is there anything wrong with the huge piles of random everything? There's not going to be anything in the formation for them to load anyway, so the information of what they used to have just isn't there. Seems for the most part they're being set to Party Level - Random with their base job and random equipment; reasonable enough in my opinion, and you can always change what you want manually. I guess you could get them to spawn with really good stuff if you levelled high enough (unless you used my gear level hack or something), but could you get that stuff off of them?

I was actually doing a mini-patch where Ramza would get skills that were Learn on Hit. Not quite the same thing, but kinda similar... if 'Learn by JP' is off then it shouldn't be visible in Ramza's list until he learns it; however, he seems to auto-get ability 6 (should be Wish; if you don't replace it, then not a problem). I believe AI learns skills with JP regardless of that 'Learn by JP' flag (thus Zodiac is 9999 JP so enemy summoners wouldn't have it).

Are you sure you don't need to have the job unlocked to learn skills by crystal, though?

I would think the WLDCORE edit would be a part of the patch, sure. As for ENTDs, I forgot about the load from ISO feature in Patcher, so it could work, but that process just seems... eh. It sounds like you're going with doing just the WLDCORE edit and not the ENTD edits anyway. I still think a companion (separate patch) SCUS edit to ignore the guest saving/loading ENTD flags would be a decent addition, but depends on how annoying that would be to write.

If you do make the ENTD companion hack, isn't it going to just keep getting overwritten by FFTPatcher when someone makes an update to their patch, though? You'd have to keep applying it. That's one of the reasons why I was thinking about changing the ENTD processing instead.

Pokeytax: Probably it would have to be removing [Join after Event] and [Save Formation] for any joining guests (so they don't join), and removal of [Load Formation] from everybody (It should only be on guests; if the unit is not in the party as a guest and it tries to load formation, I believe it wigs out rather hard).

Dome: Yes, we would have to include an edit to wldcore.bin (I believe that is the file Pride specified) as well to modify that check.

I think ENTD data is in the BATTLE directory in ENTD1.ENT through ENTD4.ENT. At the very least there's something related to ENTDs in there!

Okay, I may have misread what you said in a previous post... I thought you were saying that the Unit ID was saved as out-of-battle data with each unit, and that it was imported with the unit into the battle. If they're just generated as temp IDs then I agree that it doesn't matter that there are only 16 of them.

Quite interesting indeed, that's good info.

...Actually, that 0x70-0x7F range could be one thing we'd have to change to expand roster size... there's only 16 possible values in that range. Ramza does have his 01/02/03 though instead of one of those...
Anyway, when I was looking around at in-battle unit memory last night, my findings seemed to be that:

Offset 0x15F = Special Unit ID, if applicable, for allies (e.g. 1E for Agrias); otherwise, it was something else... sometimes 0x6X? (? I may need to look at this a bit more)
Offset 0x161 = Unit ID (Non-Ramza allies: 0x70-0x7F; Ramza: (his base job, 01/02/03); Others: ENTD Unit ID)

Very interesting! That's useful to know. I guess I can see why Square did it that way, though personally I think they should have kept the IDs unique.

It's interesting. It's like... for events you'd have to use the Unit IDs, because you wouldn't want to be confused about which unit to use if they had the same base job. But on the other hand, the Unit ID gets the base job anyway, because you wouldn't know what the Unit ID is for special characters otherwise, as they could be fielded in any order...

Regardless! I seem to have created a rather impressive tangent...