Kngt_Of_Titania

If you mean what I think you mean (as in, the module is treating it as a signed byte when it's not in the ROM), I just tested it by setting it to 200% HP growth, leveling a unit to 20, and checking the results. Nightmare reports a negative growth. It does, in fact, reduce the HP below base when you check the unit in-game.

You know what confuses me? I'm about 90% sure that HP growth is a signed byte (at least in FE8), or at least that's what Nightmare is telling me. As such, its cap would be somewhere in the range of, what, 127% (from -128 to 127, IIRC)? I remember Nightmare freaking out and putting a negative when I tried to put a HP growth of 130 in there. Mind you, it makes no sense to me that it's a signed byte. I mean, who the hell programs a FE game to decrease a character's max HP (or any stat, really) on level up?

But you can actually see Wolt's eyes

Well played, well played. (Although we all know who the one true father is >:D) But yeah, seems odd to straight up buff Marcus. I might do something like a bases nerf, growths buff to equalize his usefulness across the game (making early less reliant on Marcus to train characters; coupled with buffs on Wolt, Bors, etc., this opens up more options for training characters while making it slightly easier). I never was fond of the Jaigan/Marcus archetype, simply because they end up being just too good -- this mainly because the hardest part of most FEs is early game, before your team goes on steroids and enemies...well, not as much; so even when they lose steam comparatively, they're usually still good enough to trash late game enemies sufficiently. EDIT: But this is obviously not a balance hack; not trying to tell you what to do, just what I'd like to see.

Agreed. Wolt needs to be buffed to match the glory of his father.

But Gaiden and FE1 ARE sidequels. Gaiden literally means "side story". It happens on a different continent as FE1/FE3, which is why you see the pegasus sisters in it.

I figured that it was something like that, but like you, I found nothing that it controls. I decided to leave well enough alone, mainly since I got it to work. I figure it has to be important somehow, since they built this new way of storing X and Y coordinates around this bit flag.

Here's a small section of the document I created when I solved the hex values that determine the X and Y coordinates of REDAs (which happens to be the same numbers you put in Nightmare): For [XX,YY] coordinates for REDA 00 00 A ZB A = XX + YY*0x40 - int.floor((XX + YY*0x40)/0x100)*0x100 B = int.floor((XX + YY*0x40)/0x100) Z = Seems to be either 0 or 8 -- not sure what it controls. Only saw 8 here on Seth's REDAs in prologue map. Putting 0 here works fine. Predictions: [9,0]: 09 00 [20,15]: D4 03 [40,40]: 28 0A It works. IMPORTANT NOTE! These values I came up with are in hex and are put into the hex editor that way. Nightmare, IIRC, has you put them in decimal, so you will have to solve for A and B and then convert both numbers from base 16 (hexadecimal) to base 10 (decimal) using either the google calculator or the MS calculator.

I know that this is an old topic, but I have similar information for the FE8 ROM, for anybody that is interested. To change base poison damage, change two bytes at 08025A3E to 0X 33, where X is the consistent damage you want the poison to do. To change variable poison damage, change two bytes at 08025A36 to 0Y 20, where Y is the max additional damage you want the poison to do. Also, while finding out this stuff, I accidentally stumbled on the RNG generator on the FE8 ROM, which seems to be located at around 08000B8A, if anybody ever feels like eliminating true hit (double RNG roll system) from their games to give it more of a old school FE1/2/3/4/5 feel.

So I got it working. I guess what happened is that FEditor freaked out somehow and put in the wrong hex values, so that it referenced index 82 (staff animation) for EVERYTHING. Found the pointer, changed the correct 82 hex values to 81, and everything worked. I didn't actually script it; it came from FEditor, so I don't know whether it dumped it wrong or it got changed when I tried to insert. Thank you all for the help!

To be honest, no. Is there a reference to the pointer in question within the .file or the frame data files? It just strikes me as odd that literally dumping the Valkyrie files (both sets of the .file, .dmp, and the 3 .pngs), making no alterations to them, and then re-inserting them in another index (writing them over the Bishop entries) is causing this same problem. This suggests that it isn't anything I changed that is screwing it up, but rather something I DIDN'T change in the .file/.dmp files. I'll try changing the animation pointer data and see how it goes. Edit: No, wait. Switched the animation pointer to Valkyrie on Nightmare and it basically ends up being a basic recolor of the original (without some of the changes I made on paint so that the palette change would look good), although the animation for casting spells now works.

Alright, so I've gotten the palette fixed and it will insert -- on FEditor, everything seems to work just fine (thanks a ton for that information, btw). In game, however, the staff animation seems to work perfectly, but when I cast magic, it will actually use the staff animation AGAIN regardless of whether the spell hits OR crits. This problem occurs both when I try to insert my recolored image and when I dump the standard Valkyrie and try to re-insert *that*, so I'm sure it has something to do with an error on FEditor's side. What I'm doing: 1) Note that, on the Class Animation Manager, the input indexes of Bishop (the class I'm inserting over) are 81-82 and the input indexes of Valkyrie are 87-88. 2) Dump the animations from indexes 87 and 88 into two seperate serial files (standard procedure...FEditor does it automatically). 3) Make any recoloring edits (or not, in my second attempt). 4) Insert the serial file from index 87 (by selecting the proper .file file when the prompt comes up after pressing "Insert") in index 81. 5) Insert the serial file from index 88 (by selecting the proper .file file when the prompt comes up after pressing "Insert") in index 82. I feel like I'm missing a step or that I'm not properly inserting the Frame Data. Anybody know?

Actually, I didn't. That sounds like it would be the problem. But what do I open the .file thing with? HxD?

I was actually thinking of doing this. I've done FERecolor and effectively used the Hex code to write over the palletes for individual characters (i.e. Moulder Sage, etc.) and I know that it works just fine. I'm wondering a couple things, though: 1) I'm assuming that generics in a class get their own hex values for their coloration. I'm not 100% positive, though. 2) If they do exist, how would I go about finding which offset contains the palette information I'm looking for? EDIT: As for which file/location I used, I literally just tested the files dumped by FEditor, saw that they worked, recolored them, and saved over them. Same file name, same location.

