100+ bugs

[Assassin]

on the subject of nonsense status interaction with True Knight, since i don't know whether i've mentioned it outside of my "Disrespectful Zombie fix" Readme, here goes:

[WHAT ELSE THE PATCH ARGUABLY FIXES]

In the normal game, it's possible to end up with True Knight wearers protecting a statue for
a brief period of time. Knock Gau/Gogo into Near Fatal, then Rage an enemy who's immune to
it, so as to stick them in the status. Cast Break on your Rager, and you'll see they don't
immediately exit the crouch. This is because when Petrify is inflicted, it attempts the
removal of Near Fatal and Rage statuses, but doesn't succeed on the former because the
Rage's influence isn't completely gone yet. Only after Rage is unset and then "cleaned up"
will all its associated immunities be cleared (this happens instantaneously from the
player's perspective). When the next attack rolls around (regardless of whom it's against),
the statue will regain their upright posture (miraculous! it's a sign!!!!). In the
meanwhile, Near Fatal allows them to be guarded by characters with True Knight.

I don't need to argue why True Knight protecting a slab of rock is a flaw, because you have
common sense.

Note that I became aware of this issue (from ZED) in efforts to prevent a bug almost
introduced by my fix: True Knights would protect a Zombie who was stuck in Near Fatal by
Rage.

The game already stops True Knight from guarding Clear targets; this patch puts the
Petrified and Zombied in the same category.

[Novalia Spirit]

it was covered in Terii's/my disassembly; see Function C2/12C0.

I already did that. To be honest, I don't find the comment at C2/12E6 to be particularly explicit about this feature given how obscure it is, and the question mark at the end does suggest a certain degree of uncertainty from the author.

as for the 3000 GP, news to me.

hah, it does seem related. i get why it targets the same bodyguard, in light of #1. but what circumstances make it go after the original target?

It's purely random. The game stores both the original target and the bodyguard in $B8 at C2/58DA, and then picks one at random at C2/58F1.


That said, here are two additional bodyguard-related bugs I've found. The first one is a relatively common occurrence, and I've been aware of it for quite a long time. The second was discovered a few hours ago while I was trying to refresh my memory about the other bug. Both of these occurrences mainly stem from the fact that Love Token, unlike True Knight, doesn't preclude the attacker and the target from acting as bodyguards.

1. If an enemy casts Love Token on an ally, the victim will try to intercept its own attacks when targeting that enemy. When doing so, there's a pretty good chance that the weapon animation will be displayed far above the attacker, even moreso against large enemies such as Goddess.

2. If a character equipped with a True Knight casts Love Token on itself and is then targeted by a physical attack while in danger, it will take part in the C-shaped shield, and will attack from that location if it is the originator of the attack. If three other party members are equipped with said relic, instead of being a part of the aforementioned shield, the character with the highest entity index will be displayed at the default location for the original target (i.e., where the target normally appears when nothing is going on), which gives the impression that it's receiving protection from the other three members; curiously, this apparently won't happen if the caster is at the bottom of the party, but I'd need to make more tests to be certain about that. Note that the approach I took to meet the requirements for this bug (i.e., having a character cast Love Token on itself, while allowing all party members to remain valid candidates status-wise) was to select the Barb-e Rage with Gau or Gogo while an enemy was in the process of casting Charm on them.

[Assassin]

it was covered in Terii's/my disassembly; see Function C2/12C0.

I already did that. To be honest, I don't find the comment at C2/12E6 to be particularly explicit about this feature given how obscure it is, and the question mark at the end does suggest a certain degree of uncertainty from the author.

why i think it's reasonably clear:

- "make this potential guard jump in front of the target?" conveys that it doesn't have to be the final chosen guard doing the jumping.
- the function header is "(Consider candidate bodyguard for True Knight or Love Token)", giving us the context that this is being done with any candidate (who passes the status tests), not just the ultimate hit-taker.
- anybody who knows what a "TSB" does will realize it's additive, not a replacement.

that said, i will get rid of the question mark one of these days. .... or will i??

hah, it does seem related. i get why it targets the same bodyguard, in light of #1. but what circumstances make it go after the original target?

It's purely random. The game stores both the original target and the bodyguard in $B8 at C2/58DA, and then picks one at random at C2/58F1.

thanks; i'm following it now.

regarding the two more bugs: oh man. it seems obvious that they should not have let you Love Token yourself. as for #1, i'm not sure what the correct behavior would be.. having the attack abort, or just fixing the animation?

[Novalia Spirit]

Common sense would suggest that the attack should either abort or get redirected if possible, or otherwise ignore the bond that exists between both entities. However, I think that fixing the animation would be more in line with this game's design in general. And yeah, I agree that a self-targeted Love Token shouldn't be allowed to succeed, though a lot of people in real life do fall in love with themselves...

[Assassin]

2. If a character equipped with a True Knight casts Love Token on itself and is then targeted by a physical attack while in danger, it will take part in the C-shaped shield, and will attack from that location if it is the originator of the attack.

looking at the code tells me that True Knight isn't needed for this bug, though i haven't tested it.

[Assassin]

How does your new Blush Disease fix differ from mblock129's King of Vanity fix, aside from the GBA support?

[Novalia Spirit]

My patch fixes two bugs. The original idea was to address the second bug, which has been bothering me for nearly two decades. When I started working on the patch about three years ago, I incorrectly assumed that compatibility issues could only be avoided by releasing the patch as an addendum, so I studied the possibility of handling both bugs instead. All things considered, the decisive factor in the decision of releasing the patch as it stands was the fact that my approach doesn't consume any free space thanks to certain findings I've made, whereas King of Vanity puts a claim on 85 bytes of free space.

In a nutshell, my approach replaces the relevant palette through a single command, whereas mblock129's approach, if my interpretation is accurate, consists in modifying the colors one by one by increasing or decreasing the color components. We also assign a different palette number to Celes, but barring bugs and hacking, it shouldn't make any difference. We've both included the modified code with the release, so you can compare our approaches if you want.

By the way, technically there's also support for the Super Famicom version, for what it's worth.


On a completely unrelated note, I've been meaning to inform you of the following error concerning your patch description for the traitorous bodyguard bug whenever I'd finally end up posting in this topic again:

Examples are Gau returning from a Veldt leap, Imperial Base Kefka, and Sealed Gate Kefka. (Colosseum Shadow is not applicable because True Knight doesn't figure into one-on-one battles.)

True Knight only excludes the attacker and the target from acting as bodyguards; if Shadow is tricked into attacking himself, the challenger's True Knight functions may still activate.

[Assassin]

thanks. i'll get that next time i update patches.htm (dunno when i'll get around to the actual Readme file, as changing and reuploading that's more tedious). is it possible for Shadow to ever have True Knight then, or will he have no equipment or relics for that fight?

[Novalia Spirit]

Shadow has his equipment removed immediately before the floating continent begins to collapse, so excluding bugs (example), he should come naked for that battle.

[Assassin]

nothing outright new on this:
viewtopic.php?p=3872#p3872

but figured i'd consolidate my assessment, given my replies back then were strewn between like 6 posts on three pages. there are two mistakes the game makes:

1) if a weapon strike misses, its random spellcast for the next strike will be disabled. however, if the weapon strike finds no targets, the spellcast CAN occur.
2) like stated here: viewtopic.php?p=4649#p4649 , the game oddly sets "Can target dead/hidden targets" for weapon addition magic.

