Pandora's Box

[Assassin]

people won't request it if they don't know it exists! you should have that patch listed and readily downloadable on the website. or was it unfinished or buggy somehow? even then, just put a warning note on it.

[Imzogelmo]

Nah, it works fine, afaik. The issue I think lies with the fact that it would require hand-editing of monster battle scripts to support the extended commands, which is something very few would be brave enough to do.

However, Leno made a nice editor that can handle it quite well, as well as some PB-only targeting types. It certainly makes it more fun!

[Assassin]

editor?! i assume that's also lacking a download link? what's with you people?

[Assassin]

since we were on the subject of Function C2/35E3, i was hoping to get your view on something...

in the case of a spell reflected off multiple characters onto a monster, FC 01, FC 02, and FC 04 will all arbitrarily favor the last reflector (i.e. character #1) for counterattack target. this despite the work the game does to make $32E0,X randomly get one of the reflectors... but then it doesn't use $32E0 to set the variables used by these FC commands.

i'd posted about this 8 years ago:
viewtopic.php?p=1224#p1224
viewtopic.php?p=1243#p1243

i'm still considering it a bug, but since the F1 45 aiming command (Target last attacker) allows a script to use the randomized, non-arbitrary $32E0 value, does that mitigate the bughood? now, very few scripts ever use this F1 45, but it is available should they want to use it.

iow, can i call silly arbitrary behavior a "bug" and quest to "fix" it if the game already has a way around it (albeit generally unused)?

[Lenophis]

editor?! i assume that's also lacking a download link? what's with you people?

In due time.

[Imzogelmo]

since we were on the subject of Function C2/35E3, i was hoping to get your view on something...

in the case of a spell reflected off multiple characters onto a monster, FC 01, FC 02, and FC 04 will all arbitrarily favor the last reflector (i.e. character #1) for counterattack target. this despite the work the game does to make $32E0,X randomly get one of the reflectors... but then it doesn't use $32E0 to set the variables used by these FC commands.

i'd posted about this 8 years ago:
viewtopic.php?p=1224#p1224
viewtopic.php?p=1243#p1243

i'm still considering it a bug, but since the F1 45 aiming command (Target last attacker) allows a script to use the randomized, non-arbitrary $32E0 value, does that mitigate the bughood? now, very few scripts ever use this F1 45, but it is available should they want to use it.

iow, can i call silly arbitrary behavior a "bug" and quest to "fix" it if the game already has a way around it (albeit generally unused)?

I feel your pain here. There are SOOO many kinds of targeting bytes. They go to all the trouble of making an unbiased target, and then they never use it. I'm not sure whether calling it a bug is warranted or not, but it is certainly arbitrary as you have said. Perhaps an oversight?

I think a fix/"fix" would certainly be a good thing. Whether to put it in your bugfixes section or improvements section, I cannot say.

[Assassin]

i'm leaning towards Bugfix section, since it's still bugfix-esque enough to qualify, even if i accompany it with disclaimers that it's not necessarily a bug. heck, Brushless Sketch made it into that section.

then again, so did Alphabetical Rage. :/ i really need to reorganize that page; having "Patches" and "Miscellaneous Patches" sections makes no sense, given the first title is all-encompassing. :/ i should follow Novalia Spirit's example here.

[Assassin]

getting back to the prior FC 02/03/05 bug: i realized a setback to my C2/35E3 method of fixing it. if i clear the counterattack variables whenever that function gets called, there are a couple of issues:

1) currently, if you have a turn with a spell during it and a non-spell ending it (think multiple strikes done with spellcasting weapons), the "Last spell used on entity" and "Last attacker to use spell on entity" variables will still hold the spellcast info at the end of the turn, thus making the earlier spellcast counterable. my patch would cause spells on any strike but the last to be ignored by FC 02.
2) same deal for Items. now, Items don't have multistrike attacks, outside of Magicite then doing an Esper Summon. but there is the option for a monster to counter the Magicite item. my patch would eliminate that option for FC 03, barring some insane workaround.

