FF3usME dialogue editor broken?

I'm afraid I'm gonna need your help again guys, today I encountered a serious problem with the FF3usME dialogue editor. I've used the editor's "Manage Expanded Roms" function to move the dialogue to the F0 bank, which gave me about 73000 free bytes to work with. I've been editing and extending lots of dialogue for the last couple days, until I had about 59000 free bytes left when I last saved. But now, all of a sudden, it displayed my free space as -94000 bytes (negative number!) and told me I couldn't make anymore edits due to lack of space. I tried closing the editor and reopening it, but then the dialogue editor wouldn't open anymore, bringing an error message that says "Dialogue routine pointers were hand hex edited. FF3usME cannot work with the reformatted data."

I swear, however, that I did NOT hex edit anything dialogue-related, I wouldn't even know where in the rom the dialogue pointers are! I also didn't apply any new patches lately, as I have been doing nothing but dialogue editing for several days now, so patches could not be the cause of this. Until just a few hour ago everything still worked smoothly. I honestly don't know how it happened, but whatever the problem is, it seemingly came out of nowhere.

Does anyone have any idea what might have happened, and if there's a way to save my rom?

I have seen this before, too, under similar circumstances. There is definitely a bug. In my experience the risk seems to be if you are working with expanded dialogue, save, continue editing, and save again.

Nowadays I do all my dialogue editing in the exported script file. Any time I import changes into FF3usME, I save and immediately exit. That seems to avoid the bug, though it may be overkill.

As for recovering your ROM, I am not sure. Have you been keeping backups?
If all the caption pointers really are corrupt, then you may be in for some manual recovery fun time. I will see if I can figure out anything about this bug, though. (Has anyone investigated this already?)

I've found some threads here that talk about such a bug when saving twice without closing the editor in between, but these threads were a couple years old and were talking about an older version of FF3usME, so I'm unsure if this is the cause. I'm using version 6.8.

As for Backups, my last one is 5 days old, but I've done quite a lot in between. I never thought that anything could happen when using FF3usME, so I was a bit lazy with constant backups. I guess that's my own fault. I will heed your advice and edit stuff only in the exported txt file from now on, hopefully this will prevent future troubles.

EDIT: Wait, I just double-checked: the editor's zip file says version 6.8.0, but the editor tool itself (when you hover the mouse over it) says version 6.7.1. Does that make a difference? Is this still the latest version, or was a wrong one accidentally packed into the archive?

EDIT: Wait, I just double-checked: the editor's zip file says version 6.8.0, but the editor tool itself (when you hover the mouse over it) says version 6.7.1. Does that make a difference? Is this still the latest version, or was a wrong one accidentally packed into the archive?

The wiki has the correct version (6.8.0): https://www.ff6hacking.com/wiki/lib/exe/...e6.8.0.zip

For RotDS, we switched to Atlas for script editing (which can be done in any text editor). It allows unlimited script space but you need to make the pointers 24-bits instead of 16-bits and convert your script into an Atlas compatible one. I have a tool to convert the script/pointers and I have a ASM file for the 24-bit pointers hack. If you can't find any workaround I could try setting this up for you.

For RotDS, we switched to Atlas for script editing (which can be done in any text editor). It allows unlimited script space but you need to make the pointers 24-bits instead of 16-bits and convert your script into an Atlas compatible one. I have a tool to convert the script/pointers and I have a ASM file for the 24-bit pointers hack. If you can't find any workaround I could try setting this up for you.

Thanks for the offer, maybe I'll take you up on it. I know nothing about Atlas or extending pointers, though, so first I'm gonna try it by doing my changes in the normal exported dialog_script.txt and then reimporting it. Under normal conditions, those 73000 free bytes that FF3usME's extention grants should be enough for me, as long as that corruption doesn't happen again. If importing a heavily modified script should fail as well, I would ask you for your tool and advice on how to use it.

I know it's an old thread but I think I know what is going on. It's not a bug in ff3usme, but just a result of lazy hardcoding in the game.

The dialogue in the game spans 2 banks (although a quick optimize took me from ~400 to ~9000 free bytes). To select from all those pointers, a 24 bit address would be needed.  But that's not what they did. Instead, they have a hard-coded check for the specific indexes that will wrap, and increment the bank.

Of course if you hack the game, and the text now wraps on a different message, or worse, you consume more banks than they did, it will not work unless you go to C0 $CCE600 and edit with your new bank-wrapping index. It's a hack, not really fixing it properly, but the upside is that you save a function rewrite, one pointer-byte per message, and it's actually an easy function to write.

Note that I told Lord J about this years ago, but it doesn't come up too often as most people use less text than vanilla due to optimization .

Edit: This would put any dialogue editor program in a rather tough place: Do I add a little hack to accommodate a situation where the text expands, at the cost of forcing the new hack code somewhere to be immovable (by default bank C0)?How many banks do I let this hack expand text into?  The program needs to know all that because asm doesn't care about the bounds. Yes the code limits the number of messages (is it 4096 or 8192, I think the latter? EDIT-8192), but the messages themselves are unlimited in length each, and the DTE is decent. Someone could put the whole KJV in there if they wanted and could map to ExHiROM. There is no way a programmer could anticipate it though.

