Users browsing this thread: 1 Guest(s)
Possible solution to the sap death bug

#11
Posts: 200
Threads: 1
Thanks Received: 10
Thanks Given: 0
Joined: Oct 2015
Reputation: 18
Status
None
1) to be sure, did you just apply Bropedio's Function C2/4BF4 changes from the 1st post, or also his Function C2/4C5B changes from the 2nd post?  the latter does restrict usage of non- FC 12/FC 1C counters in a small amount of cases.

2) do you have Leet Sketcher's Item/Magic Counter bugfix applied?  it's a later sibling of Master ZED's FC 05, so could present issues, based on how i responded to Pandora's Box using that approach in the old Mnrogar forum thread.
Quote  

#12
Posts: 377
Threads: 34
Thanks Received: 10
Thanks Given: 7
Joined: Dec 2018
Reputation: 18
Status
Moog
It was only the code changes in the first post. I'll try both his first and second post and get back to you.
I just checked the patch list and yeah, it's the successor patch by Leetsketcher. I want to try both of Bropedio's code blocks before I try to roll that back, though.


EDIT: Tried it with the code from the second post. In-line version crashed, which means it's definitely fighting another patch (and not a problem with this patch itself). Freespace version 'worked' in that it didn't cause any problems, but it had the same issue Bropedio's first segment did (HP level triggers were not activating). Removing Leetsketcher's Item/Magic counter code did not resolve that issue, and neither did removing Imzogelmo's 5 byte fix to the crackboom-sap bug (which I also had applied; found it in my notes).
Imzo's code doesn't so much 'fix' the animation as it does guarantee an on-death script occurs... which is really weird when sap triggers it because an empty space will quake and disintegrate.

Anyway, sorry I couldn't be more helpful; I'm not sure anything from my experience is useful.
  Find
Quote  

#13
Posts: 16
Threads: 3
Thanks Received: 0
Thanks Given: 0
Joined: May 2019
Reputation: 2
Status
None
(01-21-2021, 01:59 PM)C-Dude Wrote: It was only the code changes in the first post.  I'll try both his first and second post and get back to you.
I just checked the patch list and yeah, it's the successor patch by Leetsketcher.  I want to try both of Bropedio's code blocks before I try to roll that back, though.


EDIT: Tried it with the code from the second post.  In-line version crashed, which means it's definitely fighting another patch (and not a problem with this patch itself).  Freespace version 'worked' in that it didn't cause any problems, but it had the same issue Bropedio's first segment did (HP level triggers were not activating).  Removing Leetsketcher's Item/Magic counter code did not resolve that issue, and neither did removing Imzogelmo's 5 byte fix to the crackboom-sap bug (which I also had applied; found it in my notes).
Imzo's code doesn't so much 'fix' the animation as it does guarantee an on-death script occurs... which is really weird when sap triggers it because an empty space will quake and disintegrate.

Anyway, sorry I couldn't be more helpful; I'm not sure anything from my experience is useful.

Thanks for giving the code a try, C-Dude -- sorry it didn't work out. I'm not sure what subtle collisions may be happening, but I did make a subsequent change to the second patch before adding it to the pending Brave New World beta. Testers have not reported any issues so far, but it's very possible that other changes in BNW may be masking side effects of my patch. Particularly, the nATB patch in BNW pauses time while animations play out, so it inadvertently resolves many of the queue issues that could arise.

In any case, my updated code is here:

Code:
org $C24BFD
DeathCounterFix:
 TRB $3A56        ; clear "entity died since last 1F"
 BNE .has_died    ; allow script if has died
 TRB $33FC        ; clear "no 1F this batch"
 BEQ .skip_it     ; bypass script if already run
org $C24C28
.has_died
 TRB $33FC        ; clear "no 1F this batch" if died override
org $C24C52
.skip_it

