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

Quality of Life Pack v1.14b

Started by Xifanie, September 17, 2021, 03:41:17 pm


is this compatible with "the lion of war the lions" that was recectly released?
  • Modding version: PSX & WotL


I don't know if it's supposed to be the case, but this hack is not compatible with The Lion War of the Lions. Upon starting a new game, or loading an old one, it freezes.
  • Modding version: Other/Unknown


May 15, 2023, 03:27:25 pm #22 Last Edit: May 17, 2023, 06:07:54 pm by Thirteen1355
I'm getting JP for all sorts of Jobs while playing as a Black Mage, but none as a Black Mage. I am playing with TLWotL and the QoL patch, with Event Instruction Upgrade v1.377.1.xml patched on top of it.

The Black Mage gets no JP, except from spillover.
  • Modding version: Other/Unknown


Quote from: Thirteen1355 on May 15, 2023, 03:27:25 pmI'm getting JP for all sorts of Jobs while playing as a Black Mage, but none as a Black Mage. I am playing with TLWotL and the QoL patch, with Event Instruction Upgrade v1.377.1.xml patched on top of it.

The Black Mage gets no JP, except from spillover.

If you had issues starting the game at all, I'd assume it would cause other issues down the line, yeah. I just double checked, the QoL hacks do conflict with hacks in TLWotL because it has a bunch more hacks than base TLW. If you want to download the resources for both and individually attempt to apply the hacks that don't conflict, you're welcome to, but overall, do not apply the QoL ppf onto TLWotL, it will break.
  • Modding version: PSX
  • Discord username: RetroTypes


1.14b isn't working for me. Patched clean game with TLW, then patched again with QoL 1.14b. Not sure if I did it incorrectly, or it's an issue with duckstation.
  • Modding version: Other/Unknown


Got it to work, but it crashes every time after the fight in fort ziekden. Been changing a bunch of settings in duckstation but nothing works.
  • Modding version: Other/Unknown


September 08, 2023, 12:08:54 am #26 Last Edit: September 27, 2023, 01:20:28 am by Nyzer Reason: Fixed a bug in Cancel Movement 1.14c Unofficial
I downloaded the 1.14 xml pack a ways back and found that a lot of what was in it seems to conflict heavily with the free space used by TLW and TLWotL, in ways that 1.13b doesn't. For the most part I just opted to use 1.13b instead. However, 1.13b's Cancel Movement lets you spam Cancel to constantly regain HP and MP, so I moved things around in 1.14 and it worked fine. (Much appreciate the liberal use of labels rather than fixed locations. Super easy to accomplish.)

But traps and Move-Find Item didn't prevent me from canceling. Did some digging today and figured a few things out. They attempt to use the same check that teleportation failures do: set byte to 0xFF so that, later on, it gets set to 0x00 (which locks cancel), while any other value is set to 0x01. However, they run after that lock, so they end up staying at 0xFF, which doesn't lock cancel.

On top of that, that teleportation failure? Turns out the teleportation failure calculation runs before committing to the teleport. It happens when you first select the tile, before even seeing the option to confirm the teleport attempt. There were no commands that affected that byte on the success calculation - meaning that if someone went to teleport, the game calculated it as a failure, but the player changed their mind before confirming the teleport, they could make another attempt, succeed, and have their movement locked anyway.

So I went and fixed that up.

I also did another thing recently, and since I'd say it's a QoL feature, and I'm posting in this topic anyway, I might as well show it here, too:

It comes with a partial fix to the JP Scroll Glitch by preventing underflow. I have no idea how xml files can be set up to provide dropdown menus/value entries, and the idea of making it something that can be toggled during the game came up in a conversation, so I included options depending on whether Variables xD5, xD6, and xD7 are flagged.
Variable xD5 fully fixes the JP Scroll Glitch.
Variable xD6 prevents refunds (even glitched ones, whether or not xD5 was flagged).
Variable xD7 causes refunds to only give half the JP back.

