Final Fantasy II Restored

[Jiggers]

EDIT: Actually, on further research, it seems that when entering Fynn Castle, it ALWAYS spits you out on the right tile, even though it has 2 tiles you can enter through. So maybe there are specific coordinates in data rather than stored in RAM.

Yep, Coneria castle in FF1 does the exact same thing. Both games share some similar code, so it makes sense. The teleports are for exiting by stepping on a teleport tile though. For places that only have 1 level, like towns, they use a warp tile that pulls your last overworld position.

Testing WARP and EXIT in Coneria Castle, I do get popped out on the left side after entering on the left. So fixing teleport data won't work after all. Nudging your last recorded overworld position down by 1 upon entering this specific map might work?

[redmagejoe]

Curious bug I've run into on the Restored version, at least. I don't know at what point this became an issue since my Guy has 39 M.Power, but I've been getting a number of M.Power gains, yet the window still says I've only got 39 M.Power. So I feel as though I've lost out on at least 5 or so increases that I've been aware of. The message is appearing at the end of battle, but I am most certainly not getting the actual stat on Guy. I'm going to do some testing on Firion and Maria, who have 31 and 28 respectively, and see if it's an upper limit bug.

EDIT: Nope, just got a gain on Firion, who is still at 31. I have no idea why I'm suddenly not gaining M.Power level ups. Did something change in the last version of the Restored update (5/17)? I'll try the same file with the Bug Fix patch.

Looking at it in debugger and RAM Watch, it does appear that base M.Power is being increased. However, effective M.Power isn't being updated and is still what's being displayed in the window, which of course means that MP gains are nerfed. I'm not sure if this is due to the code crunch involving using a refresh to replace the individual effective stat increases. Does M.Power not get recalculated by stat refreshes, perhaps, and so that's being skipped? Does M.Power still have to have a separate increment instruction, maybe? At the very least, the base value is still correct internally, but the current version of the patch freezes effective M.Power and MP gains where they are.

[abw]

Sounds like it would be simpler to move the exit teleport coordinates one tile down! If that's possible. But I also have no idea what the Tower of Magi is or how you enter it with an animation...

Yup, depending on what the game actually does, that could definitely be a better solution! I haven't done much of anything relating to maps in this game yet, so at this point I can't say much of anything about their implementation for certain.

As for Holy Lance, is it inherently different from Rune Axe (Fog), Masamune (Haste), or other items of that nature?

All usable weapons have an index into the spell data table as one of their data bytes, so in that sense they're all the same. The difference with the Holy Lance is that its index is shared with the index for Holy tomes, which have a 100% break chance. Theoretically appending a new row of spell data and updating the Holy Lance's index to use it should be enough to take care of that problem, but after giving it a quick try just now, I get crashes at the end of a battle, so probably I'm still missing a label somewhere in bank C or something.

On that note, I'm curious: Do spells cast off of items affect the combat counters? I'm assuming not, and that they don't count as using White or Black Magic.

No, only actual magic should affect the combat counters.

Toad... [...]

I'm leaning towards removing the automatic Game Over for a full Toad party and removing the automatic 0 spell successes for Toad/Mini so that items (including Maiden's Kiss/Mallet) will work normally.

Curious bug I've run into on the Restored version, at least.

Hmm, yes, it turns out that the original code for copying base stats to effective stats has an off-by-one error and stops just before reaching Magic Power instead of afterwards. Thanks for catching that! I've pushed updated patches for both Bug Fix and Restored; these also include fixes for:

• If an enemy flees, any Life/Esuna spells cast on it later in the same turn still take effect; the enemy does not return to combat, but Life/Esuna's battle messages are displayed instead of "Ineffective".
• Casting Esuna in battle on a dead target with enough successes to clear the KO ailment revives the target with 0 HP, resulting in them staying dead.

and disable casting Life/Esuna on dead/fled monsters, which avoids another newly recognized bug in the original code:

• Casting Life on a moster with less than 16 maximum HP results in the monster being revived with 0 HP.

[redmagejoe]

Excellent, I'll update my version and update the first post.