org $C24C68
RewritePrepare:
 STZ $B8            ; zero targets for counterattack
 STZ $B9            ; zero targets for counterattack
 LDA $B1            ; check for "normal" attack
 LSR                ; carry: "non-normal" attack
 BCS .skip          ; branch if ^
 LDA $32E0,X        ; "hit by attack"
 BPL .skip          ; branch if not ^
 ASL                ; get attacker index
 STA $EE            ; save in scratch RAM
 CPX $EE            ; target === attacker?
 BEQ .skip          ; branch if ^
 TAY                ; attacker index
 REP #$20           ; 16-bit A
 LDA $3018,Y        ; attacker unique bit
 STA $B8            ; save target for counterattack
 LDA $3018,X        ; current target bit
 TRB $33FE          ; flag to use full reactive script
.skip
 REP #$20           ; 16-bit A
 LDA $3018,X        ; current target bit
 BIT $3A56          ; "died since last reactive script"
 SEP #$20           ; 8-bit A
 BNE .react         ; branch if "died", so force script
 LDA $B8            ; else, check if was attacked by normal
 ORA $B9            ; ^
 BEQ .next          ; no counterattack if not ^
 LDA $32CD,X        ; entry point to counterattack queue
 BPL .retort        ; branch if already something queued
.react
 LDA $3269,X        ; top byte of reactive script pointer
 BMI .retort        ; branch if null ^
warnpc $C24CA8
padbyte $EA
pad $C24CA7
org $C24CB1
.retort
org $C24CBE
.next
  Find
Quote  

#14
Posts: 200
Threads: 1
Thanks Received: 10
Thanks Given: 0
Joined: Oct 2015
Reputation: 18
Status
None
C-Dude: what in blazes is "crackboom-sap" bug?  google comes up empty.  is there some new enemy whose counterattack script starts at a very high address?

are you up for testing my patch as well?  i'd like to see it put through its paces.  the download link is at end of my first post.

it's designed for a headered ROM.  being a beta, it assumes 107 free bytes at C2/6700, which probably conflicts with other patches.  if that's the case in your testing suite, then edit the free space addresses in each of the 3 .asm files, and reassemble them with the included .bat file.

any feedback would be much appreciated.

----

Bropedio: oy, BNW.  while it's nice that the nATB aspect you describe might cut down on existing interactions, it sounds like the rest of it could introduce a whole rat's nest of new ones.

i recall reading that they made changes to relax some counterattack restrictions.  since your patch here also relaxes restrictions (as does mine), we're talking relaxation on top of relaxation.  seems like a recipe for wacky side effects, if not infinite loops.