addressing either of these should eliminate the buggy behavior, but i'm inclined to say both should be done.

[Lenophis]

So I was checking one of the mechanics in trying to help someone out at SDA, and the question was about running away from battle. The code at C2/5C1B, C2/5C3A specifically, does not bother to check if you can actually run from battle before it adds to the overall running success. Once whatever is stopping you from running, you can run away immediately, provided you buffered up some "success" and spammed the "Can't run!" message a couple of times.

My proposed fix is to zero out $3D70,X if you can't run from this battle. This fix needs 10 bytes of free space, but so far I can only claim 1 byte from the JMP at C2/5C37.

Two things:
1) Is my proposed fix actually a fix? (I haven't tested this yet, been busy)
2) Is there any other code nearby that can be optimized so this can be squeezed in?

[Assassin]

the FAQ section of my "Running Popsicle / Lead-footed Esper fix" Readme gets into this some, as well as a related overflow bug. i don't come up with any fixes, but debate myself on how this issue is/isn't a bug.

[Assassin]

as for possible fixes.. for the overflow issue described in my Readme, you'd want to cap $3D70,X to 255 at C2/5C45.

for the larger issue of Run Success building up when it shouldn't, i'd favor skipping the incrementation if certain conditions are true (e.g. ailments on characters, pincer attacks, "Can't escape" monsters) over zeroing the variable. suppose you'd built up success before the restricting conditions were imposed; shouldn't that success be kept once the restrictions are lifted? or maybe it shouldn't.

