øAslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=363;area=showposts;start=570e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index583d.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=363e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index583d.html.zxG–h^ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈ@> ÎOKtext/htmlISO-8859-1gzip@øÕ ÎÿÿÿÿÿÿÿÿWed, 11 Mar 2020 07:58:24 GMT0ó°° ®0®P®€§²ð®F–h^ÿÿÿÿÿÿÿÿŸ$ Î Show Posts - 13375K31C43R

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - 13375K31C43R

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 »
571
Game Modification Station / Imp's Rage
« on: February 07, 2016, 02:38:52 AM »
According to Master ZED's Bug FAQ, there's a bug that occurs when Gau tries to enter Rage but is turned into an Imp beforehand. Rage is a command that is not compatible with Imp, so Gau will Fight instead, and will not gain any of the statuses or immunities attached to the Rage; however, he will still become autonomous.

Quote
Normally, during Rage, on every attack the character makes, the properties of the monster in question are reloaded for the character. However, if that character has become an Imp, the property reload routine will ignore the fact that the character is still in a Rage and not even call Rage's reload routine. They will still attack anyway though, making this a dangerous bug. It's also the reason why Critical Hits if Imp doesn't work for characters. Once Imp status is healed, the Rager must still take a turn before the Raged monster's properties are restored to them because the Rage command isn't used during Imp (it's swapped for Fight).

I tried a fix that makes Rage compatible with Imp, thus giving Gau the elemental properties of the Rage as usual, while still ensuring he only attacks and doesn't try to cast any spells (they will fail because of the Imp status). However, there's now an issue if Gau Rages as a monster with immunity to the Imp status because the immunity will prevent the status from being added or removed, meaning Gau will remain an Imp until the battle ends or he is KO'd.

With this in mind, there are three possible ways to fix this. One is to make Rage ignore immunity to the Imp status, but this is probably not a good idea as it veers away from the developers' intentions. Another is to make Rage remove Imp status if immunity is included, but again, probably not a good idea as there may be situations where being an Imp is beneficial (e.g. Imp equipment). The third way, and the best IMO, is to make sure Gau does not become autonomous if he is an Imp.

572
Game Modification Station / New patch: Vanish/Runic Glitch fix
« on: February 06, 2016, 03:46:31 AM »
I recently read that if Celes or Gogo uses Runic and absorbs the Vanish spell, they will disappear for about two seconds using the same Vanish "wipe" effect which happens twice, but it shouldn't happen at all because they don't gain the Vanish status. The reason for this is because Vanish's animation script sets the Vanish bit for the absorbing character's sprite and then refreshes the sprite, thus triggering the wipe effect, but the game also repeatedly updates sprites based on their current status, so the sprite reappears immediately. This patch simply removes the wipe effect from the animation script, thus leaving all Vanish-related updates to the status check.

:edit: September 17, 2016
After tons of scrutiny, I found a way to port this patch to GBA. This is exhausting work, so I think I'll take that well-deserved break, because I have other stuff I need to do. I'll try and port as many of the others as I can eventually, but not for a while.

573
Game Modification Station / Re: Graphics bug fixes - help!
« on: February 06, 2016, 12:37:25 AM »
It's been a while since I've had the chance to work on either of the two remaining bugs that I want to fix at some point. Right now I've put in so much effort, but I know that there's still so much more to do, that I would really appreciate some help. So, just as an update, here are the two bugs, as well as a third, that I want to fix:

  • If Haste or Slow is cast on Tyrannosaur in the Coliseum, he'll shift backward
  • If Doom is cast on a party member wearing Magitek armor, only their upper half will be taken by the Grim Reaper
  • If Phoenix Down is used on a living character with a shield, they'll block it twice

574
Game Modification Station / Re: New patch: Banon Riding Glitch fix
« on: February 03, 2016, 02:26:05 PM »
Ooh, I like that one. :happy: Yes, I agree that the arms aren't quite right on mine, or the legs for that matter, and I still don't quite like the back of his hair, either. You did a better job than I did on that. :wink:

On second thought, I think I also prefer the Locke sprite's leg position as well, but don't worry about that. I'll get around to fixing the sprite up myself the way I want at some point based on your input.

575
Game Modification Station / Re: New patch: Banon Riding Glitch fix
« on: February 03, 2016, 12:23:59 AM »
Mmm... Those look pretty cool, but I'm not sure what you mean by "authentic". Do you mean "realistic", as in more accurate to what the design would most likely have been?

The tricky thing about designing Banon's riding sprite is that there's no known precedent for how it's supposed to look in terms of the little details, such as placement of the arms and legs. I tried to be as realistic as I could with mine. For example, if you superimpose my Banon sprite onto a chocobo, you'll see that his long coat drapes down in front of its tail, which is why it doesn't flap in the wind because the tail's in the way (same for Strago's and Celes's capes), though the stole-looking thing he wears around his shoulders does. His hair's also a lot more active than either of yours as both the front and the back of his hair move around, as is the case with most of the riding sprites. I basically just stole the hair from his "ready to fight" and "magic chanting" poses.

As it stands, as nice as those sprites look, I'm not really inclined at the moment to change mine. But if I had to choose between one of yours, I'd personally prefer the Sabin one. Although I actually prefer the cape on the Locke one.

576
Game Modification Station / Re: New patch: Banon Riding Glitch fix
« on: January 25, 2016, 02:16:29 PM »
Yes, Ghost and Leo have the same problem, but it's only visible through hacking. I'm not going to address any situations involving any kind of hacks except for bug fixes.

577
Game Modification Station / Re: Graphics bug fixes - help!
« on: December 13, 2015, 09:29:01 PM »
Here's another glitch I'd like to fix: if Haste or Slow is cast on Tyrannosaur in the Coliseum, he'll be shifted backward slightly for the duration of the spell's animation.

578
Game Modification Station / New patch: Side Saddle Glitch fix
« on: December 11, 2015, 06:02:13 PM »
Hi everyone! Well, I did it. I slaved over this issue for weeks and finally figured out how to solve it. This glitch occurs when a member of your party vanishes during battle while riding Magitek Armor. The game accidentally draws both the disappearing and reappearing animations over the armor, so the legs become visible outside the armor. This patch ensures that the characters' legs never become visible while they are riding Magitek Armor.

And while I'm at it, there's another issue that's been stressing me out just as much: Doom only taking away a character's upper body when they are riding Magitek Armor. There's documentation on Slick Productions that includes the C1 bank, so you can see the code at C1/3D43 surrounding the JSR I added to replace a CMP. Basically, the Vanish animation manipulates the sprite data stored in RAM at 7F:0000-7F:A000, so to fix this glitch I made sure the legs wouldn't be stored there for characters riding Magitek Armor. When a character reappears, the sprite data there is repopulated with the sprite data in the ROM at D5/0000 onwards. I'm thinking I need to do something similar with the Doom animation. I need to find the area of the code where it grabs data for the sprite that gets hauled off by the reaper and force it to include the legs.

:edit: December 13, 2015
Fixed a problem with the patch whereby it sometimes wasn't including the legs at all, because the code that checks if a character has Magitek status was grabbing data from the wrong place in RAM. This problem is now fixed. I recommend re-downloading this patch.

:edit: February 11, 2016
Fixed a patch-breaking problem; the patch was adding the free space in the wrong place. The free space overlapped with the last three bytes of the Magitek-check function, breaking it. As I said, this problem has now been fixed.

:edit: February 11, 2016
Fixed another patch-breaking problem with the 1.0 patch; I'd failed to make the necessary adjustments to some of the JSRs. Also made a correction to the Magitek Armor check function; it was still loading from the wrong place in RAM and I'd somehow failed to notice.

:edit: March 21, 2016
Discovered a RAM byte that allows for some added efficiency. Re-downloading is optional, but recommended.

