Shock Ability

Yes, try changing TRB $2F2E to TRB $3F2F and test with that alone.

If that doesn't work, change ALL instances of $3F2F to #3F2E.

Again, not an expert on this. Just trying to say what I would try to keep forward momentum.

Yes, try changing TRB $2F2E to TRB $3F2F and test with that alone.

If that doesn't work, change ALL instances of $3F2F to #3F2E.

Again, not an expert on this. Just trying to say what I would try to keep forward momentum.

Dumb question, but can I modify the .asm hack and keep applying it over the old ROM, or do I have to edit the ROM after initially applied?  In other words, can I apply the hack multiple times to make changes?  I ask, because I can't find where that code is in Windhex, so it would be easier to edit the hack directly.

Dumb question, but can I modify the .asm hack and keep applying it over the old ROM, or do I have to edit the ROM after initially applied?  In other words, can I apply the hack multiple times to make changes?  I ask, because I can't find where that code is in Windhex, so it would be easier to edit the hack directly.

ASM files do not check the original code; they just find an address and change the bytes at that address. You can just keep applying the same ASM over and over again, so long as you don't make any changes to the "org" lines.

Dumb question, but can I modify the .asm hack and keep applying it over the old ROM, or do I have to edit the ROM after initially applied?  In other words, can I apply the hack multiple times to make changes?  I ask, because I can't find where that code is in Windhex, so it would be easier to edit the hack directly.

ASM files do not check the original code; they just find an address and change the bytes at that address. You can just keep applying the same ASM over and over again, so long as you don't make any changes to the "org" lines.

Thanks, that's what I thought.  I've been messing with your suggestions for the last hour now, and I am more confused than when I started!  I first tried the original shock hack on an unmodified FF3 v1.1 ROM (but with a savestate in which the party has Shadow with the shock ability). My initial testing seemed promising:  the shock menu graphics were messed up with the original shock hack, but fixed with your tweaks.  I then attempted it on my own modified ROM, but it did NOT fix things.  HOWEVER, I then went back to perform more testing on an unmodified V1.1 ROM, and I could NOT replicate the bug again after like 15 attempts, even with the original shock hack!  In fact, shock worked as it was supposed to, even with the battle against Airforce!  I don't have a clue what is going on, or how to consistently replicate this bug...

So, with RAM settings, there are RAM settings that remain constant, and RAM settings that get re-written and cleared at regular intervals. There are 2 reasons that GrayShadows chose $3F2F for this code:
1. It gets cleared at the end of every battle. The exception for this is the Final Battle, which has special code to clear the byte between tiers. When I looked at "what is different about the air force brigade", it struck me that it's one of only 4 battles in the game I could think of where the battle doesn't end when enemies are defeated. I am making a HUGE assumption here, which is that it MIGHT be calling the line of code that clears bytes between Final Battle tiers. In looking through the ASM, that's the only only section of code that looked like it might have an error in it.

2. Only half the byte is used. Here's a quick crash course:

Each byte contains a number 00-FF (hexadecimal value. 0-9 is the same, A=10, B=11 ... F =15). For many places in FF6 though, they use a shorthand on a byte that treats it as a flag instead of as a number. This allows them to track up to 8 different binary settings on the same byte. The following values are mapped:
1 = 01 5 = 10
2 = 02 6 = 20
3 = 04 7 = 40
4 = 08 8 = 80
By doing it this way, every combination of 8 has a unique value. if 1, 2, and 6 are set to yes, then the byte reads "23".

The Desperation Attack byte is mapped like this:
Party Characters that have used a desperation attack: (values 1-4)
Character 1 = 01
Character 2 = 02
Character 3 = 04
Character 4 = 08

GrayShadows added this
Party Characters that have used Shock: (values 5-8)
Character 1 = 10
Character 2 = 20
Character 3 = 40
Character 4 = 80

