100+ bugs

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

Moderators: General Moderator, Game Moderator

Postby Assassin » Mon Jul 31, 2006 2:33 am

To follow up on #166 (Weapon spellcast [animation] on a dead enemy after trying to hit a Jumped enemy) a little:

Code: Select all
C2/3816: A9 0C        LDA #$0C
C2/3818: 1C A3 11     TRB $11A3   (Clear learn if cast, clear enable Runic)
C2/381B: 04 BA        TSB $BA     (Set Don't retarget if target invalid, and
                                   Can target dead/hidden targets)


What do you do when you want to set Bit 2 in one byte and Bit 3 in another? Set both bits in both bytes, of course! The motive: saving a 2-byte LDA instruction. Yes, I'm nearly convinced that was the intent of these miserly SoBs.

I can't think of any reason to set "Can target dead/hidden targets" in $BA (in fact, it's apparently detrimental), especially when considering the game clears $3A89 to disable the spellcast if the initial weapon strike kills the target.

Nor can I think of any pressing reason to clear "Learn if cast" in $11A3 -- sure, it's harmless and technically correct to do, but you're not going to be casting lores with a weapon anyway, and I don't believe Item Magic (for instance) ever bothers with it.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Postby JCE3000GT » Mon Jul 31, 2006 9:40 pm

I have a bug report. It starts at byte $01 and goes until byte $300000. This is with a ROM with no header.


































Lenophis and DKK will get this inside joke...doubt it anyone else will.
User avatar
JCE3000GT
Active User
Active User
 
Posts: 20
Joined: Mon Mar 28, 2005 10:52 pm
Location: Here

Re: 100+ bugs

Postby Lenophis » Sat Jul 05, 2008 2:15 am

I have no idea what number we're on, but just bear with me here.

Some location names simply refuse to appear. There's a couple of areas where this is evident, but the easiest example is Dragon's Neck. Walk in, and the location name does not appear (this was fixed for the GBA version). The data is set for it to appear in all three places, there's just unknown agent at work preventing it.

In hacked games, South Figaro's Cave from South Figaro's entrance also experiences this, and I suspect layer 3 is doing it here (yet it doesn't explain why it does show up in the WoR). It may have something to do with the vehicle script instead (but that doesn't explain why it does show up in Vector, either).

Note: there is a check for location names, and only when Y-switching is enabled will a name never appear. Tracing has shown that $0567 (presumably the timer for the name) is being zeroed out by other routines, probably layer 3 related. This is not yet confirmed.

Another area where you can see the bug is the Cave to the Sealed Gate's gate room. The data is set in all three places, but the name does not show up. I suspect the background lightning (actually event-controlled) is causing it, and when the map is loaded, the tile trigger at your feet causes that event to trigger, causing the name not to appear.

Also note that while there is location name data for the Phoenix Cave, Kefka's Tower, and the Floating Continent, the map loads don't call them so their names won't ever appear.

My apologies for the wall-o-text.
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: 100+ bugs

Postby Lenophis » Tue Aug 12, 2008 2:43 am

Whee, double post. :oops:

An oversight of oversights, and this is a strange one. The "critical hit if imp" status will double regeneration. Strangely, it does not double seizure's damage. I do not know if this is already known, but it was brought to my (ok, who am I kidding, there's 4 of us in IRC) our attention, and I decided to see if this was really the case.

Deathlike was a step ahead of me, and posted screenshots:

http://img98.imageshack.us/my.php?image ... 005db0.png
http://img45.imageshack.us/my.php?image ... 006fl4.png

http://img177.imageshack.us/my.php?imag ... 037dr4.png
http://img177.imageshack.us/my.php?imag ... 038dh4.png

That was for JCE's hardtype hack, but I just tested it myself and I can confirm it.

--Edit--
Nevermind the above comment about seizure, I never actually tested that and just took his word for it. Seizure does double damage as well, which means poison probably does as well.

Image
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: 100+ bugs