we know per the Bugs Guide (and common sense) that the FC 02 and 03 variables being uncleared into later turns are bugs. now, the question becomes: do we consider them being uncleared into later strikes on the same turn as a continuum of these same bugs? if the answer is yes, then no sweat with my proposed fix. if the answer is no, then plenty of sweat. :/

looking within the confines of a turn, it's hard to say what the "proper" method is as far as which strike to look at for informing the counterattack variables:
1) the command used in these variables is copied from $3A7C, which matches the initial command of the turn. so if you have weapon spellcasts via Fight, the monster is still considered to have been attacked with Fight, not Magic. it's this mechanism that lets monsters specifically counter Rage or Sketch, so i respect that.
2) the elements (or lack thereof) reflect whatever the last strike of the turn was.
3) the spell or item is based on the last use of a spell or item during the turn.

let's put #1 aside for a moment. it's tempting to say that #3 is inconsistent with #2, but i can make an argument that it isn't. any given strike on a turn can have one element, multiple elements, or no elements. if the last strike is done with Blizzard, then it makes sense for its Ice element to override the Fire element done by an earlier Flame Sabre strike. by the same token, if the last strike is done with Dirk, then it makes sense for its Non-element to override the Fire element done by an earlier Flame Sabre strike. to behave otherwise is basically to say that elemental weapons like Blizzard somehow deserve more attention than non-elemental weapons like Dirk.

meanwhile, the situation for the spell and item variables is a little different. suppose you have a turn that unfolds like: Flame Sabre strike, Fire spell, Dirk strike. one could say that the last strike was a "No spell", but i think it's more precise to say that the last strike was a "Spell not applicable". and in such a case, we'd look back to the last applicable strike (i.e. one where a spellcast occurred) to see which spell to counter.

so that's a defense of the current Square behavior for #2 and #3. then again, extending my logic in the prior paragraph could also have us looking back to the last applicable *turn* when a spell was cast on the monster, which would support FC 02 being used as an omni-counter. which the Bugs Guide and most sane people agree should not happen.

of course, a bugfix that doesn't clear the FC 02/03/05 variables whenever a monster is hit, but whenever it counters (i.e. Master ZED's fix and the PB fix, combined with Hollywood Narrator's script workaround) resolve the inter-turn issue, yet preserve the intra-turn behavior. that's something my proposed method cannot readily do.

so the questions here are whether principles across turns should be applied within turns, or more generally: what is the proper behavior? i prefer bugfixes where the proper behavior is obvious, and i'm just a code monkey. but these other types are engaging on some level, if only to make the venerable forum more active.

[Imzogelmo]

*head explodes*

I need a flowchart, badly.

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

