100+ bugs

[Assassin]

hah, there's yet another small graphical glitch with that area of the Sealed Gate Cave. there are the two moving islands, each with a skull switch. the right island correctly has its skull switch face change (shut or open), depending on what position you have the switch in. however, the left island's skull switch graphic ignores flips of the switch. that should be easily fixable by changing CB/33DC to 8Ah.

also, this switch's graphic gets redrawn as open (in the process of redrawing its whole island) when flicking the right island's switch in either direction, which i believe is a safe assumption. however, CB/32A9, which is called when exiting menu/battle, will always draw the left switch as closed. that can't be assumed. the fix for this would be more complicated, and probably take extra space. EDIT: nevermind, it should also be simple: change CB/32AE to 8Ah.

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

i've assumed for years that Square having the bridge to the Magicite chest disappear from hitting the chest switch was some sort of silly gag. but given their incompetence with coding the events in this area, i'm wondering whether they weren't intending to make the Magicite chest start off unreachable, and you need to flick the chest switch to ACCESS it. it seems like a lot of effort to have all these switches and the left island's movability just there for a gag. then again, there's an earlier switch that does two things:
1) creates a stairway leading to chest switch.
2) breaks bridge leading to chest switch, making stairway pointless.

so they were clearly fucking with the player.

[Assassin]

more complications with the bridge piece that's supposed to disappear: the original map actually has bridge pieces at two layers (though with flipped appearances). so when you flick the chest switch to break the bridge (i.e. replace the bridge piece with lava), one of them disappears, but the other is still there (and for whatever reason, takes precedence over the 11h lava tile, even though it didn't take precedence over the ABh bridge tile). that is, unless you've also moved the right island, which somehow clobbers the piece on the second layer, allowing what's on the first layer to dominate.

so i'll have to use a map editor as part of this bugfix, in addition to the event code changes. hopefully, it'll allow me to easily access the second layer so i can replace the tile.

seriously, whoever put together the rightmost one-third of this dungeon floor was on crack.

EDIT: n/m, i can do it all with event code. the Event Commands document on Imzogelmo's site tells how to target a different layer. the map editors are nice, but to change just one tile on the map, one modifies ~5500 ROM bytes, and the other modifies ~250000. this is due to compression of the data.

[Assassin]

i never knew this was possible:



until studying the event code. and it takes a few steps to achieve. also, there's a bug that can make the smaller right bridge disappear until you exit the map (e.g. go in a treasure room).

i'm being deliberately vague on these for now, because i wanna see if anybody else can figure them out.

[Lenophis]

Wait, the longer bridge actually extends?

[Novalia Spirit]

Pretty cool, I definitely wasn't aware of that myself, and the repeated sound effect certainly took me by surprise, as it's fairly atypical for this game.

also, there's a bug that can make the smaller right bridge disappear until you exit the map (e.g. go in a treasure room).

It's interesting to note that it allows the party to stand directly on the lava if positioned on the bridge immediately before its disappearance. Also, it seems like the longer bridge, once destroyed, will reappear following a battle or menu access, which alleviates that issue to a degree.

With regard to your previous post:

EDIT: n/m, i can do it all with event code. the Event Commands document on Imzogelmo's site tells how to target a different layer. the map editors are nice, but to change just one tile on the map, one modifies ~5500 ROM bytes, and the other modifies ~250000. this is due to compression of the data.

Note that the event disassembler fails to read the bits that determine the affected layer for certain commands. For example, the code at CA/ED09 claims that the first layer is being modified, but in reality, the command affects the second layer, as evidenced by the Y position, which matches that of CA/ECF8 by deducting $40. Also, the chunk sizes are listed in the opposite order; for instance, a 4 x 3 chunk's real size is 3 x 4. As a consequence of that, the format in which the tile numbers are listed is also incorrect.

[Assassin]

Pretty cool, I certainly wasn't aware of that myself.

also, there's a bug that can make the smaller right bridge disappear until you exit the map (e.g. go in a treasure room).

It's interesting to note that it allows the party to stand directly on the lava if positioned on the bridge before it disappears.

hah, i shouldn't be surprised that you found another feet scalding opportunity, given your work in the shifting bridges room.

Also, it seems like the longer bridge, once destroyed, will reappear following a battle or menu access.

