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)



Messages In This Thread
RE: Error in Imp affecting call monster sprite - by assassin - 03-13-2021, 11:31 AM

Forum Jump:

Users browsing this thread: 1 Guest(s)


Theme by Madsiur2017Custom Graphics by JamesWhite