I don't think we need intra-turn granularity for counters. I'd say let the last applicable element, item, or spell win (and command doesn't change within a turn, so no issue there). If you can somehow sneak in an attack that would have otherwise triggered such a counter, then that's just great strategy (and super sneaky).

So I guess that means a lot of sweat? I guess I'd favor the clear-on-counter method. My reasoning is basically chronological-- the counter will not interrupt the multiple strikes to do its hit: it has to wait. So once it gets a time slice to act, it has to take the situation as it then exists. The most recent command is no problem, as that doesn't change during the turn. The most recent item shouldn't be a problem, as there's either some item or none (and writing FF there will be no problem). The most recent spell is a sticky one, as I never realized that weapon addition magic would trigger the spell type counter (somehow thought weapon addition magic was exempt from that**). The most recent element seems a bit sticky too: while I favor having it be the "last" strike of a multi-strike attack that counts, it seems to me that your Flame Sabre/Dirk combination should trip a fire counter, regardless of which hand holds the Flame Sabre. Then again, I wouldn't mind a stackable elemental counter... ANDing together all the applicable element upon hitting... but that's deep into the "lot of sweat" territory.

Still, I'm having a hard time wrapping my head around this. Did I mention I need a flowchart?

**EDIT: Perhaps making it so that weapon addition magic did not write into the spell counter is a good idea?

[Assassin]

*head explodes*

medic!

I need a flowchart, badly.

management!

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

I don't think we need intra-turn granularity for counters. I'd say let the last applicable element, item, or spell win (and command doesn't change within a turn, so no issue there). If you can somehow sneak in an attack that would have otherwise triggered such a counter, then that's just great strategy (and super sneaky).

agreed.

So I guess that means a lot of sweat? I guess I'd favor the clear-on-counter method. My reasoning is basically chronological-- the counter will not interrupt the multiple strikes to do its hit: it has to wait. So once it gets a time slice to act, it has to take the situation as it then exists.

as it then exists ... yet having some memory of prior strikes? specifically, you seem to favor something where the "memory" can look back a number of strikes, but it can only recall one instance of each property (i.e. spell, element, item, command) among those strikes.

The most recent command is no problem, as that doesn't change during the turn. The most recent item shouldn't be a problem, as there's either some item or none (and writing FF there will be no problem). The most recent spell is a sticky one, as I never realized that weapon addition magic would trigger the spell type counter (somehow thought weapon addition magic was exempt from that**). The most recent element seems a bit sticky too: while I favor having it be the "last" strike of a multi-strike attack that counts, it seems to me that your Flame Sabre/Dirk combination should trip a fire counter, regardless of which hand holds the Flame Sabre.

i'm leaning towards that not tripping a fire counter, due to the distinction between "Non-elemental" and "No applicable element" (as made in my previous post). but your view certainly has sense to it.

Then again, I wouldn't mind a stackable elemental counter... ANDing together all the applicable element upon hitting... but that's deep into the "lot of sweat" territory.

it is doable, thanks to fitting in one byte. i'd considered the idea, but to be consistent in approach across counterattack variables, you'd need stackable spell counters as well. and that requires 32 bytes per target, so it's unrealistic. (we agree stackable command counters and the 4 bytes per target they'd need can be avoided because Square sought to use the initial command.)

Still, I'm having a hard time wrapping my head around this. Did I mention I need a flowchart?

**EDIT: Perhaps making it so that weapon addition magic did not write into the spell counter is a good idea?

^ maybe, though it seems the coward's way out. now, it would eliminate a weakness of the Clear-variables-upon-being-hit bugfix method, because weapon addition magic is the only reason one needs to "look back" to strikes prior to the last one to find a spell. (remember that X-Magic is implemented as two rapid turns, not two strikes on one turn.) however, said bugfix method would still have the weakness of being unable to counter the Magicite item.

I guess I'd favor the clear-on-counter method.

ah! and yet you seemed to favor the clear-on-hit method for purposes of behavior in the first half of scripts. i'm not playing "gotcha" here -- merely pointing out how this potential patch is reminding me of the old Economics saying: "you can't do just one thing." that is, structuring the patch in a way that its behavior makes the most sense in one aspect causes its behavior to be suboptimal in another aspect.

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

as an aside, suppose the following scenario on a turn: Fire Sabre hit, Fire casting, Blizzard hit. in response to this, a hypothetical monster could have an Ice-elemental counter trigger. it could also have a Fire spell counter trigger. but it wouldn't have a Fire-elemental counter trigger. this is a case where looking at each category (i.e. spell, element, command, item) separately, the behavior makes sense. yet looking across categories, you have a mismatch of sorts where the monster is arguably viewing itself as "last hit" by the Fire spell and the Ice element. i'm not saying it's wrong, just a bit weird.

if this "weird" is sufficiently problematic, your idea about weapon addition magic not registering in the spell counter could solve it.. i'm not quite sure how this measure would be implemented ($3A89 is set even when the spellcast doesn't happen; $3400 is cleared by the time C2/35E3 is reached; Bit 4 of $B2 isn't cleared [from default of set] for Tempest's Wind Slash, and we'd wanna exclude that spell from counters to be consistent. what i'd probably have to do is early in C2/35E3, check if $3A89 is set, and skip over the copying of $3410 if so. but $3A89 isn't set for Tempest to start, so that'd still be an issue; damnit.) anyway, this implementation issue can wait, as nearly everything up until this paragraph was more about how the game should behave, than whether i can detect certain things in code.

[Assassin]

ooh.. i think i found a way to duplicate Master ZED's FC05 fix and the PB fixes without relying on the script reordering. it'll require an extra memory byte, though.

