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 » Mon Mar 14, 2016 9:15 pm

Outdated Speed bugs -

Byte $3204 , Bit 2 is set when doing a normal or counter attack (or periodic damage/healing) , but not when entering a ready stance. So Function C2/09D2 (which determines ATB gauge and wait timer speeds, among other things) isn't called in the last case. That means:

Change gear so Speed is altered, then pick a command. The character's wait timer will advance at a rate based on their old Speed.

----------

Also, when C2/09D2 is called after a turn, it's done *before* Function C2/2095 recalculates applicable characters' properties from their current equipment and relics. That means should the turn itself modify gear that affects Speed, possible in a hack that gives Ogre Nix breakability to a Speed-boosting/hobbling weapon, the character's next ATB recharge rate will reflect the old Speed.

----------

I actually discovered these by looking at the code 11+ months ago, but didn't test in-game until tonight.

Part of a fix for the first: take the $3204 bit setting that's in C2/00F9 and C2/4B7B, and add it to C2/2188. C2/09D2 also needs to be triggered, but I'm not sure of the best place to do that. No idea on a good way to fix the second, but since it's hacks-only, it's not exactly urgent.
Last edited by Assassin on Tue Mar 15, 2016 12:03 pm, edited 1 time in total.
Reason: clarity tweaks
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Lenophis » Tue Mar 15, 2016 1:50 am

You sure it's fictional? Illumina, Ragnarok, and Excalibur all fit the bill of increasing speed, to name a few. Cursed Shield lowers speed, IIRC.

Or am I missing the point entirely?
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 Mar 15, 2016 11:37 am

they can't be broken. :P maybe i should move "fictionally" before "breaking"?

and to be sure, "the turn itself" meant a real turn, so changing gear in the Item menu doesn't qualify. i'll reword a couple things; let me know whether it's better.
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 Mar 16, 2016 2:04 am

Ah ha, that is clearer, yes. I'm surprised breaking and just plain unequipping don't do the same thing in this regard. I'd ask why, but I fear a headache is in my future. :p
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 Mar 16, 2016 2:15 am

well, both experience some form of the bug. but unequipping doesn't actually take a turn (i.e. you can choose another command right after), so it won't call all the same code.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Imzogelmo » Wed Apr 20, 2016 6:21 pm

Assassin wrote: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.



How about this: When doing the clearing of targets (upon finding the Zombie/Muddle has toggled bit set), go ahead and clear the targets for both first and second Gem Box castings. If it was regular magic, no foul, and if Gem Box was used, i.e. X-Magic, then you're fixing the bug also.
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 Assassin » Thu Apr 21, 2016 11:45 pm

that's a good idea. it'll require walking forward in the "master list" (a queue-related structure). and perhaps confirming the next entry indeed holds an X-Magic command, in the off-chance the two spells don't immediately follow each other as expected.

a little work, but it's better than what i had in mind. i was going to add a new 16-bit RAM variable. iirc, i'd either:
- set NewVar when Function C2/0276 clears (i.e. actually alters) $3A4A, and have it so the function clears targets if either was set. subsequent calls with $3A4A clear would probably clear NewVar.
- have Function C2/0276 clear NewVar first instead of $3A4A; they were presumably set in tandem at C2/45C6. generally sort of a mirror image of the first method (?).

iirc, a main difference between approaches was the value $3A4A would be left holding in the event things unfolded in an unexpected order (or stopped unfolding early?). i was more comfortable with one way, but not fully with either. it's a bit foggy. also, i don't recall in what other places the new variable would have gotten cleared (and set, in the second approach). see, i apparently leaned on my uncanny nonexistent ability to remember every thought i've had in the past 12-18 months, rather than write any of this down. :roll:

your approach goes at things more directly, not to mention the lack of RAM invading.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Assassin » Wed Apr 27, 2016 5:14 pm

this one was discovered by BTB and/or Synchisi sometime before June 1, 2013, and has been fixed in Brave New World for awhile now. but it's worth documenting here. i'd link the righteous GameFAQs BNW topic where it was one of many things discussed, but the thread was modded by Philistines.

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

When an entity is given Poison status, it will take increasing Poison-elemental
damage at regular intervals, levelling off after the eighth round. This is
accomplished by using an incrementor that can provide up to 8x normal damage.

However, there is a bug where Poison removal doesn't cause the incrementor to
be reset. If the entity is given Poison again later in the battle, its damage
picks up where it left off during the previous ailing (albeit with the
same peak multiple).

The patch fixes things by zeroing Poison's damage incrementor when the status
is removed.

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

here's how the patch code looks (i haven't settled on a free space area for a standalone version):

Code: Select all
hirom
header

; Clear status pointers ("side effects" to perform upon clearing of a status):

