Assassin wrote: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:
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)?
Imzogelmo wrote:*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?
I guess I'd favor the clear-on-counter method.
Assassin wrote: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.
Assassin wrote: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.
Assassin wrote: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.)
Assassin wrote: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.
assassin wrote: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.
Imzogelmo wrote: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.
(at start of turn, probably in C2/2639)
(in 16-bit mode)
(start of Function C2/35E3)
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)
sta $3291,y (clear variables for FC 02)
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)
Assassin wrote: 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.
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.
Users browsing this forum: No registered users and 1 guest