1) right before C2/4BF4 calls C2/1A2F, zero a variable, which will be known as "List of FC0X counter variables to clear". as many as 5 bits will be used, for FC 01 through FC 05.
2) as part of C2/1A2F, the FC 0X functions will eventually be called. when FC 01-05 is called and the test passes, instead of directly clearing the counterattack variables, instead set a bit in the new variable (so FC 02 might get Bit 1, FC 03 Bit 2, etc).
3) after C2/1A2F returns, check the various bits of this variable. if a bit is set, clear the corresponding FC 0X counter variables for the current entity.

if i understand correctly when C2/4BF4 calls C2/1A2F and what the latter function does (both uncertain), this should behave like your asm fixes + HN's script remedy. at least as far as the second half of scripts go.

as far as the first half of scripts, it'll be a little different than both that setup and my potential C2/35E3 fix method. what will happen is that a given type of FC 0X command in the first half of a monster script will pass as true until the same type of FC 0X command is executed from the second half. so it's more strict than the C2/35E3 method, but possibly more lenient than the current patch method. it can be made more strict fairly easily (duplicate Steps #1 and #3 surrounding the C2/02DC call to C2/1A2F). i wouldn't know how to make it more lenient.

[Imzogelmo]

So I guess that means a lot of sweat? I guess I'd favor the clear-on-counter method. My reasoning is basically chronological-- the counter will not interrupt the multiple strikes to do its hit: it has to wait. So once it gets a time slice to act, it has to take the situation as it then exists.

as it then exists ... yet having some memory of prior strikes? specifically, you seem to favor something where the "memory" can look back a number of strikes, but it can only recall one instance of each property (i.e. spell, element, item, command) among those strikes.

Yes, to clarify: I'm saying I favor a situation where it remembers the most recent in each category, but only extending within the current turn (or more precisely, the current AI script command). Once that same monster issues a new command (after these variables have been checked, if applicable), all of them should revert to a clean state. I know that sounds somewhat arbitrary, as I'm having a hard time even convincing myself that it is the most correct method, but that's how I envision it nonetheless.

The most recent element seems a bit sticky too: while I favor having it be the "last" strike of a multi-strike attack that counts, it seems to me that your Flame Sabre/Dirk combination should trip a fire counter, regardless of which hand holds the Flame Sabre.

Then again, I wouldn't mind a stackable elemental counter... ANDing together all the applicable element upon hitting... but that's deep into the "lot of sweat" territory.

i'm leaning towards that not tripping a fire counter, due to the distinction between "Non-elemental" and "No applicable element" (as made in my previous post). but your view certainly has sense to it.

I guess I'm in the camp that says "some element" trumps "no element" when it comes to counters, which is why I mentioned the stackable elements. As such, a fire and non elemental weapon would stack to make a fire counter, and of course a large number of permutations both real and theoretical can be produced. But I also realize that stacking for one method and not others is inconsistent, which I seek to avoid. That being the case, we have to pick some method that results in (at most) one counter-able element at the end of an attack. And, to remain consistent, it must be the last element. And as I already elaborated, I think "some element" trumps "no element", partly because of my above logic (that all elements involved in the attack deserve to trigger a counter), and partly because having the hand which holds the one elemental weapon to suddenly matter is just too esoteric a trivia to impose on the player, IMHO. [And none are more esoteric in the knowledge of FF6 mechanics than we are]. The consequences of this, though, is that with 2 elemental weapons, one matters and the other doesn't--it's a classic case of only being able to get 2 out of 3 objectives (consistency among commands, neutrality among hands, whole-turn granularity).

it is doable, thanks to fitting in one byte. i'd considered the idea, but to be consistent in approach across counterattack variables, you'd need stackable spell counters as well. and that requires 32 bytes per target, so it's unrealistic. (we agree stackable command counters and the 4 bytes per target they'd need can be avoided because Square sought to use the initial command.)

Of course I thought about that or I wouldn't have brought it up, but I figured keeping consistency and sacrificing (a little) neutrality among hands was a decent balance.

Perhaps making it so that weapon addition magic did not write into the spell counter is a good idea?