oh man, they were all sorts of flaky here. obviously, i know that menu/battle willy nilly changing these things is wrong, but i don't know how a fix SHOULD look. my bugfixes in the later part of the basement are easy enough because they address dungeon elements that are controlled by a switch that toggles ONE event bit. so it's easy to engage in binary thinking, and make the dungeon element adhere to the current state (which is one of two possible) of the switch upon menu/battle return.

here, we have the "Heard a distant sound..." skull switch turning on TWO event bits together, which can then manipulated separately by stepping on the two invisible switches. and given that stepping on the left invisible switch initially shakes the screen and "removes" bridge which isn't even there yet, and stepping on this switch is a prerequisite to even creating the long left bridge with the righthand invisible switch, i really really don't know what the hell Square was going for here.

i suppose i could sidestep these questions, and just make a fix that ensures menu/battle return adheres to whatever was on the screen beforehand. it looks like that would involve dropping the $1EBF, bit 1 test from CB/2E47, and instead adding it to CB/2E3D.

but a question is raised: is CB/2ECE ever called, and what was Square's intent with it? it seems to be destroying the small right bridge, but is dummied afaik.

for that matter, is CB/36D5 ever called? i'm assuming not, and surrounding functions seem to fulfill any purpose it would've served. and what calls CB/3DCB? i can swear i've seen the dialogue before.

Note that some event commands fail to read the bit that determines the affected layer, so they'll always pretend to be targeting the first layer.

you mean some event command disassemblers fail to read the bit that determines the affected layer, right?

For example, at CA/ED09, the code indicates that the first layer is being modified, but in reality, this command affects the second layer, as evidenced by the Y position, which should match that of CA/ECF8. Also, the chunk sizes are listed in the opposite order. For instance, a 4 x 3 chunk's real size is 3 x 4. Consequently, the format in which the tile numbers are listed is also incorrect.

i was aware of both of these issues, but thanks for the heads up. the layer deal has been addressed in my commented code. i'll probably invert the chunk dimensions, though i might not muster up the effort to reformat the data lines (e.g. 4 lines of 3 tiles, instead of 3 lines of 4).

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

EDIT: and the "Heard a distant sound..." skull switch graphic gets reverted to closed after menu/battle return. square. O_o

also, i'm trying to figure out why CB/2F65 redraws that big chunk of lava (shifting some of it) when it's removing the left bridge. i can understand changing the lava tiles when moving the two islands at the end of the dungeon, as they're actually submersed in the lava. but a wooden bridge just goes over the lava. oh well, i spose it doesn't matter.

[Novalia Spirit]

hah, i shouldn't be surprised that you found another feet scalding opportunity, given your work in the shifting bridges room.

Believe it or not, there are at least two more cases of such:



By the way, I must admit it somewhat surprises me that you managed to recall this rather forgettable bug but not the one in which Shadow ends up impersonating Superman.

oh man, they were all sorts of flaky here.

If you're looking for more, you could try exploring the area on the left side of the switch that uncovers the entrance to the room containing the Atma Weapon. You can literally walk on one of the wall tiles from the south, and if you leave it by proceeding eastward, you can't go back. To a lesser extent, there's also the fact that when the ninja falls from above, the sound of his feet hitting the ground his heard a fraction of a second before he actually lands. Moreover, the direction he is facing is never reset, so if you trigger the event more than once without leaving the map, he won't be facing his intended direction while falling down.

and what calls CB/3DCB? i can swear i've seen the dialogue before.

That code belongs to the invisible NPCs that serve to prevent the party from returning to the map with the sealed gate.

here, we have the "Heard a distant sound..." skull switch turning on TWO event bits together, which can then manipulated separately by stepping on the two invisible switches. and given that stepping on the left invisible switch initially shakes the screen and "removes" bridge which isn't even there yet, and stepping on this switch is a prerequisite to even creating the long left bridge with the righthand invisible switch, i really really don't know what the hell Square was going for here.

It's possible they wanted to force the player into passing over the longer bridge after reaching the chest. That would explain why the smaller bridge can be destroyed and why the longer one can be created. It's also possible that they decided to drop the idea of creating the longer bridge, and forgot to deactivate the event on the western side of that bridge.

you mean some event command disassemblers fail to read the bit that determines the affected layer, right?

Yep. I edited my post quite a few times while you were writing yours, and reformulating that segment to alleviate any potential confusion is one of the changes I had to make.

and the "Heard a distant sound..." skull switch graphic gets reverted to closed after menu/battle return. square. O_o