So I've been making decent progress on my hack, and I've decided to add one class into the game, the Heretic, which is essentially a second class for healers that uses dark magic and has a mount (think the antithesis of the Valkyrie). Because I am terrible at drawing anything, I am, at least for the moment, making it a radical recolor of the Valkyrie (a placeholder so I can implement the changes and make it as least functional). So what I've done, step by step: 1) Load up Feditor, select "Class Animation Manager", go to Valkyrie animations, and dump them. 2) Using the standard Valkyrie pallete, make the minor changes to coloration necessary to pull off my recolor (otherwise, weird shit happens like the horse looks like it has 3 eyes) 3) Add in FEditor's transparant color as background and check to see if it will insert correctly. It does. --Here's where something is going wrong-- 4) Open up FERecolor. Load Valkyrie picture, tweak recoloring until I'm happy, note the RGB values of old colors and recolored ones. 5) Open up Usenti. Use its pallete feature and numbers from FERecolor values to recolor pictures. Note that Usenti still says there are only 16 colors used. Save the files. 6) Check to see if it will insert in FEditor, but get message saying something akin to "More than 16 colors used!" 7) Assume I actually am, double check in both Usenti and MS Paint. They say I'm good and that the right colors are in the right places. 8) Still, to be safe, re-do steps 4-5. Still get same error message. Does anybody have an idea what's going on? If it worked for the un-recolored image, it *should* work for the recolored one, right? P.S. In case anybody needs it to help me out with this, here are the pre-recolored and post-recolored images: Pre: Post:

Added more detailed instructions in case people were having problems applying the patch to a FE8 ROM.

