Glitches and Bugs guide updating thread

[Imzogelmo]

Also, as an aside, what are we calling the mirror status immunity thwarting fix thingy? It needs a handy name.

EDIT: I did some early testing with the patch of this. Not completely thorough, but I did test between the 2 versions and it does indeed perform as advertised regarding the blocking of regen (or not) with a ribbon/thornlet setup.

[Assassin]

^ thanks.

so "X-type instant death revives instant death-immune undead", and its sibling (#2 here: viewtopic.php?f=2&t=108&p=1355#p1355 ) are fairly simple bugs, but the fix has me dragging my feet over space and resulting concerns.

the obvious solution is for Function C2/3D43 to exit whenever C2/3890 didn't auto-activate the X-kill. since the former function is a caller of the latter and doesn't "know" the path it took, the straightforward way is to replicate the checks. for FF6j, which lacks the non-landing Jump restriction, that's just the instant death-protected $3AA1 check. (C2/3D43 already has its own Undead check, and being undead forgoes the Stamina and random 25% tests.) for FF3us, that'd also involve the C2/38AB thru 38B5 checks (albeit with the read of $B5 changed to $3A7C to be safe, as the former can get modified in the weapon effect). the bottom of this giant post has tentative code.

the FF3us version gets a bit heavy on free space needed. parceling the checks out of C2/3890 to be called as a shared mini-function is a no-go, because truly saving space with this would require shifting up the rest of the routine, which one of my patches already edits. changing the callee to return elsewhere via stack fiddling is a possibility, but would dump on anybody who wanted to call it from a different function (e.g. Geiger's Painful Chainsaw patch, iirc), and i'd need to make space for the PLAs somehow.

so that leaves C2/3D43 detecting one of various "signatures" left by C2/3890 activating X-kill:

1) 16-bit $B5 == 7E02h . the command and attack for animation purposes. possible problems come to mind, then eliminate themselves. playing on FF6j sans Jump Megafix could allow the variables to hold 7E02h even on a strike that didn't insta-kill, but we wouldn't need to have this test in the first place, as FF6j's version of C2/3890 only has the ID-protection check to duplicate. conversely, FF3us should never have 7E02h on a non-landing jump due to Square's added check.

2) Wound being marked in the "Status to Set" variable. possible foolers are:
a. an attack that already inflicts Wound (as in instant death; lethal damage doesn't mark it until later) and has the random X-kill as a special effect on top of that. but who'd make such a redundant thing?
b. a Mute-aborting Rage attack (without my Mute Steals Rage statuses fix applied) where the monster has inherent Death and the Rager gets muddled into hitting themselves with an X-type weapon on the next strike might cause ambiguity. but that is SO far out there.

3) the entity being set in 16-bit $A4. they're temporarily cleared from it by the original C2/3443 caller, as my C2/38B9 comment explains. the weapon ID activation restores them slightly earlier than usual, something of which i can take advantage. no side effects are coming to mind, but leaning on this oddity makes me uneasy somehow.

-------

so the shortening options are all reasonably safe, though #2 the least so in a non-bugfixed game.

any preferences on which? should i just do things the cleaner, longer way? also, i'm hesitant to drop the $3AA1 check -- maybe because i want FF3us to have at least as much safeguard as FF6j -- even though any #1-3 should technically remove the need for it, and it takes 7 bytes.

so, much of this comes down to my indecision between slightly flawed and/or weird methods, and wanting other opinions. but straight-up logical analysis of whether any of these methods have side effects i'm overlooking would also be helpful. i'd prefer not to require other bugfixes, so vanilla is definitely fair game. i swear i revised my stance on #1 numerous times en route to making my notes months ago. (issues with it are _probably_ limited to somebody hacking out Square's non-landing jump check on FF3us without applying Jump Megafix -- i.e. pointless -- but my slowness in grasping the interactions leaves me concerned.)

completely different techniques are also welcome.

-----

projected FF6j fix (damn, so simple and short):
http://assassin17.brinkster.net/patches ... ix1b-j.asm

FF3us the long way (26 bytes free space):
http://assassin17.brinkster.net/patches ... ix1b-u.asm

[Assassin]

Esper eyes wide open -

When you first reach Terra in Zozo, she's laying in bed with her eyes open. Then during the conversation with Ramuh, she thrashes around, and the party helps her back into bed to recuperate, with her eyes now closed. However, should you leave the room and re-enter, even before getting the Magicite or talking to your comrades, her eyes will be open again. This despite her being equally unresponsive when talked to and the party's dialogue not changing. While I can't rule out it being intentional, it's probably just a side effect of the NPC's startup pose having open eyes.