Postby Assassin » Tue Aug 12, 2008 3:58 am

aha, i was just gonna post about Seizure after doing some tests.

this doubling stems from the fact that when you have damage/healing done by a status on an entity, that entity is considered to be the "attacker" for purposes of taking the turn. after all, *somebody* has to be.

as for Poison, it overwrites the Damage Incrementor with its own counter (the one that lets it increase damage round-to-round), so i suspect it won't be affected by Auto Critical When Imped, but i have yet to test. EDIT: ok, looking at the code, i think it will be affected; i'll test some other time./EDIT

earlier in the Seizure/Regen/Poison/Phantasm-leak function (C2/500B), a bit is cleared to allow Damage Incrementation, presumably to let Poison do its thing. if you moved this clearing down after C2/503A so it was Poison specific, that oughta fix the problem (EDIT: with everything besides Poison), as i can't think of any legitimate purpose for Regen/Seizure/Phantasm-leak to need damage incrementation. of course, you'll need to come up with space for 4 bytes.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: 100+ bugs

Postby Lenophis » Tue Aug 19, 2008 3:52 am

Thanks to Deathlike, an oversight was discovered. The bug is event commands $88, $89, and $8A setting/removing/toggling status ailments when they probably shouldn't. Now, there's going to be a couple sides to this argument.

One side: The game is inconsistent with how it handles status ailments in and out of battle. The universe probably shouldn't be selective in how it handles status like that. Status-blocking equipment should be viewed in all cases.

Other side: Event commands (called when sleeping) should always remove status, regardless if your equipment setup should forbid it (as it would in battle). There's no reason to fix what ain't broke.

And there's still a can of worms to deal with. Specifically, the three terminal ailments. With what I have in mind, wearing an amulet while already a zombie would prevent the status from being removed. Although, IIRC putting on the relic after the fact will remove the status in the menu (another inconsistency to look at). This specific can of worms to deal with though will be hard to judge, which is I need some input. How should the three terminal ailments be handled?
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: 100+ bugs

Postby Assassin » Mon Dec 15, 2008 12:17 am

so i was reading the "Naming Shadow Fix" description on your webpage, and it reminded me of another oddity in that dialogue. it starts:

SABIN: You..on a journey?
I got separated from my friends. Say, can you tell me how to get to Narshe?


then either:

if you've previously named Shadow in South Figaro:

SHADOW: Imperial soldiers have built a base somewhere beyond the forest.
SABIN: ...Already!?
SHADOW: They seem to have their sights set on Doma Castle.
SABIN: So Doma's next, huh?
I have to reach Narshe immediately!
SHADOW: Your only hope is through Doma.
I'll show you the way.
Just know that I may take off at any time, if I feel like it.


or if you haven't:

MAN: The Empire has set up a base somewhere beyond the forest, and to the east.
SABIN: ...Empire!?
MAN: They seem to have their sights set on Doma Castle.
SABIN: Doma, huh?
I have to reach Narshe immediately!
MAN: Your only chance is through Doma.
I'll show you the way.
Just know that I may take off at any time, if I feel like it.


apparently, not naming Shadow earlier stops Sabin from knowing what the Empire is. :P now, one could argue that he's just shocked at the Empire's reach, but it certainly seems like the whole concept is new to him.

that shouldn't be the case, because Sabin and the party talk about the Empire, its influence on Figaro, and the Returner hideout upon his recruitment on Mt. Kolts. not to mention all the discussion that happens in the hideout with Banon.

what are your thoughts on this?
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: 100+ bugs

Postby Master ZED » Mon Dec 15, 2008 4:07 am

The ellipsis is likely what's throwing you off, since it does make it appear as if Sabin had to ponder that word for a moment to be certain he couldn't think of what Shadow was talking about. If you replaced it with The, it'd make more sense.
The Unoriginal White Sheet - http://masterzed.cavesofnarshe.com/
-Master ZED
User avatar
Master ZED
Moderator
Moderator
 
