• Welcome to Final Fantasy Hacktics. Please login or sign up.
December 06, 2021, 10:28:08 pm


Use of ePSXe before 2.0 is highly discouraged. Mednafen/RetroArch is recommended for playing/testing, pSX is recommended for debugging.

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

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.
Hacking/Patching Tools / Re: FFT Patcher (.494)
November 24, 2021, 02:29:42 pm
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.
PSX FFT Hacking / Re: ASM Requests
October 08, 2021, 05:42:14 pm
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.
Hacking/Patching Tools / Re: Error in FFTPatcher
October 07, 2021, 01:58:16 pm
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):


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