Anyway, here's what I think might be happening. In the final battle, characters are allowed to use a Desperation Attack once per tier, because there is code that comes and zeroes out the first digit of the byte (TRB $3F2F). GrayShadow's code tells it to also zero out the second digit, allowing Shock to also be used again. However, I believe he made 2 typos.
1. In an early version of his code, he used $3F2E (the summon byte) instead of $3F2F (the desperation attack byte). I think he forgot to change this 2E to a 2F when he made that changeover.
2. He mistyped the first number, writing $2F2E instead of $3F2E.

$2F2E, unfortunately, is one of those static RAM options that doesn't get changed or re-written. It probably doesn't even follow the 8-value format. So zeroing out the 2nd digit on this value is what we would call "corruption". Either way, this RAM byte is only read during the battle initialization, so you wouldn't know there was a problem until you hit a tiered battle, finished it, and then loaded the next one. Also key to this is that fixing the ROM's code and then loading up a savestate or a save file won't change anything. The problem is that the RAM byte is corrupted. You need to load a save file from BEFORE the byte got corrupted, play through the Air Force battle again, and then see if you have the trouble.

As for why this can't be reproduced, keep in mind that this code tracks Shock usage by the character's party placement. If Shadow/Leo was character 1, and your next test had him as character 2, you might get different results.

I'm happy to help break down what I think the issue might be, but understand that with custom code requests, it is ultimately up to YOU to do the testing. GrayShadows is a great guy, but he didn't need to code this in the first place. He's certainly not using it in his own hack, and I am not using it in mine. If it's not working after this, read back through this thread and see if what you've learned sparks any other ideas of where things might be going wrong.

So, with RAM settings, there are RAM settings that remain constant, and RAM settings that get re-written and cleared at regular intervals. There are 2 reasons that GrayShadows chose $3F2F for this code:
1. It gets cleared at the end of every battle. The exception for this is the Final Battle, which has special code to clear the byte between tiers. When I looked at "what is different about the air force brigade", it struck me that it's one of only 4 battles in the game I could think of where the battle doesn't end when enemies are defeated. I am making a HUGE assumption here, which is that it MIGHT be calling the line of code that clears bytes between Final Battle tiers. In looking through the ASM, that's the only only section of code that looked like it might have an error in it.

2. Only half the byte is used. Here's a quick crash course:

Each byte contains a number 00-FF (hexadecimal value. 0-9 is the same, A=10, B=11 ... F =15). For many places in FF6 though, they use a shorthand on a byte that treats it as a flag instead of as a number. This allows them to track up to 8 different binary settings on the same byte. The following values are mapped:
1 = 01         5 = 10
2 = 02         6 = 20
3 = 04         7 = 40
4 = 08         8 = 80
By doing it this way, every combination of 8 has a unique value. if 1, 2, and 6 are set to yes, then the byte reads "23".

The Desperation Attack byte is mapped like this:
Party Characters that have used a desperation attack: (values 1-4)
Character 1 = 01
Character 2 = 02
Character 3 = 04
Character 4 = 08

GrayShadows added this
Party Characters that have used Shock: (values 5-8)
Character 1 = 10
Character 2 = 20
Character 3 = 40
Character 4 = 80

Anyway, here's what I think might be happening. In the final battle, characters are allowed to use a Desperation Attack once per tier, because there is code that comes and zeroes out the first digit of the byte (TRB $3F2F). GrayShadow's code tells it to also zero out the second digit, allowing Shock to also be used again. However, I believe he made 2 typos.
1. In an early version of his code, he used $3F2E (the summon byte) instead of $3F2F (the desperation attack byte). I think he forgot to change this 2E to a 2F when he made that changeover.
2. He mistyped the first number, writing $2F2E instead of $3F2E.