org $C246F4
dw ?? ??     ; Poison


org $C2????
PHP
SEP #$20     ; Set 8-bit A
LDA #$00
STA $3E24,Y  ; Zero the Poison damage incrementor
PLP
RTS
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 May 06, 2016 12:50 am

a fix for "Muddle makes Controlled enemies face forward":

Code: Select all
(original)

C2/0773: BD 19 30     LDA $3019,X
C2/0776: 1C 54 2F     TRB $2F54      (cancel visual flipping of Controllee)

============================

(fixed)

LDA $3EE5,X
JSR extra

---------

(free space address not yet chosen)
extra:
BIT #$10
BNE DontUnFlip  (branch if former Controllee is Muddled)
LDA $3019,X
TRB $2F54       (cancel visual flipping of Controllee)
DontUnFlip:
RTS

if you're using leet sketcher's "Dead in the Air-Fix A" patch, the first part of this Control patch instead goes at C2/0771.

i actually came up with this simple fix back on August 1, 2013, but laziness and not knowing where to put the extra code means i sat on it. i'll be posting code for at least one more sat upon bugfix, since this info should really be out there where others can use or critique it. becoming a hoarder was never my goal, yet i'm still waiting on *properly* dealing with my backlog. posting pending stuff is a compromise.
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 May 16, 2016 10:10 pm

i came up with a fix for the "Multitarget Dance spells from the Control menu target in favor of enemies" bug. it requires adding a Control check to the "Randomize targets" function (C2/5937). it's a large routine, much of which just toggles the same bit back and forth and back and forth, so it's not hard to optimize.

a few varieties:

http://assassin17.brinkster.net/forum-p ... t-fix1.asm

4 bytes to spare. why didn't i parcel "AND #$80 / EOR $B8 / STA $B8" into a helper function? it turns out the "STA $B8 / LDA $B8" droppage from the end of the code limits how useful this is, because i'd have to effectively add back the "STA $B8" before calculating the function-delegating method's savings. now, i could've saved a single byte by doing "JSR helper_function" right before "noCharEnemy:", but that doesn't seem worth the speed loss of 4 function calls and the stack usage.

http://assassin17.brinkster.net/forum-p ... t-fix2.asm

11 bytes to spare. and 2 more could be claimed, as per the bottom comments. if i don't go for those, i might as well drop the PHA/PLA, relocate the Muddled and "cursor start on enemy" checks, and have them use a conventional $B8 toggle.

http://assassin17.brinkster.net/forum-p ... t-fix3.asm

12 bytes to spare. makes use of the Y register as a toggle counter. lighter on memory accesses than other methods, but heavier on branches. not like either matters, given so many instructions on this CPU have practically the same cycle count. :P can change a "CMP #$FF" to an "INC", but am holding off for no good reason.

any preference(s) among the 3? corrections? further optimizations?

figured this could be a fun routine to shrink, as it's straightforward and repetitive.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Imzogelmo » Fri May 20, 2016 3:26 pm

I find #3 to be easiest to read, although if the functionality is the same, I don't suppose it matters which one you choose.
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 Assassin » Wed May 25, 2016 10:56 am

thanks.. they hopefully have the same functionality, but are yet to be tested.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Assassin » Wed May 25, 2016 12:34 pm

Mind Blast's brain fart? -

The Mind Blast special effect makes a list of four random targets from the
originals; there can be duplicates. Then for each list entry, it randomly
marks one status from the spell data to be set.

However, should the same status be selected twice for the same target, it's
effectively wasted.

While it's not necessarily a bug, but just a straightforwardly senile
algorithm, it was worth pointing out the inefficiency here. (If only to type
the title.)

A more cerebral Mind Blast would involve editing the Evil Toot function (which
the former calls to mark statuses) to not choose a status that's already marked
for a given entity.

Three tweaks are here (choose your free space to test):
http://assassin17.brinkster.net/forum-p ... weaks1.txt

-----------

EDIT: the ghost of Lenophis visited me and told me the "JSR $522A / RTS" was stupid.

also, i realized this code would fail if the only status(es) in a byte pair had already been marked. the first way is remedied simply by just branching back earlier, though that makes it slower yet. the other two required duplicating the EOR/etc narrowing so it's also before the $520E calls. here're revised tweaks:
http://assassin17.brinkster.net/forum-p ... eaks2b.txt
Last edited by Assassin on Fri Jun 03, 2016 8:13 pm, edited 2 times in total.
Reason: an improvement and corrections to code
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 Jul 04, 2016 5:26 pm

i've posted about this before:

viewtopic.php?f=2&t=108&p=1224&hilit=reflector#p1224
viewtopic.php?f=3&t=477&p=6932&hilit=reflector#p6932