It's impossible to tell without looking at the code or hacking the game, but the switch that initiates a battle against the Ninja also suffers from this problem.

[Assassin]

well, i was refreshed by searching the forum for "sealed" to see if anybody else had found that long left bridge, before i posted it.

*tries the two walking in strange areas* cool stuff. the lava one is more visually amusing, though i'm perplexed by those tiles that seem to be one-way as far as passability goes. istr concluding that "Ice Dragon as mountain goat" had a similar issue, because once he somehow went into lala-land, he couldn't come back (unless it was the RNG walking that prevented it, but i doubt that).

as for the Ninja switch graphic, i won't worry about it, for the reason you gave. not to mention it's not really a 2-way togglable switch anyway. i think of it more as a spring-loaded, self-resetting switch, which is what enables it to keep bringing the guy back.

[Novalia Spirit]

*tries the two walking in strange areas* cool stuff. the lava one is more visually amusing, though i'm perplexed by those tiles that seem to be one-way as far as passability goes. istr concluding that "Ice Dragon as mountain goat" had a similar issue, because once he somehow went into lala-land, he couldn't come back (unless it was the RNG walking that prevented it, but i doubt that).

This is actually discussed in this very topic under bug #50; the problem with Ice Drgn technically occurs earlier than that, as it can get trapped in the bottom third of the map. Such cases are basically the mere result of a combination of tile properties, though I'm not exactly sure about the details. Over the years, I've encountered quite a few instances involving the party, but they mostly concern bridges, staircases, and tiles that were clearly intended to be impassable. Coincidentally, I managed to uncover an instance, while writing this post, that takes place in that very area of the cave to the sealed gate; after activating the switch that produces a distant sound, you can take a step west and then south, but you can't go north immediately thereafter. It should be noted that the switch is not really a prerequisite, as I'm only mentioning it for the purpose of providing directions.

as for the Ninja switch graphic, i won't worry about it, for the reason you gave. not to mention it's not really a 2-way togglable switch anyway. i think of it more as a spring-loaded, self-resetting switch, which is what enables it to keep bringing the guy back.

I would agree that it can't really be called a bug, though they could have handled the situation differently, seeing as how the party has to take a step away from the switch for it to reset.

Addendum: The code that destroys the longer bridge places a lot of mismatching lava tiles in the surrounding area during the process.

[Assassin]

re Addendum: yup, see my 4:15am post. i can't figure out why they'd bother doing that, unless the quick snapback of the bridge retreating is somehow supposed to disturb the lava.

[Novalia Spirit]

Woah... I just made an incredibly disturbing discovery while studying map data:



This is approximately two screens below the entry point for the third party in Kefka's Tower. Position your party in that specific spot, including the direction. Press and hold the "A" button, and be prepared for a big surprise!

Clearly, this was intended to be dummied out. Interestingly, there are two other such events on the map, but this is the only one that's normally reachable.

re Addendum: yup, see my 4:15am post. i can't figure out why they'd bother doing that, unless the quick snapback of the bridge retreating is somehow supposed to disturb the lava.

Oops, I guess I missed that one. Let's do this again...

Addendum:
The event that creates the longer bridge is one of few instances where the event script executes without disabling party movement. This creates two problems:
1) By proceeding quickly, it is possible to bypass an entrance trigger and therefore advance further into the wall, which leads to layering priority errors. In the case of the leftmost entrance, you can even get permanently stuck in the wall.
2) Whenever the longer bridge graphically emerges from the lava, the party momentarily halts movement. If the party is walking downward at that precise moment, there's a pretty good chance the screen will briefly glitch out. At first, I assumed this was a problem with Snes9x, but I managed to replicate this with ZSNES as well; I couldn't be bothered to test it with bsnes, however. It usually affects the whole screen, but ocassionally, only a few rows of tiles will be affected.

[Assassin]

rad!

[Novalia Spirit]

Ok, a quick glance at the code revealed that contrary to appearances, the animation is not the only discrepancy between the normal and dummy events, as the latter neglect to restore the maps to default. Thus, the state of the landslide, weights, platforms, stairways, doors, switches, and such will remain unchanged following the event. To make matters worse, the bit that serves to handle Warp inside Kefka's Tower is left untouched, so warping out after entering any area thereafter will place the party, composed only of Setzer, on the deck of the airship, and the maps in Kefka's Tower will end up getting reset in the process, thus clearing the aforementioned bit. Moreover, if this is executed in Darill's Tomb, as a consequence of how the code is organized, the position of the two turtles won't be reset either. In the case of the first turtle, crossing the pool remains possible, but the animation looks pretty ridiculous, seeing as how the turtle lies on the opposite side. The second turtle, on the other hand, does not allow the party to cross unless both are located on the same side. The only solution to this issue is to warp out from any single-party location, as simply walking out won't yield the same result.

