Error in Imp affecting call monster sprite

Howdy,

Gi Nattak referred me to this thread when the same bug was reported in ROSE, which has both Imp Skimp and Unaffected Rows.

The patch periodically compares each enemy's "displayed" Imp status with its "actual" Imp status, and if the two disagree, then the displayed sprite is updated accordingly.

The problem is, sometimes the status bit for the "actual" Imp status is not up to date, leading to at least two issues:

1. The SrBehemoth fight. The undead SrBehemoth replaces the living one in the same slot, and the Imp bit never gets cleared. The undead SrBehemoth is immune to Imp. The patch runs the check, and invalidly attempts to replace the normal enemy sprite with an Imp.
   
2. The Pugs fight. According to LeetSketcher, their appearance should not revert from Imp to normal whenever they step back, because they still have Imp status at the time. But the Pugs' statuses DO actually revert to normal automatically after stepping back; just not right away with the bit checked by the patch. (With the patch applied, Pugs will abruptly change from the Imp sprite to normal when the "actual" Imp status bit finally clears -- not very appealing.)
   

To fix the above, revert these two subroutine calls to the original:

Code:

Executes upon new enemy appearing (i.e. SrBehemoth; start of battle)
> Imp Skimp v1.4:
C1/9369: 20 1B D7    JSR $D71B
> Original FF3us v1.0:
C1/9369: 20 7C 25    JSR $257C

Executes upon enemy regenerating (i.e. Pugs; undead+Doom)
> Imp Skimp v1.4:
C1/93C5: 20 1B D7    JSR $D71B
> Original FF3us v1.0:
C1/93C5: 20 7C 25    JSR $257C

I will be posting any further developments to this solution in the FF6:ROSE thread or the C. V. Bug-Fix Compilation thread.

I have also looked into Assassin's solution above for Unaffected Rows, and have found the following:

• The code called out by Assassin does not normally execute, at least not during the SrBehemoth fight. My guess is that it only applies to "hacks that introduce formation switches differing from SrBehemoth's" --- so, this is not not a problem for Vanilla FF3us formations.
  
• The code is indeed bugged.
  

try changing C2_2E75_helper's

LDA $B1/pha/.../pla/sta $b1 to:
ldx $b1/phx/.../plx/stx $b1 .

if we're worried about altering X's value from vanilla, we can probably edit only the first 2 instructions.

• Assassin's first suggestion, the X-preserving variant, fixes the bug.
  
• The full revision should work too. After the function, X gets written before the next time it gets read.
  

So, this is the fix I confirmed:

Code:

> Unaffected Rows v0.20:
C2/50AF A5 B1       LDA $B1
C2/50B1 48          PHA
> Fixed:
C2/50AF A6 B1       LDX $B1
C2/50B1 DA          PHX

---

UPDATE 2020-10-21:
My original post erroneously reported the original FF3us 1.0's C1/9369 and C1/93C5 as the following:

Code:

C1/9369: 20 25 7C
C1/93C5: 20 25 7C

Sorry for the confusion! The error was is pointed out by Gi Nattak in the following post.
This post has been updated to fix the error.

Always remember your endianness, friends!