and it might not be a bug, but here's a more complete description:

===============================================================================

Scapegoated Reflector -

In case of there being multiple attackers of an entity in a turn (i.e.
reflectors of a multi-targeted spell), the game goes through the work of
keeping a variable that will randomly record one of them, so it can be read in
counterattacks. It is consulted in the seldom-used F1 45 script command (and
never-used variants).

The FC 01/02/03/04 script commands ("If monster has been attacked by command
/attack/item/element") have their own variables to store an attacker that might
apply to them. However, these ignore the above variable, and instead are
assigned simplistically: whichever attacker/reflector last "hit" the entity.
Because reflections are always processed in the same order, the scapegoat of
these commands will be the lowest target number, i.e. the first reflective
target of the bouncing party.

That's arbitrary and stupid. I stop short of calling it a bug because it can
be addressed by wrapping other commands with F1 45, but script expansion is
a pain for compatibility.

This patch goes the assembly route, making the above four commands base their
"last attacker" variables off the randomly-chosen one. No more scapegoats!
Rest easy, Chet Wallaby!

===============================================================================

here's FF3us patch code, untested as usual:

http://assassin17.brinkster.net/forum-p ... -patch.asm

changing FC 03 (Counter Item) wasn't necessary, but done for consistency.

i wrote 98% of this code back in September 2012, but took my time making an assemblable file with comments.

===============================================================================

for the curious, here are script command tallies:

http://assassin17.brinkster.net/forum-p ... counts.txt
http://assassin17.brinkster.net/forum-p ... counts.txt
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Imzogelmo » Mon Jul 04, 2016 10:59 pm

This is fascinating, and I'm gonna go out on a limb and say it is a bug. They have the variable needed to track the reflector, and then don't use it. Seems like enough to call it a bug.

On the other hand, reading through all those old linked posts, it seems that the discussion was of a broader issue: that is, when (and under what conditions) should the variables used for the FC 0X counters be cleared.

I think the fact that they do not get cleared at all is a bug. This is widely regarded to be the case, as it makes a counter become an omni-counter. However, it *could* be argued that rather than one-time counters, they were meant to be gates that had to be opened to get to the payload of the big attack.

Personally, I think it's the former, as the latter could (and should) be achieved with variable manipulation.

We've had some interesting discussions revolving around what the correct interpretation would be. I think it's hard to say what they intended, but the language we use can influence how we think of it. If you want to only retain the attack, command, element, and item of the current attack, for use in possible counters, then that's one thing. If, on the other hand, you want to remember the last attack, command, etc. to be used against a target (no matter how many non-matching attacks occur in the interim), then that is another thing.

I cannot say for sure which is the right interpretation, and judging from assassin's list of monsters using these FC commands (and the way they are used), I'm not sure even Square knows for sure.
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 Assassin » Fri Jul 08, 2016 2:05 am

i'm finally presenting patch code for these bugs that Imzogelmo might've heard of:
viewtopic.php?p=6898#p6898

that description has also been amended some, mostly in accordance with what we discussed ages ago. i'm particularly interested in how the last clause in the last paragraph reads now, as the earlier wording (along with some confusion over my "black box" encapsulated steps) seemed to spur some of the back-and-forth that followed. also, should i ditch the colon from that single-big-sentence paragraph, and make it two sentences instead?

anyway, there are two varieties of the fix (both are untested). the difference concerns this:
viewtopic.php?p=7067#p7067

the first one won't allow later Regen in that Ribbon+Thornlet example. (note that Ribbon by itself will permit it.) also, it should be fully assemble-able code, once you punch in a free space address.
http://assassin17.brinkster.net/forum-p ... ariety.asm

the second one will allow later Regen in that Ribbon+Thornlet example. it's a file of differences from the first one, so you'll have to do some copying+pasting (and likely relocate the last instruction shown).
http://assassin17.brinkster.net/forum-p ... -diffs.txt

so for this variety, the first part of the fix description would read (italics = added):
A patch would fix bugs #1 and 2 with two steps: only giving immunity to the
"mirror" of a status if that status is intended as permanent and wasn't
thwarted by outright immunity
(or if the status is possessed on a target that
has immunity to it),


the vast majority of the coding was done in 2012-2014; what happened since then was endless foot-dragging, and then recently expanding and improving my comments.

arguably, the first variety should introduce measures so upfront Regen (i.e. from Cure Ring) in that Ribbon+Thornlet example behaves consistently with later Regen. it'd likely involve editing Function C2/4391 (or a helper) so would-be permanent Status X fends off its "mirror status" Y (and vice versa). it's a bit outside the scope of the current patch, and i'd tread very lightly, since changing a widely-used function could have unwanted consequences.

also, for both varieties, i'm not nuts about reception (or lack thereof) of start-up statuses hinging on mirror statuses being booted out by the set status "side effect" functions called by C2/4391. (or conversely, on immunity to the first status preventing said booting.) it basically gets the right results, but without utilizing any of the measures of the yet-to-be-called C2/2675. what i can't remember is whether there's some highly-specific scenario (maybe involving being Wounded?) where this has the wrong result, or if my dislike is purely academic. iow, i'd in theory favor C2/4391 that actually had some awareness of the would-be permanent status bytes (as mentioned in the previous paragraph). the current way is sort of elegant, but i'm uneasy with it. eh, i'll put that on the back burner for now.

anyway, i'm primarily interested in whether:
- the patches actually do what i say.
- what i said the patches should do is logical in the first place.

optimization matters less at this stage, but feedback on that is still welcome. i did do my own fair share of it, but can't envision this thing ever fitting inline.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Imzogelmo » Sat Jul 09, 2016 4:32 pm

I have downloaded these and I intend to put both versions into one file (with a branch that I can quickly edit). I will attempt some testing at some point in the next week or so.
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 Assassin » Tue Jul 19, 2016 4:11 am

some manual changes to my Jump Megafix for those who don't want to (further) wait for a new release.

it concerns siblings of the "properties from earlier strikes on multi-strike turn infest later ones" bugs, as seen in posts including here:
viewtopic.php?p=7044#p7044
viewtopic.php?p=4408#p4408

those are being dealt with in a pending patch.

a couple related ones, Jump spellcasts getting damage bonuses from the Jump command and from spears, will be dealt with in the next Jump Megafix (which has multiple other changes planned). it simply makes no sense to try to tackle them in vanilla, as an algorithm that doesn't reload command, attack, or weapon properties on a strike-by-strike basis forced itself into using Variable $BD (turn-wide damage incrementor) for damage boosts, because it does all its Jump setup at the start of the turn.

i had punted on these when becoming aware of them later in patch development, because i just wanted to get it released, even going so far as to add instructions to keep the spear one in.

as mentioned, i'll get rid of them in the next update. however, for users who want to do so in CURRENT version 0.15 (because man, have 10.8 years flown by):

1) spear damage bonus:
  • Type A of patch: NOP (EAh) C2/6685 thru C2/6688
  • Type B of patch: NOP (EAh) C2/6672 thru C2/6675