[Assassin]

regarding the Scimitar and Love Token bug:
viewtopic.php?p=3303#p3303

it also works with X-kill weapons, and with True Knight.

what's happening is that when Love Token / True Knight have a bodyguard block a hit, they mark the bodyguard in 16-bit $A6 to inform the animation. now, $A6 does two things for spells:
1) tells the C2/3483 function (handle reflection and Jump/Super Ball hits) to execute, and provides it its target to "reflect off". but it's skipped for physical attacks, so that doesn't apply here.
2) gives the green reflected barrier.

the X-Kill/Scimitar dice-up animations add an extra entry to the animation buffers, in which the command is treated as Magic. when the Magic animation encounters those bits set in $A6, it puts up the barrier (so it interprets that variable differently than a physical attack animation).

now, what i don't entirely follow is the order of the two buffer writings. it goes like:
1) before per-target special effect, write to ($76) buffer
in special effect, If x-kill/dice-up triggered:
__ 2) write to ($76) buffer
__ 3) write to ($78) buffer
(a little bit after special effect is done)
4) write to ($78) buffer

i'm guessing #3 matches up with #1, and #4 with #2. this could also explain why the special effect was apparently redundantly (in my view) setting $A4 -- it's actually undoing the temporary clearing of $A4 that took place before the function call.

a fix would probably involve changing the "JMP $63DB" at the end of the function to "JSR $63DB", then clearing $A6-$A7 afterwards. now to find 4 bytes of space to fit this....

Code: Select all

rep #$20
lda $3018,y
tsb $a4
trb $3a4e
sep #$20

boom!

EDIT: bar, i still need 1 more byte to account for the RTS. changing this:

Code: Select all

C2/38CA: A9 80        LDA #$80
C2/38CC: 20 32 0E     JSR $0E32      (Set Death in Status to Set)

to a "JSR $13A1" or "JSR $3A85" (depending on whether i do it in 16-bit mode or not) will save 2 bytes.

[Novalia Spirit]

Nice findings. I don't know how I managed to overlook True Knight all this time, though the mere act of thinking about True Knight and Love Token had me wondering about a potentially buggy behavior, which in turn led to a few discoveries:
1. 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. This includes Kefka, but it requires a multistrike attack to bypass a certain bug that causes the battle to end after any attack instead of when Kefka has no HP left.
2. The jumping animation for the bodyguard only applies to the first strike of a multihit attack (this was tested with Genji Glove); it seems as if the attacker is deliberately targeting the bodyguard directly out of anger.
3. The jumping animation for the bodyguard doesn't occur with dice weapons and randomly thrown weapons like Hawk Eye.
4. With Capture, the attacker will jump directly on the bodyguard and then remain there while the bodyguard proceeds to jump in front of the weak character to take the blow.

the X-Kill/Scimitar dice-up animations add an extra entry to the animation buffers, in which the command is treated as Magic. when the Magic animation encounters those bits set in $A6, it puts up the barrier (so it interprets that variable differently than a physical attack animation).

Is there a possibility that any other blockable physical attacks might be treated as magic as well? I'm mostly wondering if there are any undecoded functions in bank C1 or possibly bank C2 that tinker with that variable and that might trigger this bug.

[Assassin]

good stuff.

re #1: monsters can actually have True Knight (but none of them have the property set), so a solution to this would be to lump in such characters with monsters. i think that putting an "ORA $3A40" after C2/1279 and "BCS old_1284 / ORA $3A40" after C2/1281 would do it. (ok, i found another way that's the same size, but whatever.)

EDIT: shit, that only covers them protecting, not them being protected. so a full fix would be another 10 bytes or so beyond that.

re #2: heh @ anger. i see that Offering sets "No critical and ignore True Knight". the obvious goal of this is to lower damage for balance reasons. but until now, i would've just figured that the True Knight disabling was along for the ride due to sharing a bit.

[Novalia Spirit]