more specific than the direction on the strict<-->relaxed continuum is *how* they overhaul some monster counters.  for instance, start reading at Post #43 here:
https://gamefaqs.gamespot.com/boards/554...i/74506707
(and read thru #71, if you have the patience.)

FC 06 instead of the venerable FC 12?!?!
this stuff is barely recognizable, and has aspects of duct tape and spackle to it. Tongue   i'm not sure how you can confidently make a patch that works on both vanilla and that, given their changes.  are they reversing some of them now that your patch goes at the bug more directly?  or maybe they've abandoned the wackier stuff with the passage of time?
Quote  

#15
Posts: 16
Threads: 3
Thanks Received: 0
Thanks Given: 0
Joined: May 2019
Reputation: 2
Status
None
(01-22-2021, 06:14 AM)assassin Wrote: i recall reading that they made changes to relax some counterattack restrictions.  since your patch here also relaxes restrictions (as does mine), we're talking relaxation on top of relaxation.  seems like a recipe for wacky side effects, if not infinite loops.

more specific than the direction on the strict<-->relaxed continuum is *how* they overhaul some monster counters.  for instance, start reading at Post #43 here:
https://gamefaqs.gamespot.com/boards/554...i/74506707
(and read thru #71, if you have the patience.)

FC 06 instead of the venerable FC 12?!?!
this stuff is barely recognizable, and has aspects of duct tape and spackle to it. Tongue   i'm not sure how you can confidently make a patch that works on both vanilla and that, given their changes.  are they reversing some of them now that your patch goes at the bug more directly?  or maybe they've abandoned the wackier stuff with the passage of time?

The "countering counterattacks" bug you mentioned in the thread linked above is actually the reason I started looking at this sap death bug in the first place. It turns out, the "countering counterattacks" bug is in vanilla, too, due to how `$3A56` bypasses the `$B1` check at `$C2/4C92`. If a counterattack kills an enemy, that enemy's full reactive script will run -- in vanilla, this is mostly avoided by `FC 12` conditionals higher up in the reactive scripts for enemies that have other counterattack behavior. BNW also makes these situations more likely by increasing frequency of counterattacks across the board, and using `FC 05` far more often.

In short, I don't think BNW relaxes counterattack conditions. When I fixed the bug above, I noticed how the `$3A56` override was being ignored at `$C2/4C02`, which is how I stumbled onto my fix for the sap death bug.

Since my patch addresses the sap death issue, BNW could revert to using `FC 12` instead of `FC 06`, but it isn't necessary. The only side-effect of their approach is that Sap and Counters can no longer kill bosses at all (since bosses are prevented from dying except via an "HP <= 0" reactive conditional). I don't think the absence of "Death" conditionals on bosses would have any impact on my patch. The normal enemies that use `FC 12` will work now, though.
  Find
Quote  

#16
Posts: 377
Threads: 34
Thanks Received: 10
Thanks Given: 7
Joined: Dec 2018
Reputation: 18
Status
Moog
(01-22-2021, 06:14 AM)assassin Wrote: C-Dude: what in blazes is "crackboom-sap" bug?  google comes up empty.  is there some new enemy whose counterattack script starts at a very high address?

are you up for testing my patch as well?  i'd like to see it put through its paces.  the download link is at end of my first post.

it's designed for a headered ROM.  being a beta, it assumes 107 free bytes at C2/6700, which probably conflicts with other patches.  if that's the case in your testing suite, then edit the free space addresses in each of the 3 .asm files, and reassemble them with the included .bat file.

any feedback would be much appreciated.

What I describe as a 'crackboom-sap' bug is basically what this thread is trying to solve.  A boss gets killed by a sap or poison proc, dying in a purple flash instead of triggering its on-death script condition.  The code from Imzogelmo I shared makes sure it does trigger that condition, but doesn't make sure the enemy hasn't been removed first!  So the boss will die in a purple flash, and THEN do its "Dies like a boss" animation.
I did repurpose enemy 0 as a very fast invisible monster to handle some extra battle reactions; its own counters could be interfering with things.

I'll give your patch a try.  I'll have to move it by hand instead of recompiling it, since I can't run xKas and Asar introduces errors, so it may take a while (and I don't have time to look into it today).
  Find
Quote  

#17
Posts: 200
Threads: 1
Thanks Received: 10
Thanks Given: 0
Joined: Oct 2015
Reputation: 18
Status
None
C-Dude: reading that patch's code, i am utterly failing to grasp why it should make any difference whatsoever -- unless there was a monster whose counterattack script pointer was some very high value (e.g. E000h), most likely in a hack/expansion.  do you know where this was originally posted?

thanks; no rush.  on xKas, are you using a non-Windows OS or something?

--------

Bropedio: ah, glad to have clarity on the origins of that.  so it's the discrepancy with $B1 and $33FE checking we discussed earlier in the thread.  while i agree it's odd and does provide a loophole, i'm not quite convinced it's a bug.  that is, i'm on the fence enough to defer to Square and preserve existing behavior.  i provide some of my reasoning in Item #4 of this post:
https://www.ff6hacking.com/forums/thread...l#pid39449

am interested in your thoughts on those reasons.
Quote  

#18
Posts: 377
Threads: 34
Thanks Received: 10
Thanks Given: 7
Joined: Dec 2018
Reputation: 18
Status
Moog
(01-22-2021, 05:26 PM)assassin Wrote: C-Dude: reading that patch's code, i am utterly failing to grasp why it should make any difference whatsoever -- unless there was a monster whose counterattack script pointer was some very high value (e.g. E000h), most likely in a hack/expansion.  do you know where this was originally posted?

thanks; no rush.  on xKas, are you using a non-Windows OS or something?

Warrax gave me the information as a short response in a hack discussion thread.  There's basically no other documentation accompanying it.

https://www.ff6hacking.com/forums/thread...l#pid37811

I got the feeling that the sap was consuming the existing counter, so the code increments the counter before proceeding so that both sap damage and the counter script execute.  I don't know the specifics, though; this is untread ground for me.  I do know it DOES make a difference, though, because without it my hack would skip the death trigger entirely on a sap tick, but with it it at least triggers the boss death animation and sounds (even if there's nothing on screen to actually fade out).
---
As for xKas, I'm running Windows 10 and it likes to immediately crash.  I think I can do something with it where I name the file the same as the demo or something; it's been a long time since I tried.  I'm usually more comfortable working directly with the hex.  I will TRY to get it working to test your patch, but looking at the .asm file there's not a whole lot of subroutines to look out for; it seems like very moveable code.