2) jump damage bonus (need to do spear change AND this one to get rid of it):
  • both patch types: NOP (EAh) C2/17FA thru C2/17FB
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Assassin » Sun Jul 31, 2016 7:41 am

Now for those numerous non-Jump "properties from earlier strikes on multi-strike turn infest later ones" bugs, as seen in posts including here:
viewtopic.php?p=7044#p7044
viewtopic.php?p=4408#p4408
viewtopic.php?p=6887#p6887 (follow-up of viewtopic.php?p=6883#p6883)

there are even more posts than that, as ones in this category were found over time; if any bug set needs a consolidated description, it's this one. here goes:
http://assassin17.brinkster.net/forum-p ... r-desc.txt

if the property names look a little unfamiliar to Bank C2 viewers, it's because i flipped them here. talking about 'Clear "No critical and Ignore True Knight" ' and such got a bit silly with the double negatives. :P it's tolerable in small doses, but when discussing a bunch of properties whose bits default to 1, no thanks on my verbiage being a slave to the Usual 0/1 Paradigm, man.

and here's a multi fix:
http://assassin17.brinkster.net/forum-p ... ti-fix.asm

untested as usual, but i actually account for FF6j, which recoups some conscientiousness points.

i couldn't find a way to optimize most of these specific areas. i thought i saw a chance starting around C2/3250 with the repeated use of 02s and FFs, but various things about the program flow thwarted me. and i'm not interested in branching outwards much for neighbors to tear up. the ratio of free space used to number of bugs fixed is pretty small, anyway.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: Glitches and Bugs guide updating thread

Postby Imzogelmo » Sun Jul 31, 2016 4:54 pm

You know I just do this to read your comments, right? (You really missed your calling as a writer... or did you? Hmm, I wonder what your day job is...)

But then this:

; Add "Can critical and heed True Knight" property to unused Bit 4 in
; command data. I could have done hardcoded checks for the two
; command IDs, but then I'd be forced to kill my coworkers and myself
; in shame before _The Legend of Zelda: A Link to the Past_ could be
; released. Also, the abandoned time machine would present a loose end.



WTF?
User avatar
Imzogelmo
Veteran
Veteran
 
Posts: 659
Joined: Wed Sep 08, 2004 4:07 pm
Location: On the spirtual plane

PreviousNext

Return to FF3 Gameplay Discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron