Jump to content

(FE8) Help With Pierce Glitch Removal


EdeaCreamer
 Share

Recommended Posts

This seems like it would fall under 'Battle Animation/Sprite Hacking', but instead of trying to create and insert a brand new animation/sprite, I'm merely interested in finding and fixing an existing screwup in the English translation of the game.

The problem is apparently that the control code for 'wait until HP has been depleted' isn't checked/is bypassed whenever the Pierce skill activates, shortening the attack animation and introducing the possibility of another attack animation executing before the HP deduction from the previous attack has had a chance to finish. I got hit with this glitch a couple times during my last playthrough with Tana, and it was quite frustrating.

Fixing this in and of itself is probably not that difficult: simply reinstate the 'wait until HP has been depleted' check in the code responsible for processing the sprite/animation data when Pierce is flagged as having been activated.

My problem is that I have no idea what this data would look like, or where to locate it in the ROM. I would attempt to trace the event during play using no$debugger, but I would not understand the output, and it doesn't seem to allow me to do a live dump of the data for others to look at. I tried a resynchronizing compare between the English and Japanese versions of the game using Hex Workshop (as the Japanese game does not possess this error), but again I don't know what data to look for, so that didn't help me. I'm looking through a lot of Hextator's docs on battle sprites/animations, right now, but I'm not seeing anything for Pierce, specifically.

So does anyone know where in the ROM the data for the Pierce animation is located, and if so what code I should be looking for/what values should I insert to force the game to check for HP being depleted before allowing the animation to continue? If I need to provide additional information I'll do the best I can, but I normally don't deal with graphics-related hacking, so I'm really out of my element.

Link to comment
Share on other sites

I love this post. This is exactly what posts by newcomers should look like. He did the research and even posted helpful info about the problem which anyone capable of solving it would need (specifically, the bit about the HP reduction being interrupted).

I think we actually figured out how to fix the Pierce glitch and it was something obvious that could be done using info about the 0x85/0x86 commands in the animation data. As for what the fix is or where to find info on it...I have no idea.

I feel like Sauce knows. He knows everything.

Edited by Solais
Link to comment
Share on other sites

Thank you for the kind words. Also, this sounds most promising, hopefully Sauce sees this topic and has the time to respond; I could not locate such a name in the Members list (I'm sorry for being so n00bish), would it be possible to obtain contact information for him?

The 0x85 command list document -does- list the code used for HP depletion (0x01), but I'm not sure if that's what it actually looks like in the ROM (I searched for '01 00 00 85' in the English version and only got one hit, at 0x0890a257), or if that's just how the code appears in OAM. As I've noticed from perusing some of these threads, FE7 is far more well-documented than 8, so some of the opcodes might have changed (for example, one of the '0x53 through 0xFF' codes that previously didn't do anything might've been assigned to Pierce).

Link to comment
Share on other sites

I would attempt to trace the event during play using no$debugger, but I would not understand the output, and it doesn't seem to allow me to do a live dump of the data for others to look at.

i think you can disassemble a block of code (idk about memory dumps)

alternately i like to take screens of the entire emulator if i'm sure that's where the issue is

Link to comment
Share on other sites

I believe the data is compressed. I also don't remember if the data is parsed as a series of bytes or integers, but if it's the former than endianness would be irrelevant and it would appear as 85 00 00 01 anyway. I'm fairly certain it is indeed processed as ints...you could always use FEditor to dump the animation data to both confirm this as well as have access to the data for editing purposes.

You could probably even do what Sauce would try and add/remove/modify the data to fix the glitch, recalculating the offsets of the various animation modes due to size changes in the separately dumped file that contains those offsets.

Sauce is the name I have affectionately given to one of the two members who go by "Shadow of Chaos". Aside from being miserably confusing, made worse by the fact that I'm on friendly terms with both, I just like calling the dude Sauce. If you must know, I call the other one Sock

Edit: Pierce is a skill and functions outside of the context of processing animation data. There will not be a command for Pierce therein. If there were the issue may have been averted to begin with.

As for how to fix the glitch specifically...perhaps there is not an appropriate 0x06 (or whatever the heck it was) command after the 0x01 command in that particular class's animation data. I wonder if giving Pierce to another class would allow that other class to have the same risk of freezing the game. The skill hack I made could be used to test that. I almost want to say that I tested it and confirmed that it's a class specific issue.

Edited by Solais
Link to comment
Share on other sites

I'll admit...whenever I gave the skill to any other class, I couldn't get the glitch to occur. I thought that I had, but upon recollecting properly I discovered I hadn't. I had given Pierce to the Sniper, but Neimi activated it twice in a row against a non-countering target with Nidhogg (damage well over 30) and no glitch happened.

It's curious, I'll dump the animation data with FEditor and take a look/perhaps contact Shadow of Chaos. I'm just happy I'm getting help, this is quite a welcome break.

Link to comment
Share on other sites

against a non-countering target

Is that the correct case to test?

Also, that change to 0x00059116 simply skips a section of code that updates one or two variables in the RAM by turning on/off a few bits in what seems to be a 16 bit array (and perhaps other things). If that code is reached as a result of a hacky attempt to get Pierce working then skipping it would be great, but I feel more like it's best to leave that code alone.

Then again, there are bits of code, like the HP bar drawing code in 7 which doesn't initialize the graphical data to zero first (oddly 8 and even 6 do), which are clearly written wrong and result in silly bugs. BwdYeti has found plenty of animations with incorrect OAM as well.

Link to comment
Share on other sites

Yes, as a target with a chance to counter allows for an ample amount of time in which the HP bar can drain, preventing the glitch from occuring (in fact, that might be why the glitch was missed when the translation was released).

Right now I'm just playing through/enjoying the game normally, in a few days I'll start trying to get the glitch to occur in earnest so I can at least attempt to trace what the heck is going on, and I'll try that code replacement BoxMulder suggested to see if that adversely affects any of the other animations.

0e4c loads something directly to register 4 (0x2000000?) and 13e0 skips that step. I've already NOP'd a section of code in the game that normally subtracts weapon experience upon promotion (Pupil -> Shaman) and haven't had problems, yet, but that's non-graphical; I'm so much less familiar with how animation data is handled that I'm worried this code will get called up for other purposes. (Changing 0x0802be68 to c0 46 prevents the game from removing weapon experience upon promotion, in case anyone wanted that information.)

Also, I was using...oh, you're Hextator! Derp.

OK, so I was using your skill patch, but unfortunately it introduced some graphical glitches. Here is an example when Neimi's attacking; did you get anything like this when you made those changes? The worst one happens during certain flashback scenes with Lyon in the latter half of the game, when the screen flashes white it looks like it was sprayed with confetti.

el42.png

Edited by EdeaCreamer
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...