The following warnings occurred:
Warning [2] count(): Parameter must be an array or an object that implements Countable - Line: 895 - File: showthread.php PHP 7.3.33 (Linux)
File Line Function
/showthread.php 895 errorHandler->error




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

#1
Posts: 2,548
Threads: 98
Thanks Received: 147
Thanks Given: 156
Joined: Aug 2009
Reputation: 52
Status
Nattak\'d
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: https://www.youtube.com/watch?v=3eYZtWkt...e=youtu.be
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:
https://www.mediafire.com/file/uete8cg7k...r.srm/file

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.
Quote  
[-] The following 3 users say Thank You to Gi Nattak for this post:
  • Lockirby2 (01-15-2019), madsiur (01-10-2019), Robo Jesus (07-24-2019)



Messages In This Thread
Frozen-status bug - by Gi Nattak - 01-10-2019, 09:49 PM
RE: Frozen-status bug - by assassin - 01-26-2019, 01:45 AM
RE: Frozen-status bug - by Cecil188 - 01-26-2019, 11:05 AM
RE: Frozen-status bug - by assassin - 01-26-2019, 06:34 PM
RE: Frozen-status bug - by Imzogelmo - 05-28-2019, 09:26 AM

Forum Jump:

Users browsing this thread: 1 Guest(s)


Theme by Madsiur2017Custom Graphics by JamesWhite