Actually, at least for Prologue - Chapter 2, I can definitely attest to this. I went to move enemies around and I realized I really couldn't place them anywhere else without making the level design WORSE. The pacing feels nearly perfect on these maps, and it feels like I would be just moving the enemies to move them. I might slightly change the terrain in the maps so I can give them a slightly different feel instead. Since the upcoming KoT patch (yes, I might have to change the name because people might confuse it for Kitty of Time, I know) is modeled after the Shin patch, this will work.

Ah, damnit. I've actually been working on working on reviving an old FE8 patch that focuses around balancing all characters/stats/classes/etc., making some engine changes, bumping up the difficulty (not just by bumping up stats, mind you, but character placement and maybe some map changes), and adding a couple maps/characters/classes. Been doing it for the last couple of weeks. Now I need to figure out how to differentiate the KoT Patch from this project, because I'm not just dropping it. :>

C:\EnterStuffFromMyComputerHere\Hextator's Doc\Media\Games\Console\NGBA\Fire Emblem\Misc FE Stuff.txt At least from the folder of Hextator's doc I got from the one linked in the "Tony Mode" thread recently posted. EDIT: Crap, realized there was a minor typo on the code for LUK/3. Sorry, I was tired when I made the thread and posted the wrong picture. It will be fixed presently. EDIT2: Alright, fixed. EDIT3: Links to .dmp files are up! Using dropbox for them.

I'll be honest. I did it this way because I failed at file hosting, somehow. I'll try to add the .dmp file later today. EDIT: You're right; it is actually a really simple mod -- the actual coding was a joke. It was learning ASM, figuring out what the hell the ROM was doing and how it worked, and finding the proper offsets that took like 99.99% of my time.

