Building a patcher tool and want to integrate FFTactext with the patcher itself

[Sardek]

As the title says, I'm working on a patching tool similar to FFTPatcher. I want to rip the edited ability/job/item names from the ROM and use them inline instead of the vanilla names. This is especially important as the base ROM I'm working with is the FFT 1.3 Arena ROM, so a *ton* of things have been renamed/changed, often to entirely unrelated things. I've had very little trouble finding the data tables for everything I care about having in the patcher (your wiki is excellent for this. thanks for that), and have successfully done proof-of-concept edits for all of them using only my little Python script.

The problem arises when I try to get the text data out. As I understand it, it is stored in several places across the disk, and is compressed in some way (or so Tactext's About tells me). I have no idea where to start finding this information out, short of asking Xifanie for the locations (given Tactext says she was the one who gave them the locations in the first place). The page linked in Tactext's about references the person who taught the author about the text compression, but that site gives me a 403 FORBIDDEN error, so I've hit a dead end there, too. I tried to search for the forum post where Tactext was discussed and initially built, but given how commonly used a tool it is, filtering through to find that proved to be beyond my search skills.

I am entirely willing to learn whatever skills I need to to accomplish this goal. I have a pretty strong grasp of coding as a whole and at least rudimentary knowledge of asm. I appreciate any assistance any of y'all can give me.

[RetroTypes]

It sounds like you dont know about the resources.zip, which renames patcher text with custom text lol. No need to make a new program. Just open tactext, load data from an iso patched with your desired text edits, and then generate a new resources.zip. Alternatively, generate a resources.zip from vanilla, then open it and manually edit the xml's as needed. After that, the patcher will use the custom names for everything.

[Sardek]

That would be accurate; I did not know about that. I do think I still want to learn this information to help me get a better grasp on what's under the hood of the thing (and to continue shaking the rust off my Python skills) before I move forward on using FFT as a platform to learn and improve on asm hacking, but I'm less worried about it now that I know the functionality I want already exists, and I can use that as a stopgap until I've got my own thing coded up.

Thanks for the big timesaver, regardless.

[Sardek]

Well, I've gotten halfway there. During my studying of the memory card format, I reverse engineered how it stores text on the CD. Simple enough substitution of A-Za-z 0A-3D. I searched the CD for "0D 28 29 3C FA 19 24 2C 31" (Defy Pain) and found it. Dash(the next ability) was right after it with an FE separating. The next entry made me realize I didn't quite have it all figured out yet, though. "1D 2B 35 32 3A 59 37 58 28 FE" had 59 and 58, which are both larger than 3D. It translated out to "Throw<59>t<58>e", which makes sense, given the next skill in the skill order is Throw Stone. This would mean 59 is " S" and 58 is "on", which presumably is to compress the text of the game. This leads me to believe there is a larger font table with a bunch of double characters in it. I'd rather not brute force the table (I could just hex edit all of the characters into character names on memory cards and record what pops out, but I know *somebody* here has done this work already, and I'd like to save myself the time). I can't find this info on the wiki, either; can I get a link or an explanation of the expanded table from somebody?

Additionally, given the space of the data tables is going to be static, using fftactext to expand the names of things is going to make them take up extra space, which presumably means having to move things around into different areas of freespace and update pointers to the data tables. Am I on the right track here with what tactext is doing when it's editing this stuff? Am I going to be able to do similar things with the game text itself if I put in the work? Having a cleaner text translation that isn't the godsawful PSP translation has been at the top of my wishlist for over a decade. (By game text I mean dialogue boxes, not abilities and the like).

[nitwit]

Have you tried looking at the source code for FFTPatcher and LionEditor?

https://github.com/Glain/FFTPatcher

https://github.com/Glain/lioneditor

[Glain]

Here are some resources related to FFT text:

Character map: https://ffhacktics.com/wiki/Font
(Same map as found in FFTPatcher suite): https://github.com/Glain/FFTPatcher/blob/master/PatcherLib/TextUtilities/TextUtilities.cs
Text locations on disc: https://github.com/Glain/FFTPatcher/blob/master/FFTacText/PSXText.xml

The text engine can also contain "jumps" starting with the F0 byte that reference another part of the same text section. (https://gomtuu.org/fft/trans/compression/).

The double characters that you found in the text are part of Tactext's dual tile encoding (DTE) which it handles automatically when patching to compress text. Tactext has a maximum number of DTE characters that it can use and will compress text via jumps and DTE to fit within the same section sizes as before. The game looks up text via (section ID, entry ID) (same as shown in Tactext) and figures out entry numbers by counting sentinel values (FE or FF).

As far as patching game dialogue goes, we already have tools for that as well.  You should be able to use either the Event Compiler/Decompiler or EntryEdit within the FFTP suite.

[Sardek]

Hey, thanks for all those links, Glain. They really help me understand what's going on underneath the tools. Also thanks to nitwit for the github repos. I'm using this as a learning project, so actually understanding the tools and how they function is more important to me than just having a tool to solve the problem I'm facing. This is a significant leap forward compared to having to figure this all out on my own. Basically, I'm trying to create enough competence that I can go in and start working on things without extensive wikis and start documenting them myself. I know that's a several-years-out kinda goal, but a journey of a thousand miles starts with a single step, right?

This is why I'm trying to write my own tools instead of using the ones already available; nothing proves understanding better than writing up a tool that works. That said, the practicality of doing so when I'm running AI tournaments right now means that I have to lean on existing things at the start as I slowly replace them with my own understanding.

As of this post, I now have enough to build my own memgen for the tournaments (which is good because the existing 1.3 spreadsheet had errors, a locked set of assumptions (costs of things and what jobs had them, statlines, etc), and was also incompatible with any non-excel spreadsheet offering [including openoffice, libreoffice, and google sheets]). I suspect the next thing I'm going to be poking my head in about is asm-related, but that should be far enough in the future for this to be buried, so I'm gonna mark it as solved. Thanks again for the help, guys.

EDIT: Uhh, I can't find that brown bar in Xif's pinned post that will let me mark the topic as solved. Where is it?

[nitwit]

Learning to read other people's code and translate it to another language is an essential skill for coders. Consider it a separate branch in the skill tree instead of a step down from reverse engineering. Learn both.