Edit2: Here's the function in question. It's trivial to edit to allow a 3rd bank (or however many) but of course you'll have to put it somewhere.

Code:

Dialogue Loading function:
C0/7FBF:    A9CD        LDA #$CD       (Initial bank is CD)
C0/7FC1:    85CB        STA $CB        (This is kept in location $CB)
C0/7FC3:    C220        REP #$20       (16 bit accum./memory)
C0/7FC5:    A5D0        LDA $D0        (get memory D0)
C0/7FC7:    0A          ASL A          (times 2 since pointers are 2 bytes)
C0/7FC8:    AA          TAX            (this gives us the index X)
C0/7FC9:    BF02E6CC    LDA $CCE602,X  (Loads pointer to dialogue X)
C0/7FCD:    85C9        STA $C9        (The pointer goes in $C9)
C0/7FCF:    A5D0        LDA $D0        (Which dialogue is this?)
C0/7FD1:    CF00E6CC    CMP $CCE600    (Checks to see whether bank byte needs is right or needs to be CE)
C0/7FD5:    9005        BCC $7FDC      (Branch if less to the pointer above)
C0/7FD7:    7B          TDC            (bank byte needs to be incremented, and this is pointless...)
C0/7FD8:    E220        SEP #$20       (8 bit accum./memory)
C0/7FDA:    E6CB        INC $CB        (Since it wasn't less, we increment the bank byte)
C0/7FDC:    7B          TDC            (Either way it is correct now, so clear the accumulator)
C0/7FDD:    E220        SEP #$20       (8 bit accum./memory)
C0/7FDF:    A901        LDA #$01       (Put a 1 in the accumulator)
C0/7FE1:    8D6805      STA $0568      (Store 1 into $0568)
C0/7FE4:    60          RTS

Note CCE600/1 is the index to wrap bank on. If you have a 3rd bank, you'll need another such check, and you'll have to know which index in advance, or else rewrite this code better.

Yeah, I've run into the issue with the dialogue editor where if I add new lines and change existing lines in the same session, the new lines get bugged out.  Therefore I generally export the script to text, edit it there, and re-import it if I want to change lines, and only use the FF3usME editor to add lines.

I've run into a different issue with the FF3usME dialogue editor in that I want to expand the pointer table to give me more lines, however FF3usME has the start address of the pointer table hard-coded and will throw as "Not a recognized dialogue expansion" if you try to load a ROM with the pointer table relocated.

In the original code, the dialogue text was split between banks CD and CE.  The first two bytes of the dialogue pointer table at CCE600 gives the index value of the last line of dialogue in CD.  The index provided by the script is compared against this value and if it's less, the starting address to add the pointer offset to is CD, else it's CE.  This is because the address pointers are only 2-byte relative pointers rather than 3-byte absolute pointers, and thus roll back over to 0000 once you've exceeded 65535 bytes of text, and it needs to know whether to add that 0000 to CD0000 or CE0000 to find the correct dialogue.  FF3usME does seem to modify the value of the "wraparound" index if modifying the text causes it to change.

In FF3usME's expansion code, the dialogue text is contained in CD, CE, and F0.  The pointer lookup routine is changed in such that they have an alternate location (C0DF80) where the "last index" value is saved, paired with its bank offset, to allow for a second one.  Now it loops through a routine where it checks "Is the index of this dialogue less than the value at C0DF80? If so, set start bank to CD.  Else, increment by 3 and check C0DF83.  Is the index of the dialogue less than the value there?  If so, set bank to CE, else, increment by 3 and check C0DF86 (there's just FFFF here).  The index has to be less than that, so as a last resort sets F0."  Because they've now put it in a loop that checks a list of values, you could conceivably manually add however many more banks to that list that you have the space for.  However, when FF3usME loads and checks for expansions, it seems to be checking for the exact code that it changed the dialogue routine at C07FBF to, so if you update the addresses of any of its checks it won't function, even though the content of that address is fine for it to use.

The problem is that this only adds text space but not pointer space, and the pointer table at CCE602 only has room to add about 200 more pointers.  Relocating it and just changing the address of the pointer table in the dialogue routine opens up more space for more lines, but because the dialogue routine is now not exactly what FF3usME changed it to, it throws an error.

This gets aggravating because if you change a line of text somewhere in the middle, the start addresses of aaaaaaalllll the lines that come after it get modified, and I don't want to have to deal with that manually, so I need the tool to work.  XD

Ok, yeah, sorry, I misunderstood. That does sound like a bug. It could still stem from the root cause above, but I imagine it could just be an oversight when he added the expansion options. He should at least allow for the full retinue of 8192 pointers and automatically calculate which indexes wrap the banks.

I really would prefer the option of mapping my expanded data according to my own wishes rather than the editor dictating it. For instance, I'd absolutely move everything out of $CD and use it for events, as a very first step of making a hack. Maybe 3 or 4 banks for dialogue, one more bank probably just for new code, etc.