• Welcome to Final Fantasy Hacktics. Please login or sign up.

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Glain

Beta v7:


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


    *   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.)


    *   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.
    *   Generate Resources XML menu option now generates more accurate skillset names, sprite file names, special names, and placed unit names.
    *   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.


    *   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.
War of the Lions Hacking / Re: Names in FFTPatcher
April 05, 2021, 05:35:08 pm
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):

    <Patch name="Defend and Equip Change treated as Default skillset">
            This patch should be applied along with Skillset Menu Hardcoding Fix if changing Defend and Equip Change into Default skillsets in FFTPatcher.
            AI doesn't use abilities in Defend or Equip Change skillsets.
        <Location file="BATTLE_BIN" offset="67594,67598" mode="DATA" offsetMode="RAM">
        <Location file="BATTLE_BIN" offset="675F4,675F8" mode="DATA" offsetMode="RAM">
        <Location file="BATTLE_BIN" offset="13628C" mode="ASM" offsetMode="RAM">
            b   0x801362a4
        <Location file="BATTLE_BIN" offset="1692B9" mode="DATA" offsetMode="RAM">
            01 01
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.

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.
Hacking/Patching Tools / Re: FFT Patcher .478 Source Code
February 26, 2021, 01:51:09 am
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:

    <Entry hex="0092" name="New Set" />
    <Entry hex="0093" name="New Set" />
    <Entry hex="0094" name="New Set" />
    <Entry hex="0095" name="New Set" />
    <Entry hex="0096" name="New Set" />
    <Entry hex="0097" name="New Set" />
    <Entry hex="0098" name="New Set" />
    <Entry hex="0099" name="New Set" />
    <Entry hex="009A" name="New Set" />
    <Entry hex="009B" name="New Set" />
    <Entry hex="009C" name="New Set" />
    <Entry hex="009D" name="New Set" />
    <Entry hex="009E" name="New Set" />
    <Entry hex="009F" name="New Set" />
    <Entry hex="00A0" name="New Set" />
    <Entry hex="00A1" name="New Set" />
    <Entry hex="00A2" name="New Set" />
    <Entry hex="00A3" name="New Set" />
    <Entry hex="00A4" name="New Set" />
    <Entry hex="00A5" name="New Set" />

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

<add key="ModSuffix" value="TLW" />

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.
Hacking/Patching Tools / Re: FFT Patcher .478 Source Code
February 15, 2021, 09:39:01 pm
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.
Hacking/Patching Tools / Re: FFT Patcher .478 Source Code
February 15, 2021, 02:04:02 pm
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.
Help! / Re: ASM understanding
January 12, 2021, 06:00:40 pm
They're two separate routines that happen to be placed next to each other.  They both have a closing jr (at 0x186d24 and 0x186d50, respectively).  Neither one has a nop, but what's the relevance of that?  They are referenced in the formula pointer table, of course...

1.  I'm unaware of unknown skill bytes.  If you wanted to consolidate the routines into one by, say, providing the action offset as an argument, it looks like you could save some space.  It doesn't seem like anything amazing though, unless there are a bunch more routines like this.

2.  Are you asking if the AI would use Cheer Up?  I haven't tested that, although I can't say I remember enemy mediators using Praise very often...
Help! / Re: ASM understanding
January 12, 2021, 09:24:27 am
1.  Just off the top of my head, a bunch of code can be made more efficient by keeping values stored in registers instead of reloading or recalculating them, and re-ordering code to remove nops can help quite a bit as well.  Getting a good understanding of what the code is doing in each case gives a good idea of which parts of it seem to be unnecessary.

2.  Generally speaking, it's absolutely not safe, and it should be assumed that a crash would result.  This will usually corrupt the stack pointer and saved register values, unless you've accounted for that.  It can be made to work in very specialized cases with the right (hacky) setup.
The Geomancy ability is intended to be placed in a Default skillset.  As for the Jump ability, yes, it's based on the Lancer job level.  I probably should have mentioned that.
Help! / Re: ASM understanding
January 11, 2021, 09:19:21 am
It's just redundant.

