Users browsing this thread: 1 Guest(s)
Frozen-status bug

Posts: 2,185
Threads: 89
Thanks Received: 236
Thanks Given: 246
Joined: Aug 2009
Reputation: 40
Hello 24 years in the making, there's a yet-to-be-documented bug I've noticed from time to time, figured it was exclusive to my hack, found out it wasn't, asked around, then opted to make a thread about it after a suggestion to do so, in order to both help shed light on it and set it in stone amongst all the other many glorious bugs throughout FF6 history, and of course to possibly see a fix down the road by one of our many talented coder-folk. Smile

I'm basically just going to paste this stuff from my other notes and discussions because I'm burned out on re-wording all this multiple times...

About the bug and how to trigger it:

Firstly, a YT link to video showing the bug in action:
Note that the character does not need to be unfrozen with Fire in order to trigger it, I just did it here to speed things up.

With a high enough speed stat rating on a character, if you happen to input your action command of any kind in a very small window of time right before/almost during the monster begins to cast a frozen-status-inducing attack, be it a spell such as Cold Dust, or even a special attack with the freeze attribute (which there are non in vanilla), and if done at an exact correct window of time, and the freeze-inducing attack targets & hits said character, the character upon being unfrozen (wether it by timer or fire cast on them) will go into the ready to commence attack pose, but then nothing...ATB is frozen forever until dead, or runs away. The issued command never fully executes and the character becomes stuck.

Now in case anyone wants to look into this themselves, here's a handy srm data with a perfect place to trigger it the next room below the save point, with the steroidite, who frequently casts Cold Dust and is easy to manage:

The characters for this save data all have a speed rating of over 100, which is technically possible in a non-hacked 'vanilla' game. It needs to be high enough to trigger this bug easier, you see, to increase the small window of time you need to input a command before a frozen-status attack is cast by the monster. I've had it happen with around 60-80 speed, though, but it must have been like a single frame of time needed to trigger it then. Around 100 speed it's much easier, and at 120+ it's hard not to trigger it.

Besides altering the character's speed stat, nothing else was done to hack the srm file.

So far I've reached out to LeetSketcher, who recommend I get in touch with assassin, who provided a great theory about what's probably going on. To quote him (assassin), what is most likely going on here in regards to frozen status as the culprit is that it's:
"a status restrictive enough to make the character immobile, but not enough to arrest time or the gauge.  and a character fast enough to complete their ready stance, but not quite enough to preempt the monster's move."

So basically it's jamming up the progressing of the ATB gauge into commencing the next action due to too much going on, or something along those lines.

Furthermore, about the possible offender(s):
"there's a good chance it involves what i dubbed the "Great Satan Bits" in Variables $3AA0, $3AA1, and/or $3204."

He calls them that because:
"they're confusing as all hell, and tend to be set and cleared in combination with each other, so it's hard to isolate one of their effects -- and they're not always changed in the same combination, either."

I will also note that Cecil has been aware of this bug also, while playing Beyond Chaos, says that it:
"happens frequently enough in the Coliseum".

And that the character seemingly doesn't need that high of a speed stat, having a higher speed stat we all think just widens the window for this bug to trigger, to quote Cecil once more, having a higher speed stat:
"probably just helps you chew through the command delay faster".

Also just to note, Sleep and Stop status do not experience this bug because they do not commence with the attack after the status is up, like frozen-status does. To quote assassin once more so he doesn't need to potentially retype stuff here:

"one way to attack the problem for Freeze (which currently toggles no such bits in its "side effect" code) might be to have it behave like Sleep. however, this admittedly goes beyond bugfix into reinterpretation.  a somewhat restrained way would be to only do the gauge reset upon Freeze removal, but it still has the issue of _some_ overreach.  and i'm not entirely sure that setting the flag upon status clear will work properly without having altered the other flags on status set. if the character just took their damn action when thawing, that'd probably clear up the gauge issues and such.  so a "true" fix of proper scope would probably just enable this ... but hell if i know how."

So there it is, bug is now in the record books and will wait for a legendary hero to come along and eradicate it.

We are born, live, die and then do the same thing over again.
[-] The following 2 users say Thank You to Gi Nattak for this post:
  • Lockirby2 (01-15-2019), madsiur (01-10-2019)

Posts: 121
Threads: 1
Thanks Received: 41
Thanks Given: 3
Joined: Oct 2015
Reputation: 14
(from the PM) a correction of some of my comments:

Quote:to correct myself: Freeze does halt the ATB gauge, and presumably the Wait Timer (used in ready stances) as well.  but it does so without modifying those two bits that Sleep status does.

assuming it halts the Wait Timer (i should really confirm with a debugger), that helps explain how slower characters dodge the bug.  they're not completing their ready stance and attempting to queue their action until *after* Freeze is gone.  meanwhile, your fast character probably has the action queue occur at about the same time as the freezing.

but now i'm not grasping why Freeze has the bug and Stop dodges it. :/  Sleep i get, because it resets the ATB once removed.

some headway on a couple of the Great Satan Bits:

- $3AA0, Bit 4 has been known for awhile, but to repeat it: Entity is Wounded, Petrified, or Stopped, or somebody else is under the influence of Quick.
- $3AA0, Bit 6: (Bit 4 conditions) OR (Entity is Controlled, Asleep, Frozen, or Tentacle-Seized) OR (C2/00F9 has (tried to) execute(d) a conventional turn for this entity since C2/08C6 last ran for it).
- $3AA1, Bit 7: C2/00F9 declined to execute a conventional turn for the entity due to $3AA0 Bits 4 and/or 6 being set, and is requesting a "second chance" at Action or Wait queuing.

usually, the Action or Wait queuing happens in response to a timer filling up.  the fact that it can also happen in Function C2/08C6 makes me think "second chance" is on the right track, and that Square was trying to account for Sleep or something similar denying the conventional turn from happening.

beyond that, i dunno what's going on.  i still have yet to debug things to verify that the conventional turn is attempted, and that the character still has an entry in their conventional  queue to facilitate the second chance being granted, etc.

Posts: 241
Threads: 2
Thanks Received: 24
Thanks Given: 3
Joined: Apr 2013
Reputation: 3
I would have expected it to be due to the fact that Stop stops all other timers, whereas Freeze does not.

The only thing harder than finding a needle in a haystack is finding a haystack in a needle. Laugh

Posts: 121
Threads: 1
Thanks Received: 41
Thanks Given: 3
Joined: Oct 2015
Reputation: 14
but i'm not yet following why that difference is meaningful here.  per C2/1158, bits set by either status should be enough to pause the Wait and ATB Timer refills.  sure, Stop will also skip C2/5A83 (status timers, Battle Time Counter, periodic damage/healing, run checks, etc) and the Morph timer.  but those don't seem to figure into this bug.

Forum Jump:

Users browsing this thread: 1 Guest(s)

Theme by Madsiur2017Custom Graphics by JamesWhite