Error in Imp affecting call monster sprite

After applying several Leet Sketcher's patches, testing and not crashing the game. I thought it went well until I discover that if I cast Imp on Live Sr Behemoth and kill it, the death version sprite that came out is corrupted.

Well the easiest fix is removing the patche(s) that cause this problem. Testing if the game doesn't crash is a good start but it doesn't mean there won't be more problem. You may also have a patch conflict that use the same free space and this is the result. I would inform leetsketcher when you find the culprit..

Well the easiest fix is removing the patche(s) that cause this problem. Testing if the game doesn't crash is a good start but it doesn't mean there won't be more problem. You may also have a patch conflict that use the same free space and this is the result. I would inform leetsketcher when you find the culprit..

Found the problem in using V1.0 us rom. If I apply Leet's Imp Skimp & Unaffected Rows from http://assassin17.brinkster.net/, then undead sprite is corrupted. 

So I just need to unpatch one of them.

no interactions between the patches jump out at me, and i can't say the following necessarily relates to the problem, but this:

Code:

LDA #$01
JML C2_2E75_helper

can't be doing what i intended, given the target function promptly clobbers A to preserve $B1 (a late-stage addition). :/

if $B1 holds 20h, i'll be calling some bogus pointer instead of a ($2E93, X) table entry. if it holds 00h, the toggle i'm attempting will fail.

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.

another alternative is to leave all 4 instructions untouched, change "JSR $2E75" to "JSR $2E77" (or "JSR $2E74"), and the caller's "LDA #$01" to "LDX #$02" (or "LDX #$01").

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!

Just a slight heads up, when reverting these two lines' values here:

Code:

C1/9369: 20 25 7C    JSR $257C
C1/93C5: 20 25 7C    JSR $257C

the offset bytes appear to not have received the 'reverse-byte' treatment, and should be:

Code:

C1/9369: 20 7C 25    JSR $257C
C1/93C5: 20 7C 25    JSR $257C

Not sure if C.V. Reynolds caught that as well before updating his patch! 

Oh, no!
And I posted that all over the place!

Thanks, Gi.
Will be fixing that pronto.