A slickproductions.org /forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=printpage;topic=2339.0 e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index12b7-2.html layed slickproductions.org /forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&topic=2339.0 e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index12b7-2.html.z x >)h^ Ћ Ǐ OK text/html ISO-8859-1 gzip @ Ǐ H Wed, 11 Mar 2020 00:13:11 GMT 0 0 P >)h^ P) Ǐ
Print Page - Remaining bugs in FF3us
Board of Slick
Banon's Donkey Farm => Game Modification Station => Topic started by: Imzogelmo on February 11, 2017, 09:23:32 PM
Title: Remaining bugs in FF3us
Post by: Imzogelmo on February 11, 2017, 09:23:32 PM
There are a great many bugs in FF3us, and certainly there are a lot of them with fixes available. For this thread, I'd like to discuss those bugs which do not yet have a fix. Some will have obvious solutions, and others may have debatable ones, and there may even be some that we still don't know enough about.
So, I'll get the ball rolling. Novalia Spirit's bug #5, Shadow's shadow, seems to need an additional event bit check on the map load event. While the cafe has a check for the fight of Vargas, the outside map does not have that check. I believe that adding that bit into the map load event should resolve the issue.
EDIT (Rolling List):
Shadow's shadow - Needs to check event bit
Returners' White Cape chest - possibly a map tile edit
Zone Eater's Belly doorways - possibly convert event triggers to exit triggers
Dead Terra at Returners' Hideout - Need event edit to restore Terra
Event-based Doors - (could possibly generalize this to all event-based map edits) - Need to make map load events match the regular events once triggered
Solitary Island Beach - Game may be using palette to determine priority over water; need to fix for characters and not mess up fish
Non-standard Battle Endings - Needs to call some routines to clean up pending items and morph timers, possibly other things
Setzer Hates Birds - possibly edit spell animation scripts (or the commands themselves) to make them aware of Slot-casted Esper attacks and adjust formation accordingly
Title: Re: Remaining bugs in FF3us
Post by: 13375K31C43R on February 11, 2017, 11:29:43 PM
I've found a way to fix the graphical error that allows the player to see clouds through the doors in the Fanatics' Tower. It involves some tileset editing, which can be done in Zone Doctor or FF6LE.
I've also found a way to fix the door-opening errors in the South Figaro clock basement and the first floor of the Tower. Basically, the way it's done in the game is, if a certain event bit is set (e.g. the "You wound the clock" bit), a section of the map is changed upon loading of the map. The way to fix it is, instead of doing that, change the normal version of the map to what it would be after the event bit is set, and change it back if the event bit is clear instead of set. This is also doable in Zone Doctor or FF6LE, and I want to make a patch to fix both of these, but I want to do it in a way that doesn't involve rewriting the whole section of map data, which Zone Doctor has a tendency to do. I think all that's really required is to just change a few bytes where the changed tiles are supposed to be, but I don't know which bytes those are.
Title: Re: Remaining bugs in FF3us
Post by: Imzogelmo on February 11, 2017, 11:55:38 PM
Basically, the way it's done in the game is, if a certain event bit is set (e.g. the "You wound the clock" bit), a section of the map is changed upon loading of the map. The way to fix it is, instead of doing that, change the normal version of the map to what it would be after the event bit is set, and change it back if the event bit is clear instead of set. This is also doable in Zone Doctor or FF6LE, and I want to make a patch to fix both of these, but I want to do it in a way that doesn't involve rewriting the whole section of map data, which Zone Doctor has a tendency to do. I think all that's really required is to just change a few bytes where the changed tiles are supposed to be, but I don't know which bytes those are.
I'm wondering what difference it makes which map is default (or does it?). Events can easily check for set or clear event bits, and map reloads are necessary to reflect any changes. But I haven't really studied those in detail. There is a similar situation in the Serpent Trench cave, where a tile of water remains if you drain the pool and then access the menu; i.e., the map load event does not completely rewrite the affected pool area in the same way the live event does. In PB, we changed the map reload event's tile replacement, which fixed that issue. It does need a standalone patch, though. I'm just wondering if the same kind of fix can be done with the South Figaro basement.
Title: Re: Remaining bugs in FF3us
Post by: 13375K31C43R on February 12, 2017, 12:37:26 AM
I'm wondering what difference it makes which map is default (or does it?).
I don't know how it really works, either, but somehow it seems to have something to do with the fact that the map change creates a door. My fix means a door is sometimes removed as opposed to sometimes created. My experience is, without the fix, not only does the map get messed up when you return from the Main Menu after opening the door, but the door also gets closed. With the fix, the map doesn't get messed up and the door stays open.
By the way, I know there's still a bug in Zone Eater's belly, which you can see in this video (https://www.youtube.com/watch?v=HiLCriMquBc); I currently don't know how to fix it.
Title: Re: Remaining bugs in FF3us
Post by: 13375K31C43R on February 12, 2017, 01:21:26 AM
Here's another one (https://www.youtube.com/watch?v=EhfaMdMRuVw) I just found... sigh... :sad:
Title: Re: Remaining bugs in FF3us
Post by: Imzogelmo on February 12, 2017, 01:37:16 AM
I was aware of the Zone Eater one, although I've never done it myself. I also have no idea how to fix it.
There are a pair of bugs, specifically the ones triggered by using Slot -> Magicite -> Palidor/Phoenix (which will cause an extra step forward/backward), that I think could be fixed by re-doing some of the animation commands. I don't know enough about that area of code to tell for sure, but it's worth investigating.
EDIT: There's one where the beach on the Solitary Island covers Cyan and Umaro, but not others... I have no idea about fixing that one either.
EDIT 2: And that White Cape chest in the Returners' Hideout-- I'm not sure how to control the openable-directions of that.
Title: Re: Remaining bugs in FF3us
Post by: 13375K31C43R on February 12, 2017, 01:59:03 AM
Actually, looking at the map data in Zone Doctor for Zone Eater's belly, it turns out the "exits" at either end of the falling ceiling bridge aren't actually exit fields, they're event triggers. Which means we could probably fix this by replacing them with exit fields and putting event triggers at the entrances to the rooms where they come out.
Title: Re: Remaining bugs in FF3us
Post by: magitek on February 12, 2017, 04:11:32 AM
Here's one that's more of an event oversight. If Terra is dead before entering the Returner hideout and meeting Banon for the first time, she stays dead even after resting before she's supposed to go around and talk to everyone. Before you tell Banon you want to be the Last hope for the Returners, you can venture back out to the field with only Terra and she still has zero HP, so if you enter battle it is game over.
And another bug with non-standard battle endings: If Terra is Morphed when Gau returns from battle, her sprite will change back to normal (without ending Morph). In this case, the supply will not be updated, unless her Morph timer runs out before Gau starts talking; she will then perform Revert and the Morph supply will be updated correctly.
Non-standard battle endings are their own can of worms because they seem to skip over several routines which are supposed to run when a battle ends. With Banon dying, it's not much of an issue since it triggers a game over anyway, but Gau Leaping or returning can cause item loss. When an item is selected for use, it is removed from inventory immediately. If that turn is canceled because the battle ends, the item is supposed to be returned to inventory. In the case of Leaping/returning Gau, that doesn't happen. I assume it's the same if Banon dies, and possibly with other battles ending via event, such as Kefka in the imperial camp or on the bridge, or sketching Ultros 3.
Title: Re: Remaining bugs in FF3us
Post by: Xenovant on February 12, 2017, 09:58:36 AM
Quote
So, I'll get the ball rolling. Novalia Spirit's bug #5, Shadow's shadow, seems to need an additional event bit check on the map load event. While the cafe has a check for the fight of Vargas, the outside map does not have that check. I believe that adding that bit into the map load event should resolve the issue.
Or you could set the scene as "seen" after you fight Vargas (the event bit 00A/81:2). I fixed it this way.
Quote
EDIT 2: And that White Cape chest in the Returners' Hideout-- I'm not sure how to control the openable-directions of that.
DarkMage fixed it by moving the chest to a different tile, with ff6le.
Quote
EDIT: There's one where the beach on the Solitary Island covers Cyan and Umaro, but not others... I have no idea about fixing that one either.
Quote
If Terra is dead before entering the Returner hideout and meeting Banon for the first time, she stays dead even after resting
I didn't know about these ones.
Quote
I've also found a way to fix the door-opening errors in the South Figaro clock basement and the first floor of the Tower.
I fixed this one with just event editing, by replacing the messed up portion on area load (not just the door part), the bad part is the door is closed again if you enter/exit the menu.
Quote
f Terra is Morphed when Gau returns from battle
It also happens with imped characters, and it always buggered me. As you say, non-standard battle endings are a can of worms, and we should be very careful if we add those battle-end routines, we could break something.
EDIT: It seems the one at the beach also happens with shadow, mog and setzer.
Title: Re: Remaining bugs in FF3us
Post by: Imzogelmo on February 12, 2017, 11:05:58 AM
Shadow, Mog, Setzer, Cyan, and Umaro.. what's the commonality there..?
Title: Re: Remaining bugs in FF3us
Post by: Xenovant on February 12, 2017, 11:20:22 AM
The palettes? They use the palettes 4 or 5. The fishes use the palette #4. Could it be that the game puts underwater the characters with palettes 4 or greater?
Title: Re: Remaining bugs in FF3us
Post by: Lenophis on February 12, 2017, 11:21:51 AM
That is exactly what the game is doing, or at least, that is what Novalia and I suspect what is going on. We were talking about that bug some years ago, though a fix was never realized.
Title: Re: Remaining bugs in FF3us
Post by: Imzogelmo on February 12, 2017, 11:25:39 AM
So the game is using palette as a surrogate priority-check? That almost seems like it would have to be hard-coded somewhere.
Title: Re: Remaining bugs in FF3us
Post by: Xenovant on February 12, 2017, 11:36:54 AM
Thanks, Lenophis, for confirming it, at least we have now identified the problem.
Title: Re: Remaining bugs in FF3us
Post by: TheNattak on February 13, 2017, 01:07:27 PM
I've also found a way to fix the door-opening errors in the South Figaro clock basement and the first floor of the Tower.
Thank you so much! I've spent hours before trying to get this one fixed. So now I'm wondering which tile is the one to stop the clouds from being shown in the door?
Title: Re: Remaining bugs in FF3us
Post by: 13375K31C43R on February 28, 2017, 03:00:30 PM
Just gonna leave this (http://slickproductions.org/forum/index.php?topic=2186.0) here...
Title: Re: Remaining bugs in FF3us
Post by: Madsiur on March 18, 2017, 11:42:37 AM
I'm not sure if someone else did, but this is my attempt to fix bug #5. It basically check if the party saw shadow (vanilla condition) or if vargas has been beat. If any of the two, NPC $15 creation is not happening. I had to do a little bit of event gymnastic to fit everything without using one or multiple FD(s), using 7 bytes of free space at $D1F9F8 and shifting shadow's queue of 2 bytes. I'd like to know if someone has a better fix or proposal before I test and make a patch.
CA/EBA1: C0 If ($1E80($1B6) [$1EB6, bit 6] is set), branch to $CA5EB3 (simply returns) CA/EBA7: C1 If ($1E80($00A) [$1E81, bit 2] is set or $1E80($010) [$1E82, bit 0] is set), branch to $CAEBC1 CA/ECAF: B2 Call subroutine $D1F9F8 CA/EBB3: 45 Refresh objects CA/EBB4: 15 Begin action queue for character $15 (NPC $15), 11 bytes long CA/EBB6: 8E Move vehicle/entity down 4 tiles CA/EBB7: 99 Move vehicle/entity right 7 tiles CA/EBB8: A1 Move vehicle/entity right/down 1x1 tiles CA/EBB9: A1 Move vehicle/entity right/down 1x1 tiles CA/EBBA: 86 Move vehicle/entity down 2 tiles CA/EBBB: 95 Move vehicle/entity right 6 tiles CA/EBBC: 92 Move vehicle/entity down 5 tiles CA/EBBD: 89 Move vehicle/entity right 3 tiles CA/EBBE: 80 Move vehicle/entity up 1 tile CA/EBBF: D1 Make vehicle/entity disappear CA/EBC0: FF End queue
D1/F9F8: D0 Set event bit $1E80($00A) [$1E81, bit 2] D1/F9FA: 3D Create object $15 D1/F9FC: 41 Show object $15 D1/F9FE: FE Return
:edit: Tested and done!
Title: Re: Remaining bugs in FF3us
Post by: 13375K31C43R on April 02, 2017, 12:29:20 PM
Madsiur: great work!
About the underwater palette problem, there is some very good detail here (https://wiki.superfamicom.org/snes/show/Transparency) on how the transparency effect works on the beach water. From what I gather, it's colour averaging, and yes, it only seems to happen over sprites with palette index 4 or higher. As the linked page explains, Super Mario World has the same problem, which causes 1-Up mushrooms to be affected by the transparency in ghost houses.
This page (https://wiki.superfamicom.org/snes/show/Registers) also has good detail on how to actually control the colour math (via registers $2130-2132). Based on the Secret of Mana screenshot in the Transparency page, that tells me that the ideal scenario, wherein everyone has their heads above water and their legs under, might actually be achievable.
Title: Re: Remaining bugs in FF3us
Post by: 13375K31C43R on April 05, 2017, 12:12:54 AM
Setzer Hates Birds - possibly edit spell animation scripts (or the commands themselves) to make them aware of Slot-casted Esper attacks and adjust formation accordingly
I do not know this one. What's it about?
Title: Re: Remaining bugs in FF3us
Post by: assassin on April 05, 2017, 01:20:31 AM
probably "Setzer resents bird-hating comrades" in Master ZED's Bugs Guide.
Title: Re: Remaining bugs in FF3us
Post by: 13375K31C43R on April 05, 2017, 02:07:15 PM
OK, I think that would be further down your alley than mine. You know a lot more about formation errors than I do, and I don't think the problem has anything to do with animation scripts.
BTW, did you happen to see my comments about Fancy Walking?
Title: Re: Remaining bugs in FF3us
Post by: 13375K31C43R on April 08, 2017, 04:10:13 PM
OK, I've done a little testing with Setzer casting Palidor via Slot, and the impression that I get, though I can't confirm it code-wise, is that when Setzer uses Slot, the game errantly decides that his turn is over and reverts him to his normal position, but then he takes an extra step back after he lands. I tried replacing the call to C2/37DC in the triple-BAR case with a call to C2/3FAD, which is the code for the Magicite item (which does essentially the same thing as triple-BAR), and Setzer did assume his correct position after the fact, but didn't take a step forward to begin with. Same happened with Phoenix (no steps forward instead of two), and with Golem as well, so I assume it would be the same case for all the other Espers. I, however, would prefer that Setzer takes exactly one step forward and returns to his normal spot.
For the record, all Magicite does over triple-BAR is store the randomly chosen Esper to $3400 (the spell ID, or whatever that means for Magicite or triple-BAR) and increase $3A70 (the number of attacks). I found a way to increase $3A70 with triple-BAR as well and nothing changed, so clearly $3400 has to have everything to do with it, but I can't say I know why.
Title: Re: Remaining bugs in FF3us
Post by: 13375K31C43R on July 31, 2017, 05:15:18 PM
Title: Re: Remaining bugs in FF3us
Post by: 13375K31C43R on August 03, 2017, 01:00:42 PM
About the beach water transparency problem, I already linked to the SFC wiki page on transparency and color math, but one thing that occurs to me is that there are some games that already seem to do it right, e.g. Final Fantasy IV and Secret of Mana. In both cases you see the characters' heads above water and their bodies under it. If there was some way to reverse-engineer one of those games to figure out its color math protocols, perhaps we could apply it to this game.
On the other hand, I think Final Fantasy V has a similar problem to this game; in the Ship Graveyard, your character appears fully submerged when you go underwater. Maybe that's intentional, because they're supposedly "swimming" through rooms of ships that are filled with water and don't have any air pockets, rather than just trudging through, but my only reservation about that is that it implies that they can hold their breath underwater indefinitely, which is not true for the sunken Worus/Walse Tower.
:edit: Actually, Final Fantasy V works a bit differently than I thought. While the Ship Graveyard sees you going all the way underwater in some places, there are other places where your head sticks above the surface. For example, in Walse/Worus Town, Istory Falls, the Castle Bal moat, or even in a couple areas of the Ship Graveyard. In fact, there was one room in the Ship Graveyard where I found that my head was above water walking around, until I went down the stairs. So clearly, there's a way to make it work for sprites in FF6.
Title: Re: Remaining bugs in FF3us
Post by: 13375K31C43R on August 04, 2017, 02:31:53 AM
Here's some new info on the beach bug: I've been playing around in Zone Doctor. Turns out every map has a "priority set" byte that determines transparency for all of the layers of the map, and the Solitary Island beach uses priority set 14.
The info on priority sets is located at C0/FE00, and is three bytes per set. The first byte is written to register $2131, a color math register that specifies what color math function is used and which layers are subject to color math. The second and third bytes are written to registers $212C and $212D, the main and sub screen designation registers, respectively. Check out this page (https://wiki.superfamicom.org/snes/show/Registers) for details.
The problem with priority set 14 is that it enables transparency for the sprite layer and BG layer 1 (the sand underneath the waves), and transparency on the sprite layer only works on sprites using palettes 4-7 (which is why Cyan, Shadow, Setzer, Mog and Umaro appear fully submerged). I've tried all the others and found that the only alternative sets that correctly show translucent water are 1, 7, 8, 10 and 18. 7 and 8 show all sprites fully above the water (which is not good for the fish), while 10 submerges only the fish and any part of your character that is close enough to the fish (it's a little hard to explain, but it's also not correct). Meanwhile, 1 and 18 show all sprites fully submerged.
I think half of the fix for this bug will be changing the priority set to one of those two, and the other half will be finding a way to ensure that characters' torsos and heads are above water while the legs are below the surface.
:edit: Actually, priority set 10 has the same problem as priority set 14: it completely submerges certain characters.
:edit: Unfortunately, there's a major flaw: the game is set up so that layer 3, which shows the waves, will be displayed on any map either over all sprites or beneath all sprites, regardless of the sprite's priority. That makes it impossible to display different parts of different sprites both over and under the surface without enabling transparency on the sprite layer, which will force a full submerge on characters whose palette ID is 4+.
Title: Re: Remaining bugs in FF3us
Post by: assassin on August 20, 2017, 11:49:25 PM
maybe write a specialized event function and command to copy the lead character's palette data into one of Palettes 0 thru 3 when entering that screen (and exiting the main menu)? which palette numbers aren't claimed by Cid, fish, the bird, the raft, magicite, etc?
:edit: (9/14/17) to elaborate:
if (lead character's palette < 4) then begin copy palette data into a palette slot that's >= 4 assign the higher palette slot to bottom sub-sprite end else begin ; character's palette is >= 4 copy palette data into a palette slot that's < 4 assign the lower palette slot to top sub-sprite end
iow, like the Transparency article said: "One way around this is to make palettes 4-7 mirrors of 0-3 so that you can select individually on each sprites".
Quote
Unfortunately, there's a major flaw: the game is set up so that layer 3, which shows the waves, will be displayed on any map either over all sprites or beneath all sprites, regardless of the sprite's priority.
how much of this area is broken should you disable the BG3 Priority flag there?
Title: Re: Remaining bugs in FF3us
Post by: assassin on August 29, 2017, 06:38:40 PM
random thoughts:
- maybe the BG3 Priority flag is set generally so text shows up on top of everything? namely boxless text, as textboxes seem to clip (or delete?) sprites. - on some screens (e.g. Albrook, Cid's house exterior), a portion of the party sprite will be moved between Priority 2 and Priority 3, depending on where you're currently standing. the beach looks to be Priority 2 all the time (albeit tested without fish, bird, magicite, Cid, or raft present). that could give some flexibility in using additional priorities for whatever fix is eventually pursued. - something that poses a challenge before register access or hardware programming: there is low tide and high tide here. conceptually, the "height" the water is relative to a character should vary. having a constant portion of the sprite submerged might look better than having it all on top, but it'd still be at odds with the wave movement.
EDIT: come to think of it.. because the tide is fairly gentle and the absolute height of a character is pretty small, depth changes from tide would probably translate to just 1-2 pixels in water height. so small enough to ignore without looking too off, and not worth the ungodly amount of effort it'd take to represent.
Title: Re: Remaining bugs in FF3us
Post by: 13375K31C43R on October 05, 2017, 07:08:22 AM
Not sure if you could really call this a bug, but I just noticed this: if one of your party members is currently being subject to the Haste or Slow spell, and another party member tries to target them for another spell during that animation, they will be unable to do so.
There are multiple facets to this: one, if member 1 casts Haste on member 2 while member 2 is already pointing at himself to cast a spell, the pointer will return into the Magic menu.
Two, if member 2 tries to select a spell that targets himself by default, he will be unable to do so until the Haste/Slow animation finishes.
Three, if member 2 is preparing to cast a spell on the entire party, the flashing pointer will appear in front of every party member except member 2, until the Haste/Slow animation finishes. However, even if he confirms that selection before the animation finishes, he will still be hit by his own spell along with the rest of the party.
It is unknown at this point if there are any other spells that cause this issue, but I'd guess that it occurs with any other spell that animates some manipulation of the party member's sprite, such as Dischord.
:edit: Apparently this isn't limited to spells; I just tried targeting a party member for Fight and it wouldn't let me do it while the animation was running.
Title: Re: Remaining bugs in FF3us
Post by: Tenkarider on October 05, 2017, 10:28:36 AM
i remember also Slash animation on an ally won't make him be available as target(of ally spells in particular) until that animation ends
Title: Re: Remaining bugs in FF3us
Post by: assassin on October 05, 2017, 02:24:48 PM
dude: http://masterzed.cavesofnarshe.com/GameDocs/ff3bug.txt "Prevent manual character targeting with certain attack animations"
this and the Chocobo thing make me think you're ignoring the best single source of bugs on this game (admittedly not complete, as Square programmers are somehow still adding bugs to FF6 -- some of them from beyond the grave -- but it's a superb starting point for any research).
Title: Re: Remaining bugs in FF3us
Post by: 13375K31C43R on October 05, 2017, 02:34:47 PM
Only because that list is SO DAMN LONG. Although I guess next time I find something like that I can check that list first.
Still, at least the bug has been reported on this thread.