Tequila

FEditor is often buggy, yes. Despite that, I don't think that's the problem here. What did you change the text to? And did you include the [X] at the end?

Looks like you've got a manageable idea here (20 chapters + final, 40 characters, seems quite reasonable) (assuming this isn't an April Fool's joke). Here's how I would do things (caveat: I've never actually completed a hack aside from some single-chapter stuff, so take this advice with a grain of salt.) Story outline should be first. Character motivations, plot, enough world-building to be able to figure out how the maps are gonna go. Leave things like dialogue and supports for later. Next, a map outline. Pencil and paper is fine here; you don't have to make the actual map. What you want to define are things like general starting positions for allies and enemies, terrain that dictates how the battle will flow, and the map's objective (very important). Now that you have an idea of maps and what should happen on them, actually make the maps (I recommend Tiled) and write the corresponding events. If you need assembly modifications (like the stealing un-equipped weapons things), add those here too. What I'm trying to say is that while it's nice to have everything planned out and written down before you actually start hack, it's not terribly practical. First, it's easy to get bogged down in details (especially writing-related ones). Second, and more importantly, things will change. This is a guarantee. Perhaps you'll find that a character you thought essential to the story actually doesn't add anything new, and scrap them. Perhaps play-testing will reveal that the growths and bases you so meticulously theorycrafted don't work all that well. Or maybe (and this might not be an issue here, since what you're proposing seems fairly reasonable so far), you'll run up against a limit that you simply can't get over. Things like GBA hardware limits, or being unable to find someone to do the assembly modifications you want, or just plain not having the time to work on your project. For this reason, I feel it's best to get a game framework down and then go back and touch it up. Another good reason to do things this way is because (and there's no shame in this) you may find you can't do this all alone. If/when that time comes, you'll probably post here something along the lines of 'I'm working on a hack, but I would like someone to help me do portraits/animations/whatever'. If you already have a skeleton game that you can make a patch for and prove to us that you're actually doing work, you will be much more likely to find people to help you. So don't stress about portraits or animations; just use the vanilla ones (or the open source stuff that's lying around) and touch them up later. Want custom music? Assembly? Same deal. You're generally expected to do your own events (and, to a lesser extent, writing), so you should focus on getting familiar with that. Even that doesn't have to be a polished product; just show that you've got something. Also very important: Be willing and able to accept criticism. Especially on the art side of things, since that's quite subjective. Your hack will not be a polished product from the get-go. There's nothing wrong with that. But you have to be willing to change things that need changing (that's not to say that you have to make every edit that everyone suggests, but if you choose not to, you should have good reasons as to why). Now, as far as XNA goes: don't count on it being out. And even if it is, the experience you'll get from hacking FEGBA will only help you in the XNA department. A misconception that many people seem to have regarding XNA is that it will have the equivalent of a Make_Hack button; you feed it a script and you get a completely finished game with a little ribbon on top. This is not the case. All XNA does is remove the limitations that GBA hardware imposes, and make it easier to code certain things. But the underlying logic of, y'know, actually making a game, remains more or less the same. So go ahead and jump right into romhacking. It can't hurt. As far as getting started goes, I'm sure you've heard of the Ultimate Tutorial. If you've never hacked before, this is a good starting point. Do note that while the concepts are the same, the actual hacking is different nowadays (especially with regards to FEditor, which has a, shall we say, reputation). That said, FEditor's fine for learning; try to insert some text or a portrait, by all means, but don't use it for a serious project. Once you think you're ready to get started, check out this video to be introduced to the quasi-wonderful land of buildfiles. The reason I say quasi is because while EA is powerful and versatile, buildfiles are not intuitive to the newbie hacker, and the documentation to make it intuitive hasn't been written yet (we keep getting distracted, sorry). Also, no fancy UI like FEditor has. But did I mention it's powerful and versatile? Because it's powerful and versatile. Really. FEU is your key to help, here, and we have a discord as well, which isn't hard to find. As far as story criticism goes, I don't have much to say other than 'it looks fine'. I especially like the fact that you've planned 10 chapters per route; it's a very reasonable number and ensures that you're more likely to actually complete the hack.

That would be me. GREETINGS, FLESHLING.

Managed to isolate the issue; it was actually Talk that was the problem. It was trying to loop through non-existent chapter data. Should be fixed. Also, might I recommend adding this?

Uploaded to the FEU Unified Hacking Dropbox: https://www.dropbox.com/s/3lugimvb77ym82r/MarkyJoe Tiled Tutorial.zip?dl=0

Then don't make a large one. Make something 7-10 chapters long. Is it going to be a groundbreaking story that no one's ever done with amazing gameplay that everyone wants to replay over and over again? Probably not. But it'll be complete. And that is something that a great many hacks out there have not achieved.

And what exactly are you doing to trigger the freeze? Is it for all characters or just one?

You'll have to be a bit more specific; I'm not seeing any issues. Which menu and which character(s)?

Text in the rom is Huffman encoded, which is a very common compression scheme. Both FEditor and text2ea (the new way of inserting text) don't bother with Huffman encoding and just enter the strings in the rom as-is, so the game needs a way to determine whether a text is encoded or not, and what to do with it if it isn't. Hence the patch.

First, take the typeless file that FEditor spits out (it doesn't have an ending) and drag and drop it onto AA.exe. That will create a big .event file (which you can open in a text editor like notepad). Open up that .event file. There'll be a line near the top that says "AnimTableEntry(0x0) //CHANGE THIS TO THE SLOT YOU ARE REPLACING". Change the 0x0 to the index of the animation you're replacing (that would be the Input index in the Class Animation Editor in FEditor). Open up Master Animation Installer.txt and #include your .event file. NOTE: EA does have a problem with labels being too long, and when making the .event file may hit the limits. I don't know the exact number offhand, but try to keep the name of the original file (from FEditor) under ~12 characters or so to avoid this issue. And make sure it doesn't have any spaces (I don't know whether Circles fixed that one or not).

Patch the .ups file with a ups patcher (I, and many others, use NUPS) to whatever ROM is required (Circles/Zim/mine all use FE8, while I think Coby/Pwntagonist's uses FE7, and I have no idea how to patch the FE1 entry, sorry).

Mod reasons (I forget exactly why), and probably never, unfortunately.

I've never used this in Nightmare, but it seems to be you could just add that 5th one on the next page. The delimiter (the thing that tells the game it's reached the end of the list) for this table is 3 0x00s in a row, I believe, so if the next entry begins at 0xFFF840, you should be fine. If you need to add another set of animations for a class, just make sure you skip a block.

Chiming in to say that while the theory is fine, the numbers are not; we're dealing with a bitfield, so all the values will be powers of 2. Fire lock = 0x2, Thunder lock = 0x8, Wind = 0x40; together that's 0x4A.

Then you may want to refer to the old Ultimate Tutorial. The theory is still more or less accurate, although certain methods are a bit outdated, but it's nonetheless a good starting point. If you're just starting out, go ahead and play around with Nightmare and Feditor and the like; make a short 1-chapter hack to get used to things, etc.

FE8 is best. Do you have any experience with romhacking at all?

Which Nightmare are you trying to use, 1 or 2? If 1, just run Nightmare.exe. I've not used 2 in a very long time, but I think it's the same; at the very least, something should open. Wrt Feditor, open up the Dist folder and double click on Feditor Adv, the executable jar file. You have to have Java installed (I believe) for it to work.

Whether a character is ally/enemy/npc depends on events, not on their character data. The theoretical maximum number of player characters at once is 64, but I believe the actual number is somewhere around 50, depending on the game. So I guess the answer to your question is 'yes'.

Repoint and expand the item table (809B10 in fe8), and use Nightmare or nmm2csv to add your new items.

Sounds like you want Palette -> Requantize.

Yeah, and check in between to make sure each inserted one works properly, so you're not wasting time.

What Kirb is (unhelpfully) referring to is this. FEditor is known for being, shall we say, difficult; however, the animation assembler won't help for fe6. Did you try adding them all at once, or one at a time? If not the latter, try that. Otherwise, all I can suggest is opening the rom, saving, closing, and then add the animations again, one at a time.

Not sure about the music part, but stat boosts for weapons work the same way as FE7/8. In the item editor, give the weapon a stat boost pointer (should be byte 0xC) and then write your bonuses out at the location pointed to in the usual order (hp, str, skl, spd, def, res, luk).

Try the other way around, then? I dunno, I've never done maps with tile changes.

I think that the 'village saved' map tile change layer has to be above the 'village destroyed' map tile change layer in Tiled.