I've also now included a v1.2, which blocks the player from refunding equipped RSM skills. Makes the book hit sound when you try; seemed like a good sort of bounce-off sound to indicate an issue.

Feel free to include Refund Abilities in the QoL pack if you want, and hopefully the fixes to Cancel Movement also come in handy?
  • Modding version: Other/Unknown


September 18, 2023, 08:21:52 pm #27 Last Edit: September 18, 2023, 09:31:53 pm by Nyzer
The .xml for Cross Skip 1.14 is just super broken. Events lock up on the first text box, with O no longer advancing text. Pressing X advances it once and then crashes the game. Xifanie, I don't know if you have a different set of xml files, since from what Akashachi says, the ppf runs great with no issues, but the xmls...

I vaguely remember there being discussions about the latest version of QoL but the specifics are long gone for me, so I don't know if it's come up before.

Also, I updated Refund Abilities.
  • Modding version: Other/Unknown


Cancel Movement 1.14c Unofficial broke Fly because I added two lines to something I incorrectly thought was free space. Thankfully, Xif's code included two nops at the very end of it (which, in hindsight, really should have made it obvious it wasn't free space), so it was an easy fix.

I made this post intending to delete the previous one. I, uh. Can't delete it.
  • Modding version: Other/Unknown


November 18, 2023, 04:22:21 pm #29 Last Edit: November 18, 2023, 04:50:42 pm by Nyzer
So it turns out there was another bug with Cancel Movement. While clearing out the bytes at 0x8016CCB4 does indeed make the unit display vanish and force it to be reloaded so it properly displays the adjusted HP & MP from canceling out of a Move-HP/MP Up, it also slowly builds up menu corruption. I assume because it's not clearing the VRAM space used by the menu or resetting the pointer it uses in the space...? I honestly don't have the faintest idea of how it works.

After a small number of canceled moves, reading ability descriptions (that are large enough) will cause the below windows (the action list, the ability list, etc.) to become corrupted. Keep canceling moves, and the corruption will occur even on descriptions that took up less space. Keep canceling moves, and the unit display will start becoming corrupted until it eventually disappears entirely, ability descriptions won't appear at all, event dialogue won't appear at all... etc. I personally never got to that point without deliberately grinding out canceled moves, but Akashachi mentioned he's seen parts of the menu disappear on rare occasion when using the QoL pack in TLW/TLWotL.

I have what seems to be a fix for it: instead of manually clearing the bytes at 0x8016CCB4 and then using jal 0x8013F900 to reset the menu position, I used jal 0x80071008, the only routine that calls the one at 0x8013F900. Since there's a lot of extra code there, I was expecting it to just horribly break something, like performing surgery with a chainsaw instead of a scalpel, with the intent to attempt to narrow things down from there, but... this alone fixes the issue and seems to have no negative side effects besides looking a smidge less clean when it reloads the menu. But it seems that as long as this routine is called WITHOUT manually clearing those bytes, it gets the job done with zero menu corruption.

Other than that, I do have another bug to report that I currently have no intention of attempting to fix, since it's so rare to see: if you're in Critical, and use Move-HP Up to get out of Critical, then cancel that movement, upon your next movement, you won't cancel the Critical animation (though the status itself will go away). Looked in Misc Data and it doesn't seem as if byte 0x0150 (Statuses to remove) gets updated upon repeat moves, which is presumably why byte 0x0140 with the Critical status doesn't get cleared out. I don't see a reason for this at a glance, myself.No message is associated with this attachment.
  • Modding version: Other/Unknown


The XML for Extended Warranty 1.14 has some sort of issue when it comes to the code for offset 0x18D3C0. When I use it and go to do an attack, the tile(s) I select will light up green, but the ones I didn't will flash a sickly yellow.