which one is "right" depends on how you conceptually interpret the whole process of trying to flee from enemies. Djibriel's guide talks about enemies' "Run Difficulty" variables being "Pursuit". so it's like as the party runs (seemingly in place), they're gradually creating separation from the monster party, until they finally get far enough to escape. if a character in the party temporarily loses the ability to run, we know at the least that he/she should stop having her Run Success increase. should the value then stay put (easy, but iffy realism), should the enemy gradually decrease whatever separation had been created (complicated, but higher on realism), or should that separation be effectively eliminated instantly by zeroing Run Success (easy, but questionable realism)?

it's hard to say. i'm lacking in answers and abundant in questions here, because you really need to determine "what's going on here when i try to run?" before changing parts of the running implementation.

say you're holding L+R, building up run success. then you voluntarily stop running. maybe for as long as 1 minute. none of your Run Success will be thrown out, and if you start running again, you'll conveniently pick up where you left off. if enemies have the ability to pursue you, then such resumption seems like a generous oversimplification. do we consider such characters as better than ailing ones at maintaining distance from enemies, even though the former are just as stationary based on the game's crude animation system?

and because "Run Difficulty" is set outright, as opposed to continually being increased or continually being subtracted from Run Success, it's hard to say exactly how this "Pursuit" by enemies works. in theory, a Pursuit value would be subtracted from Run Success at regular intervals, thus representing the enemy closing any distance created by the party. if the party member can add to Run Success faster than it's decremented, the value would eventually meet some Run Threshold, allowing you to escape. but because "Run Difficulty" IS the threshold, maybe it has more to do with an enemy's "combat reach" than any following ability. or maybe it's how far an enemy can pursue you before they tire and/or give up?

eh, just brainstorming. i realize everything but the first line was woefully lacking in code.

[Assassin]

regarding this bug:

Toggling MP cost
Bug discovered by Novalia Spirit (Applies to SFC, SNES) (Images: 1, 2)
Pressing Y toggles the MP display of every spell in the magic menu. However, if the cursor is positioned on a spell that has not been fully learned yet, the value displayed in the upper portion of the screen will only be updated after a long delay, if ever.

i'm able to get something similar without using the Y button or requiring partially-learned spells. though it's not readily pulled off. while on one spell, hit the left or right arrow for only one frame to move to another. if it's an odd frame (i.e. in Snes9x 1.43 Geiger, have a breakpoint on C3/27ED, and 7E/021E loaded in the hex viewer.. when the frame shown is odd, click the "Run" button while briefly hitting an arrow), the top right MP cost will fail to update. none of the weird lag seen in the Y button bug. the description and the cursor update fine, so the game *does* mostly recognize the arrow as being pressed.

i was able to duplicate this "live" in Snes9x 1.39 on a few tries (of many) by hitting an arrow very gently and quickly, though i can't say whether it'll work on a console.

as for the cause of the Y button issue: i still don't quite know. Lenophis thinks it could be DMA-related, and that's the best theory i've seen. months ago, he observed that C3/51C6 was correctly detecting the "new" MP cost and outputting it to a display buffer, so the bug is later on in display.

if the first call to C3/27E2 after this function detects a Y button press is done on an even frame, i can reliably get the MP cost to transition from N to 0 and back without substantial lag. i did this with Snes9x Geiger, setting a breakpoint on C3/280F, then when that's hit, setting another on C3/27ED. i'd verify that the 7E/021E frame value was even before proceeding (modifying it in the hex viewer when needed). the initial Y toggle would have the MP cost change after a few frames, while the reversal would have it occur right after the spell description finished printing, a low 20s quantity of frames with the Remedy spell.

