Patch: Pugs Rage - Printable Version +- FF6 Hacking (https://www.ff6hacking.com/forums) +-- Forum: Hacks, Resources and Tutorials (https://www.ff6hacking.com/forums/forum-1.html) +--- Forum: Jidoor Auction House (https://www.ff6hacking.com/forums/forum-4.html) +---- Forum: Patches, Bugfixes, Tweaks (https://www.ff6hacking.com/forums/forum-15.html) +---- Thread: Patch: Pugs Rage (/thread-4156.html) |
Patch: Pugs Rage - SilentEnigma - 12-06-2021 author: SilentEnigma Version 1.2 released 2021-12-31 Download Okay! I think this is ready enough. This patch makes it possible to view the Pugs rage in the field menu and select it in battle. Big thanks to @assassin for a lot of way-paving on this topic previously at Slick: https://web.archive.org/https://slickproductions.org/forum/index.php?topic=2245.60 & shouts out again to @seibaby for the post that got the wheels turning for me. A few tidbits on the implementation:
See the Readme for more & better info. RE: Patch: Pugs Rage - assassin - 12-06-2021 Code: Archive Contents this rivals some of leet sketcher's patch releases for Archive Contents size! that must've been fun to make. ;P Quote: will Function C2/1560 still have C2/1566 (which i think is run for Mimic; worth confirming) defer to an existing Rager with this pre-setting of the $33A8,indices now having occurred? --- more generally: kickass work. it'll take me awhile to process all that. not knowing enough about the relevant Bank C1 code was a key hurdle i faced in considering tackling this (though hardly the only one). it's curious how little you wound up having to change there! another was not wanting to have to 16-bit-ize a bunch of things just to allow one more Rage: it'd involve either overhauls and more RAM claiming, or nasty fudges. i'd known that the field Rage menu (generated in Bank C3) could contain placeholder/intermediate data (as opposed to the Monster ID), as you don't actually *select* anything on it ... unlike the battle Rage menu (of C2), which was thus more formidable. glad you were able to devise an intermediate system for the latter. RE: Patch: Pugs Rage - SilentEnigma - 12-06-2021 (12-06-2021, 04:54 AM)assassin Wrote: this rivals some of leet sketcher's patch releases for Archive Contents size! that must've been fun to make. ;P I think it's safe to say I will not be including a set of anti-patches with this. lol (12-06-2021, 04:54 AM)assassin Wrote: will Function C2/1560 still have C2/1566 (which i think is run for Mimic; worth confirming) defer to an existing Rager with this pre-setting of the $33A8,indices now having occurred? (The code in question...) Code: Rage Oof, who snuck that reference to $33A8,Y in there!? ...Yeah, I didn't touch this function. Looks like Mimic will grab the wrong rage 99% of the time. (Viva la 1.1!) I will need to find another way to detect that a mimic is taking place at that moment. Or, it might be as simple as changing C2/1560 to "LDA $33A9,Y" since the high byte still holds #$FF until the rage occurs, after which it holds #$00. If all works out, that should get us back to vanilla behavior. But it seems like even vanilla is a bit off, too. Won't Mimic use a stale rage ID in the following scenarios?
Anyway, thanks for the tip-off. (12-06-2021, 04:54 AM)assassin Wrote: it's curious how little you wound up having to change there! It was few months ago, but iirc the menu stuff in C1 practically wrote itself compared to C2. I'll just assume I was super careful about C1, at least until C2 gets tightened up. RE: Patch: Pugs Rage - SilentEnigma - 12-20-2021 The patch has been updated to v1.1 to address the oversight with mimicked rages. (12-06-2021, 03:32 PM)SilentEnigma Wrote: Or, it might be as simple as changing C2/1560 to "LDA $33A9,Y" since the high byte still holds #$FF until the rage occurs, after which it holds #$00. If all works out, that should get us back to vanilla behavior. This alone would have worked, but it also made sense to extend the idea. Using the high byte for all the applicable null checks, it is no longer necessary to pre-load a random rage ID for each ally at the start of battle. The update uses the high byte method instead, which as an added bonus reduces the free space used by 2 bytes. Thanks again @Assassin for the nudge. (12-06-2021, 03:32 PM)SilentEnigma Wrote: But it seems like even vanilla is a bit off, too. Won't Mimic use a stale rage ID in the following scenarios? I tested both scenarios in vanilla, and they behave as suspected. Never pegged myself as a bug finder for the battle system, but here we are! RE: Patch: Pugs Rage - assassin - 12-23-2021 your patch is currently robust to the following list: 00 01 02 02 03 04 05 05 05 06 07 07 08 08 08 [...] in terms of menu handling. however, given that you ditched the strange loop C2/05ED - C2/05F9 and don't attempt to replicate its list crawling or sanity checking, i believe your patch is NOT robust to the above list in terms of random selection. if that is acceptable/intended *and* you're willing to go further in that direction, i _think_ you could save ROM space by leaning harder on the $3A9A counter variable and the fact that the in-battle Rage list is compressed (i.e. blank-less). this should allow the following corner-cuttings / optimizations: 1) shrink Function C2/A691 by a few bytes, replacing the $257D,X check with a $3A9A check: Code: phx 2) drop most of the C2/A6AB function by no longer padding the end of the list. ---- the thing is, i LIKE that your current patch method is robust, for menu handling, to the above example. so i'm not ACTUALLY advocating you change things in this way. rather, i'm interested in whether you think it'd work (both the idea and my code attempt), and if so, how many bytes could be squeezed out of the patch code. or conversely, whether you think it's worth adding "smart crawling" dupe-accounting to the random Rage selection. (not to say it's necessarily an either-or choice; neither could also suffice.) admittedly, i first decided to make this post back when i thought i could reduce C2/A691 by ~8 bytes, before remembering to account for the ($3A9A == 0) edge case. RE: Patch: Pugs Rage - SilentEnigma - 12-24-2021 Great stuff, @assassin. Now, assuming I've done my job right with modding C2/5841 - C2/585F (building the compressed list @ $257E), your example list should not be possible. The only duplicates should be the padding at the end. (Just like you should never actually see FFh in the middle of the compressed list in vanilla. Am I missing something?) To help my case, I believe the battle rage list was originally not going to be compressed. Then the strange loop would have been necessary: (note the slightly tweaked C2/05F2) Code: Hypothetical Early Build: This resembles the loop C2/053C - C2/0549 for locating a randomly selected Magic/Lore spell from an uncompressed list. With this in mind, I do not take the rage loop itself as any evidence that it is possible to have a compressed rage list with nulls in the middle. If I am mistaken, then I would definitely want to restore the correct game behavior via some similar list-crawling as you suggested. (But I think we're good, so... onward!) You raise a great point with the rage count, and that is a beautiful revamp for C2/A691 -- Since every list item of index 0 through ($3A9A) - 1 is going to be a valid rage ID, then why get fancy with duplicate IDs? Just as well to compare the list index to ($3A9A) - 1 and call it a day. Excellent. We still need the "SEP #$10" at the beginning, but besides that it's testing great so far. We only get 3 bytes out of C2/A691, but then C2/A6AB can be eliminated entirely. In total, it is going to save about 24 bytes. If all checks out, I'll generate another set of patches to incorporate your optimization. Thanks! By the way, C2/585F in the "AZ" variants of this patch has a benign bug... Code: Pugs Rage v1.1: Merry Christmas! RE: Patch: Pugs Rage - assassin - 12-24-2021 thanks. i think (and hope) so. yeah, my example should just be a hypothetical input. for some reason, i was half uncomfortable "downgrading" your function to no longer be robust to even that. :/ but since you're comfortable with it, and the patch's random selection does not account for such a situation, might as well make the optimizations. good theory on the reason for the strange loop, and the C2/05F2 change is sensible and elucidating. i'd pretty much attributed vanilla's way to a sanity check with "emergency ejection", but that seems a bit abortive and panicky. your way, complete with the branch tweak, is more logical and useful. it's plausible that Square would miss code branching too far, if they changed the list format before that code ever activated. Quote:With this in mind, I do not take the rage loop itself as any evidence that it is possible to have a compressed rage list with nulls in the middle. good. i saw no corroborating evidence, either, but would have been antsy about dropping it, "just in case". re C2/A691: 1. thanks. 2. i was about to include the "SEP #$10" after initially glossing over it to focus on parts i was editing. but then, i was thinking that the new function is agnostic to Index Register size: a) it doesn't directly use X with immediates (e.g. "CPX #$00"). b) vanilla already does "C1/8531: BD 7E 25 LDA $257E,X <= X holds the rage ID" without specifying/switching register size right before. however, i forgot about the C1/662D path! so yeah, it's safer to keep the "SEP #$10". now, upon further examination yet, i think we might be able to: a) insert "TDC" right before "LDA ($4F)", as C1/63FE will be zeroing the top half of A imminently, anyway. b) accommodate (a) by changing C1/6635 to a BRA. but it might not be worth it just to save 2 bytes, as your SEP is very straightforward and reliable (i.e. no code following needed to know X/Y size). on (b)'s subject of optimizing vanilla callers (of C2/A691): is C1/853A indeed a pointless instruction? if so, any way to harvest the 3-byte savings that'd result? (none comes to mind, as C2/A691 needs to be fully callable by C1/662D as well.) ---- Quote:We only get 3 bytes out of C2/A691, but then C2/A6AB can be eliminated entirely.you're welcome. RE: Patch: Pugs Rage - CVReynolds - 12-28-2021 Congratulations on this fix and thank you. I always wanted someone to fix the Pugs Rage, but I always thought it wouldn't be possible. :O Do you think it would it be possible to make Gau learn the Chupon and Siegfried Rages immediately upon encountering those enemies in the Colosseum? I know it's different than the usual learning method, but I think it's a better fix than dropping them and their incomplete battle scripts on the Veldt (and the complications that come with it). RE: Patch: Pugs Rage - SilentEnigma - 12-31-2021 The patch has been updated to version 1.2 to incorporate @Assassin's optimization. (12-24-2021, 02:37 PM)assassin Wrote: now, upon further examination yet, i think we might be able to: Oh, I would totally trade readability for two bytes. Unfortunately, we need to keep the B register value intact so that this 16-bit write is good: Code: C1/63FE: C220 REP #$20 (from C1/6647, C1/6651 etc.) ...Otherwise the first letter of the rage name is hidden :/ (12-24-2021, 02:37 PM)assassin Wrote: on (b)'s subject of optimizing vanilla callers (of C2/A691): is C1/853A indeed a pointless instruction? if so, any way to harvest the 3-byte savings that'd result? (none comes to mind, as C2/A691 needs to be fully callable by C1/662D as well.) Yeah, looks pointless to me. Not sure how it could be used either. Good to know though. (12-28-2021, 04:45 PM)CVReynolds Wrote: Do you think it would it be possible to make Gau learn the Chupon and Siegfried Rages immediately upon encountering those enemies in the Colosseum? I know it's different than the usual learning method, but I think it's a better fix than dropping them and their incomplete battle scripts on the Veldt (and the complications that come with it). Sounds very doable. I'll check it out. Happy New Year! RE: Patch: Pugs Rage - assassin - 01-02-2022 eep, i majorly brainfarted, and lumped A in with X and Y as far as size changes clearing the top half! |