1.13b seems to work fine - aside from the duplicate katana issue. As it turns out, the reason it's giving dupes is because the "add to fur shop if broken" code is in the ability formula itself. The game pre-breaks katanas before that point and runs a check whether to "steal" one back out of thin air after the formula ends. But it runs the "katana stays broken" check during the formula. But the only roll that counts is the final roll that's made. But every time the "yes, break that shit" roll comes up, it adds 1 katana to the Fur Shop inventory, even though it's not yet at the point where the final determination of whether or not it broke has been made.

I cut out that part of the hack and included my own, which places the stay broken/Fur Shop check after the formula, so it only runs once. Bundled it with Extended Warranty v1.13b since it seems to lack the visual bug and hasn't been giving me duplicates in my tests.
  • Modding version: Other/Unknown


Found a bug with the Equip Change Fix hack: because Defend runs the same set of code that is altered, Defend tries to load data that would be set by EQUIP.OUT during Equip Change but turns out to just be junk data when using Defend. As a result, sometimes Defend would consume Act, and sometimes it would not.

Here's an update that would allow the modder to choose whether Defend consumes Act or not:

    <Patch name="Equip Change Fix">
<Author>Xifanie, with a fix from Nyzer</Author>
        <Description>Allows changing your Right Hand/Left Hand equipments without consuming your Act.
Additionally, can optionally prevent Defend from consuming Act as well.</Description>
        <Location file="BATTLE_BIN" offset="E929E" mode="DATA">
        <Location file="BATTLE_BIN" offset="E9AA0" mode="ASM">
@EquipChangeKanji1: lbu r1,0x0005(r16) # Load unit's used skillset
ori r2,r0,0x0003 # r2 = 3 - Equip Change
bne r1,r2,@eqch_br_1 # Branch if not using Equip Change
ori r3,r0,%DefendConsumesAct
sw r6,0x0000(r29)
sw r7,0x0004(r29)
addiu r6,r0,0x0002
lui r7,0x801f
lw r7,-0x6d1c(r7)
lui r5,0x801e
addiu r5,r5,-0x781c
addiu r7,r7,0x0004
@eqch_br_2: lhu r3,0x0054(r7)
lh r2,0x0000(r5)
addiu r7,r7,0x0002
addiu r5,r5,0x0002
bne r2,r3,@eqch_br_1
ori r3,r0,0x0001
sltiu r2,r6,0x0005
bne r2,r0,@eqch_br_2
addiu r6,r6,0x0001
ori r3,r0,0x0000
@eqch_br_1: lui r2,0x8015
lw r2,-0x2cfc(r2)
ori r5,r0,0x01c0
mult r5,r2
mflo r5
lui r1,0x8019
addiu r1,r1,0x08cc
addu r1,r1,r5
sb r3,0x0188(r1)
lui r1,0x8015
ori r5,r0,0x0001
subu r3,r5,r3
sb r3,0x029e(r1)
lw r6,0x0000(r29)
lw r7,0x0004(r29)
@used_defend: j 0x000751c8
addiu r29,r29,0x0008
@EquipChangeKanji2: sb r0,0x029e(r4)
beq r5,r0,@eqch_br_3
ori r5,r0,0x0001
j 0x00138f18
sw r5,0x0110(r29)
@eqch_br_3: bne r2,r3,@eqch_end
sw r3,0x0110(r29)
sw r0,0x0110(r29)
@eqch_end: j 0x00138f18

        <Location file="BATTLE_BIN" offset="751C0" offsetMode="RAM" mode="ASM">
j @EquipChangeKanji1
addiu r29,r29,-0x0008
        <Location file="BATTLE_BIN" offset="138F0C" offsetMode="RAM" mode="ASM">
lui r4,0x8015
j @EquipChangeKanji2
lbu r5,0x029e(r4)
<Variable name="Defend Consumes Act" default="1" bytes="1" symbol="true"/>
  • Modding version: Other/Unknown