Glitches and Bugs guide updating thread

Talk about all aspects of the gameplay of Final Fantasy 3us/6j.

Moderators: General Moderator, Game Moderator

Re: Glitches and Bugs guide updating thread

Postby Assassin » Tue Oct 08, 2013 10:45 am

all of this is giving me pause in my planned fixes for the Piranha and Possessed monster bugs (the foes end up gone but not entirely, and can be sorta revived.. this was discussed awhile back in this thread and Novalia's). i'd planned to supplement Piranha's Hide command (FB 0D nn) with a flagging in $2F4D (mark enemy to be removed from battlefield), but this might open it up to the same fleeing bug.

i also had the same $2F4D flagging plan for Possessees, as it's already done for PossessORs. while there aren't any monster-transitioning battles (ala Chadarnook or Piranhas) to use Possess in, the intended change could let Possess end the battle slightly sooner when there's one monster left, possibly suppressing how the enemy could respond in its script. depending on one's views (it can be argued that a command which thoroughly eliminates the attacker should do the same for the target), this isn't necessarily desirable.

Piranha is just fucking weird, anyway. it's the only monster in the game to use "FB 0D nn" (Set Hide status on self), even though Hide status could have been designated with FB 0B 1D, the more general "Quietly gain status" command. (it goes through more steps to set the status this way, but ought to work.)

it's also the only monster to have a certain custom flag set in the ROM data. up until now, i thought it was simply "Removable Float" (rendered moot by the "Permanent Float" Piranha also has), but it turns out that is just a side effect of Square using Monster Status Byte 4. the real purpose is to modify the behavior of Function C2/1429 slightly, so that Piranha is cleared from $2F2F (bitfield of remaining enemies?) a little more readily than other monsters are.

given these two special cases and that the enemy appears early in the game, i figured it was handled before Square really got their footing, and that they didn't know what they were doing. but learning that Ifrit and Shiva (and possibly other similar battles) can be run from, maybe i should show this lunatic enemy some deference, even though its implementation reeks of fudging things.

i really wish i understood all the subtle nuances involving Variables $3A3A, $2F2F, and $3409. there are all sorts of bytes used to indicate varying degrees of monster presence, along with the ubiquitous Bit 0 of $3AA0,X. it feels like every time Square got an illogical result in battle, they came up with another byte+bit to provide a slight divergence in meaning. :/
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Novalia Spirit » Tue Oct 08, 2013 1:34 pm

Assassin wrote:you can run from the Ifrit and Shiva fight!

It's worth noting that the bug also applies to the following enemies:
  • Ultros at the Gathering Place of the Espers, after he goes all the way in front and submerges.
  • Master Pug, when returning to its original position.
  • Pugs, when returning to their original position, if there's only one enemy remaining.
I recall coming to the conclusion that these scenarios work because they don't have any dialogue or event interfering with the process. It's been about 5 to 7 years since I made this research, and I don't remember how thorough it was, so it might be worth investigating the other possibilities just in case.
User avatar
Novalia Spirit
Regular User
Regular User
 
Posts: 268
Joined: Tue Aug 30, 2005 5:30 am
Location: Quebec

Re: Glitches and Bugs guide updating thread

Postby Assassin » Tue Oct 08, 2013 10:30 pm

i wonder whether having the switching commands in the counterattack script as opposed to the main prevents the running bug, as counters have a higher priority.

is Opera House Ultros fleeable during his transitions if the text commands are deleted? (i assume he isn't normally.)

---------------

as for my last post, maybe add an "F5 nn 01 nn" command (with no animation) after the new Piranhae/Rizopas are summoned. aside from being Captain Assembly (tm), i'm not nuts about script fixes that involve additions, because they have to relocate gobs of other monster scripts. thus, they're nigh-guaranteed to be incompatible with practically every other patch that modifies any script. oh well; i can always have an "FF3usMe Instructions" section in the patch Readme.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Lenophis » Wed Oct 09, 2013 1:51 pm

I also knew about it, and PB took the approach to change the Ifrit/Shiva transition so the esper comes in first before the other flees, never leaving an opportunity for the "can't run!" flag to be cleared. It's a pretty hackish "fix." :p This was also some inspiration for a hack I did to not let you build up run success in battles where it's impossible until all monsters with that bit set are dead. ;)
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: Glitches and Bugs guide updating thread

Postby Assassin » Thu Oct 24, 2013 7:29 am

To recap "Imped Ragers keep automatic movement, but not anything else", there are two obstacles to you keeping/getting the monster properties:

1) A routine that is called upon Imp toggling, Rage ending, and mid-battle equipment changes recalculates the character's properties from his or her current equipment and relics. It does not account for any present Rage (as it doesn't need to in the last 2 cases). Thus, the Rager loses monster properties upon Impage (an exception is that they'll keep statuses, as nothing outright removes them, but any ones that were permanent will no longer be so *).

2) Normally, a Rager gets monster properties every Rage turn, so #1 alone would be a minor speed bump. However, Rage is one of the commands that gets swapped out for Fight if the attacker is an Imp. Thus, the Rager misses their chance to regain the properties.