IMPORTANT EDIT: Links to .dmp files are up! You can find them in the spoilers with the .asm code down below. Using dropbox for them, so it should work. Please tell me if they don't! So basically this is my first ASM hack, so don't get too mad if it isn't the most efficient thing ever. However, this SHOULD work without any problems (i.e. if, for some freak reason, it does something weird, PM ME ASAP with the bug and I'll fix it). In most Fire Emblems, I always felt LUK tended to be a lackluster stat in general, being only necessary to have just enough in order to reduce enemy crit chance (most of the time) to 0. In addition, I noticed that, as you went through the game, dodge outscaled crit, since 1 LUK reduced enemy crit chance by 1% but 1 SKL only gave 0.5% crit. You could skirt around this by gradually making B and A rank weapons crit chances, but that causes a who slew of problems (esp. if somebody reaches A rank early in the game and gets their hands on a A rank weapon), or by forcing enemies to have low LUK (which might make the game easier than you want). You might ask, why would crit not scaling as fast as dodge be a problem? Well, classes like swordmasters are balanced around having only one weapon by getting an extra 15% crit; however, if dodge outscales crit (to the point where people might have 10+ more dodge than crit w/o weapon or support bonuses), this actually can effectively lower that bonus to 5% crit or even lower at very late game (however, simply setting the 15% bonus notably higher to compensate is not a good idea; to see why, see FE6 Rutger). I found this unacceptable, simply because only having one weapon can be a serious handicap (especially if your game happens to have reaver weapons) and should be counterbalanced appropriately. I found two possible (and very similar) solutions, both of which have some justification: A) Make crit scale with LUK/3. With two units at 30 SKL/30 LUK, the Crit will be exactly 5 less than Dodge -- however, S rank bonus gives 5% hit and 5% crit, so it all works out in the end. However, units with S rank will have slightly inflated crit chances and units without it will have slightly deflated crit chance mid-game. B) Make crit scale with LUK/2. Similar to option A, but it means you don't NEED S rank bonus to make up the difference. I tend to like this option more because crit scales at the same rate as dodge on average. However, you'll have to deal with a baseline 3-5% crit chance if units are attacking with their S rank weapons unless you also modify S rank bonuses. I will personally use this option and then probably make S rank give 10% hit instead of 5% hit/5% crit, thereby solving all my problems. (However, I don't know where the S rank bonus is coded for crit and hit, so if anybody DOES know and tells me, that would be cool and save me some time). ANYWAYS, enough blubbering. Here is the code! It's designed for FE8 atm, but I doubt that it will be hard to make it work for FE7 since the engines (for crit, at least) should be similar. [spoiler=LUK/3 Code] .dmp link: Click [spoiler=LUK/2 Code] .dmp link: Click [spoiler=Instructions for Applying Patch]1) Open HxD; load my ROM and the .dmp file. 2) On .dmp file, highlight all numbers from offset 2AC28 to 2AC2F. Press "Copy". 3) On ROM, highlight all numbers from offset 2AC28 to 2AC2F. Press "Paste Write". You HAVE to include that "00" byte at 2AC28 or it WILL crash. That "00" byte is actually partly responsible for directing the ROM to read my hack instead of a random section of code that causes it to crash. 4) On .dmp file, highlight all numbers from offset 2AD26 to the end of the file. Press "Copy". 5) On ROM, highlight all numbers from offset 855060 to 85507B (for LUK/2) OR 85507F (for LUK/3). Press "Paste". 6) Load ROM and make sure right patch is applied and that it works. Please let me know what you guys think of it and PLEASE let me know if you can't get it to work. I hope you guys find it useful. P.S. If you REALLY want to go wild, I *THINK* you can make just about any stat on a character affect crit chance in the same way. All you need to do is replace the #0x19 on line 25 with one from this list (copied from Hextator's doc). For example, I'd imagine you can replace it with 0x08 to make it scale with level and then combine it with that hack that doesn't reset level on promotion. Or, just looking at this list, if I could find somewhere where the type of weapon equipped is stored, I could theoretically alter and expand this code to make it give crit based on the weapon level of your equipped weapon -- i.e. D rank gives 1 crit, C rank gives 2 crit, B rank gives 3 crit, etc.; essentially, I could make it so that the S rank bonus happens gradually. [spoiler=Ze List]0 Portrait 4 Class 8 Level 9 Exp 11 Slot mod 12 Turns used Subtract two from each of the following for FE 6: 16 Horizontal Position 17 Vertical Position 18 Max HP 19 Current HP 20 Str 21 Skl 22 Spd 23 Def 24 Res 25 Luck 26 Con bonus mod 27 Traveling mod 29 Move bonus mod 30 Item pointer slot 1 31 Uses left item 1 ... 40 Sword Level 41 Lance level axe, bow, staff, anima, light, dark 48 Condition mod 50 Supports 60 ???

