Aslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;sa=messages;u=397e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index752c.htmldelayedslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=397e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index752c.html.zxgh^ ̗OKtext/htmlISO-8859-1gzip@̗HWed, 11 Mar 2020 07:12:00 GMT0 0Pgh^#̗ Show Posts - silentenigma

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 - silentenigma

Pages: 1
1
Game Modification Station / Re: C. V. Bug-Fix Comp and C. V. Script Fix
« on: February 19, 2017, 08:39:50 PM »
It occurs after Terra's flashback: https://youtu.be/1WBHYAB-HOM?list=PLa38YJsyG7Og0-EjkTaq4cWwmZr8oJJFS&t=843.

I can say it isn't me this time. But while we're at it,  stuck-in-a-pose v1.0 and v2.0 result in a minor, brief eyesore a few minutes later, just after Setzer gives the airship tutorial. Unpatched, when the characters merge, the M.C. gets placed in the "I'm ready!" pose, and control is immediately given back to the player. Patched, that pose becomes a just a quick blip. So I made a v2.1, to make that moment appear more natural.

(Since we're not exactly hurting for free space in the C0 block, I'll be happy to make adjustments for any other edge cases that pop up.)

2
Game Modification Station / Re: C. V. Bug-Fix Comp and C. V. Script Fix
« on: February 18, 2017, 08:37:40 PM »
Stuck-in-a-Pose has now been updated to address the bug. C.V., if you are interested for your project, you can find it here.
The new version uses 21 fewer bytes of free space than the original (I found a better candidate for the data table than what was in the readme.) Thanks to Assassin for the suggestion to optimize.

Again, 100% confidence will come with time, but I do feel optimistic that we'll find Leet Sketcher's solution to be robust.

C.V., I look forward to giving your megapatch a spin soon! (and...competing with it  :laugh: ...sort of... )

3
Game Modification Station / Re: Patch: Stuck in a Pose fix
« on: February 18, 2017, 08:11:16 PM »
A bug was found with this patch. Details here.

The patch has now been updated to address this bug, and now uses 21 bytes fewer free space. Thanks Leet Sketcher for rapidly finding a solution. Any additional feedback is always welcome.

4
Game Modification Station / Re: C. V. Bug-Fix Comp and C. V. Script Fix
« on: February 14, 2017, 10:24:29 AM »
Hi folks. Thanks C.V. Reynolds for giving my patch a whirl, thanks to Leet Sketcher for finding a solution, and thanks to seibaby at ff6hacking for notifying me about this.

Ah, it would seem that all those LDA index-Y commands need the new Y, not whatever garbage was in there before.

I must not have realized that $0803 (from the instruction I delayed) holds "the most up-to-date offset for where to find the current direction". I do want to be a bit more confident that this is always the case, though I don't know if I'll have time right now to look very deep. So unless Leet Sketcher already did that digging to arrive at his solution, the confidence may just have to come over time through testing.

In the meantime, this weekend I will be posting updates to the patch (here and across the pond) to include Leet Sketcher's fix.

also, i think the new function could benefit from a data table.  it'd save 20 bytes if we use the starts of the tables in the patch Readme, or 18 if we make our own 4-byte table.

I agree, and yes, the table in the Readme (every fourth byte starting with C0/581D) can be used. I will make that a part of the update.

wow, walking toward him? even this one is due to "stuck in a pose" patch?
Ouch, have I been making headaches all over the place with this thing? Sorry about that.

I'll post again soon.

5
Game Modification Station / Re: Patch: Stuck in a Pose fix
« on: February 26, 2016, 12:18:05 PM »
I agree it's a gray area, and some might prefer my example unaltered. But for most cases, I tend to gravitate towards this being a result of lazy design/coding. What actually convinced me was Novalia's last example, where the player ends up being able to talk to an NPC when the hero sprite appears to be facing away. To me it seems like the event programmer(s) thought that a check like mine would kick in after the end of each scene, while the field gameplay programmer(s) thought that each scene would be fully resolved before giving back control to the player.