Fortunately, going into the menu while in the room doesn't trigger the reversion, ala Cave to the Sealed Gate.

[Imzogelmo]

I'm still trying to digest your Nov. 30th post.

My first thought is that I'd prefer not to rely on any other bugfixes if at all possible. That would include both Jump Megafix, Jump Megafix 2: The Untold Story, and Square's own non-final Dragon Horn bounce check. Certainly not wanting to clobber functions that other patches use is a concern somewhere too.

As for your actual implementation, I will have to chew on it a while to form a better opinion, but I'm of the mind that longer is not necessarily bad if it eliminates reliance on what you call "weirdness" of certain paths (and I can't come up with a better term at the moment). I really don't want to rely on uncollected garbage data, but another term for that could be "repurposing" of the data, which certainly makes it sound better.

Anyway, as we've established before, the ROM space is not that precious; we can always find enough space. I think independence of patches is a higher priority.

[Assassin]

My first thought is that I'd prefer not to rely on any other bugfixes if at all possible. That would include both Jump Megafix, Jump Megafix 2: The Untold Story, and Square's own non-final Dragon Horn bounce check.

so combining all those, you think i should account for the hypothetical of "somebody hacking out Square's non-landing jump check on FF3us without applying Jump Megafix"? if so, why? for the fictional hacker to do the first but not the second is effectively sabotaging the command. thus, how concerned am i that the FF3us patch would work "wrong" in such a scenario that's rife with disappearance bugs and the like, particularly when simply adapting the FF6j patch would work "right"?

if some goofball wants to vanilla-FF6j-ize (read: ruin) the Jump command, and they also want to use my pending patch, then it's incumbent upon them to FF6j-ize my patch too.

[EDIT: i'm taking the flipside of my prior devil's advocate position a bit here. i.e. balancing "can it withstand that?" with "who's gonna do that?" and "they can also do this".]

I really don't want to rely on uncollected garbage data, but another term for that could be "repurposing" of the data, which certainly makes it sound better.

i sorta follow you here.. it depends on how reliable certain data "signatures" left by the insta-kill activation are, and how much them holding a certain value can be seen as a fluke.

a straightforward way of doing the patch would be initializing a scratch variable before the C2/3890 call, changing its value in the function if insta-kill is chosen (e.g. increment it, or toggle a bit in it), then checking its value when the function returns. obstacles include space concerns, coexistence with other C2/3890 modifiers, and hoping some hypothetical other caller (i.e. in a hack) of C2/3890 doesn't use the same scratch variable. of the methods i mentioned on 11/30/16, the $A4 one comes closest to this approach. it's really handed to me on a silver platter (and avoids those obstacles due to being existing Square code), but something about the temporary nature of $A4 being cleared at C2/3443, then how C2/3890 sets it for animation reasons, make it seem weird.

[Imzogelmo]

so combining all those, you think i should account for the hypothetical of "somebody hacking out Square's non-landing jump check on FF3us without applying Jump Megafix"? if so, why? for the fictional hacker to do the first but not the second is effectively sabotaging the command. thus, how concerned am i that the FF3us patch would work "wrong" in such a scenario that's rife with disappearance bugs and the like, particularly when simply adapting the FF6j patch would work "right"?

if some goofball wants to vanilla-FF6j-ize (read: ruin) the Jump command, and they also want to use my pending patch, then it's incumbent upon them to FF6j-ize my patch too.

[EDIT: i'm taking the flipside of my prior devil's advocate position a bit here. i.e. balancing "can it withstand that?" with "who's gonna do that?" and "they can also do this".]

My point is that we have 2 different versions of vanilla; FF6 and FF3us. So, we have a historical reason to have 2 different versions. I am not actually suggesting that you anticipate the FF6-ized FF3us, but rather that you do not depend on it. If someone wants to do that, the onus would be on that person to further derive it from your work. But, since there are already 2 official versions, and they happen to differ in a way that is pertinent, I was advocating for having one fix that is (logically) common to both (i.e., shifting and code location aside). So that, if one wanted to add the check to FF6, or remove the check from FF3us, it would be as trivial as possible and not suddenly break your code. That's all I was saying: patch independence.

