Final Fantasy II Restored

[Leviathan Mist]

Sounds like Evasion% (the actual percentage) continues to store values above 99, even though it caps at 99, and then overflows when it reaches 256.

[abw]

I'll grab a few screenshots, give me a moment.

Okay, that definitely helps. The calculation itself is 16-bit, but the high byte of the result isn't taken into account when capping the low byte (which is what gets written back to character stats at ($7A),Y) at 99. Give this a try!

[redmagejoe]

I'll take a look when I can. Got my hands full fixing the Combat Counter Overflow / Firion Spirit Magic Counter patch. LeviathanMist found an oversight in my code that led to (as you'd warned me in the past), back row characters getting attacked physically. I think the issue is with that minor difference in those two looping checks to acquire a target, where the first one has a BEQ and a BNE, and the second only has a BNE. I'm testing taking the branches out of the subroutine I made (which then only has the identical instructions of the two subs), and I JUST BARELY have enough space to make that work. Hopefully this fixes it. I'll post my updated mock-up here before putting up the fixed patch.

I seem to have narrowed the problem down to having something to do with my JSRs to the combat counter overflow sub... Odd. I'll see if I can't figure out where the problem is. EDIT: I see the problem! I'm manipulating A beyond what the game is expecting, so rather than having the JSR to the counter overflow check in place of the old INC, I put it BEFORE A is loaded with $9E (character index), so that once it returns from doing its counter overflow check, A is properly loaded. After all, I don't need $9E in A going into my sub, as it ADCs $9E already. Sure enough, this fixed the issue.

Finalized / Fixed Combat Counter Overflow Fix

Code Select Expand


; control flow target (from $A525)
0x03254A|$0C:$A53A:A0 2A    LDY #$2A   
0x03254C|$0C:$A53C:B1 44    LDA ($44),Y
0x03254E|$0C:$A53E:D0 23    BNE $A563
0x032550|$0C:$A540:A6 76    LDX $76   
0x032552|$0C:$A542:BD 5A 7B LDA $7B5A,X
0x032555|$0C:$A545:F0 03 BEQ $A54A
0x032557|$0C:$A547:20 20 A7 JSR $A720

; control flow target (from $A545, $A54F, $A558)
0x03255A|$0C:$A54A:20 88 A5 JSR $A588
0x03255D|$0C:$A54D:F0 02 BEQ $A551
0x03255F|$0C:$A54F:D0 F9    BNE $A54A

; control flow target (from $A54D)
0x032561|$0C:$A551:A0 35    LDY #$35
0x032563|$0C:$A553:B1 7E    LDA ($7E),Y
0x032565|$0C:$A555:4A      LSR
0x032566|$0C:$A556:90 02    BCC $A55A
0x032568|$0C:$A558:B0 F0    BCS $A54A

; control flow target (from $A556)
0x03256D|$0C:$A55A:20 52 F8 JSR $F852
0x03256A|$0C:$A55D:A5 9E    LDA $9E
0x03256C|$0C:$A55F:AA      TAX
0x032570|$0C:$A560:4C 10 A6 JMP $A610

; control flow target (from $A53E)
0x032573|$0C:$A563:A0 2B    LDY #$2B   
0x032575|$0C:$A565:B1 44    LDA ($44),Y
0x032577|$0C:$A567:C9 01    CMP #$01   
0x032579|$0C:$A569:D0 0F    BNE $A57A
;; New Increment Loop only used after LDA #$08
0x03257B|$0C:$A56B:A2 48    LDX #$48
0x03257D|$0C:$A56D:20 64 F8 JSR $F864
0x032580|$0C:$A570:E8    INX
0x032581|$0C:$A571:E0 4C    CPX #$4C
0x032583|$0C:$A573:D0 F8    BNE $A56F
0x032585|$0C:$A575:A9 08    LDA #$08
0x032587|$0C:$A577:4C 10 A6 JMP $A610

; control flow target (from $A569)
0x03258A|$0C:$A57A:C9 02    CMP #$02   
0x03258C|$0C:$A57C:D0 1C    BNE $A59A