C3/0F75 (which is curiously only called from one place) must somehow be setting up a clobbering of the buffered top-right MP cost tiles.. but getting the tiles established first with C3/A991 must protect them. (i don't know what either function does, really.)

i can safely say that if this bug is ever fixed, the Work:Significance ratio will blow everything else out of the water.

[Lenophis]

I think the problem, at least partially, is that it appears both C3/0F75 and C3/A991 are setting up DMA with the same channel. When DMA is to happen, a series of routines starting at C3/1463 executes. In this case, C3/14AC executes.

Code: Select all

DMA routine 4
C3/14AC:   A41B       LDY $1B
C3/14AE:   F021       BEQ $14D1
C3/14B0:   8C1621     STY $2116
C3/14B3:   A901       LDA #$01
C3/14B5:   8D0043     STA $4300      (set transfer method to...?)
C3/14B8:   A918       LDA #$18
C3/14BA:   8D0143     STA $4301      (register address becomes $2118)
C3/14BD:   A41D       LDY $1D
C3/14BF:   8C0243     STY $4302      (starting location)
C3/14C2:   A51F       LDA $1F
C3/14C4:   8D0443     STA $4304      (starting bank)
C3/14C7:   A419       LDY $19
C3/14C9:   8C0543     STY $4305      (amount to transfer)
C3/14CC:   A901       LDA #$01
C3/14CE:   8D0B42     STA $420B      (turn on channel 0 of DMA)
C3/14D1:   60         RTS

So C3/0F75 moves 0x800 bytes from 7E/8049 (tilemap, IIRC) to $2116 which at this point I should know what this register does. Likewise, C3/A991 moves 0x700 bytes from 7E/A271 to $2116. Curious, C3/A991 also turns off bit 0 of $45, and as far as I can tell, that's only checked for at C3/14D2 which sets up a palette transfer. Perhaps Square set up C3/A991 incorrectly?

[Novalia Spirit]

i'm able to get something similar without using the Y button or requiring partially-learned spells. though it's not readily pulled off. while on one spell, hit the left or right arrow for only one frame to move to another. if it's an odd frame (i.e. in Snes9x 1.43 Geiger, have a breakpoint on C3/27ED, and 7E/021E loaded in the hex viewer.. when the frame shown is odd, click the "Run" button while briefly hitting an arrow), the top right MP cost will fail to update. none of the weird lag seen in the Y button bug. the description and the cursor update fine, so the game *does* mostly recognize the arrow as being pressed.

i was able to duplicate this "live" in Snes9x 1.39 on a few tries (of many) by hitting an arrow very gently and quickly, though i can't say whether it'll work on a console.

Nice finding. I managed to replicate this myself with relative ease by creating a savestate while the cursor was on a spell that was immediately above a blank entry; what I did was to simply hold the down arrow, and then release it a fraction of a second after reloading my savestate. For whatever reason, this bug seems to be more cooperative with blank entries.

As for the cause of the bug, I tried to figure it out somewhere near the beginning of the year (edit: actually, based on file dates, it was nearly a year ago...), and this is what I found:
1. The call to C3/0F75 seemingly updates the MP cost by refreshing the tile numbers in VRAM. To provide some evidence, the MP cost's tens digit is located at 7E/81BF, which is part of the transferred data.
2. The other frame-dependent subroutine seems to update BG3 tile graphics in VRAM.
3. The DMA setup created by the first call can get overwritten via a call to the second function at C3/A888, thus preventing its execution. This always seems to be the case when the cost fails to be updated.
4. The bug is not limited to the magic menu, as the relic menu is also affected (see the code at C3/9E14, it's pretty similar). This specifically affects the colored numbers when browsing equipment, notably after quickly alternating between two pieces of equipment. The equip menu is unaffected because it will never print a description for the item being examined.

[Assassin]

good info, both of you.

if the first call to C3/27E2 after this function detects a Y button press is done on an even frame, i can reliably get the MP cost to transition from N to 0 and back without substantial lag. i did this with Snes9x Geiger, setting a breakpoint on C3/280F, then when that's hit, setting another on C3/27ED. i'd verify that the 7E/021E frame value was even before proceeding (modifying it in the hex viewer when needed). the initial Y toggle would have the MP cost change after a few frames, while the reversal would have it occur right after the spell description finished printing, a low 20s quantity of frames with the Remedy spell.

C3/0F75 (which is curiously only called from one place) must somehow be setting up a clobbering of the buffered top-right MP cost tiles.. but getting the tiles established first with C3/A991 must protect them. (i don't know what either function does, really.)

ok. i made a patch to have C3/27E2 pretend the frame count was even, if a Y button press was detected on the previous call to the function. strangely, that wasn't enough; i have to actually *make* the frame count variable even (like i did in my tests, and something a real bugfix would never do). so that means that something after the initial 0F75/A991 choice is dependent on the frame. i'm not seeing C3/9E17 run while in this menu, so it's probably the next call to C3/27E2. iow: after pressing Y, this function needs to call C3/A991 on the next frame, AND C3/0F75 on the frame after that.

what i'm still not getting is why a thwarted display update isn't consistently remedied within the next few frames. after all, each of these functions is being called 30 times a second. as long as the detected MP cost is Z, shouldn't they have an opportunity to put Z in the top right? it's like they're doing a "diff" somewhere, and saying, "the video buffer hasn't changed since last time, so there's no point in retransferring it to video memory".

why am i getting the impression that it'd be easier to make the MP Cost part of the damn VWF, and display it that way? (not an option on the Relic menu, i realize.)

speaking of Variable $45, what does Bit 4 do?

--------------------

EDIT: to be complete, i got the arrow form of the bug with very brief taps of the L or R buttons.

regarding commonality in the bug variants, i wonder if Y is considered as only being pressed for one frame (regardless of how long you hold it), because unlike the arrows and the shoulder buttons, it doesn't "repeat" when held down?

[Assassin]

Lenophis: http://bin.smwcentral.net/u/4842/regs.txt

(it's also on RHDN, where you'll need a text viewer other than Notepad.)

[Novalia Spirit]

regarding commonality in the bug variants, i wonder if Y is considered as only being pressed for one frame (regardless of how long you hold it), because unlike the arrows and the shoulder buttons, it doesn't "repeat" when held down?

Variables $08 and $09 are variants of joypad 1 status that disallow autofire on a normal controller. So yeah, it's set only on the first frame when held down.

[Assassin]

3. The DMA setup created by the first call can get overwritten via a call to the second function at C3/A888, thus preventing its execution. This always seems to be the case when the cost fails to be updated.

okay. in reaction to hitting a relevant button, C3/A888 can be skipped for a frame *. if this skippage directly follows a C3/27ED ==> C3/0F75 call, then that's good. but if it directly follows a C3/27ED ==> C3/A991 call, then tough luck.

i had noticed when moving with the arrows that the displayed cost would update right away, or not at all. it didn't seem to have the lag issue present with the Y button. i spoke too soon. there are two "events" that can make C3/A888 be skipped: the button press, and the completion of the spell description's output. if the MP cost display gets thwarted on the former, it can still be displayed on the latter. whether it is depends on the number of characters in the description (as one is output per frame), as that affects how the second skippage lines up. i had luck getting lagged update moving right from Ice to Bolt, with the second spell having a description of 26 characters. in contrast, a crapload of tests with odd-sized descriptions didn't let me pull this off.

as for why the Y button behaves differently.. i think it's because its pressing isn't reacted to until the end of Function C3/27E2, and requires said function to be called *again* a frame later to update the top right cost via C3/51C6. so we'll have a case of:
- Y button pressed, C3/27E2 detects, and overwrites spell menu.
- C3/14C7 does DMA transfer.
- C3/27E2 is called again next frame, and calls one of the DMA setup functions.
- same frame, C3/27E2 calls C3/51C6 to update cost in upper right video buffer.
- C3/14C7 does DMA transfer.

there are C3/A888 executions in there as well, along with skipping it once (i forget when). but i'm thinking that the button-induced skippage (unlike the description-completion skippage) happens too early relative to C3/51C6's running for it to be taken advantage of.

however, the button skippage WILL have the prior information buffered by C3/51C6 available. that probably explains the lag+flicker that's seen with the Y-button variety of the bug. namely, say you've hit the Y button, and the cost display doesn't update. then you hit the Y button again, the cost display updates to what the old value should have been, and then a fraction of a second later (when the normal or null spell description completes), it updates to the new value.

* maybe more if holding down an arrow or shoulder button. i have yet to test.

EDIT: ok, this post still doesn't explain the cases of big, ~3/4 of a second from button press lag. but it's made sense of some things.

EDIT2: ok, that longer lag seems to equal, in frames: (time from button press until description completes; i.e. normal lag) + # of characters in description + 2. is the game secretly printing the description twice?