a straightforward way of doing the patch would be initializing a scratch variable before the C2/3890 call, changing its value in the function if insta-kill is chosen (e.g. increment it, or toggle a bit in it), then checking its value when the function returns. obstacles include space concerns, coexistence with other C2/3890 modifiers, and hoping some hypothetical other caller (i.e. in a hack) of C2/3890 doesn't use the same scratch variable. of the methods i mentioned on 11/30/16, the $A4 one comes closest to this approach. it's really handed to me on a silver platter (and avoids those obstacles due to being existing Square code), but something about the temporary nature of $A4 being cleared at C2/3443, then how C2/3890 sets it for animation reasons, make it seem weird.

Again, how you actually implement it is best left to your expertise. If you're fairly certain that the $A4 variable can be used reliably, then I'd just call it good optimizing. If it came down to either that or claiming some new/unused RAM location, then there's really no contest in my mind. And really, the zero page variables are meant to be scratchpad anyway, it's just that Square has given most of them a broad permanence throughout the battle routines. I am fairly certain that if it had been passed through a modern optimizing compiler, there would be some really odd re-uses of variables, but fewer of them overall.

[Assassin]

understood. i'll include a note to the effect of: "Should you add or remove any checks to/from C2/3890 for deciding whether instant death happens, C2/3D43 needs to have the same changes to match it. Or if C2/3D43 is testing for variable states that result from the original checks, make sure that the variables hold these values if and only if the revised checks pass." Then I'll give a couple examples.

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

(S)he who summons the bird reaches the worm late -

Right after a turn where Palidor is summoned, anybody carried away by the big bird is given a "Time to Wait" value of E0h, consistent with the Jump command he or she is effectively going to perform. (Or if you were entering a command as the Summon started and the character hadn't entered their ready stance yet, it gets bumped up to E0h + other command's wait time.)

More generally, right after any turn taken (aside from something like the first casting in an X-Magic sequence), "Time to Wait" for the entity who acted gets set to FFh, as a way of nulling it.

Oh, but combine these two, with the second step happening slightly later, and that means the Palidor summoner needs the top byte of their Wait Timer to elapse FFh units to land, putting them at a 1/8 disadvantage to their comrades.

(Aside: A check of the "Palidor was summoned this turn" flag several lines before the "Time to Wait" FFh setting might lead some to say Square saw this coming. But I'm pretty sure the check is just there to skip the C2/01B1 check, so Palidor+pre-entered command doesn't get lumped into the same category as Magic+X-Magic. Even though I think the summoner is the sole character who can't have a pre-entered command, I do respect their reasoning of not wanting the hypothetical chaining to happen until landing.)

[Imzogelmo]

Going out on a limb and supposing this info is the result of your investigation into Palidor+Quick/Smoke Bomb, are these timing issues and the exact sequencing thereof somehow responsible for the game hang? I'm wondering what other weirdness can ensue from Palidor + other attackers? It certainly seems that they anticipated some things, but possibly not every contingency.

[Assassin]

looking closer at Palidor did lead me to this, yes. however, i don't have reason to believe the bugs are related. that said, i should probably go back and test the other one with the Quick user being both the Palidor summoner and mere passenger. (iirc, i tested them as former.)

---------

EDIT: as for a fix for this newer bug, my first impression was to skip C2/01C6 thru 01CD if "Palidor was summoned this turn" had been set. however, it's possible the summoner is not on the passenger manifest, if they were Muddled. in which case, i'd instead want to check bit 0 of $3204,X, which is set for those whisked away on the current turn *. the problem is, it's already been processed and cleared by C2/0836. how to duplicate its presence? do i check "Palidor was summoned this turn" in conjunction with Bit 7 of $3205,X ?

* Aside, part deux: when an academic aside from a prior post needs an even more academic follow-up, and no other board administrators are active to stop me. because of Muddle+Palidor possibility (as even my old bugfix stopping the enemies from getting carried away won't make characters be carried away), i believe Square should have done something equivalent to this at C2/01AA, in place of solely a "Palidor was summoned this turn" check. see, if i'm right that the C2/01AA check exists to stop a hypothetical pre-entered command from being chained right after the Summon, it's doing so because a ride on a giant freaking bird is putting off the other command. but somebody not riding said bird shouldn't be affected in the same way. now, my concern here is still academic, as that other command is still hypothetical.

---------

same EDIT, other idea:

(Or if you were entering a command as the Summon started and the character hadn't entered their ready stance yet, it gets bumped up to E0h + other command's wait time.)

the sum is capped at FFh, of course. gee, if there was a command the character(s) could buffer that would have its effective "Time to Wait" greatly reduced by doing this...