As for Toad, I definitely think removing 0 spell successes should be a Bug Fix addition, as it does indeed seem strange to me that your characters are technically still viable targets and "in" the fight, even if the game seems to go to lengths to make them ~95% worthless. By that logic though, I guess the automatic Game Over does indeed seem out of place. I think these can be applied to Bug Fix.

Are you maintaining the bug fixes txt, or should I update that? I just realized I've deleted a few more items from our bugs list without copying them down, so I might need to do a bit of re-reading through this thread... Got it covered and linked in the first post.

Do Mini characters also always Miss like with Toad, or do they only have spell successes set to 0? Considering series convention (Toad and Mini have their first incarnation in this game, I believe), Toads and Minis should still be able to use items, and Mini usually hits for 1 even if it doesn't Miss. I don't think it demands any changes, I'm just looking for clarity on what differentiates Toad from Mini on players. I'm assuming currently Toad can do nothing but use potions or items that don't invoke spells, or maybe Flee (unless this is affected), while Mini can do nothing but attack for low damage (unless they Miss?), flee, or use potions or items that don't invoke spells. And I'm guessing a full Mini party doesn't also result in a Game Over, but again, I haven't tested this.

[abw]

Theoretically appending a new row of spell data and updating the Holy Lance's index to use it should be enough to take care of that problem, but after giving it a quick try just now, I get crashes at the end of a battle, so probably I'm still missing a label somewhere in bank C or something.

Yup, I was right, there were some pointers in bank F that hadn't been converted to labels in the reassembleable version, and that's where the crash was coming from. After fixing that, I was able to add a new item-spell row for Holy with a 0% break chance and make Holy Lances use that instead of the 100% break chance Holy 8 effect. I also pumped it up to Holy 16 to make it slightly less underwhelming, but its damage still falls far short of Thunderbolt 16 from the Thunder Lance due to Thunderbolt's +5 base damage and +50% success rate compared to Holy.

Are you maintaining the bug fixes txt, or should I update that? I just realized I've deleted a few more items from our bugs list without copying them down, so I might need to do a bit of re-reading through this thread...

Intermittently, yeah. I've uploaded my local copy with the latest notes; we've now fixed or avoided over 50 bugs!

Updates to both Bug Fix and Restored:

• FIXED: The Holy Lance currently uses the same effect as Holy tomes, which means it has a 100% chance to break when used as an item in combat.
• FIXED: Characters affected by Toad or Mini always get 0 spell successes in combat, including for the "spells" that power items, which makes the Maiden's Kiss and Mallet items ineffective in combat. This has been fixed so that status-curing items now always succeed.
• NEW: When the actor is affected by Toad or Mini, the target always gets 0 defense successes in combat; this is probably not exploitable since the target's resists usually only negate the actor's successes, which will be 0 if they have the Toad or Mini ailments.
• FIXED: The player receives a premature Game Over when all characters are Toads.
• NEW + FIXED: Toads that don't act before the first non-KO/Stone/Toad entity don't act at all.
• NEW + FIXED: Multi-target item effects triggered by Toads stop after their first target.

Do Mini characters also always Miss like with Toad, or do they only have spell successes set to 0? Considering series convention (Toad and Mini have their first incarnation in this game, I believe), Toads and Minis should still be able to use items, and Mini usually hits for 1 even if it doesn't Miss. I don't think it demands any changes, I'm just looking for clarity on what differentiates Toad from Mini on players. I'm assuming currently Toad can do nothing but use potions or items that don't invoke spells, or maybe Flee (unless this is affected), while Mini can do nothing but attack for low damage (unless they Miss?), flee, or use potions or items that don't invoke spells. And I'm guessing a full Mini party doesn't also result in a Game Over, but again, I haven't tested this.

Minis also get 0 successes, so they always miss and their spells don't work very well (status spells always fail, damage spells don't get any extra hits, etc.). Toads and Minis can both use items, but the 0 successes makes the items less effective for them than for non-Toad/Minis. I'm not sure about Flee off the top of my head, but since Mini is a temporary ailment, it shouldn't cause a Game Over.

[redmagejoe]