EDIT: I do not have 107 continuous bytes of free space in the C2 bank! What little was left apparently got eaten up by changes to the ending names ("Biggs delNorte" takes up a lot more space than "Umaro"). I might be able to adjust your code to jump into a more spacious bank, like C0 or C3. I will look into this.
  Find
Quote  

#19
Posts: 16
Threads: 3
Thanks Received: 0
Thanks Given: 0
Joined: May 2019
Reputation: 2
Status
None
(01-22-2021, 05:26 PM)assassin Wrote: Bropedio: ah, glad to have clarity on the origins of that.  so it's the discrepancy with $B1 and $33FE checking we discussed earlier in the thread.  while i agree it's odd and does provide a loophole, i'm not quite convinced it's a bug.  that is, i'm on the fence enough to defer to Square and preserve existing behavior.  i provide some of my reasoning in Item #4 of this post:
https://www.ff6hacking.com/forums/thread...l#pid39449

am interested in your thoughts on those reasons.

My gut tells me that it's a bug, or at least an oversight. As I mentioned above, the countering-counters issue doesn't really arise in vanilla, primarily because `FC 12` death conditionals short-circuit them. I understand your point about "Counterattacks" being conceptually different than "Periodic Damage", but that doesn't square (pardon the pun) with the fact that they only behave differently when their target dies. And it doesn't make sense for Square to program an exception that promotes counterattacks to "fully fledged" attacks in the context of fatal hits, but then for that exception to (practically) never arise in normal gameplay. It seems far more likely to be an oversight that was simply never addressed because it never materialized during testing.

My guess is that the "sap death" bug cropped up during their testing cycle, so they inserted the $3A56 and $33FE variables to fix it up. It would have been very easy to overlook the $B1 conditionals, or to insert the $3A56 conditional on the wrong side of the counter-duplicate conditional $33FC. Their development timeline was very short, after all.
  Find
Quote  
[-] The following 1 user says Thank You to Bropedio for this post:
  • assassin (01-23-2021)

#20
Posts: 377
Threads: 34
Thanks Received: 10
Thanks Given: 7
Joined: Dec 2018
Reputation: 18
Status
Moog
@Assassin
I was able to get xKas to spit out a binary file for me, which I could then transfer to the appropriate addresses in my own file using HxD.  So yay, I know how to do that now.

I had to alter your code to jump to the C0 bank and return long, since I lacked the space to fit it in C2.

It... somewhat works.  Seizure correctly triggers a monster's death counter, but it is not triggering the "Monster HP at or below <X>", the FC 06 battle script command.
I had to remove Imzogelmo's code (the block I shared earlier) to get yours to work, but removing Leetsketcher's Item/Magic counter patch (by coping the vanilla Hex from its associated addresses) made your new function do nothing.  I think there might be problems with my Vargas script, which I tweaked to handle bugs introduced by the latter patch (Leetsketcher's).

Here's my nonStandard Vargas script if you care to look at it.  I have yet to test your patch against any other bosses as I was having trouble here.
Setting seizure and standing around to wait lets Vargas bypass the 'Off with ya now!' event.
I think Vargas is a good monster to test these things on because he's got a lot of moving parts: he's got an in-battle event, a timer, a targetability toggle, and several HP checks (well, Vanilla Vargas has several, I truncated it to one).

EDIT: If struck once by anything (even a spell that does nothing, which my status monster casts IF a status is present) after Seizure is applied, the script will run as expected. So there seems to be an edge case where Seize is inflicted and then no other damaging exchange occurs.
  Find
Quote  
[-] The following 1 user says Thank You to C-Dude for this post:
  • assassin (01-23-2021)



Forum Jump:

Users browsing this thread: 1 Guest(s)


Theme by Madsiur2017Custom Graphics by JamesWhite