This is a bit unrelated, but is it a known fact that even though only a single entity can take damage as a bodyguard, all eligible canditates marked in $A6 and $A7 will attempt to protect a vulnerable target animation-wise? For example, if all party members are equipped with a True Knight, and one of them is attacked while in danger, the other three members will join forces and form a C-shaped shield around the character (enemies under the influence of Love Token will also participate). This also means that the Reflect barrier bug can apply to multiple entities at the same time.

[Assassin]

yes, i was aware of that, but hadn't thought of its impact on the Reflect barrier bug. i was wondering what determines who gets put where in the "C". not as intriguing as the priority for the complex Ramuh dialogue, but it's something to unravel.

[Novalia Spirit]

Thanks for clearing my doubts. I couldn't help but wonder after failing to find any mention of it anywhere. But then again, I've never seen any mention of the fact the party starts out with 3000 GP, so I guess that doesn't say much.

The character positioning appears to be determined by the entity index. The candidate with the lowest index (the lowest possible index being the character in the first party slot) is placed in the middle, the one with the second-lowest index appears at the bottom, and whoever's left goes at the top.

Some additions concerning True Knight and Genji Glove:
1. If the bodyguard is in a Near Fatal condition after the initial strike, it may receive protection from another candidate on the second strike. (This is just an addendum to one of the bugs I mentioned earlier.)
2. If the first strike involves Atma Weapon or a weapon that ends up casting a spell, and the attack proves to be lethal to the bodyguard, the second strike will target either the same bodyguard or the original target. Thus, if there are any other characters equipped with a True Knight, they'll suddenly stop caring about their duties, and will therefore not react at all. Edit: After making a quick search on the boards, I'd say this is related to this bug.

Also, I'm not sure if this should be considered a bug, but there's apparently nothing preventing a character from acting as a bodyguard while riding a magitek armor. It just doesn't seem right to me that such a large, presumably heavy machine can get teleported around the battlefield like it weighs less than a feather.

[Assassin]

Thanks for clearing my doubts. I couldn't help but wonder after failing to find any mention of it anywhere. But then again, I've never seen any mention of the fact the party starts out with 3000 GP, so I guess that doesn't say much.

it was covered in Terii's/my disassembly; see Function C2/12C0. as for the 3000 GP, news to me.

The character positioning appears to be determined by the entity index. The candidate with the lowest index (the lowest possible index being the character in the first party slot) is placed in the middle, the one with the second-lowest index appears at the bottom, and whoever's left goes at the top.

cool; thanks.

Some additions concerning True Knight and Genji Glove:
1. If the bodyguard is in a Near Fatal condition after the initial strike, it may receive protection from another candidate on the second strike. (This is just an addendum to one of the bugs I mentioned earlier.)

whoa.. when i first read that bug, i just figured that somehow the game was failing to draw the bodyguard in front of the initial target for the remaining strikes, but that the protection of the initial target was still happening mechanically. now, you've convinced me that the actual target has changed.

maybe this can be solved by moving the "JSR $3865" ahead of the "JSR $123B". but that could cause issues with Battle/Special done via Sketch (i don't know of any other zeroers of $3415 that are True Knight-able). better yet, around C2/329F, push A (which holds 16-bit $B8) on the stack, and right before C2/3865 is called, we should restore $B8. i think this'll work, because afaik, nothing on the remainder of the strike reads from $B8-$B9; they operate on $A2-$A5 instead. (some special effects will overwrite $B8-$B9, but they don't read from it first.)

if i'm wrong, then maybe C2/123B should check if $3415 is FFh, and if so, call C2/3865, and set some flag in a scratch variable (or the stack). then we skip the latter call to $3865 if the flag is set.

regardless, i really need to comment Function C2/3865...

2. If the first strike involves Atma Weapon or a weapon that ends up casting a spell, and the attack proves to be lethal to the bodyguard, the second strike will target either the same bodyguard or the original target. Thus, if there are any other characters equipped with a True Knight, they'll suddenly stop caring about their duties, and will therefore not react at all. Edit: After making a quick search on the boards, I'd say this is related to this bug.

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?

Also, I'm not sure if this should be considered a bug, but there's apparently nothing preventing a character from acting as a bodyguard while riding a magitek armor. It just doesn't seem right to me that such a large, presumably heavy machine can get teleported around the battlefield like it weighs less than a feather.

it's goofy, but yeah, arguably short of bug territory.

anyway, addressing it would involve a simple change to C2/12D6.