$2F2E, unfortunately, is one of those static RAM options that doesn't get changed or re-written. It probably doesn't even follow the 8-value format. So zeroing out the 2nd digit on this value is what we would call "corruption". Either way, this RAM byte is only read during the battle initialization, so you wouldn't know there was a problem until you hit a tiered battle, finished it, and then loaded the next one. Also key to this is that fixing the ROM's code and then loading up a savestate or a save file won't change anything. The problem is that the RAM byte is corrupted. You need to load a save file from BEFORE the byte got corrupted, play through the Air Force battle again, and then see if you have the trouble.

As for why this can't be reproduced, keep in mind that this code tracks Shock usage by the character's party placement. If Shadow/Leo was character 1, and your next test had him as character 2, you might get different results.

I'm happy to help break down what I think the issue might be, but understand that with custom code requests, it is ultimately up to YOU to do the testing. GrayShadows is a great guy, but he didn't need to code this in the first place. He's certainly not using it in his own hack, and I am not using it in mine. If it's not working after this, read back through this thread and see if what you've learned sparks any other ideas of where things might be going wrong.

Thanks Panda.  Everything you said makes absolute sense!  I thought there might be some variable in there (especially with the party order) that was preventing me from getting consistent test results.  It just so happens that I kept a save before the Airforce battle just in case it came to this on my playthrough on real hardware.  I just hope the corruption did not occur BEFORE the Airforce battle, or else I am screwed and would have lost weeks of testing (unless the .SRM save file can be hacked). Just let me know what code has to be changed on the asm hack, and I can do all the testing from there to see if it is fixed.  One thing I AM good at is testing!  You are looking at the bug-finding master.  Hah.

RAM can certainly be hacked. You might also just be able to go into the config screen, change all of the display options, save, and then change them back. Depending on how the RAM bytes work, that might be enough to force a new value.

But again, this is all IF my hunch on what is happening is in any way correct.

Panda, you hit the nail in the head with your suggestion of the party order! I did some more testing just now, and discovered WHY exactly there are different results! The ENTIRE bug seems to be related to Leo's party position. I don't think there is any link whatsoever to the Airforce battle or multi-Tier battles. The reason I was fooled before was because before you fight the battle with Airforce, the game AUTOMATICALLY switches Leo to party position #2 (I usually keep him in position #1 to see him walking around). Here is Exactly what happens to the game depending on Leo's order:

If Leo is in position #1 (the very top): Everything works as it should: Shock is disabled after one use, EVEN in multi-tiered battles. I can't find any bugs with this party order yet.
If Leo is in position #2 (second from top): The Shock code doesn't seem to work at all, and Leo can use Shock an unlimited number of times.
If Leo is in position #3 (3rd from the top): The shock code does not work, AND there are graphical errors with the text box when he uses shock
If Leo is in position #4: Seems to be the same as position #2

These results are consistent every single time, as far as I can tell. I was only getting different results when I just so happened to change the position of Leo, and I simply wasn't connecting the dots. I was only getting the graphical bugs, for example, when I just happened to switch Leo to party position #3. The bad news: I don't have a clue what is causing this bug, but maybe this gives you a huge hint? I tried modifying the code a bit with some of your suggestions earlier, but so far the errors remain...

Edit: This is probably why this hack did not work with Gogo. I most likely had Leo in party position #1 (which works), and Gogo in some other party position. I'll bet if you place Gogo in position #1, this hack would work just fine for him. I am also sure the original hack with MP would work if this bug was fixed, although I think I prefer the once per battle solution.

Only $1600-$1FFF is saved in SRAM. The rest of RAM is lost when you reset (more or less) or power off.

I have not look closely at that hack, but here is how the game use those bytes, as far as the battle module is concerned:

Code:

$2F2E Command Setting (0 = window, 1 = short)
$2F2F --654321 Monsters that are present (graphics buffer)
$3F2E ----1234 Characters that have an esper equipped
$3F2F ----1234 Characters that have used a desperation attack this battle

I don't think this bug has anything to do with anything stored in the RAM now.  The entire thing is based on Leo's party position (see my previous post).  Could this be because the game tracks desperation moves based on party position?  I am only speculating here.