; control flow target (from $A57D)
0x03258E|$0C:$A57E:20 88 A5 JSR $A588
0x032591|$0C:$A581:D0 FB    BNE $A57E
0x032593|$0C:$A583:A5 9E    LDA $9E
0x032595|$0C:$A585:4C 0C A6 JMP $A60C

; control flow target (from $A54A, $A57A, $A595)
0x032598|$0C:$A588:A2 00    LDX #$00   
0x03259A|$0C:$A58A:A9 03    LDA #$03   
0x03259C|$0C:$A58C:20 11 FD JSR $FD11
0x03259F|$0C:$A58F:85 9E    STA $9E   
0x0325A1|$0C:$A591:20 E1 96 JSR $96E1
0x0325A4|$0C:$A594:20 6C AF JSR $AF6C
0x0325A7|$0C:$A597:29 C0    AND #$C0
0x0325A9|$0C:$A599:60    RTS

0x031478|$0C:$9468:20 4E F8 JSR $F84E ; Character #1 physical attack counter
0x031E68|$0C:$9E58:20 48 F8 JSR $F848 ; Character #1 spell slot #1 battle use counter
0x031E75|$0C:$9E65:20 5A F8 JSR $F85A ; Character #1 black magic use counter
0x031E7A|$0C:$9E6A:20 5E F8 JSR $F85E ; Character #1 white magic use counter
0x03256A|$0C:$A55A:20 52 F8 JSR $F852 ; Character #1 counter for times physically attacked by enemy
0x03257D|$0C:$A56D:20 64 F8 JSR $F864   ; Character #1 counter for times magically attacked by enemy (full party)
0x03261D|$0C:$A60D:20 56 F8 JSR $F856 ; Character #1 counter for times magically attacked by enemy

0x03F858|$0C:$F848:8A        TXA            ; JSR here from $9E58
0x03F859|$0C:$F849:18        CLC
0x03F85A|$0C:$F84A:69 04     ADC #$04
0x03F85C|$0C:$F84C:D0 15     BNE $F863      ; finish necessary math and jump down to rest of subroutine
0x03F85E|$0C:$F84E:A9 00     LDA #$00       ; JSR here from $9468
0x03F860|$0C:$F850:F0 0E     BEQ $F860
0x03F862|$0C:$F852:A9 44     LDA #$44       ; JSR here from $A55A
0x03F864|$0C:$F854:D0 0A     BNE $F860
0x03F866|$0C:$F856:A9 48     LDA #$48       ; JSR here from $A60D
0x03F868|$0C:$F858:D0 06     BNE $F860
0x03F86A|$0C:$F85A:A9 4C     LDA #$4C       ; JSR here from $9E65
0x03F86C|$0C:$F85C:D0 02     BNE $F860
0x03F86E|$0C:$F85E:A9 50     LDA #$50       ; JSR here from $9E6A
0x03F870|$0C:$F860:18        CLC           
0x03F871|$0C:$F861:65 9E     ADC $9E        ; adds character ID offset with the offset loaded into A before the JSR
0x03F873|$0C:$F863:AA        TAX           
0x03F874|$0C:$F864:BD F3 7C  LDA $7CF3,X    ; JSR here from $A56D, load value from counter address now modified by counter offset and player id
0x03F877|$0C:$F867:C9 C8     CMP #$C8       ; compare to overflow protection (200)
0x03F879|$0C:$F869:B0 03     BCS $F873      ; skip increasing
0x03F87B|$0C:$F86B:FE F3 7C  INC $7CF3,X    ; increase value
0x03F87E|$0C:$F86E:60        RTS




Back to the newest items, I'll take a look at the evasion fix more closely since that seems easier to digest than the special weapons effect fix and how we can address the battle pose situation. Having said that, I am in awe of how quickly you were able to take a simple musing and turn it into a working reality abw. Nice work on the patch!

[abw]

Code Select Expand


0x03257B|$0C:$A56B:A9 08    LDA #$08
;; New Increment Loop only used after LDA #$08
0x03257D|$0C:$A56D:A2 48    LDX #$48
0x03257F|$0C:$A56F:20 74 F8 JSR $F874
0x032582|$0C:$A572:E8    INX
0x032583|$0C:$A573:E0 4C    CPX #$4C
0x032585|$0C:$A575:D0 F8    BNE $A56F
0x032587|$0C:$A577:4C 10 A6 JMP $A610
[...]
0x03261D|$0C:$A60D:20 74 F8 JSR $F874 ; Character #1 counter for times magically attacked by enemy


