Users browsing this thread: 1 Guest(s)
Error in Imp affecting call monster sprite
06-19-2020, 02:30 AM
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.
06-19-2020, 10:22 AM
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..
(06-19-2020, 10:22 AM)madsiur Wrote: 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.
![[-]](https://www.ff6hacking.com/forums/ff9/collapse.png)
• assassin (06-20-2020), SilentEnigma (10-17-2020)
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").
10-17-2020, 01:15 PM
(This post was last modified: 10-21-2020, 02:41 PM by SilentEnigma.)
Howdy,
Gi Nattak referred me to this thread when the same bug was reported in ROSE, which has both Imp Skimp and Unaffected Rows.
To fix the above, revert these two subroutine calls to the original:
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:
UPDATE 2020-10-21:
My original post erroneously reported the original FF3us 1.0's C1/9369 and C1/93C5 as the following:
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!
Gi Nattak referred me to this thread when the same bug was reported in ROSE, which has both Imp Skimp and Unaffected Rows.
(10-16-2020, 09:51 PM)SilentEnigma Wrote: 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:
- 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.
- 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.
(06-20-2020, 01:36 AM)assassin Wrote:try changing C2_2E75_helper'sLDA $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.
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:
the offset bytes appear to not have received the 'reverse-byte' treatment, and should be:
Not sure if C.V. Reynolds caught that as well before updating his patch!
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!

We are born, live, die and then do the same thing over again.
10-21-2020, 02:19 PM
Oh, no!
And I posted that all over the place!
Thanks, Gi.
Will be fixing that pronto.
And I posted that all over the place!
Thanks, Gi.
Will be fixing that pronto.
« Next Oldest | Next Newest »
Users browsing this thread: 1 Guest(s)