tabachanker

@Spy I didn't know about the glowing green text when a unit has all of its support convos unlocked. That's why it's not implemented in the FE6 translation... yet! I made some tests today to my original support convo coding and it seems to work correctly. I'll have to test it thoroughly though because their is only one subroutine for all the places that need to display the units list (same one used in support convo, items trading and picking units) and I don't want something to change in the other lists. I'm eager to see your own translation, as French is my primary language.

Excellent @gringe! I'll look at it this weekend. Should be able to send you back the ROM with my modifications in the next few days. Thanks!

OK found the bug. Found 2 bugs even! Both related to the changes I made to save on the amount of objects used (which I described in my previous post). First, the "bypass space characters to save on objects" didn't work properly. This was a minor bug but by fixing it, there are less objects used overall on an intro page. This in turn seems to have fixed the full hang with the loud noises. The page that hanged used almost all available objects to display the long text (63 out of 64 max) and sometimes, after a full intro loop, it generated more objects than the previous time. I still don't know why that is, but we have a much bigger buffer now! The garbled intro text were caused by me forgetting to initialized some RAM. The first time, all went well because objects had all 00s in their RAM. But the subsequent loops, that RAM had been used by other things and, since I didn't initialize it properly, it was all garbage that the intro text routines tried to interpret the best it could. There's a good chance that this was also the culprit for the full hang described in the paragraph above. Last modification I made, something not apparent, but it bugged me knowing I could have made it better. It's the way I ordered the units in the support convo menu. I borrowed an unused byte in the units table to sort the units a specific way. Little did I know that there was actually a byte already in the units table for that purpose AND it's available & can be easily changed in FEBuilder. By using this byte, the support convo menu is much more friendly with FE6 hacks. The creator just has to make sure that every unit has this byte set in FEBuilder to a number from 1 to x, in sequence, just like in the original game. @gringe I will wait for your new version with your own corrections, and then I'll send you the new ups patch that will include the fixes above. If you'd like to have the fixes before releasing a new version, pm me or write in this thread, I'll try to monitor it a little more frequently than usual! In the meantime, I'll see what I can do with other suggestions in the thread. As always, if time permits!

Wow, so many things since last time I checked here. Thanks to all for the feedbacks. As German FE Nino said, the opening glitch is probably a memory leak thing. I remember when I did the prologue hack back in, what, 2014 iirc, I had problems with the "too many objects opened" (or procs as you called them Nino). In the original game, each characters used 2 objects. That might have been OK for Japanese characters, but English uses more of them to convey the same meaning and it effectively crashed when too many letters were used. So I changed the code a bit to only used 1 object per letter and no objects for spaces. The 1 object per letter was still needed since the letters fading animations are done asynchronously for each letter. This, at least, without major reprogramming of the intro. Good news is, with Seafarer's instructions, I was able to experience the bug. Even better, if I skip the first time, I get a bit of garbled text on the Nintendo logo (but no hang). So it IS most likely related to the intro skip. And that might have been due to halving the objects used for each letter. So all I need now is time! I'll see what I can do and keep everyone update here.

There's a typo in Larum & Ogier's B support (more like repeated words). Larum says at some point: Oh, you're the guy who was who was spying on me. And I finally gotten around to fix the Battleground label displacement on the minimap of the Preparations menu. If anyone's handy with a hex editor, here's how to fix this yourself: There's a string of 8 bytes at offset $7bc78: 68 00 88 10 68 10 68 00 And another 8 bytes following at offset $7bc80: 62 00 42 00 62 00 42 00 You need to swap those 2 sets of 8 bytes so that it reads, from offset $7bc78 to $7bc87: 62 00 42 00 62 00 42 00 (and then) 68 00 88 10 68 10 68 00. Very unfortunate mistake on my part there, those bytes are used to display the battleground elements on the minimap. The 1st set of 8 bytes are used the majority of the time. The 2nd set is used only when the city is near the left edge of the minimap. I just inadvertently switched those sets around. 😥

In-game, if you go in the "status" menu, you can press the "L" button to toggle this feature on and off. You'll see a number in the bottom-left corner of the screen appear and disappear as you do this. I don't know if this feature is in the original game or if the original translation put this feature in there. The way it is implemented is weird to say the least.

It's possible sure. Basically, all you have to do is replace a couple of bytes (about a hundred) in any ROM image with my new version. That part of the ROM was probably never changed by any version of the ROM out there (be it a different language ROM, a stats-altering ROM, or just a ROM with cosmetic changes). As long as the 100 or so bytes I changed are exactly as mine were before the patch, it should work perfectly. But I want to test the fix though before posting here, because as I said, the injected code was everywhere in the ROM, and not just Hugh's stats were impacted. All the characters and possibly all the enemies are affected. That's why I want to make sure that my fix accounts for every possible outcomes before making it public.