* Ok, some will, due to the "Permanent miscellaneous status" bug, but let's not rely on that.

----------------

The fix for each part would look like:

1) Alter the "recalculate character properties" routine to check for a Rage on the character, and if so, give him or her the relevant monster's properties after handling equipment properties.

2) Don't have the Rage command swapped out for Fight on Imps. Rather, perform Rage, but have it check for Imp status; if detected, still load monster properties, but always do Battle as the attack.

I'm pretty sure I'll need to do #2, and it will resolve most of the problem. That leaves the question of whether I should also do #1. There are trade-offs each way:

- If I don't do #1, the character will have to wait until their next Rage turn to regain the monster properties, when they really shouldn't have lost them in the first place. So a Chaos Drgn Rager who gets Imped can momentarily be hurt by Fire, for instance.
- If I do do #1, the character will arguably regain some statuses too early. Suppose an Anguiform Rage gives (removable) Dark. I cure it with an Eyedrop. Normally, the character won't get Dark back until the next Rage turn (the recurrence is odd in its own right, but that's how the game works). However, should they get Imped, they'll regain Dark right then and there.

Thoughts?
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Lenophis » Fri Oct 25, 2013 12:12 am

Liquor is needed. :lol:

If Imp makes you regain the statuses quicker, why can't a similar call be used? I'm really beginning to dread the flow of this game...
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: Glitches and Bugs guide updating thread

Postby Assassin » Fri Oct 25, 2013 9:08 am

c2/2DC1 is the routine to load monster properties relevant to Rage, and that's what I was going to call. if I want to exclude just one thing from it, I'd either have to duplicate most of it piecemeal, or zero the Status to Set bytes after calling it.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Assassin » Mon Nov 04, 2013 12:13 am

To draw all of these together:

viewtopic.php?f=2&t=109 (item #1)
viewtopic.php?p=1522#p1522 (Muddling isn't a requirement, though it introduces the aspect that you won't see the non-final counter either)
viewtopic.php?p=6609#p6609
viewtopic.php?p=6869#p6869 (not the bug itself, linked in the post above it, but the oddities I noticed while messing with it)

A theme in many of these is a monster sustaining lethal Poison/etc status damage within a short span of being hit normally.

There are two factors contributing to the cases of aborted final attacks:

----

1) In Function C2/4C5B, which is what prepares counterattacks in response to being hit, the game will skip queueing of the counterattack (Command 1Fh) if the monster already has a counterattack or periodic damage/healing (from Regen/Seizure/etc.) queued. (These two things use the same queue.)

While I haven't come up with a scenario where a queued periodic damage/healing prevents a counter, what can happen is that a queued counterattack (due to a "normal" and non-fatal hit) prevents periodic damage/healing from triggering a counter of its own.

----