Posts: 472
Joined: Sat Sep 04, 2004 4:31 am

Re: 100+ bugs

Postby Novalia Spirit » Mon Dec 15, 2008 10:28 am

Master ZED wrote:The ellipsis is likely what's throwing you off, since it does make it appear as if Sabin had to ponder that word for a moment to be certain he couldn't think of what Shadow was talking about. If you replaced it with The, it'd make more sense.

That's basically what appears in both the GBA script and Sky Render's translation, so I guess your theory is correct. And interestingly, each of those scripts contains the same dialogue for both scenarios, with the sole exception of the name swap, obviously. Perhaps it is more questionable that Sabin exclaims, "...Already!?", as I don't see any reason for him to say that, and this apparently doesn't appear in the original game.

Assassin: Your post reminded me, in turn, of an eerily similar oddity, perhaps not as eerie as the BoF/FF6 similitude you outlined in my BoF topic, but it's still very eerie :P. This one actually takes place in the Imperial camp; more specifically, near the entrance, and only on your first visit:

If you've previously named Shadow:

This's an Imperial base.
Too many soldiers…

Otherwise:

SABIN: What the…?
Where'd these soldiers come from?

The problem resides in the former, in that if you've previously named Shadow in South Figaro and did not approach him during Sabin's scenario, this message will be selected anyway.
User avatar
Novalia Spirit
Regular User
Regular User
 
Posts: 268
Joined: Tue Aug 30, 2005 5:30 am
Location: Quebec

Re: 100+ bugs

Postby Assassin » Mon Dec 15, 2008 5:16 pm

Perhaps it is more questionable that Sabin exclaims, "...Already!?", as I don't see any reason for him to say that, and this apparently doesn't appear in the original game.


see, that line makes sense to me.. Sabin knows the Empire is powerful and expanding, but didn't know they built a base that fast.

This one actually takes place in the Imperial camp; more specifically, near the entrance, and only on your first visit:


ah.. i forgot about that one.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: 100+ bugs

Postby Lenophis » Mon Jan 12, 2009 3:22 am

First of all, I do not know if the qualifies as a bug, so I'm bringing it up here for discussion.

Doom Gaze is a fickle beast, as I'm sure all of us are aware. Fighting him can be a pain, especially if you run into him when you don't expect to. Finding him is a pain, especially if you want to. It's a crapshoot of the worst caliber. So, while commenting some code tonight I came across this:

Code: Select all
EE/869A:   AD6D1F     LDA $1F6D      (load RNG index)
EE/869D:   1A         INC A
EE/869E:   1A         INC A
EE/869F:   1A         INC A          (increment it by 3)
EE/86A0:   8D6D1F     STA $1F6D      (save new RNG index)
EE/86A3:   AA         TAX            (transfer RNG index to X)
EE/86A4:   A000       LDY #$00
EE/86A6:   BF00FDC0   LDA $C0FD00,X  (get a random number)
EE/86AA:   293F       AND #$3F
EE/86AC:   99000B     STA $0B00,Y    (set Doom Gaze's X 4x4 block position)
EE/86AF:   7B         TDC
EE/86B0:   99010B     STA $0B01,Y
EE/86B3:   E8         INX
EE/86B4:   BF00FDC0   LDA $C0FD00,X  (get a random number)
EE/86B8:   4A         LSR A
EE/86B9:   4A         LSR A
EE/86BA:   99020B     STA $0B02,Y    (set Doom Gaze's Y 4x4 block position)
EE/86BD:   7B         TDC
EE/86BE:   99030B     STA $0B03,Y
EE/86C1:   C8         INY
EE/86C2:   C8         INY
EE/86C3:   C8         INY
EE/86C4:   C8         INY
EE/86C5:   C010       CPY #$10       (place him in 4 spots, even though 2 are only checked for)
EE/86C7:   D0DD       BNE $86A6      (branch if haven't done 4 placements yet)
EE/86C9:   4C4691     JMP $9146


Yes, you're reading that right, he's being placed in 4 separate locations. Why am I bringing this up? Because of this:

Code: Select all
EE/6EE8:   E220       SEP #$20       (8-bit accumulator and memory)
EE/6EEA:   AD641F     LDA $1F64      (load current map, low byte)
EE/6EED:   C901       CMP #$01       (are we in the world of ruin?)
EE/6EEF:   D07A       BNE $6F6B      (branch if not)
EE/6EF1:   A504       LDA $04        (load shared controllers bits)
EE/6EF3:   8980       BIT #$80       (are we pressing A?)
EE/6EF5:   F074       BEQ $6F6B      (branch if not)
EE/6EF7:   ADD21D     LDA $1DD2      (load battle bits)
EE/6EFA:   8901       BIT #$01       (is Doom Gaze dead?)
EE/6EFC:   D06D       BNE $6F6B      (branch if so)
EE/6EFE:   C230       REP #$30       (basic checks have passed, but now you need to run into him yet o_O)
EE/6F00:   A534       LDA $34        (current X position in pixels)
EE/6F02:   4A         LSR A          (divide by 2)
EE/6F03:   4A         LSR A          (divide by 4)
EE/6F04:   4A         LSR A          (divide by 8)
EE/6F05:   4A         LSR A          (divide by 16)
EE/6F06:   4A         LSR A          (divide by 32)
EE/6F07:   4A         LSR A          (divide by 64, determine what 4x4 block you are on)
EE/6F08:   29FF00     AND #$00FF     (keep it within the 0-255 range for X)
EE/6F0B:   8558       STA $58        (save as current X 4x4 block)
EE/6F0D:   A538       LDA $38        (current Y position in pixels)
EE/6F0F:   4A         LSR A          (divide by 2)
EE/6F10:   4A         LSR A          (divide by 4)
EE/6F11:   4A         LSR A          (divide by 8)
EE/6F12:   4A         LSR A          (divide by 16)
EE/6F13:   4A         LSR A          (divide by 32)
EE/6F14:   4A         LSR A          (divide by 64, determine what 4x4 block you are on)
EE/6F15:   29FF00     AND #$00FF     (keep it within the 0-255 range for Y)
EE/6F18:   855A       STA $5A        (save as current Y 4x4 block)
EE/6F1A:   A20000     LDX #$0000
EE/6F1D:   BF000B00   LDA $000B00,X  (load Doom Gaze's 4x4 block. also, LDA $0B00,X would've worked)
EE/6F21:   C558       CMP $58        (compare to current X 4x4 block)
EE/6F23:   D00A       BNE $6F2F      (if they don't match, branch and keep trying)
EE/6F25:   BF020B00   LDA $000B02,X  (load Doom Gaze's 4x4 block. also, LDA $0B02,X would've worked)
EE/6F29:   C55A       CMP $5A        (compare to current Y 4x4 block)
EE/6F2B:   D002       BNE $6F2F      (if they don't match, branch and keep trying)
EE/6F2D:   800B       BRA $6F3A      (you're here if both matched, proceed to fight Doom Gaze)
EE/6F2F:   E8         INX
EE/6F30:   E8         INX
EE/6F31:   E8         INX
EE/6F32:   E8         INX
EE/6F33:   E00800     CPX #$0008
EE/6F36:   D0E5       BNE $6F1D
EE/6F38:   8031       BRA $6F6B      (no matches, or both didn't match on all checks, finish and exit)
EE/6F3A:   6426       STZ $26        (you're here if all checks passed, so the encounter with Doom Gaze can finally begin)
EE/6F3C:   6428       STZ $28
EE/6F3E:   642A       STZ $2A
EE/6F40:   642C       STZ $2C
EE/6F42:   642D       STZ $2D
EE/6F44:   C210       REP #$10       (16-bit indexes)
EE/6F46:   A27401     LDX #$0174     (if the event was loading it, this would be 2-pack $5D)
EE/6F49:   BF0050CF   LDA $CF5000,X  (Monster Formations used in Event Scripts)
EE/6F4D:   8DE011     STA $11E0      (save Doom Gaze's formation)
EE/6F50:   A92900     LDA #$0029
EE/6F53:   8DE211     STA $11E2      (set background as WoR airship view, ship on right side)
EE/6F56:   E220       SEP #$20       (8-bit accumulator and memory)
EE/6F58:   9CE411     STZ $11E4      (clear various battle flags, which is default for most monsters)
EE/6F5B:   ADF611     LDA $11F6
EE/6F5E:   0922       ORA #$22
EE/6F60:   8DF611     STA $11F6      (LDA #$22, TSB $11F6 would work here)
EE/6F63:   ADFA11     LDA $11FA
EE/6F66:   0901       ORA #$01       (LDA #$01, TSB $11FA would work here)
EE/6F68:   8DFA11     STA $11FA      (ok, fight Doom Gaze)
EE/6F6B:   28         PLP
EE/6F6C:   60         RTS


That CPX #$0008 at EE/6F33 is only checking 2 spots. Is this an oversight? Did Square feel that 4 possible spots is too much to run into? Will Al be able to solve the murder in time?!

So, I'm slightly puzzled, but am not sure if this warrants a patch or not. Thoughts?
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: 100+ bugs

Postby Assassin » Wed Jan 14, 2009 3:41 pm

cool discovery!

Is this an oversight?


maybe.

it's possible they forgot the # of possible spots. or it's possible that in the latter block of code, they momentarily (i.e. at the CPX) forgot that each coordinate is two bytes. assuming 1-byte coordinates, you'd have 2 bytes per location * 4 locations = 8 bytes.

Did Square feel that 4 possible spots is too much to run into?


maybe.

Will Al be able to solve the murder in time?!


is this a reference to the Bundys' Florida vacation, or their British vacation? if it's the latter, good job on cracking the coordinates, Marlboro. if it's the former, then nice axe, or however that went.

So, I'm slightly puzzled, but am not sure if this warrants a patch or not. Thoughts?


it's hard to rule whether it's a bug when the game handles so much behind the scenes -- and never really has a concrete, accessible definition for the player. conceptually speaking, either the winged Doom Gaze hovers in one damn place, or he's moving around. now, the 2-stationary-spot system is a divergence from both of those.. so it's hard to say what "makes sense", because 2-stationary-spots and 4-stationary-spots are both kinda artificial to begin with. you could say that they failed to check 2 of the spots, or that they wasted 8 bytes by representing 2 extra spots. and i couldn't respond that one conclusion is more correct than the other.

what it definitely warrants is applause.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: 100+ bugs

Postby Lenophis » Thu Jan 15, 2009 5:13 am

Assassin wrote:is this a reference to the Bundys' Florida vacation, or their British vacation? if it's the latter, good job on cracking the coordinates, Marlboro. if it's the former, then nice axe, or however that went.

The Florida one was a bit funnier. :wink:

it's hard to rule whether it's a bug when the game handles so much behind the scenes -- and never really has a concrete, accessible definition for the player. conceptually speaking, either the winged Doom Gaze hovers in one damn place, or he's moving around.

I really want to believe that Square tried to make him do basic flight patterns during development, but failed to do it/make it work for whatever reason. In FF7, Ultima Weapon even has a really crappy flight pattern...

now, the 2-stationary-spot system is a divergence from both of those.. so it's hard to say what "makes sense", because 2-stationary-spots and 4-stationary-spots are both kinda artificial to begin with. you could say that they failed to check 2 of the spots, or that they wasted 8 bytes by representing 2 extra spots. and i couldn't respond that one conclusion is more correct than the other.

This is where I am, as well.

what it definitely warrants is applause.

I think you would change your mind if you saw how bad some of this code is in bank EE. :cry:
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: 100+ bugs

Postby Dragonsbrethren » Mon Sep 28, 2009 10:39 am

I was watching some FF4 videos on YouTube today and saw this in the related section:

http://www.youtube.com/watch?v=jVdGPEbNe1E

It's from FF6 Advance. I had no idea what it was supposed to be showing, but this was posted in the comments section:

This is overflow checking movie of GBA version FF6. SNES and PS version FF6 had overflow bug, that Haste makes characters slow when the caster has very very high magic ability. The bug was fixed in GBA version.


I don't remember ever reading about that one before. I did a search here to see if it was mentioned, but didn't find anything.
Image
"You know, now that I think about it, getting stabbed hurts really, really bad...!"
User avatar
Dragonsbrethren
Regular User
Regular User
 
Posts: 150
Joined: Wed Jul 20, 2005 8:38 am

Re: 100+ bugs

Postby Master ZED » Mon Sep 28, 2009 1:47 pm

Dragonsbrethren wrote:I had no idea what it was supposed to be showing
What Locke is like at 156 speed. I can't read Japanese, but I can still read numbers. ;)

Dragonsbrethren wrote:
This is overflow checking movie of GBA version FF6. SNES and PS version FF6 had overflow bug, that Haste makes characters slow when the caster has very very high magic ability. The bug was fixed in GBA version.


I don't remember ever reading about that one before. I did a search here to see if it was mentioned, but didn't find anything.
I don't remember it either, and the comment is wrong anyway because Locke's Mag.Pwr in that video is unmodified. Maybe he meant high Vigor? Either way it doesn't sound right, I don't think those three stats ever interact (then again, this is FF6...). :\
The Unoriginal White Sheet - http://masterzed.cavesofnarshe.com/
-Master ZED
User avatar
Master ZED
Moderator
Moderator
 
Posts: 472
Joined: Sat Sep 04, 2004 4:31 am

Re: 100+ bugs

Postby Lenophis » Mon Sep 28, 2009 5:18 pm

This is overflow checking movie of GBA version FF6. SNES and PS version FF6 had overflow bug, that Haste makes characters slow when the caster has very very high magic ability. The bug was fixed in GBA version.

This suggests the agility overflow bug, considering you need agility higher than 235 for it to overflow and make you really slow. I don't recall this being fixed in FF6A though. :?

There was another bug I saw posted at gamefaqs yesterday, but I don't remember which thread it was in. It was a bug I had never heard of, so if I stumble across it I'll update this post with it.
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: 100+ bugs

Postby Master ZED » Mon Sep 28, 2009 11:05 pm

Lenophis wrote:
This is overflow checking movie of GBA version FF6. SNES and PS version FF6 had overflow bug, that Haste makes characters slow when the caster has very very high magic ability. The bug was fixed in GBA version.

This suggests the agility overflow bug, considering you need agility higher than 235 for it to overflow and make you really slow. I don't recall this being fixed in FF6A though. :?
Nor would it have anything to do with Haste, which is why I didn't guess Speed.
The Unoriginal White Sheet - http://masterzed.cavesofnarshe.com/
-Master ZED
User avatar
Master ZED
Moderator
Moderator
 
Posts: 472
Joined: Sat Sep 04, 2004 4:31 am

Re: 100+ bugs

Postby Dragonsbrethren » Tue Sep 29, 2009 5:47 am

Master ZED wrote:What Locke is like at 156 speed. I can't read Japanese, but I can still read numbers. ;)

Yes, of course, but I still had no idea what was being shown (other than Haste making Locke faster than he would be without it).
Image
"You know, now that I think about it, getting stabbed hurts really, really bad...!"
User avatar
Dragonsbrethren
Regular User
Regular User
 
Posts: 150
Joined: Wed Jul 20, 2005 8:38 am

Re: 100+ bugs

Postby Assassin » Thu Jul 21, 2011 10:35 am

#20 Shadow leaves while in mid-air

Steal some DragoonBoots from Harvester in Mt.Zozo, and give them to Shadow. Now encounter the enemies and try having Shadow be in mid-air as you win the battle: if Shadow leaves your party, he'll just do that from mid-air... Ta-da!

Obviously, this bug can only be achieved starting from Mt. Zozo till doing the Opera House sequence, depending on when Shadow was recruited.


at least as stupid: the same bug can happen if you have Shadow run from the battle before winning it. (an easy way to do it is to quickly tell your other party members to attack, and right after they do so, start running. there's a good chance that Shadow will be the only runner, or 1 of 2.)

and a nitpick: Mt. Zozo is inaccessible at the point you describe, so just call it "Zozo". :P

EDIT: ok, it seems you already found this variant in your February 8 2006 post. so i was only 5.5 years late. :P
Last edited by Assassin on Thu May 03, 2012 4:52 pm, edited 1 time in total.
Reason: missed prior post
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

Re: 100+ bugs

Postby Assassin » Mon May 07, 2012 12:12 pm

me wrote:speaking of visiting the menu restoring things to default, check out that chest with a switch near the end of the Cave to the Sealed Gate. flicking it breaks a bridge on you. (Japanese humor?)

flicking it again restores the bridge piece (so it's a 2-way switch), as does visiting the Atma Weapon room (++). entering the menu or a battle will also do so (inexplicably), but unlike the other ways, they don't change the position of the switch. by this, i mean that if you hit the switch again after menu/battle, the bridge piece will stay complete.


woo, i finally tackled the menu/battle wrongful restoring of the bridge piece. it was much simpler than i expected; change CB/386C to 11h. that's the value that CB/386E uses when destroying the bridge piece. the value previously at CB/386C was ABh, which is what CB/3882 uses to restore the bridge piece, and afaik the original map value.

then there's the skull switch nearest to the chest. it regenerates the bridge piece for no good reason (and like menu/battle, has the chest switch position problem). it doesn't mess with the chest graphic, however.


haven't done this yet. i'm thinking that when that skull switch rewrites the big chunk of map to move the far right island and its bridge, it also overwrites the chest-togglable bridge piece which technically isn't part of the island's vertical bridge (as it's a horizontal bridge piece connecting to the stationary right land mass).

and looking closely, what it rewrites the piece with is actually a horizontally flipped version of the original piece. :P i figured this out when ABh was nowhere in the data set.

to remedy the reappearance, i'd have to write a duplicate CB/3867 with an IF-test to check $1EBE, Bit 7 at the beginning, then add a call to that new function at the end of: CB/32A9, CB/33C9, and CB/3506. and i don't know where the free space is for that.

i also noticed another minor problem relating to this island's moving. it shifts two vertical squares total. when Function CB/3506 does the second shift, it inexplicably operates on a 12x5 chunk at 109,11 , instead of a 13x5 chunk at 109,10 , which is what the first half of the function does, as well as Function CB/32A9 (which refreshes the map upon return to it). so you'll see weird lava patterns (namely, duplicate "swirly circles", for lack of a better phrase) a few rows above the righthand island. they'll go away if you enter+exit battle or the menu. CB/3506 really needs to be expanded by 10 bytes to remedy this...

the needed space could be freed by replacing CB/3472 thru CB/34FD with a 4-byte call to CB/333B, saving 136 bytes (!!). it'll take me a bit to figure out how to edit the data in CB/3506, as i don't understand the format, or know exactly which tile IDs are needed.
Last edited by Assassin on Tue May 08, 2012 3:32 pm, edited 1 time in total.
Reason: elaboration on tackling lava graphics bug
User avatar
Assassin
Moderator
Moderator
 
Posts: 1195
Joined: Tue Sep 14, 2004 5:10 am

PreviousNext

Return to FF3 Gameplay Discussion

Who is online

Users browsing this forum: No registered users and 2 guests

cron