I think you meant JSR $F864 in both places instead. It's really past time to start using an assembler . Also, you need to do the LDA #$08 after the loop, otherwise everybody gets credit for a target-all spell but the spell actually hits an entity determined by character #4's counter, which will probably crash the game once character #4's counter gets past 8, and will probably have bizarre effects even before that.

If you still need more space, you can save at least 6 more bytes by moving the BNEs after each JSR $A588 call into the $A588 routine (it's just looping until it finds a non-dead, non-stone target) and by eliminating some useless branches:

Code Select Expand


0x03255D|$0C:$A54D:F0 02 BEQ $A551
0x032566|$0C:$A556:90 02    BCC $A55A


Back to the newest items, I'll take a look at the evasion fix more closely since that seems easier to digest than the special weapons effect fix and how we can address the battle pose situation. Having said that, I am in awe of how quickly you were able to take a simple musing and turn it into a working reality abw. Nice work on the patch!

It would have been faster if I hadn't also been watching TV at the time . Thanks for taking a look - it's always nice to get a second set of eyes on these changes, especially in cases where I've been coding while distracted!

[redmagejoe]

Updated my documentation. I'd actually failed to update the documentation above (now corrected) but applied the actual behavior that is listed there. No, I wanted F864 (you're right there) for only the target all situation, and the F856 for a single-target spell. Sorry about the sloppiness. Everything should reflect what the IPS is doing now. I didn't catch the LDA 08 issue, so thank you for noticing that.

[abw]

One more thing:

Code Select Expand


0x031E75|$0C:$9E65:20 5A F8 JSR $F85A ; Character #1 black magic use counter
0x031E78|$0C:$9E68:D0 03    BNE $9E6D 
; control flow target (from $9E63)
0x031E7A|$0C:$9E6A:20 5E F8 JSR $F85E ; Character #1 white magic use counter

This results in credit for both black and white magic use when $F85A exits with Z set, which happens when $7CF3,X is exactly #$C8; the original code has the same problem when $7CF3,X wraps around to 0. Not a huge issue in practical terms, but something to consider. Conversely,

Code Select Expand


0x03261D|$0C:$A60D:20 74 F8 JSR $F856 ; Character #1 counter for times magically attacked by enemy
; control flow target (from $A537, $A56E, $A5A2, $A5AB, $A5CA, $A609)
0x032620|$0C:$A610:A0 2B    LDY #$2B   
0x032622|$0C:$A612:91 44    STA ($44),Y

ends up using the old value of the counter as the command's target, which is a bigger problem. One possible fix is something like this:

Code Select Expand


; $0C:$F856; JSR here from $A60D
PHA
LDA #$48
JSR $F860
PLA
RTS


[redmagejoe]

Since that's an issue with the original code, I'm not too worried, especially for how unlikely it is to even reach that cap. But just to be thorough, what would be the best way to address this? I'm assuming the idea of the original BNE is to always be taken so that white and black magic counters aren't both incrementing. Is there a better way to achieve an "always branch" situation here?

As for the returning A issue, what if I were to simply put LDA $9E before the RTS, such that no matter what, $9E is properly loaded back into the Accumulator once it returns from that subroutine? I have the room to do that since it's in our free space. Going into any of these counters, it's assumed that A currently holds $9E, correct? That way I could also remove the LDA $9E and TAX from the increment loop I wrote for magic-on-whole-party situation.

Hmm, no watching RAM, that doesn't quite work. I guess it should involve PHA and PLA. Let me play with that and test it while watching RAM.

[abw]

Is there a better way to achieve an "always branch" situation here?

If this were 65816 on the SNES, BRA would be the way to go, but for 6502, JMP is the shortest alternative, which doesn't fit into the 2 bytes available. The first thing that comes to mind is expanding the capping routine:

Code Select Expand


; $0C:$F85A; JSR here from $9E65
LDA #$4C
JSR $F860
LDA #$01
RTS