Sorry for the late delay, but I FINALLY got it all ironed out. Yes, the patch is done! After this much effort, I might post my code here in on Serenes for people to use/test. I have two versions: One that adds (LUK/2) to the crit chance, and one that adds (LUK/3). It's a bit sketchy how I got around all of the technical difficulties, but it seems to work perfectly -- I have yet to get it to act weird, but it's still possible. Special thanks, of course, to Burning Gravity and CT075 for making this possible, and for the patience to walk me through my first ASM hack. When I finally get around to posting the thread for my remake, you guys will definitely have your own special section. EDIT: Oh yeah, it turns out that CT075 was right the first time; it is r0, =Lucky. What seems to have happened is a limitation of the .org format, although it's hard for me to explain. [spoiler=Me Failing to Explain]As CT075 said: ldr r0, =0xDEADBEEF is pretty much the same thing as ldr rY, [pc, #0xNN] @ 0xNN bytes later .long 0xDEADBEEF From playing around, it seems that the two bytes in Hex end up being MM 4X. It looks like the system basically says "Alright, after [2 + (4*MM)] = NN bytes, treat the next four bytes as a word and load it to the register in question." It seems that the fourth digit, X, is used to determine which register is used. The Assembler looks like it is sticking all the .long 0x00000000 at the end of the code for the ldr opcodes and then putting in values of MM to make it work. The problem comes with the fact that MM is only one byte, which means that the distance it can go to pull up the .long is very limited. For almost all hacks (i.e. those added to the ROM rather than REPLACING CODE IN THERE), this would never come into play, as they would never be long enough to run into the problem. However, since I'm putting in the ldr & bx at offset =0x02AC24 but inserting the main section of the code at offset =0x855060, the assembler is sticking the .long at the end of the code around =0x855089 but trying to link it to the ldr at around =0x02AC24, which isn't going to happen. This means that I have to insert the .long called by ldr manually, tell the assembler that the main section of my code is close to =0x02AC24 (but it's not) so it won't go berserk, paste the code from the .dmp file instead at =0x855060, and then go into the Hex editor and adjust MM so that the ldr properly calls the .long I inserted into my code instead of whatever the assembler told it to do. Not that big of a deal, IF YOU KNOW WHAT THE HELL IS GOING WRONG. I didn't. And this is why I thought bx had a limited range. Essentially, it wasn't bx that was the problem, it was the limitations of ldr rY =0xDEADBEEF and the way the assembler coded the .dmp file that was giving me shit. I think. On a side note, I just read through this and realized that a week ago I didn't even know what ASM was. Yay for the Ultimate Tutorial and people willing to help me out~

Yep, works now. All the code has transferred perfectly except for this =0x08855060 part. Basically, I'm taking the hex values from the .dmp file and copying and pasting them in the proper sections of the FE8 ROM. Unfortunately, everything is transcribing perfectly (checking the No$GBA debugger) EXCEPT for that one line. Essentially it's transcribing the opcode as ldr r6 =#0x43086AA1 instead of ldr r6 =0x08855060. Don't know why this is happening, but once this is fixed, my hack is officially finished. I am, however, confused as to exactly ldr works. How can you allow for every permutation of every word you can load in only...two bytes?

This worked perfectly. Thank you! For this code, I'm having one last problem (I know, I know, but basically I can't imagine anything going wrong past this): [spoiler=My Issue] This is the code based off of revisions you gave me (sorry, the .org 0x02AC2A in this pic should be 0x02AC28): Those two lines of code? I'm trying to add them to 0802AC28 -- I'm utilizing the fact that, when this ASM is called, r1 stores base crit and r7 stores the offset where the character's stats begin, which I'm about 75% sure will work since I don't push either r1 or r7. Here's a pic of the ASM code around where I'm trying to stick the bx opcode: It gives this error message: Am I trying to branch too far even for the "bx" command? And if so, where can I find room in the ROM that is closer to 0x02AC2A (or at least close enough to branch to)?

Yeah, I'd rather not have to rely on somebody else to assemble, but if I have no other choice, I don't know what else to do. Sad part is I get the exact same problem when I try it on my other computer. Is devkitPRO the only thing that needs to be installed for this assembler to work? EDIT: On a side note, is there anything really fishy with this code? Should be pretty simple, but I'm not *entirely* sure about a couple aspects of it. It's essentially what I'm trying to insert. .thumb .org 0x02AC2A bl Lucky @0802AC2A is the area near where crit formula is calculated Initial: .org 0x855060 (I THINK this is free space on the ROM) Lucky: push {r4,r5,lr} @Safe to push these add r1, r1, r2 @First two lines asr r1, r1, #0x1 @Are from old program ldrb r4, [r7, #0x19] @r7 is where character's stat starts at 0802AC2A; 0x19 is to pull up LUK mov r5, #0x5555 @0x5555 is approx. 2^16 divided by 3 mul r4, r5 @Multiply r4 by r5 lsr r4, r4, #0x10 @Divide by 2^16, these three lines effectively divide r4 by 3 add r1, r1, r4 @r1 is base crit, r4 is extra crit from LUK pop {r4,r5,pc} @Standard pop bl Initial