|
Title
|
Applies to
|
Last Updated
|
Description
|
Duplicate enemy names fix
(Version 1.3)
|
FF3us: 1.0 and 1.1
|
28 August 2012
(Updated Readme to account for bug having wider influence than I thought; patch is identical to version 1.2, released waaay back on Jan 20, 2004)
|
Here's the brief description from the readme:
In FF3us, one function forgot to account for the change to 10-character enemy names from the 8-character names in FF6j. This means you'll get duplicate entries listed onscreen if you encounter a party with two or more different enemies of the same name (e.g. with the Mag Roaders; it *should* be
condensed to one "Mag Roader"; likewise with Cranes, Tentacles, Chadarnooks, and Hidonites). The bug can also cause some enemy names to be OMITTED entirely, but that's not a risk unless you're using a ROM with custom enemies/formations and you're very unlucky or deliberate. Finally, it can cause the FC 10 monster script command to malfunction in a hacked game. The patch makes FF3us behave correctly, like FF6j (except there is still no display of enemy quantities).
Comes with one patch that works with both FF3us versions, and detailed disassemblies for the bad code Square wrote and my fixes.
|
|
Genji Glove damage
reduction fix
(Version 1.01)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
13 Nov 2005
(Corrected and slightly modernized documentation; patch is identical to version 1.0, released waay back on Mar 6, 2003)
|
Repairs the 25% physical damage reduction caused by Genji Glove so that the cut happens just when you have two weapons. Normally, that penalty would occur only if you had the Genji Glove on and one or no weapons equipped; hence the need for the fix, since that obviously doesn't make any sense.
Comes with two patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fixes.
|
Alphabetical Rage patch
(Beta 0.45)
|
FF3us: 1.0 and 1.1
|
01 Feb 2004
|
Alphabetizes the enemy Rage listings -- under both the in-battle command and Skills menu -- to make life a little easier for ROM players. The game normally lists Rages in the order of their position in ROM, which is of no use to the player, and generally makes finding the Rage one wants rather annoying. This patch can be quite the timesaver, and may just convince players to hold back less on their Veldt learnings.
Comes with a patch that works with both FF3us versions, and two detailed disassemblies: one for the original Square code, one for my alphabetized revamp.
|
Magic Damage Overflow fix
(Beta 0.30)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
04 April 2004
(Takes up 2 less bytes than the 01 Feb 2004 release)
|
Repairs the main Magic Damage Calculation function to make sure damage stays within a 16-bit value. Previously, there was nothing preventing magical attacks from overflowing the damage counter, wrapping it to some paltry number; try a Level 99 character with 140+ Magic Power and Ultima to see the bug in action. Thankfully, Square did foolproof all (?) the other functions that can increase damage, minimizing my work.
Comes with two patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
|
Jump/Launcher and
Jump/Super Ball fix
(Beta 0.20)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
09 June 2004
(No longer uses extra space)
|
Normally, if an enemy uses Launcher when all the characters have jumped, or a character uses Super Ball when all the enemies have jumped, the battle will bug out. Targets will be invisible; actions will be prevented; it's a mess (though it's largely remedied if another Super Ball or Launcher is used with actual targets present). This fix prevents all the misbehavior by making sure the function that deals with Launcher and Super Ball always clears a counter variable, even when no targets are found.
Comes with two patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
|
Muddle/Mantra fix
(Beta 0.15)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
14 Feb 2004
|
If Sabin or Gogo get Muddled or Charmed before using Mantra, it will heal enemies more than it should. In fact, Mantra cast on a lone enemy will always heal for 9999, regardless of Sabin's/Gogo's HP. The game wrongly assumes that the caster is always one of the original targets, using this formula for healing:
Healing per target = Caster's Current HP / (Number of targets - 1)
This patch fixes the oversight, so a misdirected Mantra will now abide by the same formula as a normal one:
Healing per target = Caster's Current HP / (Number of targets after excluding caster)
Comes with two patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
|
Muddle/Palidor fix
(Beta 0.15)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
09 March 2004
|
If a character gets Muddled or Charmed right before casting Palidor, they'll attempt to use it on the enemy party. Because the spell and/or its animation aren't equipped to handle enemy jumpers, the caster will disappear indefinitely after getting whisked away by the giant bird, even though he or she didn't technically jump. Meanwhile, the enemies will be visible but unhittable until suddenly doing their jump attacks. This patch eliminates the bugginess by removing enemies (and characters acting as enemies, like Gau returning from a Veldt leap) from Palidor's targets.
Comes with two patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
NOTE: This patch uses free space that was consumed by older versions of Terii Senshi's Rippler patch. Thus, I recommend downloading the MUCH improved newest version of his fix from http://www.rpglegion.com
|
Master ZED's Allo Ver fix
(Version 1.0)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
25 March 2004
|
Allo Ver belongs to two different enemy formations: 126 and 515. Only formations 0-511 can be encountered on the Veldt (or give Magic Points). Because Square blundered and linked #515 instead of #126 to the treasure chest in the Veldt Cave, you'll never see Allo Ver on the Veldt. Master ZED figured this out a long time ago, and has provided a couple elusive fixes over the years. But my thieving self takes the honor for creating an accessible standalone patch.
Comes with one patch that works with either version of FF3us and with FF6j.
Game Genie codes are also provided for cartridge players within the Readme.
|
Jewel Ring description fix
(Version 0.61)
|
FF3us: 1.0 and 1.1
|
07 May 2004
(Just a small update to Readme; patch is identical to version 0.60)
|
The game wrongly gives this description for Jewel Ring:
Protects against "Dark", "Petrify"
In reality, the relic only protects against Petrify. One immediate clue to players that
something is amiss is that Goggles, which protect against Dark status, and Jewel Ring are
both first sold in South Figaro. This would make Goggles (even more) pointless from the get-go.
This fix changes Jewel Ring's description to:
Protects against "Petrify"
Comes with one patch that works with either version of FF3us.
|
Deceptive Tapir fix
(Version 0.40)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
22 April 2004
|
Tapir, summoned by Mog's Dance, heals any ailment besides Freeze or those that can't be healed normally (such as Charm). On top of that, its special effect will fully restore the HP and MP of sleeping targets. When the special effect detects that a target isn't sleeping, it will trigger a "Miss" message, which is misleading because the status ailments are still removed from the target.
This fix causes the Tapir special effect function to essentially do nothing for awake targets. No "Miss" message appears; their ailments are simply cured. This does NOT influence the unnamed tapir that appears automatically to wake up snoozers, as that's not even the same spell.
Comes with two patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
|
1-way status immunity fix
(Beta 0.25)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
24 May 2004
|
Status immunities in this game are two-way: if a target is immune to a status but doesn't have it, it can't be given to it; if a target is immune to a status but already has it, it can't be removed from it. However, a couple special cases break the rules: Zombie (through Overcast) and Near Fatal (through HP <= 1/8 of its maximum). With these two cases, it's possible to enter those statuses while already immune to them, which in turn causes the statuses to be impossible to remove. This patch will prevent the former from happening, thus preserving 2-way immunity.
Comes with two patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
|
Stackable immunities and permanent statuses fix
(Beta 0.22)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
05 May 2005
(Just another small documentation correction; patch is identical to versions 0.20 and 0.21)
|
When you change a piece of equipment or exit a Rage (i.e. croak or get petrified) mid-battle, the game forgets to clear some of the status immunities (and thus, permanent statuses, too) that were provided by that Rage or shield. Fun ways to abuse this are switching between multiple shields (e.g. Force ==> Cursed ==> one with good Defense), or by Raging a resilient beast like Intangir, killing and reviving Gau, then Raging something else. You'll be able to "stack" all sorts of permanent boosts and immunities you shouldn't have.
This patch prevents such stacking. It does so by clearing or replacing ALL immunities when equipment is changed mid-battle or a Rage is exited; now, the only immunities a character will possess at those points are the ones provided by their current equipment.
Comes with two patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
|
Pincer + Row fix
(Beta 0.15)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
2 July 2004
|
From Master ZED's Bugs and Glitches Guide:
Normally, when you begin a fight in a Pincer attack, all characters are in the front row. You can use the Row command to [randomly] turn around, but oddly it also switches rows. This isn't a visible change, but something you'll notice in damage dealt and received. Since there should be no rows for characters in a Pincer (and for enemies, no rows in a Side attack, but they don't change rows mid-battle anyway), the effect on damage becomes a very sneaky bug.
This patch stops the Row command and the R.Polarity spell from switching a character's row when they are caught in a Pincer, unless all the enemies on one side are gone.
Comes with two patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's lacking code and my fix.
|
Auto Swordless Runic fix
(Beta 0.15)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
11 July 2004
|
From Master ZED's Bugs and Glitches Guide:
Runic and SwdTech share a trait in that they both require weapons to make them available for use in battle. SwdTech works properly; no/improper weapon, no SwdTech. Runic is faulty however, in that if a character is acting automatically (Colosseum, Muddled, Charm), that character can use Runic regardless of equipment.
This patch adds a check so that Runic won't be chosen for a character who's acting automatically unless he or she holds at least one weapon that supports the command. As a bonus on top of the fix, I've also given hackers more flexibility to change the commands available for Berserk and Zombie (see the Readme for more on that).
Comes with two patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's lacking code and my fix.
NOTE: This fix conflicts with any version of my Alphabetical Rage patch before 0.45. If you want the two to coexist, make sure you get a copy of that patch dated Feb 1, 2004 or later.
|
Disrespectful Zombie fix
(Beta 0.20)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
15 Aug 2004
|
Status immunities in this game are two-way: if a target is immune to a status but doesn't have it, it can't be given to it; if a target is immune to a status but already has it, it can't be removed from it. A permanent status means the target gets both the status and immunity to it. However, if a target is turned into a Zombie, it'll always lose certain statuses (Dark, Poison, Near Fatal, Berserk, Muddled, and Sleep), even if they were supposed to be permanent (e.g. from the Cursed Shield or clever Rage use). You won't be able to re-inflict such a status on the target, as it's still immune to it.
This patch preserves 2-way immunity by fixing Zombie to not eliminate statuses to which a target is immune. It also removes a minor flaw where True Knight wearers could momentarily protect Petrified characters.
Comes with two patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
|
Step Mine's missing digit fix
(Beta 0.22)
|
FF3us: 1.0 and 1.1
|
05 May 2005
(Just a small Readme correction; patch is identical to versions 0.20 and 0.21)
|
Slightly modified from Master ZED's Bugs and Glitches Guide:
Whenever the MP cost of Step Mine is at 100 or up to 109, the in-battle MP cost display for the Lore menu will glitch and not display the middle digit. The formula for a character's Step Mine MP cost is playtime in minutes DIV 30, so you can only see this bug at or between 50:00 and 54:59, in which range the middle digit of Step Mine's MP cost will be a 0.
This patch makes it so the tens digit will only be blanked if it AND the hundreds digit are both zero. Thus, no more gaps in the displayed MP cost.
Comes with one patch that works with both FF3us versions, and detailed disassemblies for the bad code Square wrote and my fix.
|
Brushless Sketch patch
(Beta 0.16)
|
FF3us: 1.0 and 1.1
FF6j 1.0
RPGOne 1.1
|
20 Oct 2004
(Just a small update to Readme; patch is identical to version 0.15)
|
Relm and Gogo can sketch without a brush. While not a bug, that's still bunk. Common sense forced me to intervene with a giant patch; it makes three changes as long as a character doesn't hold a brush:
- The Sketch command is grayed (and therefore unavailable) on his or her in-battle menu.
- The character won't choose Sketch when acting automatically (in the Colosseum, or when
Muddled or Charmed).
- His or her Sketch command is grayed on the Status screen and where you arrange the "Short" layout under the Config menu. This measure is just for information and consistency.
Comes with three pairs of patches and anti-patches: one for FF3us (either version), one for FF6j, and one for RPGOne's FF6 translation. Also includes detailed disassemblies of Square's original code and my changes.
NOTE: This patch REQUIRES my "Auto Swordless Runic" fix; you must apply that patch before this one. See the Readme for more info.
|
Recapture the Glory fix
(Beta 0.225)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
09 Nov 2005
(0.22 and up: Uses a different RAM byte to avoid animation conflicts)
(0.225: Minor documentation fix; patch is identical to version 0.22)
|
From Master ZED's Bugs and Glitches Guide:
Some weapons, such as Atma Weapon, Drainer, and Fixed Dice, have special effects that tell
the game to treat them differently and to what extent (drain HP/MP, new damage formulas,
etc.). Capture negates a weapon's special effect to replace it with a steal attempt. This results in some weapons not functioning correctly.
See the Readme for a list of the weapons that lose functionality (there are 21 in all) and how they are affected.
With this patch, the Capture command marks its steal attempt in a new variable rather than
overwriting the original special effect variable. Thus, weapons will retain their special
functionality when used with Capture.
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
|
Mute steals Rage statuses fix
(Beta 0.21)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
25 Dec 2004
(Just a Readme update; patch is identical to version 0.20)
|
When a spell of nonzero original MP cost is attempted by a Muted character via the Rage command, the character wrongly won't gain statuses of the Raged monster. These monster statuses are of two types: removable (e.g. Dark, Poison, Clear) and permanent (e.g. Safe, Haste, Reflect). Application of the removable statuses is delayed until some entity next makes a working move (i.e. one that doesn't abort from Mute or Imp). An aborted spell thwarts the would-be permanent statuses, but only if it happens as the first turn of the Rage. In that case, the Rager is also locked out of those statuses for the remainder of the Rage because the game still gave him/her immunity to them in an attempt to make them unremovable.
A prime victim of the bug is a deliberately Muted Intangir Rager.
This fix separates the giving of the Raged monster's statuses from the actual Rage attack. Now you'll inherit them regardless of whether the attack aborts, just as already happens with the monster's other acquirable properties (such as elemental tolerances and status immunities). In the process, the patch also fixes some other Rage and status bugs, which are mainly just an issue with monster hacks (see the Readme for more info). This just in: On top of that, it fixes a bug where a Battle strike used as the first turn of a Brawler Rage won't get the Berserk damage boost (and a couple other similar problems; see the Readme for more info.)
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
|
Control attacks ignore MP cost fix
(Beta 0.20)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
11 Aug 2013
(Functionality unchanged from version 0.19, but meddles with less nearby functions to fit patch code)
|
Straight from Master ZED's Bugs and Glitches Guide:
Control attacks ignore MP cost in use -
Whenever you use an attack with a MP cost via a Controlled monster, the game will ignore the
cost entirely, not taking it from the Controller or the monster. The menu doesn't do the
same, however, though it's kinda slow at actually noticing a change in MP under certain
circumstances (see Control menu responds poorly to MP change under 2. In battle -
Miscellaneous).
The Control menu already disables access to any attacks which cost more than the monster's
remaining MP. That's a strong sign Square didn't want Control to render spells free.
This fix bills controlled monsters for the MP costs of spells they cast, since there's no
good reason hypnosis should provide infinite resources.
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Plus an anti-patch pair to remove prior versions of the patch. Also includes detailed disassemblies of Square's bad code and my fix.
|
That Damn Yellow Streak fix
(Beta 0.25)
|
FF3us: 1.0 and 1.1
|
26 Dec 2004
|
Straight from Master ZED's Bugs and Glitches Guide:
The red/yellow streak in Gogo's command options window -
There's a red/yellow streak in Gogo's command options window that shouldn't be
there. About the only thing I can elaborate on is the cause, which is that the
line comes from the very last line in Gogo's subscreen portrait. This portrait
is mysteriously reprinted behind the window, and the last line comes out from
behind the window due to a sprite priority bug.
Square put code in FF6j to deliberately give Background 2 tiles priority over the sprite in
the Status screen's right-hand command list, which is why you don't see any of the portrait
in that version, nor most of it in FF3us. The reason FF3us has a problem is that the
portrait was shifted down from FF6j; its bottom line entered another row of tiles, but the
code that modifies the tiles' priorities was never updated.
This fix makes the necessary adjustment to that code. Tada; no more accursed streak!
Comes with a patch and an anti-patch for FF3us (either version). Also includes detailed disassemblies of Square's bad code and my fix.
|
Auto-expiring statuses don't reset their timers with manual removal fix
(Beta 0.20)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
19 Feb 2005
|
Partial excerpt from Master ZED's Bugs and Glitches Guide:
Statuses such as Stop, Reflect, Sleep, and Freeze eventually wear off after
awhile unless, in the case of Reflect, they can become permanent. The game
does this through the use of individual timers for each status, for each
target. Stop makes all other timers, along with Regen, Poison, and Seizure,
halt execution for its duration since it is supposed to be a time freeze. The
bug here, however, is that if you remove the timed statuses with a spell such
as Dispel, the timers will not be reset and will still count down on their own,
not even checking to see if their respective status still exists. While this
doesn't affect anything with most of the statuses, Stop's superceding of Regen,
etc. and other timed status can cause problems such as prolonging timed status
and [temporarily] keeping Regen and co. from doing any HP healing/damage.
[Proper behavior doesn't resume until Stop's timer expires.]
This fix zeroes a status' auto-expiration timer *whenever* it's removed, meaning the timer
for any entity who doesn't have the status will now correctly be zero. As a result, the
game won't trick itself into partially thinking an absent status is still present.
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's lacking code and my fix.
|
Control menu responds poorly to MP change fix
(Beta 0.13)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
04 February 2012
(Finally resolves limitation present in Beta 0.10! Bounty has ended!)
|
Straight from Master ZED's Bugs and Glitches Guide:
Control menu responds poorly to MP change -
This bug deals with the fact that Control takes a turn, two at most, to notice a change in a monster's MP rating. Once you have Controlled a monster, wait for the Controller's gauge to fill up, then try something like zeroing the monster's MP. Take a look at the menu, and you'll see that all MP-dependent attacks are still available. Not only that, you can still use them for one turn since attacks initiated from the Control menu ignore MP cost in practice. This also works in reverse; for example, Control a Sprinter after you have zeroed its MP. Now use its Special (Drainbeak) to replenish 20+ MP. On the Controller's next turn, Cyclonic, the only MP-dependent attack in Sprinter's Control menu, will still not be available even though it gained sufficent MP from the previous turn.
With this fix, Control menus are updated more often, and will correctly reflect their
associated monsters' current MP. To be specific, the same types of cases that make the game re-determine availability of spells on Esper, Magic, and Lore menus for a character will now make the Control menu regenerate for a monster.
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's lacking code and my fix.
|
Jump Megafix
(Beta 0.15)
|
FF3us: 1.0 and 1.1
FF6j 1.0
RPGOne 1.2
|
05 Sep 2005
|
There are five bugs involving Jump here, a couple specific to Ogre Nix (italicized portions courtesy of Master ZED's Bugs and Glitches Guide):
BUG #1:
Jump doesn't reload command, attack, or weapon data -
Palidor-induced jumps and Jump itself have a tendency to not reload any
command, attack, or weapon data between Dragon Horn combination strikes,
causing all of the strikes to, if they have special effects that are supposed
to randomly kick in, be the same once that effect is loaded. ThiefKnife,
Ogre Nix, Tempest, and (in FF6j/FFA only) the X-type/Dice-up instant death
weapons are all affected. Some even experience disappearance bugs. I've
used enough space here, so see this bug in Section 0 of the Readme for how
the weapons are affected.
------------------------------------
BUG #2 and 3, respectively:
Jump only uses one weapon of a dual weapon wielder... or so it seems! -
If you use Jump with two weapons, the command will pick one of the two weapons
and use it. However, no matter which hand it picks, it always uses the right
hand weapon graphic. Also, if either weapon is a spear, it will give a 2X
damage multiplier disregarding which weapon is actually used.
------------------------------------
BUG #4:
Prophetic Jump predicts broken Ogre Nix -
Normally, when Ogre Nix breaks, you still get a sword strike, then see the
message "Ogre Nix was broken!" afterward. With Jump and Palidor attacks,
however, the character will come down weaponless, then you will get the message
that the sword was broken. This is weird since it appears as though the weapon
shattered before it ever hit anything.
------------------------------------
BUG #5:
Riskless Ogre Nix - If the Ogre Nix special effect decides to break the weapon, it only follows through with the breakage if it finds Ogre Nix in the attacking hand. Unfortunately, it uses the number of strikes remaining in the turn to detect which hand that is. This method works just fine for Fight and Capture (for reasons I won't get into here), but does not for Jump. An easy way to see the effects: put Ogre Nix in a character's right hand, give him/her DragoonBoots but no Dragon Horn, and Jump as much as you'd like. The thing will never break because the Ogre Nix code wrongly checks the *left* hand with this setup.
------------------------------------
This patch fixes all those bugs. If you're interested in how it does that or more info on the bugs themselves, consult the Readme, particularly Sections 0 and 6 (and Sections 1-5 if you crave uber detail).
There are two types of the patch: one randomizes the attacking hand once per pounce, and the other randomizes it once per Jump turn. For each type, there are four pairs (!!) of patches and anti-patches enclosed: one for FF3us 1.0, one for FF3us 1.1, one for FF6j, and one for RPGOne's FF6 translation. Also includes detailed disassemblies of Square's bad code and my fixes.
NOTE: This patch uses free space that was consumed by older versions of Drakkhen's Ignore Defense patch. Thus, I recommend using at least v1.10 of his patch: http://www.angelfire.com/un/drakkhen/index.html
Known patch flaw: If you equip Genji Glove, (Fixed) Dice in the left hand, and some other weapon in the right hand, and do a Jump attack that uses the Dice, the animation will always show whatever's in the right hand instead. (What it should show is a bare hand, as that's how the vanilla game illustrates Jump+Dice.) One day, I'll remedy this.
|
Throw down (part of) the Gauntlet fix
(Version 0.201)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
24 March 2012
(Just a tiny Readme update; patch is identical to initial version 0.20)
|
When you equip Gauntlet with a compatible weapon, your Battle Power displayed on the Equip/Relic/Status menu doubles. This is quite misleading, as when calculating physical damage in battle, the game uses 7/4 of your normal Battle Power in part of the formula, and the normal amount in another part. So the attacker's effective Battle Power is somewhere between 1x and (7/4)x normal, depending on their level.
There are two types of patches distributed here. One will always display 1.75 times your original Battle Power when combining Gauntlet with an eligible weapon. The other displays Battle Power multiplied by an amount ranging from 1.0 to 1.75, depending on your level.
For each type, there are two pairs of patches and anti-patches enclosed: one for FF3us (either version), and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fixes.
|
Cave to the Sealed Gate
Basement 3 Event Megafix
(Version 0.15)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
20 July 2012
|
There are a number of event bugs in the third basement in the Cave to the Sealed Gate, most of them in the latter portion, and most of them related to the use of switches.
There is a chest with a 2-way switch inside near the end of the cave. Flicking it breaks some of
a bridge to the right, preventing you from progressing further (Japanese humor?). Flicking
it again restores the bridge piece. However, there are three bugs that will cause the bridge piece to not disappear like it should or to wrongly reappear, when the switch is in the "on" position.
There is an island with a chest containing Genji Glove, that has two bridges connecting to it (one is well-known, the other not). There are two bugs on return from menu/battle which can cause one bridge to disappear when it shouldn't, and the other to wrongly reappear.
There are also five graphical bugs involving: the chest with the switch appearing closed when it's open, the skull switch on the left moving island not having its "mouth" open (2), the lava above the right moving island getting some duplicate tiles, and the skull switch above the high breaking bridge not staying open graphically.
This patch fixes those ten event bugs.
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fixes.
|
Premature Continuation fix
(Version 0.20)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
31 July 2012
|
Statuses such as Stop, Reflect, Sleep, Freeze, and Condemned eventually wear off after awhile unless, in the case of Reflect, they can become permanent. The game handles the expiration through the use of individual timers for each status, for each target. Since Stop is supposed to be a time freeze, all other timers, along with Regen, Poison, Seizure, Phantasm's HP Leak, and Draining a Seized target, and checks for whether a character is trying to run, halt execution for its timer's duration. After Stop's timer expires and Stop is removed, the applicable other timers, periodic damage/healing, and run checks will resume. The bug here is that the invisible Reflect, Sleep, and Freeze timers are resumed ON Stop's final tick rather than afterwards, so they get a premature start of about: 2 seconds normally, 4 seconds if the entity's Slowed, or 1.5 seconds if it's Hasted.
(Italicized portions mostly courtesy of Master ZED's Bugs and Glitches Guide, for another bug.)
This patch fixes things by making the Reflect, Sleep, and Freeze timers wait until the tick
*after* Stop's timer runs down to continue, thus behaving as Condemned, the periodic
damage/healing, and the run check already do.
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
|
Some MP changes don't update menus fix
(Version 0.20)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
16 August 2012
|
There are two bugs here with the same cause, but opposite effects.
1) From Novalia Spirit's "100+ bugs" thread description:
Magic menu doesn't get refreshed through MP-costing weapons -
Have a character waste all of his MP through Illumina, Ragnarok, Punisher, [Rune Edge], or Ogre Nix (they use MP to inflict critical hits), and then access the Magic menu immediately after: even though he should lack the MP to cast many of his spells, these [won't] have been greyed out.
To be sure, the wrongly lit-up spells still won't be castable if selected.
2) Deplete a character's MP (e.g. by Rasping it) to where some of his or her spells are unaffordable. Then have Strago or Gogo use Pep Up on him/her, or cast Sleep on him/her, use the Love Sonata Dance, and hope it chooses Tapir. When you enter the healed character's Magic menu shortly afterwards, some spells will be grayed out despite the character having full MP. The wrongly grayed spells won't be castable, unless the character is acting automatically (e.g. they're Muddled).
For both varieties of the bug, you can knock the affected character's menu back into the present by using a traditional MP damaging or healing move on them (Tincture, Rasp, etc.), by Imping/un-Imping them, or by having them cast an available spell.
This patch keeps menus up-to-date by making the aforementioned weapons, Tapir, and Pep Up
set a flag for the entity whose MP they are altering. This flag causes the availability
of contents of the entity's Esper, Magic, and Lore menus to be re-examined at the end of a
turn, and is already set for any other action that can affect MP.
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's lacking code and my fixes.
|
Doom Darts and Trump name fix
(Version 0.30)
|
FF3us: 1.0 and 1.1
|
5 September 2012
|
In FF3us, Square got the names switched for Doom Darts and Trump. "Doom Darts" has thrown playing cards as an animation, and randomly casts Doom after attacking in battle. "Trump" has thrown darts as an animation, and randomly insta-kills with a red "X" instead of doing damage in battle.
_Final Fantasy Anthology_ for Playstation calls these card and dart weapons "Trump" and "Doom Darts", respectively, while _Final Fantasy VI Advance_ calls them "Death Tarot" and "Viper Darts", and RPGOne's translation (based on FF6j SFC) calls them "Death Card" and "Intense Darts". So the problem is FF3us-specific.
I am providing three patches (along with anti-patches) which remedy the name problem in the
way that Anthology, Advance, or RPGOne did. One reason for all the options is that having a
weapon named "Doom Darts" when the darts don't cast the "Doom" spell is a bit misleading.
For another FF3us option that was first made a few years before these patches, try darkmage's FF6 Improvement, which has the darts as "Doom Darts" and the cards as "Trump Cards".
|
Ironic Metamorph Pack fix
(Version 0.30)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
12 September 2012
|
Ragnarok's Metamorph, when successful, will turn an enemy into an item. Each monster has a Metamorph pack assigned to it, which holds the four possible items into which the enemy can be transformed. There are 26+ packs, and many of them have themes, particularly these four:
| Group # |
Items |
| 4 |
MithrilBlade, Mithril Helm, Mithril Mail, Heavy Shld |
| 5 |
Gold Lance, Gold Shld, Gold Helmet, Gold Armor |
| 6 |
Crystal, Crystal Shld, Crystal Helm, Crystal Mail |
| 7 |
Imp's Armor, Titanium, TortoiseShld, Imp Halberd |
Either somebody was trying to be funny, or this is tied to Heavy Shld's Item ID being just
one less than Mithril Shld's.
This patch fixes the problem by changing the Heavy Shld in Morph Set #4 to a Mithril Shld.
Comes with one patch and an anti-patch that work with either version of FF3us and with FF6j.
|
Suplex wrongfully splits damage fix
(Version 0.30)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
14 September 2012
|
Suplex starts off as a multi-target attack, so as to allow the normal game mechanics to choose a list of valid potential targets. Then its first special effect will choose one target from this list at random, favoring those which aren't a non-Suplexable monster (unless there are no other choices). However, the code which splits damage in two for multi-target attacks is executed before Suplex's special effects, which means this Blitz will have its damage halved when multiple valid targets are present, even though the attack ultimately goes after only one of them.
It's hard to believe that this was intentional, given that this fact and Suplex being unable to hit about 40% of enemies make it generally inferior to Pummel, despite being learnt multiple levels later.
This fix stops Suplex's damage from being halved by giving it the "No split damage" attribute, which a number of other multi-target attacks already have.
Comes with one patch and an anti-patch that work with either version of FF3us and with FF6j.
|
Step Mine MP cost fix
(Version 0.20)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
20 September 2012
|
Adapted from mblock129's description:
At the start of battle, when generating the Lore menu, the game gets Step Mine's MP cost from a special formula: Total minutes played DIV 30. However, the necessary Hours and Minutes aren't read from the original time played variables, but from variables which are set when you're on the main menu, and which respectively equal the XX and YY in the time (XX:YY) displayed there. This has two consequences.
Because the time variables used are updated when you last visited the subscreen, but the damage is based on actual step count, you can build up Step Mine's power without increasing its MP cost if you walk around without visiting the menu. This is useful for normal, untimed areas.
In a timed area (like the escape from the Floating Continent or the house in Tzen), (XX:YY) is not the total time elapsed (HH:MM), but the time remaining (MM:SS), making Step Mine's cost the total seconds remaining DIV 30. This can be rather puny -- even zero, if you wait until there are 29 seconds left, go to the main menu, then get in a fight.
This patch fixes both issues by making Step Mine's cost be based directly on the original time elapsed variables, which are current and not repurposed for timed areas.
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
|
Miscolored command names fix
(Version 0.20)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
28 September 2012
|
The long list of commands on the right-hand side of Gogo's Status screen often lies about their availability. For instance, it might wrongly have SwdTech lit up even if you lack a sword, or Runic darkened even if you hold a bladed weapon. The cause is that the list is generated when you enter anybody's Status screen from the main menu, before anybody's equipment data is read; thus, it'll be based on the equipment data for whichever character whose Equip/Relic/Status menu you visited most recently.*
An easy way to get an accurate view is to enter Gogo's Status screen, exit to the main menu, and enter it again.
SwdTech and Runic are the only commands that can be grayed on menus outside of battle, so they're the only ones affected by this bug (and Sketch if you're using my "Brushless Sketch" patch).
I made patches employing two different solutions to the miscoloring. One uses Gogo's equipment data when generating the long list. The other keeps it all white, supportable by every command on the list already being selectable regardless of color. For each type of the patch, there are two pairs of patches and anti-patches enclosed: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fixes.
* If you haven't been in anyone's menu recently, it gets more complicated; see the Readme.
NOTE: If you're using the all-white commands version of the patch, and Version 0.16 or earlier of my "Brushless Sketch" patch, be sure to apply Brushless Sketch first.
|
Incoherent Gungho dialogue fix
(Version 0.30)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
7 October 2012
|
When first meeting Gungho in Thamasa in the WoB, there are two conversations that can take place: one without Strago in your party, and one with. There's a line of dialogue from Gungho in both versions where he addresses Strago in
the second person, that doesn't make sense when Strago's absent. There's also a seemingly extra line of dialogue in the Strago-present version, where Gungho inexplicably speaks of him in the third person. See the Readme for both conversations.
This patch fixes the incoherency by moving one line from the with-Strago conversation to replace another in the sans-Strago one. Now both chats make far more sense.
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's goofy code and my fix.
|
Running Popsicle / Lead-footed Esper fix
(Version 0.30)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
12 October 2012
|
When you try to run in battle, a Morphed Terra isn't illustrated as running, even though she's fully capable of doing so (and will briefly be shown striding when she finally escapes). Meanwhile, a Frozen character will be given a running animation, even though they're unable to flee.
This purely graphical bug happens because when the game prevents Zombied, Petrified, Wounded, Sleeping, and Stopped characters from getting a run animation, it oddly counts Morphed characters as among those ineligible, but not Frozen ones.
This patch fixes the problem by changing one byte to check for Freeze status instead of Morph.
Comes with three pairs of patches and anti-patches: one for FF3us 1.0, one for FF3us 1.1, and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
|
Bottomless HP and MP Well fix
(Version 0.22)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
6 November 2012
(Uses a different free space area than version 0.20)
|
From Novalia Spirit's "100+ bugs" thread description:
Absorbing HP/MP from invincible enemies -
As you face invincible Guardian or invincible Phunbaba, have your characters use Osmose or Drain or have them attack with a Drainer or a Soul Sabre: it'll deal 0 points of damage, yet the characters' HP/MP will get healed for an amount that won't equal 0.
The game has a check to zero out damage done to invincible targets, but there is no invincibility check in an earlier function that determines what the drainage amount will be.
This patch adds the needed check.
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
NOTE: The first release of this patch had free space usage conflicting with that of Drakkhen's "Ignore Defense Patch 2", so be sure to get Version 0.22 if you're also using his patch.
|
Reflect barrier shown on bodyguards fix
(Version 0.20)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
28 October 2012
|
If a Love Tokened or True Knight-wearing entity blocks a Scimitar or "X"-kill weapon attack, and the weapon activates its instant kill, the green barrier animation that's used when a spell is reflected will play out next to the blocker (as well as any attempted blockers). Also, the red "X" insta-kill animation is skipped. The cause of the bug is an uncleared variable with multiple meanings.
When a spell is reflected off of a target, the game marks the target in a variable to tell the Magic animation to display a green barrier in front of them. True Knight and Love Token mark candidate bodyguards in the same variable, to have them jump in front of an entity in the Battle animation. The problem is that Scimitar and the X-kill weapons add on a Magic animation when
doing their insta-kills, and since the variable is still set from the bodyguarding, the barrier shows up.
The solution, employed by this patch, is to have the weapon special effect clear the variable before writing the Magic command data to the animation buffer.
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
|
Flaky True Knight protection fix
(Version 0.20)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
13 November 2012
|
Adapted from Novalia Spirit's "100+ bugs" thread (direct quotes are italicized):
Characters acting as enemies are treated like normal characters when it comes to True Knight, so they can both protect a vulnerable target or receive protection when weak. Examples are Gau returning from a Veldt leap, Imperial Base Kefka, Sealed Gate Kefka, and Colosseum Shadow (if you manage to trick him into attacking himself). Note that characters acting as enemies require a multistrike attack (Genji Glove, no Offering) to receive protection, due to battles ending after they're attacked once (the Sealed Gate Kefka battle should go until he has no HP left, but doesn't due to a certain bug).
This patch fixes True Knight's behavior by factoring in the "Characters acting as enemies" variable when determining potential bodyguards.
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
|
Equip wrong item to slot via event fix
(Version 0.20)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
6 December 2012
|
On rare occasion, Terra and/or Edgar will have nonsensical equipment on their head or body when being re-recruited in the WoR. It'll be gear the character can normally equip, but it'll be in the wrong slot (e.g. a weapon as a helmet).
The game's event script calls a menu subroutine to Optimize Terra's equipment right before the first Phunbaba battle, and Edgar's right before the Tentacles battle. This routine sets a variable to indicate to a helper function which equipment slot (0 = right hand, 1 = left hand, 2 = head, or 3 = body) is currently being looked at, so it can generate an appropriate list of candidate equipment. However, if a Non Maskable Interrupt occurs at an inopportune time, it'll overwrite this variable with junk (generally zero) before it can be read.
This patch fixes things by rewriting the Optimum routine to no longer rely on this variable.
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's susceptible code and my fix.
Also recommended: Equip Anything fix
|
Reflectable Magitek Beams fix
(Version 0.30)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
13 December 2012
|
Adapted from Fenrir9's description (italics are direct quotes):
The programmers forgot to flag Fire, Bolt, and Ice Beams as Not Reflectable. The bug results in minor graphical glitches when the beams' graphics appear on certain battle backgrounds. Also, there is no green reflection graphic on the targeted monster, implying the beams were not intended to be reflectable, and the character in the first slot is always the one shown using the beam blast, regardless of who the actual attacker was. Most notable is a displacement in the attacker that lasts until the end of the battle. He or she steps forward for the beam attack, but doesn't step back afterwards, and the bug can be performed multiple times [to] make the character move closer to the monster(s).
This patch fixes things by giving Fire, Bolt, and Ice Beams the Not Reflectable property. This now matches the other five character Magitek attacks, as well as any other machine-fired laser/ray/missile/etc.
Comes with one patch and an anti-patch that work with either version of FF3us and with FF6j.
|
Unaffected Rows fix
(Version 0.20)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
25 December 2012
|
At the start of battle, the game will choose your encounter formation (i.e. Front, Back, Pincer, Side). Then it will flip your characters' rows if you're in a Back attack, or make them all front row if you're in a Pincer.
The problem is, when encounter formations are changed due to a monster formation switch, the function responsible for the actual row-altering is skipped. After defeating the first SrBehemoth formation, a second one attacks from behind, and all of the characters run an equal distance to the left. Visually, this flips their rows, but because of the bug, the characters' mechanical rows (i.e. what affects physical damage taken and given) are unchanged, and thus the opposite of their new depiction. Choosing "Row" for apparent back row characters will move them back further, and for apparent front row ones will move them up further; there are four rows (!!) visually speaking.
This fix updates the mechanical rows by calling the skipped function on formation switch. It also remedies a couple hacks-only issues, one related, and one involving start-up Condemned status (see Readme Section 1).
Comes with three pairs of patches and anti-patches: one for FF3us 1.0, one for FF3us 1.1, and one for FF6j. Also includes detailed disassemblies of Square's lacking code and my fix.
|
Randomosity monster encounter fix
(Version 0.20)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
31 December 2012
|
From Master ZED's description (direct quotes in italics):
Battles in FF6 have four formation types: Normal, Back, Pincer, and Side. The game chooses between these using a random number generator, but because of how the game initializes this particular RNG's index for combat, the game ends up excluding Back and Pincer attacks depending on certain other factors, such as the size of your party and the enemy's. The main cause of the bug is the game's initializing of the RNG index, which can go from 0 to 255, using the 1-60 frame counter * 4, before adding a number based on the party sizes. This frame reliance means that for any given size combination, roughly 3/4 of all possible [index] values are left out. Normal and Side attacks are negligibly affected due to their large probabilities, if they're affected at all, but because Back and Pincer attack probabilities are small as it is, they risk being completely lost in the shuffle.
Chances for preemptive attacks, evaluated next, also get distorted, but nothing drastic like excluding them.
This patch fixes things by adding a 0-255 frame counter (that still advances 60 times per second) to initialize the RNG table index at battle start. Probabilities for encounter types and preemptive attacks will now be more in-line with their intended chances, resolving the Back and Pincer exclusions.
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's lacking code and my fix.
Also recommended: Randomosity Documents
|
Slightly lagged battle event timer display fix
(Version 0.25)
|
FF3us: 1.0 and 1.1
FF6j 1.0
|
21 July 2013
|
Certain events (e.g. the Opera House) use a frame-based timer that counts down to impose a deadline on the party. It's converted into minutes and seconds for display on the main menu, on the map, and in battle. While the underlying count of frames remaining in the event is correct, the battle display conversion routine is called every 61 frames, as opposed to every 60 like it should be. This tinily slower display update isn't humanly noticeable. A more observable consequence is that after 61 real seconds in a battle (sometimes sooner), the timer display will decrement by 2 seconds on one of its ticks.
This patch fixes the in-battle timer display to update every 60 frames.
Comes with two pairs of patches and anti-patches: one for FF3us (either version) and one for FF6j. Also includes detailed disassemblies of Square's bad code and my fix.
|