Going into any of these counters, it's assumed that A currently holds $9E, correct?

Not necessarily, no. A is set to different things at different calls. Most of the time the value of A after the call to the capping routine doesn't matter, but in a couple of places it does.

[redmagejoe]

I will expand my capping code then. Would you review and confirm or refute my assumptions about these branches, as outlined below kind sir?

0x031478|$0C:$9468:20 4E F8 --- is fine as it is, A is set before it's needed again
0x031E68|$0C:$9E58:20 48 F8 --- is fine as it is, A is set before it's needed again
0x031E75|$0C:$9E65:20 5A F8 --- is fine as it is, A is set before it's needed again
0x031E7A|$0C:$9E6A:20 5E F8 --- is fine as it is, A is set before it's needed again
0x03256A|$0C:$A55A:20 52 F8 --- is fine, as the LDA $9E needed for original code is shifted (the TAX isn't needed though, right?)
0x03257D|$0C:$A56D:20 64 F8 --- is being set to #$08 now, which I ASSUME is what A needs to be heading back into original code
0x03261D|$0C:$A60D:20 56 F8 --- is the only one having A modified by us before it is needed by original code, so PHA and PLA in that single branch should suffice

Assuming that my assumptions about the other two "not an issue" branches are true, how does this look?

Code Select Expand


; control flow target (from $A525)
0x03254A|$0C:$A53A:A0 2A    LDY #$2A   
0x03254C|$0C:$A53C:B1 44    LDA ($44),Y
0x03254E|$0C:$A53E:D0 23    BNE $A563
0x032550|$0C:$A540:A6 76    LDX $76   
0x032552|$0C:$A542:BD 5A 7B LDA $7B5A,X
0x032555|$0C:$A545:F0 03 BEQ $A54A
0x032557|$0C:$A547:20 20 A7 JSR $A720

; control flow target (from $A545, $A54F, $A558)
0x03255A|$0C:$A54A:20 88 A5 JSR $A588
0x03255D|$0C:$A54D:F0 02 BEQ $A551
0x03255F|$0C:$A54F:D0 F9    BNE $A54A

; control flow target (from $A54D)
0x032561|$0C:$A551:A0 35    LDY #$35
0x032563|$0C:$A553:B1 7E    LDA ($7E),Y
0x032565|$0C:$A555:4A      LSR
0x032566|$0C:$A556:90 02    BCC $A55A
0x032568|$0C:$A558:B0 F0    BCS $A54A

; control flow target (from $A556)
0x03256A|$0C:$A55A:20 52 F8 JSR $F852
0x03256D|$0C:$A55D:A5 9E    LDA $9E
0x03256F|$0C:$A55F:AA      TAX
0x032570|$0C:$A560:4C 10 A6 JMP $A610

; control flow target (from $A53E)
0x032573|$0C:$A563:A0 2B    LDY #$2B   
0x032575|$0C:$A565:B1 44    LDA ($44),Y
0x032577|$0C:$A567:C9 01    CMP #$01   
0x032579|$0C:$A569:D0 0F    BNE $A57A
;; New Increment Loop only used after LDA #$08
0x03257B|$0C:$A56B:A2 48    LDX #$48
0x03257D|$0C:$A56D:20 6C F8 JSR $F86C
0x032580|$0C:$A570:E8    INX
0x032581|$0C:$A571:E0 4C    CPX #$4C
0x032583|$0C:$A573:D0 F8    BNE $A56F
0x032585|$0C:$A575:A9 08    LDA #$08
0x032587|$0C:$A577:4C 10 A6 JMP $A610

; control flow target (from $A569)
0x03258A|$0C:$A57A:C9 02    CMP #$02   
0x03258C|$0C:$A57C:D0 1C    BNE $A59A

; control flow target (from $A581)
0x03258E|$0C:$A57E:20 88 A5 JSR $A588
0x032591|$0C:$A581:D0 FB    BNE $A57E
0x032593|$0C:$A583:A5 9E    LDA $9E
0x032595|$0C:$A585:4C 0C A6 JMP $A60C

; control flow target (from $A54A, $A57A, $A595)
0x032598|$0C:$A588:A2 00    LDX #$00   
0x03259A|$0C:$A58A:A9 03    LDA #$03   
0x03259C|$0C:$A58C:20 11 FD JSR $FD11
0x03259F|$0C:$A58F:85 9E    STA $9E   
0x0325A1|$0C:$A591:20 E1 96 JSR $96E1
0x0325A4|$0C:$A594:20 6C AF JSR $AF6C
0x0325A7|$0C:$A597:29 C0    AND #$C0
0x0325A9|$0C:$A599:60    RTS

0x031478|$0C:$9468:20 4E F8 JSR $F84E ; Character #1 physical attack counter
0x031E68|$0C:$9E58:20 48 F8 JSR $F848 ; Character #1 spell slot #1 battle use counter
0x031E75|$0C:$9E65:20 5E F8 JSR $F85E ; Character #1 black magic use counter
0x031E7A|$0C:$9E6A:20 66 F8 JSR $F866 ; Character #1 white magic use counter
0x03256A|$0C:$A55A:20 52 F8     JSR $F852 ; Character #1 counter for times physically attacked by enemy
0x03257D|$0C:$A56D:20 6C F8     JSR $F86C   ; Character #1 counter for times magically attacked by enemy (full party)
0x03261D|$0C:$A60D:20 56 F8 JSR $F856 ; Character #1 counter for times magically attacked by enemy

0x03F858|$0C:$F848:8A           TXA             ; JSR here from $9E58
0x03F859|$0C:$F849:18           CLC
0x03F85A|$0C:$F84A:69 04        ADC #$04
0x03F85C|$0C:$F84C:D0 1D        BNE $F86B       ; finish necessary math and jump down to rest of subroutine
0x03F85E|$0C:$F84E:A9 00        LDA #$00        ; JSR here from $9468
0x03F860|$0C:$F850:F0 16        BEQ $F868
0x03F862|$0C:$F852:A9 44        LDA #$44        ; JSR here from $A55A
0x03F864|$0C:$F854:D0 12        BNE $F868
0x03F866|$0C:$F856:48 PHA
0x03F867|$0C:$F857:A9 48        LDA #$48        ; JSR here from $A60D
0x03F869|$0C:$F859:20 68 F8     JSR $F868
0x03F86C|$0C:$F85C:68 PLA
0x03F86D|$0C:$F85D:60 RTS
0x03F86E|$0C:$F85E:A9 4C        LDA #$4C       ; JSR here from $9E65
0x03F870|$0C:$F860:20 68 F8     JSR $F868
0x03F873|$0C:$F863:A9 01 LDA #$01
0x03F875|$0C:$F865:60 RTS
0x03F876|$0C:$F866:A9 50        LDA #$50       ; JSR here from $9E6A
0x03F878|$0C:$F868:18           CLC
0x03F879|$0C:$F869:65 9E        ADC $9E        ; adds character ID offset with the offset loaded into A before the JSR
0x03F87B|$0C:$F86B:AA           TAX
0x03F87C|$0C:$F86C:BD F3 7C     LDA $7CF3,X    ; JSR here from $A56D, load value from counter address now modified by counter offset and player id
0x03F87F|$0C:$F86F:C9 C8        CMP #$C8       ; compare to overflow protection (200)
0x03F881|$0C:$F871:B0 03        BCS $F876      ; skip increasing
0x03F883|$0C:$F873:FE F3 7C     INC $7CF3,X    ; increase value
0x03F886|$0C:$F876:60           RTS


[abw]

Let's see here... for $A55A, you do need at least the LDA $9E, since that's the target to use after $A610. I don't see X being used for a while afterwards, so I'm not sure whether that TAX is still needed or not. $A56D definitely needs to set A to #$08 before $A610 in order for target-all spells to work. In this revised code, I think there's only one path that goes through $A60D now, and it already has A set correctly, so I guess we don't actually need the PHA/PLA and I was just getting mixed up with the original code .

[redmagejoe]

Alright, so I can crunch the code back a little, though I'm still going to have that one JSR to avoid the black+white magic counter situation. This should be good to go, yeah? I'm leaving that TAX alone because it's one byte and not worth the energy crunching until we get to a point where we're done with bug-fixes and just need to do some major code crunch for more major enhancements.

I'll have a closer look at the new patches you dropped tomorrow. Got a lot on my plate in the morning. Just to be clear, your special effects patch currently makes Ripper actually do its +20 per hit damage, and has what effect upon Blood Sword (Drain # of hits / 16 target's max HP) and undead hit by Heal Staff (meant to do 0 damage and Cure 1 * level = number of hits to non-undead, but 78 base attack modified by family bonus against undead, and then an ADDITIONAL bonus damage on top of that, but NOT HEAL THEM like it currently does)?