579
Game Modification Station / Re: Graphics bug fixes - help!
« on: December 11, 2015, 12:36:11 PM »
OK! I managed to fix the Vanish issue, and I'll post a patch for it shortly. Now all that's left is the Doom issue. The problem seems to be in the copying of the sprite that's on the screen to a lighter tinted sprite that gets lifted by the reaper, which is probably why the legs aren't there. For the Vanish issue, I found that the vanish animation takes sprite data that was loaded into RAM from the sprite data bank in the ROM - there's a function at C1/3D43 that does this. So if I can retrieve that for the Doom animation, I can add the legs.

580
Game Modification Station / New patch: Banon Riding Glitch fix
« on: December 10, 2015, 02:05:18 AM »
Hi everyone! I finally got around to fixing a bug that's been...bugging me ever since I found out about it. It's the infamous oversight of Square not including a chocobo-riding sprite for Banon, making the game pull data from Terra's Esper form sprites instead. To fix this, I drew up my own riding sprite for Banon, which came out pretty well if I do say so myself. The best part is, there's a lot of free space right before the sprite data, so I just shifted all the other sprites into that section to make room and adjusted all the pointers accordingly. This patch also fixes a related issue that causes Banon to look all scrambled when riding a chocobo on the world map.

Unfortunately, due to the size limit, I cannot post all of the patches at the same time, only one. So be sure to make a backup of your ROM before applying this patch! ;) Or, follow this link to find the full set.

:edit: December 12, 2015
I decided to edit Banon's hair just a little bit.

:edit: February 4, 2016
As a response to some constructive feedback, I've made a few more changes to the sprite, including his cape, leg position and hair.

:edit: April 23, 2016
I've made some optimizations, and now this patch no longer uses any free space in bank EE.

:edit: July 25, 2017
Added "lite" patches; see below for details.

:edit: December 26, 2017
Fixed a neglected pointer.

581
Game Modification Station / Re: Graphics bug fixes - help!
« on: November 16, 2015, 04:55:06 PM »
OK, after a bit of fiddling around, I've managed to determine that the functions that control the Vanish animation are C1/3050, C1/3106 and C1/3157. So far I haven't managed to make any of those methods affect the sprites exactly the way I want, but it's a start.

582
Game Modification Station / Re: Graphics bug fixes - help!
« on: November 14, 2015, 09:12:09 AM »
Also, since the legs only change during the Vanish on/off animation, that tells me that if I can find the code for that animation, maybe I can figure out how to make it affect only the upper body and that will also help me with the Doom animation.

583
Game Modification Station / Re: Graphics bug fixes - help!
« on: November 12, 2015, 04:17:11 PM »
No, it's not so much a bug as it is a...logical inconsistency. Like the "Invisible Zombie".

One thing that bugs me, though, is that Vanish seems to be the only status that causes a party member's legs to be drawn outside the armor. Every other status accommodates. Also, after being drawn outside of Magitek armor, the legs never move to match what the upper body is doing. That tells me that perhaps the programmers did in fact intend for the armor to disappear, they just didn't do it correctly.

584
Game Modification Station / Re: Fancy Walking patch issue
« on: November 10, 2015, 08:08:15 PM »
OK, never mind, I can still reproduce it. But you can still optimize a bit using my suggestion.

585
Game Modification Station / Re: Fancy Walking patch issue
« on: November 10, 2015, 06:54:32 PM »
I was able to reproduce the problem too, until I noticed this in the ASM file:
Code: [Select]
C0496A: JSR $4A03  ; add to step count, deal with poison damage, save point use, etc
C0496D: ; JSR $4AEC  ; now a redundant call
C04970: LDA #$01
C04972: STA $57
C04974: STZ $078E
C04977: RTS

What I noticed in particular is, the three instructions that follow the JSR also appear at the end of the function at C0/4A03. So you could replace that JSR with a JMP and get the same effect. I tried that in my ROM and haven't been able to reproduce the problem since.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 »