Final Fantasy Hacktics

Quote from: Arimala on August 28, 2024, 10:40:07 amNot sure if this is a known bug or not, I couldn't find anything on it. When I edit the UnitNames file in the Resources Zip folder it breaks FFTPatcher so that I cannot even open it. If I revert the changes its fine.
I only change 2 entries: 113 and 114 (also tried 128 and 129 when those didn't work). These are the changes.. they worked just fine in older versions of FFTPatcher

Code Select Expand

  <n id="113"/>Drycha</n>
  <n id="114"/>Sentinel</n>Not a big deal, only 2 names I use like once or twice. All the other Resources I edited worked though.

This is invalid XML formatting.  It should look like this:
  <n id="113">Drycha</n>
  <n id="114">Sentinel</n>


Quote from: pontifficator on September 18, 2024, 04:41:48 pmThis is probably a dumb question, but I'm curious if anyone has any info on the various forks of FFT Patcher on Github? One thing I noticed is at least one of them (gtlittlewing) is only one commit behind the main one and the notes mention an ASM persistence feature for the ISO's which sounds useful. It also has a few more ASM spreadsheets vs the main one (Glain).

I tried downloading the fork I mentioned to test it out, however I have no idea how you actually build it to try out the persistence feature. The latest package is a few years ago and the persistence is only a few months old.

There is nothing original in that fork.  The feature you're talking about seems to be persistent labels in ASM patches (@ prefix), which have been around a while.

Quote from: darkskyx on June 21, 2023, 09:58:30 pmMistake that I found:

When rebuilding a fftpack.bin, FFTPatcher .497 creates a wrong 71k KB file.
When rebuilding a fftpack.bin, FFTPatcher .494 creates a right 215k KB file.

(I didn't test other releases post .494) Tested for the PSP version of FFT.

The discrepancy here is the naming of the file OPEN\OPNBK.BIN within the fftpack directory.  If you change it to OPNBK.BIN (instead of OPENBK.BIN), then it should be able to rebuild the fftpack correctly.

I've pushed a change to the source control to give a more descriptive error message for this case.

FFTPatcher suite 0.497 released!

Release page here with patch notes! (Direct download)
(Patch notes are from 0.494 forward)

I believe the attack.out editor can output an XML that can be applied with FFTorgASM.  That might be easier than importing the file because that way you won't overwrite Tactext's edits.

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.

Oh.  Some text sections are in multiple places on the disc, and are listed in multiple sections within the .ffttext.  Job names should actually be in there in 6 different spots.  If you want to change them, they need to be changed in each section.

FFTPatcher 0.494 released!

Release page here with patch notes! (Direct download)

Edit - There was an issue where the Settings.xml wasn't being loaded.  Redownload 494 at the link above for the fix.
Edit - There was another issue where ASM patches that include other patches weren't copying variables correctly, causing a crash in FFTorgASM when selecting the patch.  Once again, redownload 494 at the link above for the fix.

The important difference with that code is that a variable is being set on the action as opposed to the unit.  Setting HP Damage on the action will cause the preview to show the damage, and the damage will take effect if and when the action is executed (and hits).

If that code was loading the unit HP, subtracting the damage from it, and saving the HP back, then the unit HP would decrease every time the preview was shown.

In your code from earlier, you're directly changing the unit's elemental weakness stats, as opposed to setting a variable on the action that would take effect later. (You might also have an issue with the newfound weakness disappearing in the event that the unit's elemental weakness values are recalculated, say, when a piece of equipment on the unit is stolen/broken/equip changed out)

I'm referring to the current action data set by the formula code (not the ability data).  See the way r16 is manipulated in this routine, and then passed to the earned experience routine.

Well, the issue is that you're directly affecting stats in the formula code, and the formula code is run during the attack preview.  You'll want to check for the preview by doing something like this:

lui r8, 0x8019
lbu r8, -0x0a04(r8)
li  r9, 2
beq r8, r9, skip

Also, I just want to point out a trick that can help out here... since you're taking the remainder of a division by a power of 2, you can just take the binary digits after that number and zero out the rest with a simple binary AND.
(Much like how doing modulus 100 on a base 10 number is the same as just taking the last two digits)

andi r6, r3, 0x07    # modulus division by 8

Edit:  As for not gaining EXP or JP, the action probably isn't flagged as doing anything (HP/MP damage, healing, or status infliction) and so the game doesn't see the action as anything that had an effect.

There is a logic error here:

[0x0018908c]   jal 0x001885b8           #   Magic evade
[0x00189090]   lui r10,0x8019         

r10 is being set to the value 0x80190000... but then will be overwritten when the routine at 0x1885b8 is run.  You can't assume the value of r10 won't be changed by the routine.  (In this case, the call to rand() should actually change it to 0xa0, with the trace: https://ffhacktics.com/wiki/Rand -> https://ffhacktics.com/wiki/Pass/Fail_Roll -> https://ffhacktics.com/wiki/Attack_Evaded_Calculations -> https://ffhacktics.com/wiki/Calculate_Final_Hit_%25 -> https://ffhacktics.com/wiki/Calculate_Hit_%25 -> https://ffhacktics.com/wiki/Magical_Evade_Calculation)

[0x00189094]   bne r2,r0,0x00189100     #   Jump to end if evaded
[0x00189098]   lbu r11,0x38f4(r10)         
[0x0018909c]   jal 0x001889cc           #   magic accuracy check
[0x001890a0]   andi r11,r11,0x0020      #   Check for unknown flag
[0x001890a4]   bne r2,r0,0x00189100     #   Jump to end if accuracy fails
[0x001890a8]   nop         
[0x001890ac]   bne r11,r0,0x001890cc    #   Jump ahead to MP section if unknown flag checked

Same problem with r11.  You're assuming the value won't change, but it very well might.  Either use saved registers, with appropriate loading and storing on the stack, or use unsaved registers in a way that they load and use their values without a routine call being inbetween them.

FFTP is probably trying to load the patch normally, failing, and falling back to trying to load it as XML, which also doesn't work.  It certainly shouldn't have anything to do with any of the XMLs in the XmlPatches directory.  You would probably need to provide your patch file for us to get a handle on what's wrong with the initial attempt to load it.

Version 0.493 (previously Beta v7):

General:

    *   File operations that open the disc image now open the file only for reading where appropriate.

Shishi:

    *   Now shows entries for the entire sprite table, including for sprite IDs 0x00, 0x9B, 0x9C, 0x9D, and 0x9E.  These are blank and unusable with a size of 0 unless ISO is expanded.
    *   The internal sprite entries have been adjusted to be numbered accurately, so that 01 Ramza is actually the second entry, with the new 00 entry being first.  If using custom sprite names in a Resources.zip file, the corresponding SpriteFiles.xml entries will need to be updated accordingly.
    *   Sprite entry IDs are now displayed accurately instead of being increased by one. 
    *   The default entry has been changed from 00 (displaying as "01 - Ramza") to the real 01 Ramza entry (second in the list).
    *   Can now handle showing blank entries, with the Sprite menu actions disabled.
    *   Any sprite can now have an SP2 entry if the appropriate association is made in the correct table in the disc image. (PSX: BATTLE.BIN 0x2E1CC, RAM 0x800951CC)
    *   There is now a FOUR option for SEQ and SHP values because that is the default for sprite entries 0x9B, 0x9C, 0x9D, and 0x9E.  It's treated the same as TYPE1.
   
    *   Fixed an issue where transparency values could be set to the wrong values when importing bitmaps.
    *   Fixed an issue where an imported bitmap could be saved incorrectly to the disc image if the bitmap's width was not a multiple of 8 (this seemed to only affect OPNTEX12 in Other Images with its size of 258x180).
    *   Adjusted compression data for some sprites to import into the disc image accurately.
    *   Fixed an issue where monster sprites could import into the disc image incorrectly if a 4bpp image was used.
    *   Now pads monster sprites appropriately with zero data if they are too short.  This allows sprite 0x5D (BATTLE_DAMI_SPR) to be imported without error (yay for technicolor goop)!
   
    *   Expand ISO has been reworked.  No longer increases the size of the disc image, but instead expands the sprite data and moves it into empty sectors.  (This seems to fix the sector read errors that would appear in the pSX emulator in certain circumstances.)

FFTPatcher:

    *   Can now patch PSP version slowdown fix.
    *   Corrected PSX RAM offset for Store Inventory data (for Gameshark section).
    *   Updated some formula labels.
    *   Updated some default labels for sprite files.
   
FFTactext:
   
    *   Generate Resources XML menu option now generates more accurate skillset names, sprite file names, special names, and placed unit names.
   
FFTorgASM:
   
    *   Added "align" attribute for <Location> tags.  This will align the offset to the specified multiple.  For example, align="4" will cause an offset that isn't a multiple of 4 to advance to the next multiple of 4.  Using mode="ASM" also automatically uses an align of 4.
    *   Updated some patch XMLs.

EntryEdit:

    *   Fixed an issue where a set name lookup could cause an error if there were more sets than known set names.
   
ASM Encoder/Decoder:

    *   Now reports errors translating pseudoinstructions.  Errors should be visible where appropriate in both FFTorgASM and MassHexASM.

In .493, FFTactext can generate a Resources.zip, which might make this easier.

Thanks for the test/report.  You should be able to use this patch to make Defend and Equip Change work like Default skillsets, along with the other changes (FFTP and the skillset hardcoding patch):

EDITED with potential fix for AI issue, but have yet to test...

I'm not yet sure if some of this should eventually be rolled into the skillset hardcoding patch.  Anyway, let me know if that fixes the issues.

EDIT
The AI only looks at its primary and secondary skillset(s) to find skills that can be used.  Defend and Equip Change have a fair bit of hardcoding.
Either a fairly big rewrite of some AI routines or some fairly sizable new code would probably need to be added to handle this. 
If the goal is for the AI to have more abilities, there are probably better and/or more robust ways to do it... this may not be a useful road to go down.

You should still be able to patch, yeah.  As Xifanie pointed out, it's reading the data as ASM, but that's not meant to be ASM.

The whitespace between the Location tags shouldn't be particularly relevant. To get rid of the warnings, put mode="DATA" in the appropriate Location tag(s). (Or change the spreadsheet to do this for you in the output)

You might want to check out this topic where I write about some of the results of my own investigation into effects: https://ffhacktics.com/smf/index.php?topic=12226.0

It describes how to find the header data and where the sections are when the start of the file is program code.

Thanks! Glad to hear you like the tool!

In the case of TLW, it looks like the battle conditionals and scenarios were rearranged, and EntryEdit's XML files are based on vanilla's order. This error is happening because the program is trying to look up the names of battle conditional sets that don't exist in vanilla. I've put in a patch that will fix that particular problem in the next version.

In the meantime, the simplest fix is probably to take the ConditionalSets.xml file in the EntryData subfolder of the application directory, copy it into the same directory, name the copy ConditionalSetsTLW.xml, and add a bunch of entries to the end of the new XML file, like so:


Then open the EntryEdit.exe.config file and change the ModSuffix value to TLW.  The new line would look like this:


With that, the data should load and the program shouldn't crash... but the names of the scenarios and conditionals won't make much sense like this. Ideally we would create a separate set of XML files that would contain the correct names for TLW.

Quote from: nitwit on February 15, 2021, 09:08:47 pmI saw your revision and can now more easily grab gameshark/RAM addresses for everything FFTPatcher edits, but where can I find the disc files/addresses for the same? A search of 0xAD844 and it's base 10 equivalent in the FFTPatcher suite repo returns nothing.

I don't know what the GitHub search is doing or why it doesn't return results, but this is the file.

Quote from: nitwit on February 15, 2021, 07:09:05 amOn testing the shop inventory data does not start at 0x8018d840. Instead it starts at 0x8018d844.

Good catch.  It was writing to the correct location when patching the ISO (0xAD844 in WORLD.BIN) but to the wrong corresponding RAM location for Gameshark codes.  I've checked in a fix to the source control to correct the offset.