^ maybe, though it seems the coward's way out. now, it would eliminate a weakness of the Clear-variables-upon-being-hit bugfix method, because weapon addition magic is the only reason one needs to "look back" to strikes prior to the last one to find a spell. (remember that X-Magic is implemented as two rapid turns, not two strikes on one turn.) however, said bugfix method would still have the weakness of being unable to counter the Magicite item.

Could it be approximated by having a "spell" counter always fail when then previous command was "Fight" (or "Capture")? Not that I've thought this through, but it would plug up this hole I would think. Probably venturing into the implementation a little too far too soon though.

I guess I'd favor the clear-on-counter method.

ah! and yet you seemed to favor the clear-on-hit method for purposes of behavior in the first half of scripts. i'm not playing "gotcha" here -- merely pointing out how this potential patch is reminding me of the old Economics saying: "you can't do just one thing." that is, structuring the patch in a way that its behavior makes the most sense in one aspect causes its behavior to be suboptimal in another aspect.

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

as an aside, suppose the following scenario on a turn: Fire Sabre hit, Fire casting, Blizzard hit. in response to this, a hypothetical monster could have an Ice-elemental counter trigger. it could also have a Fire spell counter trigger. but it wouldn't have a Fire-elemental counter trigger. this is a case where looking at each category (i.e. spell, element, command, item) separately, the behavior makes sense. yet looking across categories, you have a mismatch of sorts where the monster is arguably viewing itself as "last hit" by the Fire spell and the Ice element. i'm not saying it's wrong, just a bit weird.

Weird yes, but it's a level of weirdness I can live with...unless we can go all-out with a stackable elemental counter (and stackable spell/item counters too). And no, for the record, I don't think it is worthwhile to try doing all that.

*implementation stuff snipped*

*still picking up pieces of exploded cranium*

[Assassin]

Could it be approximated by having a "spell" counter always fail when then previous command was "Fight" (or "Capture")? Not that I've thought this through, but it would plug up this hole I would think. Probably venturing into the implementation a little too far too soon though.

good idea. $3A7C is used in that very function (C2/35E3), so it could be put to this use as well.

-----------

cripes, i just (re-)thought of another issue. the current patches (ZED's and PB) have a vulnerability with a monster script like this:
+++++
[second half script]
If (HP < nnnn) then
If monster was attacked by Spell (or Item) XX or YY then
[do counter]
End if
End script
+++++

suppose the party hits the monster with an eligible spell or item early in the battle, but its HP is still high. then we beat it down to low enough HP with our fists. it'll belatedly use the spell or item counter in response to this Fight hit. (you can replace the HP check with something else that takes awhile to kick in, such as a counter variable reaching a certain threshold.)

based on what we've written here, i think we'd both view that as wrong. not as obnoxious as a repeating Omni-counter, but a cousin of sorts.

i actually discovered the equivalent issue with Master ZED's FC 05 patch waaaaaay back (like 2004-2006), but am not sure where the post is, if it survived. now, because FC 05's "If monster was damaged" requirement is less specific than those of FC 02 or FC 03, i want to say that triggering this belated FC 05 counter was a little more involved. the steps were like:
1) have character smack monster for damage
2) have monster repeatedly hurt itself (e.g. with Reflected spells, or maybe getting a status like Poison)
3) wait for monster to fall below HP threshold. monster will belatedly counter the character who damaged it ages ago.

the patch style i proposed this afternoon would have the same vulnerability. for whatever my next approach is, i'll be sure to go through every possible scenario before posting it.

*wishes cranium was also on floor so it couldn't cause this pain to my gut*

[Assassin]

ok, i think i found a way to make the C2/35E3 fix method be more flexible with multi-strike attacks. it'll require 2 bytes of free RAM.

Code: Select all

(at start of turn, probably in C2/2639)
(in 16-bit mode)
stz $new_variable

[...]

(start of Function C2/35E3)
rep #$20
lda $3018,y
tsb $new_variable  (indicate this target as having this function called
                    for it this turn)