2) The game handles queued actions in "batches" of decreasing priority:

  • Special actions, including expiring of timed statuses and auto-spellcasts from equipment
  • Counterattacks and periodic damage/healing (from Seizure/Regen/etc.)
  • Wait to Act queue (yes, there's an ordering to see who will enter their "ready stance" first)
  • Normal action queue
A given entity is only allowed to execute one Counterattack Command (1Fh) in a batch. Should a counterattack command be triggered in response to a counter or periodic damage/healing in a batch, it'll be added to the end of the same batch. Note that this command involves parsing the monster's counterattack script in response to C2/4C5B detecting it was hit. It doesn't necessarily mean the monster takes any action (i.e. attacks/spells/etc), as seen in the Retainer case.

----

Why are these measures necessary if Function C2/4C5B normally limits the triggers of counterattacks to normal attacks (i.e. no other counters, no periodic damage/healing, no "special actions")? It's because this requirement is waived should an entity's $3A56 flag be set, due to it dying. After all, we don't want to cancel something as important as a final just because the monster died via unconventional means. So these steps are probably here to prevent a monster from (continuously) countering its own final somehow, though I'm not sure. If events are sequenced such that an additional counter gets past #1, #2 will catch it.

I don't know how the skipped final attack bug would be fixed, given its causes stem from intentional precautions. A straightforward but RAM-intensive way would be to give periodic damage/healing a separate queue from counterattacks, with a lower priority. However, this would mean that Poison/Regen/Seizure/Phantasm rounds could no longer occur during a string of counterattacks. A subtle but noteworthy change in how a battle unfolds. Also, it still wouldn't fix the Chadarnook variant of the bug, as that one's rooted in the foe not countering its own counterattack, and thus seems to be a product of good design.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Lenophis » Mon Nov 04, 2013 8:33 pm

Assassin wrote:So these steps are probably here to prevent a monster from (continuously) countering its own final somehow, though I'm not sure.

I would think it would be easy enough to check. The periodic seizure/regen/poison has to set itself as the target, so there's two methods right there you could check for to see if you should counter yourself. Some animations draw a queue where you'll see 3 or 4 poison ticks, so I guess my question is how far back does the buffer go? If it keeps enough animations in store, you could simply scroll through the regen/poison/seizure calls and look for the previous attack that hits. Could that be viable?
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: Glitches and Bugs guide updating thread

Postby Assassin » Tue Nov 05, 2013 10:26 am

i'm sorta following.. carving out exceptions for periodic seizure/regen/poison would require a few changes:

in Function C2/4C5B (dealing with Step #1 from my prior post):
- if it's periodic damage triggering the counterattack (testable by checking the Command #), then skip the requirement that a counterattack or periodic damage/healing can't already be queued. the easiest of the additions. EDIT: if something's already queued for an entity, maybe verify that the entity is actually the one being hit by the Poison/Seizure/etc before proceeding.
- if an entity has periodic damage/healing but no counterattack queued, allow for a new counter to be queued. this'd be more involved.. i probably would need to use $32CD,index to look into the $3184 structure and find all of the entries for the entity, then check these entries' command numbers in the corresponding slots of $3420 to see whether they match seizure/regen/poison or the counterattack command. this check is geared towards stopping a queued periodic damage/healing from preventing issuance of a counterattack -- as mentioned in my last post, it's a scenario i don't know whether can happen, but am regarding as possible.

later on in the process (dealing with Step #2 from prior post):
- this'd be when deciding whether to execute the queued commands. i'd somehow need to detect whether a counterattack command was triggered by periodic damage/healing -- a piece of information that isn't currently present, so i'd have to create a field/flag for it. and if it was, exempt it from the one-counter-per-entity-per-batch rule. easily the hardest of the three additions, and definitely beyond me.

-----------------

so the third one is the most difficult. however, even if i might be able to code the first two changes (dealing with C2/4C5B), i still don't know enough about the game's counterattack and queueing system to say that implementing the additions wouldn't break something.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Assassin » Sat Nov 09, 2013 9:54 am

Enemy graphic stays flipped, edition NN -

Muddle an enemy, causing it to flip around. Then Zombify it. That causes the enemy to disappear while still randomly attacking, and because of how late Zombie boots out other statuses (e.g. Muddle), the Muddled removal "side effect" is never called, and the foe's "flip graphic" bit remains set. Then Revivify it, achievable by having somebody select the item before the Zombification takes hold.

Now, you'll have a living, un-confused enemy that is still facing backwards.

This is highly unlikely to pop up in gameplay, given that your party doesn't have access to Zombifying attacks, outside of Sketch and Control/Muddled/Charm.

As for a remedy, it's already pending. I was expanding my "Disrespectful Zombie" bugfix to call the "side effect" routines of statuses specially removed by Zombie, after realizing in Summer 2012 that Zombifying a Sleeper won't zero their Sleep timer, even with my "Auto-expiring statuses don't reset their timers with manual removal fix" applied. That's a harmless bug outside of wasting CPU cycles, but still illogical.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Assassin » Fri Nov 15, 2013 11:56 am

As for Lord Bob Bree's Petrified monster omni-counter bug (linked at viewtopic.php?p=6864#p6864), the cause stumped me at first, and I never really investigated it until a couple weeks ago.

When statuses are set or cleared, they have various "side effects" they can trigger, which include marking other statuses to be cleared in the former case, and altering variables. Wound, Petrify, and Zombie all turn on an entity's $3A56 flag (which has a role in counterattacks) when they're granted, and the first two also mark for removal a boatload of statuses. Petrify has unique treatment in Function C2/450D in that it's added to "Statuses to Set" and made to trigger its side effects as long as the status is present. This is apparently done to repel Muddled/Mute/Clear/Dark/etc for its duration.

Normally, limits are imposed by Function C2/4C5B to when a counterattack can be triggered. It has to be in response to a normal attack (i.e. no other counters, no periodic damage/healing, no "special actions"), the entity has to have been a target of the attack, and it won't come from an entity attacking itself (unless there was a spell reflection involved, as the reflector is considered the "attacker" in some regards). However, should an entity's $3A56 flag be set, which happens from receiving terminal statuses, these restrictions are skipped, so as to allow a final counter.

It's mostly a one-time skippage, because the $3A56 flag gets cleared when the counterattack command (1Fh) is run. However, the continual re-invoking of the Petrify side effect means the bit in $3A56 will be turned on over and over at the end of anybody's turn. Thus allowing the omni-counter.

A fix would probably entail changing C2/46A9 to skip setting $3A56 if the entity already had one of the three terminal statuses. Or if we don't want to mess with a hypothetical ChokeSmoke, then have the check see if Petrify status is being (re-)given and was already present.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Assassin » Sat Nov 30, 2013 7:58 am

@Imzogelmo:

13 months ago, with regards to a pending patch of mine, you made the case that equipping Thornlet and Cure Ring shouldn't just cancel each others' statuses at the outset, but the presence of both relics should also prevent you from giving the target Regen or Seizure later in the battle via other means (i.e. attacks). i agreed, and accounted for it in my code-in-progress.

yesterday, another scenario dawned on me. in the original game, equipping Ribbon + Thornlet + Cure Ring will allow the last gear's Regen, because Seizure immunity stops Seizure from trying to be set at the same time as Regen at battle start. for purposes of my patch, do you think this allowance should extend to wearing Ribbon + Thornlet and casting a Regen spell later? on one hand, Thornlet's "anti Regen force", for lack of a better phrase, is present, and perhaps should fend off that status. on the other, Ribbon + Thornlet + Cure Ring does establish a bit of a precedent, and its behavior is determined outside of the flawed function (C2/2675) i'm editing in this bugfix (though that doesn't necessarily make its sensibility ironclad).
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Imzogelmo » Tue Dec 10, 2013 2:20 am

In light of this new information, it seems there is some, albeit tiny, bit of precedent of precedence in the game. I suppose that such should be preserved, even though I still see the logic of mutual-cancellation as being the most consistent.

This certainly is an interesting wrinkle, and I'm not sure what would be the best solution. Although I do consider a spell-cast Regen to be somewhat inferior to an equipment-bestowed permanent Regen, I can see the potential confusion that would arise from treating them differently. If I had to decide, I'd say that the spell's inferiority would mean it gets shut out, while the equipment would still be able to have its effect.
User avatar
Imzogelmo
Veteran
Veteran
 
Posts: 659
Joined: Wed Sep 08, 2004 4:07 pm
Location: On the spirtual plane

Re: Glitches and Bugs guide updating thread

Postby Lenophis » Thu Mar 05, 2015 3:37 am

So Psycho Cyan may need some updating...
http://www.twitch.tv/thelcc/c/6234569

I do find it strange that Imp was never involved...
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: Glitches and Bugs guide updating thread

Postby Assassin » Thu Mar 05, 2015 2:23 pm

weird. as is his Number 128 video, particularly the end (edit: ok, i think that's just the Retainer variant of the thwarted enemy finals bug discussed here not too long ago, but the Blade still being present gives the body another shot at a final).

i dunno whether you're referring to the bug description or to the patch needing update, but Terii's fix is not Imp-specific:
http://www.rpglegion.com/ff6/hack/psycho.htm

and i assume the video is made on a vanilla game (i.e. without that patch)?
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Lenophis » Fri Mar 06, 2015 1:20 am

I'm not 100% sure if the video uses a vanilla game or not, but seeing the counters in the bottom corners definitely says it's an emulated video. I *hope* it's a vanilla game, and I'm not being lead on.
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: Glitches and Bugs guide updating thread

Postby Assassin » Wed Jul 29, 2015 3:21 pm

very belated post here. think i know what's going on with Retort re-activating from Sleep tapir:

- as already known, Cyan dying makes Retort an omni-counter.
- somebody hits an entity, queuing Retort.
- during hit animation, Sleep status auto-expiration kicks in for Number 024, and queues removal.
- latter has uber-high priority, so occurs BEFORE Retort. this means Retort flag is still set during the removal, allowing another counter to be triggered by it.
- first Retort counter runs, turning flag off.
- second Retort runs, but detecting flag is off, acts as re-activation instead.

i've been able to readily duplicate this against a group of Crawlers hacked to have Stop status.

still no idea why the other bizarre Retorts occur, and i've only duplicated them minimally.
Last edited by Assassin on Wed Aug 12, 2015 1:20 am, edited 1 time in total.
Reason: minor clarifications
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Assassin » Sat Sep 19, 2015 11:15 pm

Intent multi-caster -

If a character inputs two spells with X-Magic, and is Muddled or Zombified
during his or her ready stance, the first spell will retarget as usual, but the
second retains its original target(s). There is no problem with an
already-Muddled character who chooses X-Magic and the spells randomly, nor with
one whose spells are inputted while being hit by a Muddle/Zombie-granting
attack.

What's happening is that there is a variable that gets cleared for an entity
when it performs most commands or enters a ready stance, and is set when it has
Zombie or Muddled statuses granted or removed. (So it indicates whether either
status has changed since the former events.) When most commands detect this
variable is set, they'll clear targets, so they can be rechosen later.
However, because the Gem Box spells are two separate commands, and the variable
is cleared by the first, the second won't have its targets affected.

Not sure how to fix this.

---------------------------

A related probable bug: Magitek users who get Muddled/Zombied during their
ready stances won't have their targets change. Commands >= 1Dh are exempted
from reading or clearing the aforementioned variable, probably so commands like
"Run Monster Script" or Periodic Damage/Healing (e.g. Regen) aren't affected.
Why Square lumped in Magitek with these instead of testing for >= 1Eh eludes
me.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Djibriel » Tue Oct 20, 2015 4:04 pm

Some guy at GameFAQs taught me that Cyan's Retort upon first activation (not execution) will remove Clear from a random enemy target. That's as logical as Bomblet removing Clear, which is not at all.
"The population in Iraq is over 80% Shi'ite. Couldn't the same be said about your music, Mr. Durst? "
User avatar
Djibriel
Regular User
Regular User
 
Posts: 354
Joined: Wed Sep 08, 2004 3:45 pm
Location: Outsider!

PreviousNext

Return to FF3 Gameplay Discussion

Who is online

Users browsing this forum: No registered users and 2 guests

cron