I'm in the process of updating the new bug fix txt, which I'll happily maintain, but I'll update things soon. The Holy 8 -> Holy 16 is only for Restored, right? I think just making it not break in Bug Fix is sufficient, but I agree that it's pretty underwhelming at the point you get it so that's a solid change for Restored.

Also I know this may sound silly, but I was looking at the Magic menu, and there's easily one tile of space beside each spell's experience to put a % in it, isn't there? I'm guessing that would be something I'd have to apply in the translation as well since I'm pretty sure that interface is handled at least partially in the Misc 2 bank of script.

Increases to a character's base stats would not be reflected in their calculated stats until the start of the next battle or an attempt to change the character's equipment. Calculated stats are now automatically updated at the end every battle.

Does the refresh actually run at the end of every battle, or only when stat calculations have occurred? I want to be accurate in my notes.

I'm not sure about Flee off the top of my head, but since Mini is a temporary ailment, it shouldn't cause a Game Over.

Ahhh, that's the difference. So Mini is like the Basuna version of Toad, then. I agree with your assessment of that newly discovered quirk, that the 0 defense resists probably don't matter since you'll never hit with physical attacks anyway. As I'm updating the bug fix txt, I'm curious if those NEW+FIXED bugs apply only to Toad, or also to Mini? Can it be assumed that it did, since the logic behind the code likely assumed neither of them could succeed at casting anything?

• WIP The logic for determining whether a monster will run or not calculates (total party HP - total monster HP) >> 5, but then ignores the high byte of the result and the possible carry from adding the monster's fear level.