bne skip_clear     (branch if that was already the case)
sep #$20
lda #$ff
sta $3d49,y
sta $3291,y  (clear variables for FC 02) 
sta $3d5c,y
sta $32a4,y  (clear variables for FC 03)
sta $327c,y  (clear variable for FC 05)
(no need to clear FC 01 and FC 04 variables, because they're overwritten
every strike anyway)

skip_clear:

a remotely possible (?) problem with a bugfix done via C2/35E3 is if a monster could "self-hit" with Poison/Seizure/etc. between them being hit by a character and their counterattack code at C2/1A2F being executed. it would overwrite the FC 02/03/05 variables with FFh. but i'm going to trust that such a thing can't happen, given that it would already overwrite the FC 01 and FC 04 variables with new data in the existing game. and i've never seen it happen, from a gameplay perspective. so i'm putting this concern on the record moreso to express my cluelessness with exactly when C2/4BF4 is executed, when the queued periodic damage/healing is executed, and the "main loop" in general -- as opposed to actually thinking the interruption will happen.

[Imzogelmo]

i'm putting this concern on the record moreso to express my cluelessness with exactly when C2/4BF4 is executed, when the queued periodic damage/healing is executed, and the "main loop" in general -- as opposed to actually thinking the interruption will happen.

It is sad that after all this time we still cannot say precisely how these loops are layered and thus say with authority that X will precede Y. I don't know either, just lamenting is all.

[Imzogelmo]

*necro-post*

I'm not sure if anyone has tried assassin's suggested fix in this topic, but I'm going to put it in my working file so it can at least be tested.

[Assassin]

a remotely possible (?) problem with a bugfix done via C2/35E3 is if a monster could "self-hit" with Poison/Seizure/etc. between them being hit by a character and their counterattack code at C2/1A2F being executed.

i'm still leaning towards this not happening (but have gone back and forth on it, iirc). however, other meddlers could be:
- attack that triggered the entity's counter was MT, and the counter of another entity hit by it runs first, and somehow hits our main entity, overwriting its variables.
- entity was hit by two rapid-fire attacks in a row (counters, as normal ones aren't high priority enough to not be interrupted), with the second one clobbering the variables established by the first one.
EDIT: - something from the uber-high-priority queue executed, like auto status expiration, or Life 3 revival.

now, both of these the second one will involve the entity countering a counter, which can't happen aside from when they've been killed (and $3A56 is set). so it's fairly limited. and maybe the overwriting (edit: for the first two) is less obnoxious than it would be with the periodic damage/healing, since it's being done by more fully-fledged attacks/spells.

queuing of the FC 01/02/03/04 variables so the counter that eventually runs can be matched up with what triggered it -- and not soiled by interveners -- would make things more robust, but would be memory-sapping and a bit complex.

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

as for implementing _reliable_ ideas of mine.. from what i understand of your Function C2/0DED alterations in PB, my "Bottomless HP and MP Well fix" handles things better with regards to undeads, so you'd probably want to adopt it. the Readme gets into why i chose my ordering.

[Imzogelmo]

ah..

Despite the thread title, I'm actually making a working file of vanilla with gating around the changes of each patch, so they can be enabled or disabled independently and tested under any combination desired.
(although I did put at least one PB-debuting tweak in the file, because I really *love* stackable retort)

EDIT: I can see how the uber-high queue may clobber some variables (in theory) but is that merely theoretical? <rant> And, even it if is, it seems to me that your above approach is still a giant leap forward from the vanilla game, and perhaps the best we can do without the massive RAM-consuming overhaul that it would probably take to truly track it faithfully. I'm not saying throw in the towel, but free RAM being the premium that it is, and due to the rather situational use of the variables anyway, I'd say some (occasionally flawed) memory is still better than nothing at all.

Yes, if I were coding the engine from the ground up, in an architecture where I can just create gigs of variables whenever I felt like it, we would probably have a page of variables for every attacker-target pair (hey, that's a good idea!). But, for what it is, and what it's used for, we do have a fairly robust system as it is. </rant>

But seriously, do actions in that "uber-high" queue even bother with the counter variables? I'd be inclined to think that they are avoided altogether. Countering a Life 3 revival? If it's happening, it probably shouldn't...