[abw]

In this revised code, I think there's only one path that goes through $A60D now, and it already has A set correctly, so I guess we don't actually need the PHA/PLA and I was just getting mixed up with the original code .

Actually, I take that back - I was right the first time and we do need the PHA/PLA on the call from $A60D. A is set correctly as input for $F856, but $F856's output in A is incorrect for setting the spell's target at $A612. Sorry about the confusion .

Just to be clear, your special effects patch currently makes Ripper actually do its +20 per hit damage, and has what effect upon Blood Sword (Drain # of hits / 16 target's max HP) and undead hit by Heal Staff (meant to do 0 damage and Cure 1 * level = number of hits to non-undead, but 78 base attack modified by family bonus against undead, and then an ADDITIONAL bonus damage on top of that, but NOT HEAL THEM like it currently does)?

Let me do another pass on this one first - I just noticed I accidentally omitted the section of code for killing the attacker when Blood Sword vs. Undead drains the attacker dry, and I want to check whether the game displays any message in that case.

Mechanically, the intent is to make Ripper and Heal Staff (vs. Undead only) actually inflict the damage their battle messages display (Heal Staff doesn't actually heal Undead; only the base damage is inflicted, and like Ripper, the bonus damage is only displayed, not inflicted). As a consequence of moving the special effect code up, Heal Staff against non-Undead now sets its base damage to 0 and directly heals the target instead of inflicting the weapon's base damage and then negating it and adding the heal effect, which means Heal Staff will no longer be extra effective against targets that were killed by its base damage.

GUI fixes should include displaying the usual death message when a target gets killed by the bonus damage from a special effect (currently messages are only displayed if the target is killed by the base damage) and updating their critical HP/battle pose (still WIP), and now that I've noticed it, I'm also going to investigate death messages for when an attacker commits suicide via trying to drain Undead.

[Rabite890]

Is this all compatible with ChaosRush's translation? I figure it probably is, but when I did the patches I ended up with a weird issue.

When I'd get attacked, the enemy would sometimes have hit sparks on them. I think it might be evasion related since I'd take no damage, but I have no idea. I'm not sure if this is an already known issue or not, so I wanted to report it. I'm using an Everdrive N8 in an AVS not an emu. When I tried a translated only (no patches from this topic) ROM, I had no issues with it.

Also, are you going to have an optional patch to get rid of the penalties to INT that most equipment has? It makes sense for it to be there, but it really ruins magic.

[redmagejoe]

Is this all compatible with ChaosRush's translation? I figure it probably is, but when I did the patches I ended up with a weird issue.

When I'd get attacked, the enemy would sometimes have hit sparks on them. I think it might be evasion related since I'd take no damage, but I have no idea. I'm not sure if this is an already known issue or not, so I wanted to report it. I'm using an Everdrive N8 in an AVS not an emu. When I tried a translated only (no patches from this topic) ROM, I had no issues with it.

That issue is most likely due to the reversal on a change I'd made that abw just pointed out. I need to go back and fix that... It's on the Combat Counter Overflow Fix. Please bear with me while I revert the change. As for the Chaos Rush translation, it should be applied after all other patches listed here.

EDIT: Thankfully Google Drive keeps past versions. Just deleted the newest version, as the previous version should be the working one. Please apply the patches in this thread, including the fixed Combat Counter Overflow Fix, to a fresh (J) [!] ROM, then Chaos Rush's latest available translation. If you are still having bugs with enemy attacks on the party, please report them here. Also bear in mind that Dispel and Barrier will report the wrong (see: in reverse) resistances compared to what resists they actually affect. This is a bug native to the game, Japanese version and all translations. I have a version of Chaos Rush's translation with the messages properly reversed/fixed, but would like to make some other changes before I release it onto the site.

Also, are you going to have an optional patch to get rid of the penalties to INT that most equipment has? It makes sense for it to be there, but it really ruins magic.

I will add this to the first post, and consider it as an optional patch since we're already looking at improvements to bring things in line with the remakes. It would indeed be optional and not part of the main patch.



@abw

So as of now, Ripper works properly, as it deals its shown damage of +20 per hit. Heal Staff works properly on non-undead targets, as it does no damage and heals them.

Are you saying that Heal Staff was NOT actually healing undead before, or that you've FIXED it to not heal them? Also, is it doing its family damage and bonus damage to Undead either pre- or post- fix? I'm curious about what the code is currently doing versus what it's doing in your ASM, as I'm trying to better navigate around the instructions and commit certain batches of instructions to memory, as to what they're doing. I can already recognize certain things the game is doing just based on the instructions. As for the Blood Sword, I'll leave you to that and the other WIPs while I mentally unpack the Evasion Overflow fix. Work is being very distracting, so apologies if it's slow progress. After that Combat Counter Overflow Fix, I've become super overly cautious about commits to stable.

[Rabite890]

"That issue is most likely due to the reversal on a change I'd made that abw just pointed out. I need to go back and fix that... It's on the Combat Counter Overflow Fix. Please bear with me while I revert the change. As for the Chaos Rush translation, it should be applied after all other patches listed here.

EDIT: Thankfully Google Drive keeps past versions. Just deleted the newest version, as the previous version should be the working one. Please apply the patches in this thread, including the fixed Combat Counter Overflow Fix, to a fresh (J) [!] ROM, then Chaos Rush's latest available translation. If you are still having bugs with enemy attacks on the party, please report them here. Also bear in mind that Dispel and Barrier will report the wrong (see: in reverse) resistances compared to what resists they actually affect. This is a bug native to the game, Japanese version and all translations. I have a version of Chaos Rush's translation with the messages properly reversed/fixed, but would like to make some other changes before I release it onto the site.

I will add this to the first post, and consider it as an optional patch since we're already looking at improvements to bring things in line with the remakes. It would indeed be optional and not part of the main patch."



That's what I figured. It looked like some sort of overflow. Also, good to know on the correct order for the translation. I'll make sure to redownload it. Thanks.

I agree fully on the "fix" being an optional patch. There's going to some purists out there who don't want that feature and shouldn't have to play with it.

I'm just glad someone is taking the time to fix the issues, unlike Demonic Pandemonium which was a good attempt but didn't fix the big issues. Thank you for your work.

[redmagejoe]

Thank you for your interest in the project! And I, for one, am okay with the intention behind INT/SPR penalties. Given that they were removed in remakes, however, and it's a controversial change, I don't see why we can't work on an optional patch so people can choose whether they want to play "the original", an NES version of the remake, or an "enhanced original", since we've got a Mysidian Tower Orbs buff and consideration for a weapon-switching experience tracking feature, among other things.

My hope is for this to serve as another definitive version similar to Final Fantasy Restored for the first game, even if neither one has Dawn of Souls content.



Watching LeviathanMist's playtest stream, it seems the RNG may still be taking too long, abw. He gained... I'm not sure how many stats, but it seems like whenever a character's stats went up he would get that same graphics glitch. Is the new RNG still taking too many cycles compared to the old one? I'm assuming that's what the issue is? Supposedly the bug was happening before every character's stat ups, but when Leviathan and I were watching specifically for it, I must have blinked as I only saw it happen before Minwu (Char4). EDIT: He's streaming at 30fps, but he's playing it at 60fps obviously, so I didn't see the frames he did. Assume it happens for every character. It seems to happen after or as their name box is written before the actual stat up messages.

[Leviathan Mist]

So, two things I noticed:

1. RNG seems to still favor the middle two characters for enemy targeting. Firion's HP is much lower than Maria's and Guy's.
2. Weapon exp is not going up uniformly for every character, despite the fact that I am always using the attack command with all four characters at the same time, otherwise casting with the top 3 characters and attacking with Minwu. This is not due to target-canceling either, as it's Maria with the highest weapon exp, and the only target-cancels I've done are with Firion by accident. Also, shouldn't Minwu have much higher weapon exp than the other four characters, since he's attacking while the others are casting? For reference, my weapon exp values are as follows: Firion 1-87%, Maria 1-91%, Guy 1-87%, Minru 1-88%

[redmagejoe]

I haven't done extensive testing on the RNG to figure out what the actual math will come out to for bias towards the characters, but it may simply be a case of too small sample size at this point in the game? I don't know. I do know we may have to review the RNG anyway to see if we can't address the graphics bug on stat ups.

As for the Weapon Experience, with the numbers and situations you provided, I think that's normal behavior. At least, there's no mods we've made to weapon exp that should cause that outcome and the way the formula the game uses for giving credit is such that those variations could be simply due to the slight differences in actions. Remember that at level 1 weapon skill, in Rank 1 battles, there's a bonus for the first use in that battle of an attack (of +2 I think), and then +1 for every attack after that. As your weapon level goes up, the bonus becomes a malus, and it becomes harder and harder to clear the threshold to get ANY weapon exp. I think that #2 is working as intended, as I did extensive testing on the bonus/malus before. It's understandable that you'd think that though given the weird mechanic they use and unless you were testing it very strictly, it's easy to misconstrue what the game is doing with it.

In essence, what it looks like has happened from a glance is that Minwu has attacked 1 more time than Firion and Guy, and Maria has attacked 3-4 more times than Minwu and Firion/Guy respectively. In reality though, what likely has happened is Maria attacked 1 or 2 more times across all battles where Firion and Guy cast, and Minwu attacked 1 more time, or any combination of situations. Or to frame it another way, Guy and Firion cast a single time more than Maria did, perhaps.

[Leviathan Mist]

I haven't done extensive testing on the RNG to figure out what the actual math will come out to for bias towards the characters, but it may simply be a case of too small sample size at this point in the game? I don't know. I do know we may have to review the RNG anyway to see if we can't address the graphics bug on stat ups.

As for the Weapon Experience, with the numbers and situations you provided, I think that's normal behavior. At least, there's no mods we've made to weapon exp that should cause that outcome and the way the formula the game uses for giving credit is such that those variations could be simply due to the slight differences in actions. Remember that at level 1 weapon skill, in Rank 1 battles, there's a bonus for the first use in that battle of an attack (of +2 I think), and then +1 for every attack after that. As your weapon level goes up, the bonus becomes a malus, and it becomes harder and harder to clear the threshold to get ANY weapon exp. I think that #2 is working as intended, as I did extensive testing on the bonus/malus before. It's understandable that you'd think that though given the weird mechanic they use and unless you were testing it very strictly, it's easy to misconstrue what the game is doing with it.

In essence, what it looks like has happened from a glance is that Minwu has attacked 1 more time than Firion and Guy, and Maria has attacked 3-4 more times than Minwu and Firion/Guy respectively. In reality though, what likely has happened is Maria attacked 1 or 2 more times across all battles where Firion and Guy cast, and Minwu attacked 1 more time, or any combination of situations. Or to frame it another way, Guy and Firion cast a single time more than Maria did, perhaps.

I thought the game awarded all weapon/spell exp upon selecting the action, in which case, whether or not the action was carried out in a battle would become irrelevant. Unless I am misunderstanding that portion of it. But if I'm not, then I never attacked with Maria while casting with Firion and Guy, I always chose cast with all three of them, or attacked with all three of them. If anyone should have more weapon exp, it's Firion because I target-canceled with him once or twice.

Anyway, I will continue playing and report any other oddities. I stopped streaming because I was having frame drop issues, but I am recording my grinding sessions so if anything weird happens, I can just post a video of it.

[John Enigma]

I know it's way to early to say, considering the ongoing efforts on this project, but I hope someone does a "Restored" version for Final Fantasy III (Famicom) as well, knowing that this entry from the series is more obscure than the rest, even after receiving countless of modern remakes and ports. Also, due to the fact that, before being remade, FFIII was one of the particular entries that Square lost the source code from. The game hasn't been disassembled either unlike FF I & II.