The stairs example is definitely a minor bug, though, since it's such an inconsistent effect.

6
Game Modification Station / Re: Patch: Stuck in a Pose fix
« on: February 26, 2016, 02:43:50 AM »
I'm pretty sure there are countless cases. I hadn't noticed those listed by Novalia Spirit either, but my pet example is at the end of Terra's first scene with Edgar - The scene concludes with Terra looking down and saying the line "But I'm hardly... normal...", and the player regains control with her head still nodded. It sticks out in my mind because it took me a few seconds to realize that the scene had actually ended!

Also I'm not sure about your example (It's actually been awhile since I last did a full playthrough...), but if it's a case where the player has movement control, is not pressing any buttons, and the character is making any pose other than the usual "standing still in x direction", then this patch applies.

7
Game Modification Station / Patch: Stuck in a Pose fix
« on: February 21, 2016, 08:49:21 PM »
Here's another patch I've whipped up to fix the "Stuck in a Pose" bug from Novalia Spirit's 100+ bugs thread.

Quote from: Novalia Spirit
After any event-dictated movement occurs, the hero sprite may appear to be stuck in its last pose or its walking pose. The easiest way to see this is to go up and down some stairs. Most of the time, if you stop walking, the hero sprite should appear in a walking pose. Other examples of this are when you jump on a turtle, when trying to go up a conveyor belt to no avail, and after a scene where your party was split temporarily.
...
One better example of this bug is when you're within the airship and talk to the guy who can unequip your characters. While you do so, the hero sprite should look South and be in a walking pose, yet, even if the said guy isn't South of the hero sprite, you can still talk to him since the game still considers you're facing him.

This patch inserts a check to ensure that the character's standing-still sprite is being used whenever the player has control, but is not pressing any directional buttons. I'm pretty sure there won't be any circumstances where that creates a problem (but let me know if anyone thinks of any). It uses 38 free bytes in the C0 bank below my "Sliding Dash" patch.

Cheers!

Edit: The patch has been updated as of Feb. 18, 2017 to address a bug described in  this thread.
Edit2: The patch has been updated once more as of Feb. 19, 2017 to smooth out a blip in the sprite animation, which occurs right after Setzer gives the airship tutorial.

8
Hello!

I have made an updated version of Angelo's Final Fantasy VI: Restored Ability Names patch, with the following new features:

 - Moves battle scripts to the FE block in the expanded portion of the ROM (workaround found by Dr. Meat for a bug in the original patch)
 - Realigns the Spell/Learn Rate list in the Esper submenu.
 - Space optimization:  Returned special ability names (Lore, Dance, etc.) to their original location on the ROM.
 - All of Angelo's name choices are retained.
 - Version compatible with Imzogelmo's Multi-Steal Fix is now available. As far as I know, Restored Ability Names should now work with projects like FF6 Improvement.

I've also included a version with a few additional modifications (See the screenshots below):
 - Returned spell description window to its original height. All default descriptions now fit properly again.
 - Esper names, LV/HP/MP, etc. rearranged in submenus and the airship menu for (in my opinion) a more natural-looking alignment.
 - Several name changes vs. Angelo's version (e.x. Efreet -> Ifrit, Regene -> Regen, ...)
 - The appearance of class names has been revamped to be a bit less intrusive vs. how they were designed for the original game. I'm pretty sure they are just a novelty for most players, so instead of putting them  in nearly every menu and cluttering everything up, class names are instead relegated to the Status page. They also have been renamed where appropriate to match with actual recurring FF classes.

The patch can be found here. Edit: I've actually just found a minor flaw immediately after posting. Hold off for just a bit while I fix it. Edit: Should be good.

Enjoy!

9
Game Modification Station / Re: New patch: Side Saddle Glitch fix
« on: February 12, 2016, 03:31:51 PM »
Looks like that did the trick! Nice work.