This happens a lot in the vanilla code, where it's like the compiler generated code to do one thing (in this case, set the action's CT), then generated code to do another thing (set the action's type), and just mashed them together without taking into account that it could have just reused the value in r3 instead of reloading the action pointer.

(Vanilla code isn't going to branch into the middle of the routine, and the only branches inside the routine skip to the end of the routine, so those two bits of code will always be run in sequence.)
Another update to my XML, brought about by an issue found with the swap units hack when units are on proposition.  That issue should be fixed in this latest update. There are also a bunch of new hacks! The original post has the new version of the XML and include files.
Beta v6:

Command line patching is now supported for FFTPatcher, FFTactext, FFTorgASM, and EntryEdit by using command line arguments "-patch" and then specifying the patch file and disc image (or pSX savestate).  There is generally no output on a successful run (unless FFTorgASM is warning that files appearing in patches are either unsupported or not present in the specified savestate), and an error message can appear in the console if there is a problem.  If the program opens up its normal window, then there was something wrong with the passed arguments (file(s) not found, etc.) 
    By default, the console does not wait for the program(s) to finish, because they aren't configured as console applications.  Using "start /wait" will make the console wait.
        start /wait "Patch" FFTPatcher -patch patchfile.fftpatch fft.iso
        start /wait "Patch" FFTactext -patch patchfile.ffttext fft.iso
        start /wait "Patch" FFTorgASM -patch patchfile.xml fft.iso
        start /wait "Patch" EntryEdit -patch patchfile.eepatch fft.iso

    *  Enabled editing ability effects for all applicable abilities.
    *  View stat form now uses correct Monster average Raw MP.

    *  Now displays patch descriptions in a more natural way, with better handling of whitespace.
    *  Persistent labels can now be referenced anywhere in a patch, even if they are defined in later Location tags.
    *  Save Patch XML option now updates variable values and doesn't write out blank Location tags.
    *  Spacebar can check/uncheck patches again, if the selection cache for the type ahead is empty (ESC to clear).
    *  Variables can now be declared with symbol="true" and no accompanying file, sector, or offset.  These variables would then only be referenced as macros in ASM blocks.
    *  Added a "hidden" attribute for patches (true or false, default false).

    *  Added support for .if, .else, .endif preprocessing commands.  Skips lines if condition is not met.  Blocks can contain multiple lines, and nesting is possible.
            .if    >, %ChangePartyLevelRandom, 0
                srl    t3, t2, 4
                move    t3, t1

    *  Fixed an issue where using the "load immediate" pseudo (li) with a label could cause addresses to be calculated incorrectly.  Using li with a label will now always cause it to expand to two instructions.

** Updated with additional fixes (thanks Cerabow and EnderC for reporting issues):

        *  Fixed context menu exception when clicking out of bounds in a data grid view (Action Menus, Monster Skills, Poaching tabs)
        *  Fixed an exception that occurred when setting an item to use an ability with an ID > 0x7F, where the ID would erroneously be used in a reference to the Status Infliction list.
        *  Selected entries for Inflict Status and Item Attributes tabs refresh when the tabs are clicked, so that they display the current correct information for which Items or Abilities are linked to each.
Hacking/Patching Tools / Re: Formula mapping
December 21, 2020, 10:10:40 pm
For some of these questions, it would make sense to look over the MassHexASM thread, which explains some of this.  In short:

The "@" in front of a label means it persists across Location tags.
t1 and t0 are names for the first two "temp" registers (and actually refer to $9 and $8, respectively). Check out the calling conventions.
.eqv is a preprocessor instruction that defines a simple macro which replaces the first string with the second before actually encoding the block.
I tried this out earlier today. I didn't get any freezing but did get weird behavior (enemy AI attacking their own units!) 

I think the issue is that the code block in the second Location tag is one line too long, and overlaps another case (which would jump directly to that line, storing a bad value).  I was able to make a modification that I think got it to work though.

What I did was cut the last line of the second Location tag, paste it over the first nop in the first Location tag, change r2 to r5 in that line, and change r2 to r5 in the "Load Charge Power" line.
Quote from: Arimala on December 05, 2020, 07:50:50 amHmm I did not notice this... using the formula 2D Dmg (PA*(WP+Y)) on the wiki, "addiu r29, r29, 0x0018" did not get transferred over using import code because on the wiki it says:
"27bd 0018 addiu r29,r29,0x 0018" instead of "27bd0018 addiu r29,r29,0x 0018"
Is that space there for a reason? Most of the formulas on the wiki seem to be like that, but not all. I guess it is not intended for this use is why.

This is a mistake on the Wiki that stems from the way the formatting was done. 

To elaborate, if you use View Source to look at how the code is formatted on basically any of the Wiki pages, you should see that each line actually starts with a space.  This makes it so that the code formats the way we want it.

Generally when we put code on the Wiki, we're pasting it from a text file that doesn't have the spaces.  So, to add the spaces, there were times when a certain search/replace was done.  In this case, "0018" was replaced with " 0018" because the start of each line (the RAM address of the line) started with 0018.  That did create the leading spaces, but also the side effects you're seeing.

Quote from: Arimala on December 05, 2020, 07:50:50 amSo if I can just keep using r1 as the base then you are telling me the code on the wiki is less efficient?
From what I could see on all the code, anything new loaded in used a new register.

Yes, the code on the Wiki (the game's default code) is less efficient than it could be in many places, a product of the compiler they used.  In some cases, very much so.

Quote from: Arimala on December 05, 2020, 07:50:50 amI am confused by the wires crossed bit though.
This is taken directly from https://ffhacktics.com/wiki/Store_PA_and_WP_%2B_Y.
lui r4, 0x8019
lbu r4, 0x0036(r4)  Load Attacker's PA

Those two lines don't appear in sequence without another manipulation of r4 first:

00185e5c: 3c048019 lui r4,0x8019
00185e60: 8c842d94 lw r4,0x2d94(r4)    # Load acting unit pointer (from 0x80192d94)


00185e74: 90840036 lbu r4,0x0036(r4)  # Load PA of acting unit (from acting unit pointer + 0x36)

Quote from: Arimala on December 05, 2020, 07:50:50 amand loading ability X is 0x38f9 in all the other formulas from what I saw

Ability X is stored at 0x801938f9.  What you're loading is 0x38f9 away from the acting unit's pointer. 
The acting unit's PA is stored 0x36 bytes away from its pointer, but you're instead loading from 0x80190036.

It should be more like this:
[0x80151114]  lbu r4, 0x0036(r5)  # Load PA of acting unit
[0x80151118]  lui r5, 0x8019
[0x8015111C]  lbu r5, 0x38F9(r5)  # Load Ability's X
The freezing is probably because you're corrupting the stack pointer (r29).  You're subtracting from it at the start of the routine (the first instruction is really "addiu r29, r29, -0x0018" and then not adding that 0x18 back at the end.  The solution is to insert "addiu r29, r29, 0x0018" at the end of your routine before the "jr r31" (or after it).

You are also inexplicably ending your routine after setting XA equal to PA.  What is this doing here?
0x80151140   jr r31   
0x80151144   nop

For efficiency's sake... you can set a register to 0x80190000 and then just keep using it as a base, i.e.:
lui r1, 0x8019          # r1 = 0x80190000
lw  r5, 0x2D94(r1)      # Keep using r1 as the base...
lbu r2, 0x3902(r1)
lbu r3, 0x38FA(r1)

You would only have to repeat the lui after a routine call (jal).

It also looks like you got your wires crossed here:

0x80151114   lui r4, 0x8019   
0x80151118   lbu r4, 0x0036(r4)   # Load Attacker's PA Loading from 0x80190036?
0x8015111C   lbu r5, 0x38F9(r5)   # Load Ability's X   Loading from (Attacker base pointer + 0x38F9)?

Beta v5!

Introducing EntryEdit!
    * Edits Battle Conditionals, World Conditionals, and Events.  Loads/saves to patch files, script files, disc images, and pSX save states!
    * Customizable by editing EntryEdit.exe.config and associated XML files.  Defaults are vanilla, but has pre-built support for Event Instruction Upgrade by setting "ModSuffix" to "Upgrade" in the config file.

FFTP suite now includes MassHexASM.

FFTPatcher, FFTactext, and EntryEdit can open patch files directly (.fftpatch, .ffttext, .eepatch) via command line.  Also works with file association in the file explorer.
Icons added for FFTPatcher, FFTactext, and FFTorgASM.
Version number of the FFTP suite now displayed in the title bar.

    * When importing ISO, no longer loads additional entries per section.
    * When importing ISO, uses non-DTE character map for sections with DTE disabled (such as all OPEN.LZW sections by default).

ASM Encoder/Decoder:
    * Now replaces labels and equivalences in reverse order of name length to avoid replacing partial names.
Help! / Re: Editing Text WOTL PSP
September 30, 2020, 05:03:08 pm
What happens with this version?