Final Fantasy Hacktics

I've started work concurrently with Nax on a few other upcoming chantage capabilities including:

1: The ability to add extra bytes to unit BattleData structs and use them in new Formulas/Battle (masks  for new status ailments... or a stored unit ID for a working taunt mod =p)
2: The ability to add extra bytes to AbilityData and use them in Formulas/Battle (masks for new status ailments)
3: The ability to add new abilities to the game without deleting old ones.

Current approach is something similar to the games approach to dealing with items; existing abilities are still located in their current tables, new abilities are located elsewhere and extra fields for all abilities are located in yet a third place, which a helper function which handles fetching the correct pointers to each struct when it is given an offset. Quite a few routines will have to be re-written and replaced to get this working as currently ability data  and the like is generally accessed via offset to the relevant pointer table. This is three pointers  which is kind of annoying but it easier for PoC  without breaking the whole game. Eventually this will probably end up being a new relocated table with all direct access to it replaced with  the getter function, but that is gonna be harder.

I was wondering if anyone involved with FFTPatcher might have a big list of where all of the data assets patcher patches are located in WotL; currently we're finding all of those as we go but the patcher obviously already has this information. I attempted to source dive it but I'm unfamiliar with C# (more importantly, the code is complex and opaque to someone just trying to dive in) so was unable to locate the offsets. If anyone has them, it would greatly speed up our work =)

Obviously a bit of hyperbole there, but there are some considerable advantages of this approach(allocating new memory at run-time/loading functions there and relocating the games original routines) over any tool that patches the actual ISO

By allocating new memory for mods at run-time and re-pointing WotL's original routines, essentially any function in the game can be replaced without having to try and manually "fit" the ASM into the same space or jump around between subs to use the padding space.

It also means new weapons, enemies, items, or formulas etc can be added to the game without destroying old ones and without having to patch the ISO at all (other than the original patch needed to load chantage) as the in memory structs containing their associated data can be re-located at run-time and extended.

Moreover with a map of the original games routines (currently a WIP, but all of the formula routines and most of the one dealing with items I've disassembled, and Nax ahs hit a lot of the graphical/AI code) a high-level programming API can be built around this procedure; methods for doing things like adding an item or an enemy can be re-usable function calls depending on core chantage utils that accept their parameters, relocate the relevant struct inside memory and add the resulting items/formulas/enemies to the struct.

Magnificent work my dear friend! RIP PSX 

We've also done a fair bit of work reverse engineering the WotL ISO and will be documenting that, and soon we'll be creating C++ functions for overwriting specific sub-routines at run-time without needing to worry about memory constraints (well, within reason).

The age of WotL is beginning 

WeaponXA() location in EBOOT.Bin are as follows:

Formula Pointers are at 0x08A7500C

0x88A54C0 - main routine, branches to all specific weapon type ID's, and includes the formula for fell swords at 0x88A5748

Specific XA calc locations:

PA -> 0x88A559C
PA * Br/100 -> 0x88A5610
SP+PA/2 - > 0x88A55DC
1....PA -> 0x88A56BC
PA*(100-FA)/100 -> 0x88A5748
PA + MA -> 0x88A5714

ElementalModifiers() is located at 0x88A6040
This handles oil, float, and elemental weak/half/null/absorb flag setting

SetStatusChanges() is located at 0x 88A4540
This reads from the status data and handles cancelling statuses, stackable/unstackable statuses, the immortal ENTD flag, and not inflicting statuses that a unit is immune to or already has.

A large damage modifiers function (which I am not totally done decoding yet) begins at 0x88AA180; it handles elemental strengthening, arcane defense, aracane strength, applies damage boosts due to toad and chicken, handles defend, and some more things.  It calls both the elemental/status setting routines. I will update with more info once I have finished parsing it.

EDIT: The above function is the main magic damage formula; I have found/documented many of the formulas real locations in EBOOT.bin. I'll start porting hacks/writing some documentation for all of this in the coming weeks

Amazing work man

This makes one real advantage for the PSP version, since we now have the extra item slots to work with.

I'm eagerly awaiting your next release.

Is that so? I'm interested in a more detailed description of how the emulation layer might complicate modding. I haven't gotten that far into it (because I'm having to learn MIPS r3000) but I did manage to track a few formulas and make some simple changes in BATTLE.BIN (modifying 5E to use PA) as a POC, which seem to be working.

I'll try to get shirahadori only working on melee weapon types once I've improved my comfort with this instruction set & explored some more, but I've seen no evidence of this emulation in memory dumps (I don't know what to look for though, admittedly)

Feel free to throw the most technical explanation you feel like writing at me; I don't shy aware from it.

EDIT: Actually, this doesn't work -- I tried modifying 5E to use PE evasion routine instead of the MA one it normally uses, and there was no effect. There's also appears to be no effect in simply replacing the address after the jal opcode with all 0's, which leads me to think that somehow the formulas in BATTLE.BIN aren't even used on the PSP version (is this possible?)

EDIT2: So this approach was awful, but I've sense then being reverse engineering the WOTL battle mechanics; I have found most of the formulas (they're in EBOOT.bin) and have verified that changes to them work. Nax and I are working together disassembling the game/labelling the data structures/subroutines and I intend to start porting hacks in the next few weeks.

This is great!

I wonder how difficult it would be to perform a similar hack for move-find-item rewards?

It might be possible to modify the 3rd and 4th bytes of each maps 16 byte move-find-item field to instead be one 2-byte value representing the 2-byte item type; I'm not sure where the routine that reads those bytes from battle.bin lives, though. If any of the four bytes which hold a maps move-find-item ids are followed by unused bytes, it might be possible to do something like this there as well.

This is pretty exciting.

Ah, that makes sense. Looking at the current set of patches in FFTorgASM there seem to be quite a few which *appear* relatively simple to port (smaller formula changes, PA multi-hit formula, rewrite of the axe formula, fix shirahadori), provided no unforeseen interaction with the new code.

I shall get to it and see what happens.

Hello everyone,

In defiance of what seems to be the general consensus in these parts, I strongly prefer the war of the lions version of the game (especially its translation) and am interested in attempting to port some ASM hacks from the PSX version to WotL. I don't know MIPS R3000, but I do know x86 and I think I can figure it out. Rather than individually port the hacks, I'd like to first see if it's possible to write a program capable of adjusting PSX ASMs to work for the WotL ISO.

I found a few threads around here from a long time ago which seemed to suggest that WotL actually contains the original Japanese PSX code (structurally untouched) within it though things have been moved around, so offsets & addresses for a given piece code might be different between the two versions.

If these are the only differences, it seems to me it should be possible to match bytestrings on only opcodes (by zeroing out all the address values in both games) in order to search for sections of code which have the same "structure".  Provided one can identify the opcodes/addresses present in a code block (Using a dissassembler) it should be possible to map the address values used to certain in game variables between their PSX and PSP versions.

Given that no one has done this, I feel like it's probably not as easy as I'm imagining it (and I'll find out soon enough when I attempt to do so with some simple ASM hacks), but has anyone attempted anything like this before, or does anyone have any knowledge about the structure of the PSP ISO that would preclude such a solution in principle, or expedite the process of creating one?

Thank you,
QP