Users browsing this thread: 1 Guest(s)
Error in Imp affecting call monster sprite

#11
Posts: 200
Threads: 1
Thanks Received: 10
Thanks Given: 0
Joined: Oct 2015
Reputation: 18
Status
None
(10-17-2020, 01:15 PM)SilentEnigma Wrote: Howdy,

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:

  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.)

re #1: no, the living is in the 1st slot, and the undead in the 2nd.  are you by chance using Dragonsbrethren's SrBehemoth fix, which puts a non-present living SrBehemoth in the 2nd formation's 1st slot so its data-dictated prize will be given after the 2nd battle?

aside: this does raise a point that hackers making custom formation interchanges/summons should avoid reusing slots between formations (aside from special cases like DB's), especially when the slot's new inhabitant is a different monster.  i see no sign of the game clearing statuses, nor properties like elemental reactions.  given there's only a single script-invoked formation swap in vanilla, and reuse is avoided, it's hard to say whether Square dropped the ball by not clearing/defaulting properties; the sample size is simply too small.

back on topic: so i suspect that the undead SrBehemoth isn't _directly_ having its graphics operated on.  rather, the absence of FFh in the top byte of the living one's Monster ID will let C1/205A (and in turn C1/202F) be called for the absent foe.  (see more modern C1/202F and C1/205A comments in: http://web.archive.org/web/2014062408535...c1bank.txt , btw.)

when that's combined with a patch that is more vigilant about setting $62C2 flags and redrawing things, the graphical weirdness results!

if Dragonsbrethren's patch puts living SrBehemoth at coordinates matching or overlapping the undead, the latter could be compromised as a side effect of operating on the former.  in that case, moving them apart might dodge the problem, though i suspect oddities would still show up in the living's new spot.

maybe the C1/2597 check needs to be expanded to also exclude non-present enemies, using variables like $201E or $61AB.  however, i'm loathe to modify a well-traveled function and risk all sorts of side effects.  another approach might be to add the check to Leet Sketcher code in Function C1/303C or such.

but i reckon the first thing to do is test my theory by trying the Imping and battle transition without DB's patch applied, and see whether the problems go away or even decrease.
Quote  
[-] The following 1 user says Thank You to assassin for this post:
  • SilentEnigma (03-21-2021)

#12
Posts: 173
Threads: 23
Thanks Received: 20
Thanks Given: 6
Joined: Feb 2016
Reputation: 8
Status
Enlight
I must admit I've lost the plot since last fall, so bear with me...

(03-13-2021, 11:31 AM)assassin Wrote: re #1: no, the living is in the 1st slot, and the undead in the 2nd.  are you by chance using Dragonsbrethren's SrBehemoth fix, which puts a non-present living SrBehemoth in the 2nd formation's 1st slot so its data-dictated prize will be given after the 2nd battle?

...

but i reckon the first thing to do is test my theory by trying the Imping and battle transition without DB's patch applied, and see whether the problems go away or even decrease.

Huh. My investigation may well have been with Dragonsbrethren's fix applied at some point. Or I was making lazy assumptions  Confused
However, I can confirm that the symptoms are the same even without Dragonsbretheren's patch applied. That is: if you apply Imp Skimp 1.4 on vanilla, then beat the living SrBehemoth while it is Imp'd, the undead SrBehemoth will be invisible, etc.

(03-13-2021, 11:31 AM)assassin Wrote: when that's combined with a patch that is more vigilant about setting $62C2 flags and redrawing things, the graphical weirdness results!

Taking a guess, Leet Sketcher may have tried covering all bases by replacing every call to $257C, without necessarily knowing the context of each one.
I don't see any benefit to running the check when a new enemy appears, or when an enemy regenerates, so doing any more rocket surgery to accommodate those cases feels unnecessary at this point.
(Am I in the ballpark here?)

I am comfortable with sticking to the following...

(03-12-2021, 12:21 PM)Dev J Wrote: Wondering if anyone could update Imp Skimp with the fix, to a standalone patch?

I don't want to rev Imp Skimp myself (yet...), but try applying the attached patch on top of Imp Skimp 1.4. This will apply the fix I posted earlier:
Code:
Executes upon new enemy appearing (i.e. SrBehemoth; start of battle)
> Imp Skimp v1.4:
C1/9369: 20 1B D7    JSR $D71B
> Fixed (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
> Fixed (Original FF3us v1.0):
C1/93C5: 20 7C 25    JSR $257C

The attached patch is for unheadered FF3us 1.0 + ImpSkimp 1.4.
Of course, make a backup first!

.zip  ImpSkimp_SrBehemoth-Pugs-Fix_SE_NH.zip (196 bytes, 2 downloads)
Quote  

#13
Posts: 200
Threads: 1
Thanks Received: 10
Thanks Given: 0
Joined: Oct 2015
Reputation: 18
Status
None
(03-21-2021, 10:51 PM)SilentEnigma Wrote: I must admit I've lost the plot since last fall, so bear with me...

(03-13-2021, 11:31 AM)assassin Wrote: re #1: no, the living is in the 1st slot, and the undead in the 2nd.  are you by chance using Dragonsbrethren's SrBehemoth fix, which puts a non-present living SrBehemoth in the 2nd formation's 1st slot so its data-dictated prize will be given after the 2nd battle?

...

but i reckon the first thing to do is test my theory by trying the Imping and battle transition without DB's patch applied, and see whether the problems go away or even decrease.

Huh. My investigation may well have been with Dragonsbrethren's fix applied at some point. Or I was making lazy assumptions  Confused
However, I can confirm that the symptoms are the same even without Dragonsbretheren's patch applied. That is: if you apply Imp Skimp 1.4 on vanilla, then beat the living SrBehemoth while it is Imp'd, the undead SrBehemoth will be invisible, etc.

yeah, same here.  i get the invisible undead, and the cursor and any attack animations directed at it appear in the top right corner of the screen.  also, casting Slow on it crashes the game with a black screen (on this ancient version of Snes9x, anyway).

so much for my theory on DB's fix. :/

however, i also still see no evidence that the undead is sharing a formation slot with the living.  though i can't rule out Leet Sketcher's patch being fooled somehow into _thinking_ that they do.

Quote:
(03-13-2021, 11:31 AM)assassin Wrote: when that's combined with a patch that is more vigilant about setting $62C2 flags and redrawing things, the graphical weirdness results!

Taking a guess, Leet Sketcher may have tried covering all bases by replacing every call to $257C, without necessarily knowing the context of each one.
I don't see any benefit to running the check when a new enemy appears, or when an enemy regenerates, so doing any more rocket surgery to accommodate those cases feels unnecessary at this point.
(Am I in the ballpark here?)

well, in the hypothetical case of old and new enemies sharing a formation slot: will a new enemy entering clear the $62C2 flag by default?  if so, then barring a monster with start-up Imp status, i guess undoing the call redirect would be safe.

however, even if the patch's changes are *unnecessary* in certain circumstances, i wish i had a damned clue why they're *harmful* for SrBehemoths.

me Wrote:if Dragonsbrethren's patch puts living SrBehemoth at coordinates matching or overlapping the undead, the latter could be compromised as a side effect of operating on the former.  in that case, moving them apart might dodge the problem, though i suspect oddities would still show up in the living's new spot.

DB's just got it at (0, 0) default coordinates (which get automatically changed to (192, 0) by the Back attack).  that does partially overlap the undead; its rear 2 tile columns, all but the bottom tile row.

doubt that'd be enough to explain invisibility, if his patch were even required for the bugginess in the first place.
Quote  



Forum Jump:

Users browsing this thread: 1 Guest(s)


Theme by Madsiur2017Custom Graphics by JamesWhite