10
Game Modification Station / Re: New patch: Side Saddle Glitch fix
« on: February 11, 2016, 12:55:46 PM »
Thanks for taking a look at this. Just tried again. I'm still getting the same behavior for the 1.0 headered version, and on the 1.1 headered version, full legs are visible on top of the magitek armor when vanish is cast (like the original).

(Also I think the .zip version you uploaded is the old version - last modified December 11.)

Good luck!

11
Game Modification Station / Re: New patch: Side Saddle Glitch fix
« on: February 11, 2016, 01:25:11 AM »
Leetsketcher,

I've been having trouble with this patch. I'm trying it on fresh ROMs, and I believe I'm using your latest version (the one here and on your site). For the 1.0 headered version, battles get stuck before the fade-in, and in the 1.1 headered version, everyone is invisible (no character sprites drawn, iirc) all the time in battle. Are you aware of the issue? (There's always a chance I'm just crazy.)

12
Game Modification Station / Patch: Sliding Dash
« on: February 11, 2016, 01:07:29 AM »
Hello!

I just finished writing a fix to take care of the standing-still-while-dashing bug that popped up in Master ZED's FF3dash B & C patches. It also makes walking animations more smooth in general, which should be noticeable for some of the slow-moving NPCs.

The problem stemmed from the way the game reduces the character's position data in order to decide which sprite to show mid-stride, which ended up being asymmetrical between increasing your position value (moving down/right) and decreasing your position value (moving up/left). The sprite goes through a four-part cycle every two tiles (e.g. right step, standing, left step, standing...). When going at max speed with Master ZED's patch, the Up/Left animations skip the "standing" sprite, while the Down/Right animations would skip the "stepping" sprites.

This hack avoids the half-baked solution that FFAnthology implemented, which itself had the side-effect of putting stationary characters in the walking pose after dashing.

I used 15 21 bytes of space just underneath Master ZED's dashB/dashC code - I'm under the impression that this space is still unused by other hacks. Let me know if I am mistaken.

Enjoy!

13
Game Modification Station / Re: New patch: Banon Riding Glitch fix
« on: February 03, 2016, 11:51:52 PM »
Thanks, I'm glad you like it! I played with the Locke version some more as well, but I won't spoil it now ;) There are plenty valid directions one can go with that - leaning forward like Locke, or a bit straighter like Celes/Terra.. Looking forward to whatever you come up with. Thanks for accepting some of my input!

Cheers!

14
Game Modification Station / Re: New patch: Banon Riding Glitch fix
« on: February 03, 2016, 01:32:26 PM »
Thanks for the feedback. Yes, I meant "realistic" in the way you put it. I'd liked to have used the Locke-style cape on both sprites as you mentioned, but width became a problem when I started animating. However...

You definitely have me beat on what is/what isn't animated on the sprite, so kudos there (and I'm attempting to adjust - width is no longer poses an issue...). Though I agree the cape should be static, I think there might be more precedent not for it to be totally draped around, but rather for it to have more of a rumpled-up look (at least that's how I interpret Strago's and Celes').

Anyway, if you don't see a use for mine and are up for some more specific feedback on yours...
What did prompt me to give this a shot was the way the arms were handled - mostly that they appear a bit too long to me. I think it's because the shoulder position was taken from an angled sprite, and this puts them pretty far back for the arms to be in a forward-reaching position. (Also the sleeve color, but I'm sure that's already been noticed.) So those might be some minor improvements worth making sometime in the future.

Of course, this all is a speculative exercise by nature - and mostly fun for me. But either way, nice going on making this fix - quite an oversight indeed on Square's part.

15
Game Modification Station / Re: New patch: Banon Riding Glitch fix
« on: February 02, 2016, 11:40:58 PM »
Leetsketcher,

I just ran into your work recently, and I'd like to offer you a redesign - These might look a bit more 'authentic'. There are two options - one is based on Locke's riding sprite, and the other is based on Sabin's. Let me know what you think.

Pages: 1