I investigated this problem and I found the culprit. Seems like there was some code injected from the original translators. This code isn't in the Japanese version. The additional code executes everytime the characters stats are written to or read from SRAM (when you save, suspend, or the game auto-saves, and then when you reload a game). In the original version, your characters stats are all save as is in SRAM, with a bit of compression going on (all stats are put back to back, and each use only 5 bits, so they can never be over 31). The additional code, for whatever reason (I haven't figured out why they did this, it doesn't serve any apparent purpose), removes each character's base stats before saving the results to SRAM. When you reload a game, another part of the injected code adds back each character's base stats. Normally, it all goes well except for when Hugh gets recruited with diminished stats. Hugh has only one table entry for his character. When you haggle his recruitment price, the game fetches his base stats from that one table entry, and subtracts 1 to every stats each time you refuse his cost. The problem arises when the resulting stat is lower than its base in Hugh's table entry. For example, when you recruit Hugh, his base Magic is 12 + the mage class is 1, so you get a 13 Magic Hugh if you don't haggle. When the injected code do its thing, it takes that 13 , subtracts 12 (Hugh's base magic), which gives 1. That gets saved to SRAM. At reload, 1 + 12 = 13, so no problems there. Same thing if you haggle Hugh's recruitment cost once (12 - 12 = 0, then 0 + 12 = 12). But if you haggle twice, now the bug rears its ugly head,. 11 - 12 = -1, -1 is represented in binary form as "11111111". When the original game takes over and smush everything together in SRAM, it only uses 5 bits of each stats, so 11111111 becomes 11111, or 31 in decimal, instead of -1. Now when you reload, the injected code doesn't check for this kind of overflow, and just add the character's base stats as always. So 31 + 12 becomes 43. I was contemplating just removing the subtracting and re-adding operations for a while as I can't find the purpose of why they did this in the first place, except maybe if you want to cheat and hack yourself monstrous stats like the 43 magic above (with the original game, stats can never be more than 31). But they really injected their code everywhere and I was afraid of breaking something else in the process. So, with the power of math, I found the best way to overcome this bug and with minimal changes. I just added one instruction to the injected code, and moved it a bit to compensate for this added instruction, and lo and behold, the bug is gone. I added a "and $1f" mask whenever the injected code subtracts or adds to a stat. That way, when 11 Magic Hugh gets saved to SRAM, the calculations goes: (11-12) and $1F, which is still 31. That gets saved to SRAM. But when a reload occurs, 31 + 12 = 43 (binary 00101011) AND $1F (binary 00011111) = our old friend 11 (binary 00001011)! This was the simpler and the best solution I could think of. All other options I thought of made the previous save games oblsolete. Because that injected code made sure all saved games since then were filled with diminished stats. The solution I came up with still has the diminshed stats in the SRAM, and the injected code is still there, doing nothing useful, but at least people's save games / save states are still usable. I worked on this because Gringe asked me if it was possible to erase this bug for his upcoming final (maybe?) translation version. So, the bug will be gone whenever the new translation version comes out.

Glad to see you're still working on this patch Mr. Gringe! I'm still lurking about here from time to time, so if you need my help for anything a little more technical, fell free to ask!

Yeah, you have to unzip the file before applying the patch. You have to apply the patch on the ".gba" file, not the ".zip" file.

Yeah, that's FEditor's fault. I remember trying at some point to correct this just by tweaking its config and it seemed to work for a while. But then it started appending new text after 16 MB again. Unfortunately, you really need that last portion of the code. It contains the latest text edits that Gringe did. If you truncate this, the game will most probably crash when it tries to display the text that was supposed to be there.

Unfortunately, It wouldn't fix those. It would simply change the text to something else. The best thing we can do for the cut items is to modify their text pointers to somewhere else in the ROM and put our own text there. The only purpose I see for compressing the texts is to have a neater release, and even then, only at a code level, i.e. not apparent to anyone that doesn't bother with those kind of things.

Hey all! Just popping up to say hello, and to tell Gringe I may have found a typo in the last version. It's the description for the blue gem I believe. Here's the entry in FEditor Adv: Text of ID 0x0626 A rare gemstone woth 5,000 gold.[X] Also, I found out how to compress all the texts back into the original game's compression format. That way, almost all the texts can be compressed and tucked neatly inside the ROM at their original spot (offset $00817C00). It doesn't serve any purpose other than being neat I guess? The original game and the older English translation were done that way. But it's short and easy to do (now that I know how to do it). The only downside is having to check almost everything again, just to be sure every text is still in its proper place. FEditor Adv can be used to compare the texts before and after (since it can read FE compressed texts). Anyway, just wanted to tell you it's something feasible, and if that interests you, send a message my way!

Woohoo! Congratulations on your version 1.0 gringe! And it was time too as FEditor started appending again new text corrections at the end of the ROM... Well, it's not a problem anymore!! Yay! Well, if need be, just ask and I'll do the same trick I did the last time to recompress the ROM. I hope everyone will be happy with this version. I sure enjoyed it a lot on my first run.

@Gringe: Yeah I know, those are reaaallly minor things to correct! But at this point, they aren't hard to figure out. And the almost glued "Move" & "Con" labels were bothering me a bit! But don't worry if you haven't had the chance to include these last minute changes to your 1.0 version! Ok, here's how to move the labels around in unit stats screen. I took screenshots of FE7 to position all the labels as close as to this game as possible. Change Affi label to Affin: Points to "Affin" label instead of "Affi": Put $6E $72 $81 $08 at offset $6789D4 Pull label to the left a bit (cause "n" is a bit clipped): Put $CB at offset $6789D8 Move "Move", "Con", "Aid" labels around: Pull label "Move" a bit to the left: Put $44 at offset $678A98 Push label "Con" a bit to the right: Put $61 at offset $678AA8 Push label "Aid" a bit to the right: Put $7B at offset $678AB8