I've been curious about this for a while. This is (arithmetic?) right shift 5 on the difference and then ignoring high byte and carry, but in practice what does this mean for its current behavior? In our current version of the game (where monsters run way more frequently compared to it almost never happening in vanilla), are the monsters running more often, less often? Or is the high byte issue essentially resulting in unpredictable results so that it could be either or? Through tentative testing, it seems like the issue is that enemies aren't running away ENOUGH, but it seems ludicrous to me that enemies would run away more than they do in the Jade Passage, for example, where my party has between 2720 and 3450 HP (minus Leon who's at 1290). Even with that HP, there's plenty of enemies who could still do serious damage to my party based on gear.

[abw]

I also pumped it up to Holy 16 to make it slightly less underwhelming, but its damage still falls far short of Thunderbolt 16 from the Thunder Lance due to Thunderbolt's +5 base damage and +50% success rate compared to Holy.

Oops, this was an unfair comparison - I was actually testing against something that was weak to thunder, so Thunderbolt 16 was always dealing its full 32 hits and getting a double damage multiplier on top of that! Trying again against something not weak to thunder, Thunderbolt 16 is only a little over twice as strong as Holy 16 when cast from an item instead of being over six times stronger . (Casting Holy 16 as a spell with a decent Spirit bonus, on the other hand, is nearly three times stronger than Thunderbolt 16 even against a target weak to Thunder.)

I'm not sure about Flee off the top of my head

It looks like the only ailments that prevent a monster from running through its fear calculation are KO/Stone/Paralysis/Sleep.

I'm in the process of updating the new bug fix txt, which I'll happily maintain, but I'll update things soon. The Holy 8 -> Holy 16 is only for Restored, right? I think just making it not break in Bug Fix is sufficient, but I agree that it's pretty underwhelming at the point you get it so that's a solid change for Restored.

Hmm, I actually did it for both, but you're right, Bug Fix should keep the level at 8. Fun fact: the game appears to be perfectly happy letting you cast spells with levels over 16 from items, and even Holy 99 as an item doesn't do as much damage as Thunderbolt 16 to a target weak against thunder .

Also I know this may sound silly, but I was looking at the Magic menu, and there's easily one tile of space beside each spell's experience to put a % in it, isn't there? I'm guessing that would be something I'd have to apply in the translation as well since I'm pretty sure that interface is handled at least partially in the Misc 2 bank of script.

You could do that either in the menu layout string (follow the pointer at 0x2845C) or in the code for printing skill level + "-" + skill experience at $0E:$898D.

Does the refresh actually run at the end of every battle, or only when stat calculations have occurred? I want to be accurate in my notes.

It runs after the end of each character's level up code regardless of whether the character gained any stats or not; we could have saved (lots of) cycles by only running it inside the level up code, but it was more convenient to locate the code after updating the NMI handler since we were running into timing issues.

Ahhh, that's the difference. So Mini is like the Basuna version of Toad, then. I agree with your assessment of that newly discovered quirk, that the 0 defense resists probably don't matter since you'll never hit with physical attacks anyway. As I'm updating the bug fix txt, I'm curious if those NEW+FIXED bugs apply only to Toad, or also to Mini? Can it be assumed that it did, since the logic behind the code likely assumed neither of them could succeed at casting anything?

Yeah, somewhat, though unlike Toads, Mini characters are able to cast spells (but like Toads, they still get 0 successes). The last 3 bugs only apply to Toad, and they were all fixed by flipping a single bit . I went into a little more detail in the text file, but basically the game loops over each character at the end of every command execution (including once for each target during multi-target commands) and sets the battle command of each KO/Stone/Toad character to nothing (#$FF) until the first non-KO/Stone/Toad character, which results in Toads randomly not getting to act and multi-target commands issued by Toads only affecting their first target. This game really doesn't like Toads for some reason .

I've been curious about this for a while. This is (arithmetic?) right shift 5 on the difference and then ignoring high byte and carry, but in practice what does this mean for its current behavior? In our current version of the game (where monsters run way more frequently compared to it almost never happening in vanilla), are the monsters running more often, less often? Or is the high byte issue essentially resulting in unpredictable results so that it could be either or? Through tentative testing, it seems like the issue is that enemies aren't running away ENOUGH, but it seems ludicrous to me that enemies would run away more than they do in the Jade Passage, for example, where my party has between 2720 and 3450 HP (minus Leon who's at 1290). Even with that HP, there's plenty of enemies who could still do serious damage to my party based on gear.

Oh, I forgot to mention this: the original code with its overflow errors effectively capped a monster's chance to run at 85% (= 255 - 170), and since monsters were running too often with the overflow errors fixed, I added a cap at 85%. But yeah, if your party has somewhere around 10000 HP and is facing a monster party with around 2000 HP, then (10000 - 2000) / 32 = 250; assuming you're fighting one of the monsters with a Fear level of 4, that gives it a 250 + 4 - 170 = 84% chance of running. That calculation didn't involve any overflow, so you should be seeing the same thing with an unaltered ROM. If the difference between your HP and the enemy HP was at least 8192, though, 8192 / 32 = 256, but the game didn't check the high byte of the result, so it would treat $100 as $00. Conversely, if you were fighting one of the monsters with a Fear level of 9, 250 + 9 = $103, but the game didn't check for overflow, so it would calculate 3 - 170, see that the result was negative, and set the monster's chance to flee to 0%.

The entire system is based around HP and the monster's Fear level, so it doesn't take any of your gear or other stats into account. Like a lot of things in this game, it's a decent idea that's just not quite fleshed out enough to work really well.

[redmagejoe]

Hmm, I actually did it for both, but you're right, Bug Fix should keep the level at 8. Fun fact: the game appears to be perfectly happy letting you cast spells with levels over 16 from items, and even Holy 99 as an item doesn't do as much damage as Thunderbolt 16 to a target weak against thunder .

I'm sure there's probably something in the existing code that more or less caps out how many attempts are calculated, even if it does "print" 99. Otherwise without considering weird overflow/underflow bugs, I can't imagine that outcome being feasible. Ah well. Let's put the Holy Lance to 8 on Bug Fix. Tested it on Restored, no breaking, good damage, a very nice piece to have on your Black Mage character to complement their arsenal.

You could do that either in the menu layout string (follow the pointer at 0x2845C) or in the code for printing skill level + "-" + skill experience at $0E:$898D.

If it can work in both, maybe it would be best to do it in the code (in both, because why not?) since that makes it universal rather than being dependent upon a translation patch. Honestly after staying up late last night poring hours into v2.2 of the Chaos Rush translation (partially because of careful script compression, partially because of a mistake caused by relying too heavily on CastleFynn's compile bank feature when some lines have been stuffed at the end of another bank due to space constraints since even before I picked the project up), I'm happy where it is and I'm sort of afraid to touch the script again for fear of breaking it again.

It runs after the end of each character's level up code regardless of whether the character gained any stats or not; we could have saved (lots of) cycles by only running it inside the level up code, but it was more convenient to locate the code after updating the NMI handler since we were running into timing issues.

All good, there's not a significant enough delay to justify reworking it anyway.

Oh, I forgot to mention this: the original code with its overflow errors effectively capped a monster's chance to run at 85% (= 255 - 170), and since monsters were running too often with the overflow errors fixed, I added a cap at 85%. But yeah, if your party has somewhere around 10000 HP and is facing a monster party with around 2000 HP, then (10000 - 2000) / 32 = 250; assuming you're fighting one of the monsters with a Fear level of 4, that gives it a 250 + 4 - 170 = 84% chance of running. That calculation didn't involve any overflow, so you should be seeing the same thing with an unaltered ROM. If the difference between your HP and the enemy HP was at least 8192, though, 8192 / 32 = 256, but the game didn't check the high byte of the result, so it would treat $100 as $00. Conversely, if you were fighting one of the monsters with a Fear level of 9, 250 + 9 = $103, but the game didn't check for overflow, so it would calculate 3 - 170, see that the result was negative, and set the monster's chance to flee to 0%.

Hmm, so is the current behavior still bugged? Or are you saying that instead you implemented the 85% (0x55) cap so that the high byte and carry don't even matter? I'm guessing that this is only an issue for monsters that you drastically outclass, thus it wouldn't be an issue the further you get into the game. I don't know if it really matters how the game went about it so long as the end result is that math is done to determine % chance to run away. It sounds like you essentially found the bug, fixed it, and the fixed behavior was that their system was way non-functional, and thus the current system essentially... replicates the old unintentional cap, but still has drastically improved running behavior, yes?

I'm just trying to wrap my head around its current as I understand the before, and I will say in its current form after hours of playtesting, it seems very satisfactory with enemies running rather reasonably based on party strength. If you're happy with it where it is, I'll go ahead and remove that item from our list and update the bug fixes. Also I put a link to our bug fixes in the first post so it's easier to keep track of!

[abw]

I'm sure there's probably something in the existing code that more or less caps out how many attempts are calculated, even if it does "print" 99. Otherwise without considering weird overflow/underflow bugs, I can't imagine that outcome being feasible.

Nope, the damage algorithm will work with any 8-bit number of hits, and Holy 99's damage was about what it should be. When cast as an item, it isn't affected by the caster's Sprit, so it uses its base accuracy of 0% and power of 15, except it's multi-target, so that gives a 50% penalty to accuracy (fifty percent of nothing is, let me do the math here, nothing into nothing, carry the nothing... ) and 75% penalty to power, which means you never get any successes and deal an average of 4.65 damage per hit. Thunderbolt 16, on the other hand, is balanced as a monster spell, so it comes with 50% accuracy and 20 power, giving it 25% accuracy and 5 power for multi-target, resulting in an average of 20 hits at 7.75 damage per hit against normal foes, but 32 hits at an average of 15.5 damage per hit against foes weak to thunder.

I'm just trying to wrap my head around its current as I understand the before

The original game had monsters fleeing less often than then should have. I gave an example in the text file using a lone Goblin at full health; it has an 85% chance to flee from a party with 2437 total current HP, but had a 0% chance to flee from a party with 2438 total current HP. The chance to flee reset to 0 with every additional 8192 ($2000) difference between monster and character party HP, but the specific reset points vary based on HP difference and each monster's Fear level (as adjusted by the Fear spell).

Eliminating the overflow errors stopped the probabilities from periodically resetting to 0, but also allowed them to reach and exceed 100%, so monsters were guaranteed to run once your party HP was high enough; this wasn't possible in the original and I feel it's undesirable behaviour (among other things, it presents some problems if you need to go back and farm weaker monsters for drops, though once you know how the mechanic works you can just reduce your current HP), so I've explicitly capped the chance at 85% in order to match the original's implicit cap.

[redmagejoe]

*rubs temples*

So player spell names must be no longer than 4 tiles since it prints 1 space, and then the spell level, with a second space for <10. The 5-tile names worked fine for <10 because it wouldn't "push" into that extra space, as far as I could tell. So I took this logic to change some names of enemy spells, looking through online resources and only making spells that never went above 9 use 5 tiles. Yet for some reason, THESE spells SPECIFICALLY have the exact same issue with 5 tiles REGARDLESS of spell level, pushing the numbers, even if they're <10, out of the box. Are there two separate routines for printing spell messages between party members and enemies? There's no way something so absurd could be the case.

I SHOULD in theory be able to make Charm, Tsunami, and Self-Destruct 5 tiles rather than 4 since they never go above 9, 8, and 7 respectively. Garlic use, I learned, is also supposed to display "Garlic 3", but suffers the same problem due to using 5 tiles. The only thing I can imagine looking at the disASM is that the routine that replaces leading 0's with spaces is doing something wrong in these cases. Is it because of some issue where the spells only have preset levels, rather than scaling from 1-16? Are they not considered proper integers as a result of this? After all, there is only Garlic 3, Tsunami 8, Self-Destruct 1, 3, 5, 7, and Charm 6 and 9.

[abw]

The 5-tile names worked fine for <10 because it wouldn't "push" into that extra space, as far as I could tell.

I'm pretty sure this is false. If I cast e.g. Scrge 3, only the 5 tiles for Scrge + 1 tile for the space separating name from level + 1 tile for the space replacing the tens digit of the spell level are displayed, with the ones digit of the spell level getting pushed outside the box. You can follow through the code at $0C:$ACF3 if you want to see exactly what it's doing.

[redmagejoe]

I'm pretty sure this is false. If I cast e.g. Scrge 3, only the 5 tiles for Scrge + 1 tile for the space separating name from level + 1 tile for the space replacing the tens digit of the spell level are displayed, with the ones digit of the spell level getting pushed outside the box. You can follow through the code at $0C:$ACF3 if you want to see exactly what it's doing.

How odd. I was almost certain it was behaving the way I'd described... at the very least, watching the LP someone's doing before they updated their ROM, 5-tile names were displaying their levels just fine, but I changed "Fire" to "Flint" for testing, and indeed both 10 and 9 were pushed outside the box (" 1" and "  " respectively). I wonder if it's because of the tiles that were being used...? As the end of most of Chaos Rush's original tiles emulated a space after the squished character. But I wouldn't think that would be considered at all by the code, since it's just a sprite. I'm very confused by the behavior now.

https://youtu.be/VdVmefMN7fU?t=186

You can see here in the LPer's pre-v2.1 ROM the spell levels for Blizzard and Thunder displaying just fine, with both using "d " and "r " squished tile sprites. Yet I now can't seem to reproduce the behavior that originally came to my attention weeks ago specifically when using Blizzard and Thunder, I believe, which I'm 100% certain were using 5 tiles and not the 4 I abbreviated them down to. On his latest episodes he is using the v2.1d patch, which has the abbreviation already, and the appearance of the spell levels is identical. The only takeaway I have from this is by pure chance, it worked the way it did specifically because of the last tile in those particular spells. Assuming that's the case, then I guess I should revert the 5-tile Tsunam(i) to 4 tiles.

EDIT: Whatever, I took the path of least resistance. I left Charm and Self-Destruct as Chrm and De"st"r instead of Charm and De"st"ro, and since Garlic and Tsunami only ever have one level in the whole game, I'm going to hard-script them as "T'suna'mi8" and "Gar'li'c 3". The redundant levels will be pushed outside the box, and life moves on.



Uhhhhhhh... I think I found a bug in Restored, don't know if it's also in Bug Fix. By pure chance I discovered I could "use" Cat Claws, which left me scratching my head as I looked everywhere and found no indication it cast anything. I just now finally watched what it cast... Haste 66... on Emperor... who isn't even in the battle. I'm pretty sure that's incorrect.

AND IT BROKE! Time to reload a save...

[abw]

You can see here in the LPer's pre-v2.1 ROM the spell levels for Blizzard and Thunder displaying just fine, with both using "d " and "r " squished tile sprites.

Hmm, interesting. Any idea which exact patch that LP is using? Is there any chance some code changes got removed between that version and the current translation patch?

Uhhhhhhh... I think I found a bug in Restored, don't know if it's also in Bug Fix. By pure chance I discovered I could "use" Cat Claws, which left me scratching my head as I looked everywhere and found no indication it cast anything. I just now finally watched what it cast... Haste 66... on Emperor... who isn't even in the battle. I'm pretty sure that's incorrect.

AND IT BROKE! Time to reload a save...

Well, that's special... the code for determining whether a weapon can be used in battle to cast a spell took the weapon's in-battle use byte (byte 8 of weapon data), looked it up in the table of spell effects at $0C:$8336, and then checked to see whether the spell effect has a battle command. That's fine for weapons that actually can be used in battle, but for weapons that can't, the lookup still happened but overflowed the end of the table and started reading from monster data, specifically the byte at $0C:$8336 + #$FF * 5 = $0C:$8831, a.k.a. Adamantoise's spell list index, which by pure chance also happens to be #$FF (no battle command). Adding a new row of spell effect data for unbreakable Holy pushed the monster data by 5 bytes relative to the start of the spell effect data, so instead of reading Adamantoise's spell list index, it started interpreting Phoracos' data as spell effect data, starting with its Evasion Level/% indices, which are #$13 (battle command for Haste) not #$FF . There's another bug for the list!

I've uploaded a fix for this in both patches.

[redmagejoe]

No code changes at all, purely script. I can only assume that it had to do with my theory of the ending tiles having some sort of spacing at the end, and indeed, all those 5-tile spell names were using a tile of that sort compared to my re-spriting. It's moot at this point the why, as I've gone ahead and ensured that all spell names that appear in combat fit.

What was the level of Holy Lance's spell between the two versions? 8 and 16? I think I'll add a note about the level buff to our Restored improvements list.

[nosynose]

redmagejoe, I hope this is also the place to report on Chaos Rush's FF2 Retranslation that you maintain.
Under FCEU 0.98.12 (yeah, a very old emulator), v2.2 & v2.2a just give blank screen after you name your 4 characters, while all previous versions (v2.1-) proceed normally (I also applied B Button Dash to them if available). So I don't know what's wrong here.

[redmagejoe]

redmagejoe, I hope this is also the place to report on Chaos Rush's FF2 Retranslation that you maintain.

It is absolutely fine to use this thread to report on the Chaos Rush translation given our discussion of it here. You may also send me a PM and I will respond.

Under FCEU 0.98.12 (yeah, a very old emulator), v2.2 & v2.2a just give blank screen after you name your 4 characters, while all previous versions (v2.1-) proceed normally (I also applied B Button Dash to them if available). So I don't know what's wrong here.

I cannot seem to recreate the issue with either of these versions on FCEUX 2.2.3. I will see if I can't track down the emulator you're speaking of, but I'm inclined to say it's an emulation issue rather than a patch issue. No code at all has been changed in these patches. In the meantime, might I recommend the latest version of FCEUX?

EDIT: Both patched and unpatched versions work perfectly fine for me (save for FCEU's color accuracy being... debatable) on both FCEUX and FCEU v0.98.12. Are you sure you didn't accidentally apply a different patch to the ROM that may not have been compatible? Be sure to apply the patches onto a clean, unpatched ROM to rule out any incompatibilities in the case of a problem like you've described.



I just encountered my first Iron Giant, and after prepping my party up on my Preemptive Strike with buffs and gearing up for an epic battle, he ran away... Iron Giant, the superboss ran away? -170% fear score, party HP of ~12000 to his 3500 means his chance to run was effectively 119%, capped at 85%. Looking at vanilla behavior, I mean... it's not our fault, and this seems like behavior he would actually have, but how stupid for this guy to run away from you. Do you think we should impose a drastically lower fear score on Iron Giant in Restored, so that he's an actual threat to decently-trained parties rather than some sort of elusive Bigfoot? Upon further inspection I see that most if not all bosses have this value of -170%, but the difference is, I'm guessing, that they're all flagged as inescapable battles.

Frankly I feel for how rare (1.6% on 3 of the 10 rooms of the final dungeon) Iron Giant is, it should also be flagged as inescapable, moreso for him than the players. Unless we wanted to adjust the fear score, which would only be effective if it's a signed 2-byte integer rather than an unsigned 1-byte which by code's handling of it implies it to be negative. Definitely a Restored change rather than Bug Fix, but I don't see any reason the player should have to try to 1-turn nuke this guy into the ground or, if their party is GROSSLY underleveled, be able to escape a curb-stomping. It's a 1988 Famicom JRPG, that kind of harsh punishment for underprepared players is par for the course.

[nosynose]

redmagejoe
Okay, I just retraced my steps. Base ROM is correct per RHDN page. Use FLIPS v1.31 patcher as before. Same FCEU v0.98.12. Same problems.
But when I exclude B-Button-Dash patches, v2.2 & v2.2a proceed normally to the first battle!
So this problem lies on those optional patches.
I checked v2.1's B-Button-Dash patch size and it's different than v2.2 & v2.2a's (35 bytes vs 51 bytes). Any weird changes there?

[redmagejoe]

I will investigate. It's very possible I included some bad data in the B Button Dash patch.

EDIT: Yes, I see what happened. I accidentally pulled the B Button Dash that's incorporated into the Restored patch, which is not identical in its implementation to the standalone B Button Dash patch that goes on a non-Restored ROM. Let me do some testing to see if the standalone patch will work on top of a Bug Fix only ROM, and see about reuploading a revision.

Reading my old post about digging up the patch, I have implemented and tested a dash that works both in towns and on the overworld as abw's version did, but using the old implementation. Assuming code didn't move around too drastically in Bug Fix only, it should work with that, but I'm about to test. At the very least, my current version will work with the translation and no bug fix patches. Time to test.

According to Patch Checker, my new version is compatible not only with Bug Fix, but also Restored (though why would you combine these patches) from records comparison alone. At first glance I would assume that to mean only that there's no overlap in bytes being modified, but I'm skeptical. I'm guessing that abw simply found a cleaner way to implement the B Button Dash in Restored, and I was remiss in trying to use that as the basis for a standalone.

I will upload the patch to my drive and link it here, while also updating the submission. Sorry about the inconvenience. https://tinyurl.com/ybk7sz2a

[Special]

n/m.

[abw]

What was the level of Holy Lance's spell between the two versions? 8 and 16? I think I'll add a note about the level buff to our Restored improvements list.

The original and Bug Fix are at level 8, Restored is at 16. I'm tempted to also pump its accuracy up to 200% to ensure 32 hits, but even that wouldn't be enough to make it better than Thunderbolt 16 .

I just encountered my first Iron Giant, and after prepping my party up on my Preemptive Strike with buffs and gearing up for an epic battle, he ran away...

Aww, that's sad .

I haven't encountered an Iron Giant yet, but I do feel that monsters flee too much in general. Dividing the HP difference by 64 (minimum 14444 party HP required for a 1% chance for a lone Iron Giant to run) or even 128 (25388 HP) instead of 32 (8972 HP) would be an easy change to make. That said, I've had an average over my recent playthroughs of about 7000 HP when reaching the final boss and haven't had any serious difficulties, so 12000 HP seems like a lot... maybe I've been abusing save states too much?

According to Patch Checker, my new version is compatible not only with Bug Fix, but also Restored (though why would you combine these patches) from records comparison alone. At first glance I would assume that to mean only that there's no overlap in bytes being modified, but I'm skeptical. I'm guessing that abw simply found a cleaner way to implement the B Button Dash in Restored, and I was remiss in trying to use that as the basis for a standalone.

In Restored I stole some of the space freed up by the RNG fix to hold a routine for updating the movement speed that gets called from a couple of places, so getting a crash the first time the game asked for a random number sounds about right. I've only made a few changes in the fixed bank (RNG fix, gil cap fix, and B-button dash), so if your patch works with both the base ROM and the translation, it's probably compatible with Bug Fix too.