A Guide to Modification by Hex

Tutorials
1

Ancient, but could be useful.

This is Icy Toast’s original tutorial, a guide to most everything he knew. This was an absolute must-read when it came out, it’s impact was huge. Without Icy Toast’s enormous advances, I doubt FE hacking would be anywhere near the level it is today. So without further ado, I present A Guide to Modification by Hex, copied word-for-word.

~ PROLOGUE: Getting Started ~

There are a few things that need to be said first. One of them, a rather important one actually, is this:
DISCLAIMER: Fire Emblem and all related characters, locations, names and whatever else are property of Nintendo and Intelligent Systems. Also, should anyone believe that their (possibly copyrighted) work has been used unrightfully in this guide, I’d appreciate it if they could contact me about it so that I can credit them/remove it.
Well, that’s that. =P
Secondly, you should remember that this guide won’t be complete and doesn’t aim to be so. I’m just providing this as a starting point for people to learn how to modify FE games by hex. After reading all of it, you’ll probably be able to find out many more things on your own. By the way, with ‘a starting point’ I mean, all the way from the start, so everyone should be able to understand this stuff, in fact. If you don’t understand it, it’s not because you’re not talented enough or anything, it’s just because I suck at explaining things. So… feel free to ask questions should anything be unclear.
The next thing that needs to be mentioned is the fact that although my guide will completely focus on modification of FE7, much of it can be applied in (almost) the same way to the other gba FE’s, except the locations of most parts of the data are different.
Finally, this chapter is called ‘prologue’ for a reason: it’s not one of the real chapters. It’s there only to explain the basic knowledge you should have to understand the chapters that are still to come. If you already have some experience with hex editing, you can just skip all this. If you don’t, well… I advise you to read it very thoroughly. ;D

What you will be needing

  • An FE7 (US) ROM. The reason should be pretty obvious. Remember though, that owning a ROM is illegal, and that you should really buy the original games to support their creators. But yeah, I suppose everyone already knew that. XD
  • A hex editor. I bet that surprised you all, didn’t it? Anyway, I personally recommend googling and downloading both WindHex32 and Cygnus Hex Editor 2.5. The latter can only be used freely for 30 days, but there… ehm, might just be a way around that. Of course I won’t be telling you, but… well, let’s just say it’s got something to do with your computer’s clock. >_> If you prefer not to taint your moral purity, just stick to WindHex, or any other hex editor you like. In this guide, however, I’ll be using Cygnus in a number of examples, and I’m afraid it’s almost a necessity for custom map coding.
  • An IPS patcher/patch creator. I highly recommend StealthPatch, since it allows for expansion of the file being patched, which is a great advantage, to say the least. Again, just google it to find out where to download it.
  • Nightmare and some FE7 modules. While not absolutely necessary, having these would be a plus, but I assume most of you will already have some anyway. If not, find them at FESS. (Download my modules here)(Link is dead)
  • Unlz-gba: Only needed for graphics editing, but it’s an awesome tool. Once more, google is the key to finding it. =P
  • Tile Layer Pro: It might be called ‘Pro’, but it’s really a free program, so don’t worry about having trouble to find this. It allows you to view a file’s code with the bytes showing up as coloured pixels, effectively enabling you to view and edit uncompressed graphics in the ROM. (As opposed to Unlz-gba, which lets you edit compressed graphics only)
  • Mappy map editor: Not an absolute must, but it’ll save you many hours of work in the map programming section, so… find it and download it. Oh! And don’t forget to also download the FE7 tilesets here (updated with my link).
  • The FE7 parser (by Twilkitri): Only needed for text editing. It allows you to change the script and it recompresses and inserts it into the game for you. An amazing tool, but unfortunately, it’s not publically available. Or maybe I should say, it’s not supposed to be publically available… since in fact, several links to it can be found in old topics at FESS. Good luck finding them. ;D
    As an alternative to the parser, you could also try Zeld’s Anti-Huffman patch (to be found at FESS as well), which allows you to edit text directly in a hex editor. I’ve never worked with it myself, but apparently it does the job pretty well, so you might consider giving it a try.

The hexadecimal editor & system
Now that you (hopefully) have all you need, it’s time to run your hex editor and open the Rekka ROM. If all goes well, you should now see a bunch of seemingly illogical numbers and letters on your screen. In most hex editors, you should see three columns, the middle one being the widest. This middle column shows you what it’s all about: the 16777215 bytes that together make up one of the greatest games ever to exist. ;D

Depending on your hex editor and its settings, the middle column will show data in groups of either 2, 4 or 8 digits. One of the first things you should know, is that, in any hex editor, every 2 digits represent a byte. Let’s take a closer look at how this works.

Most likely, you’ll already know that a byte is made up of 8 bits, each of which can store a value of either 0 or 1. Together, this makes a total of 256 combinations for each byte, ranging from 00000000 to 11111111. This way of describing values is called the binary system, as there are only two (=bi) possible options for each digit.
Let’s compare this to the system we normally use: the decimal system. In the decimal system, we have 10 different possibilities for each digit in a number (hence the name), namely 0, 1, 2, 3, 4, 5, 6, 7, 8 and 9. Once we’ve had those ten, we just start over with a 1 in front of, then a 2, then a 3, and so on, until we reach 99, after which we start using a third digit. This should all sound terribly familiar, so why am I telling you this?
Well, in fact, it’s because the hexadecimal system is just the same thing, except there are 16 different options for each digit. These are represented by 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E and F. After that, counting in hex continues with a 1 in front of it, then a 2, … then an 8, then a 9, then an A, then a B… until we reach FF. See? It’s not at all hard to understand hex. (Note that although FF is the 256th possible value, it corresponds to 255 in the decimal system, since 0 is also a value.)

Now how does this relate to bits and bytes? When studying data in a hex editor, we want to be able to see the value of each individual byte. Of course, it might seem logical to make up a symbol for all 256 values a byte can store, so we can read the value of all of them, but since this would require learning 256 different symbols, this wouldn’t really be practical. On the other hand, if the hex editor would show every byte as the collection of 8 bits it actually is, thus only utilizing two different symbols, it wouldn’t be much clearer, as this would mean a lot of trouble if you wanted to decipher the actual (decimal) value of the byte from the 0’s and 1’s. That is why a middle road has been chosen. As it happens, half a byte, which thus consists of 4 bits and is often referred to as a nibble, can take 16 different values, ranging from 0000 to 1111. As 16 different values per digit, or a hexit, as it is also called in this context, is a manageable amount, each nibble is represented by a digit in a hex editor, so every pair of digits is a byte.

Look at the very first byte in the Rekka ROM; it says 2E. As you just learned, 10 in hex is 16 in decimal (since 0F = 15 and 10 comes after 0F), so 20 in hex is 32. It shouldn’t take much effort too figure out that E represents a decimal 14, so the 2E byte stores a value that would be represented by 32 + 14 = 46 in the decimal system. Don’t worry about having to calculate this stuff though, you won’t often need to do that. Still, it’s useful to be able to convert hex to decimal and the other way around, since it helps you to spot/edit things that represent an actual decimal number in the game, like character stats.
Here are a few numbers in both decimal and hex that are helpful to keep in mind:
hex 0A = dec 10
hex 10 = dec 16
hex 32 = dec 50
hex 64 = dec 100
hex 7F = dec 127
hex A0 = dec 160
hex FF = dec 255
Obviously, values exceeding FF are stored using more than one byte. There’s one catch to this though; those values taking more than a single byte have to be read by reversing the bytes. So a value that shows as 5A 8B 9F in the ROM, is to be read as 9F 8B 5A, which is 10455898 in decimal. Again, don’t worry about this too much yet, you won’t be needing this all that often. What might be good to remember though, is that a group of 2 bytes is referred to as a ‘half-word’, and a group of 4 bytes is referred to as a ‘word’.

Now that we’ve had all that theoretical stuff, let’s continue our guided tour of the hex editor itself. The column to the left of the actual data should show something like:
00000000
00000010
00000020
00000030
…
If it doesn’t, set your hex editor to display 16 bytes per row to fix it.
The numbers shown here are the addresses (also called offsets) of the first byte for each row. Each byte after that is obviously the address plus 1, but you should keep in mind that addresses are given in hexadecimal. The addresses are there to make it easier to refer to a certain part of the data, and you’ll soon be very thankful your hex editor shows them.

Finally, there should be another column at the right that shows lots of text, numbers, other kinds of characters and simple dots. This is the ASCII representation of the file. In other words, that’s what the file would look like if it were a text file. Usually, there’s very little of interest to see there, but at some points in the ROM, it allows you to see things you’d otherwise overlook. If you’d like to see an example of this, go to the offset 00FD8000. Each line here is partially written in ASCII, namely the names of a number of characters, and the other parts tell the game some vital information about that character’s battle animation, so having the ASCII column allows you to see which data is about which character. I won’t go into detail about this right now, but the thing you’re supposed to remember about this, is that the ASCII column can at times come in very handy.

Well, I’ll leave it up to you to explore all the awesome buttons of the hex editor yourself, but some you should definitely take a look at (if your hex editor has them) are the bookmarks, search and goto functions. They’ll be able to save you lots of time in the near future. =P

Pointers
Now that you’ve learned a bit about how to use a hex editor, you probably think we can now start doing some actual editing, don’t you? Wrong. There’s one extremely important thing you should learn first, and you’ll need it for almost everything this guide will cover. Pointers.
A pointer is a small group of bytes, in Rekka’s case 4 bytes long, that does exactly as its name suggests. It points to another location in the ROM, or possibly even a location outside the ROM, like the gba’s memory. We won’t need to go into detail about the latter though, so I’ll stick to pointers pointing to places within the ROM here. Anyways, there are loads of pointers in the ROM, and you’ll need to learn how to read and formulate them if you want to get any further than the simple stuff.
Basically, a pointer is the exact address of the data it points to. The thing is, the bytes are reversed. This is not always the case, but in Rekka (and the other gba FE’s for that matter), it is. Also, 08 has to be added to the first byte of the offset, which has become the last byte in the pointer. Confusing? Nah, you’ll get used to it sooner than you think. And anyway, the 08 at the end of every pointer (since all adresses in Rekka start with 00, unless you expand the ROM) is really helpful as it allows you to quickly recognize pointers between other data.

Let me give you some examples just to get the hang of it.

Let’s say we have data at offset 00C9AB34, and we need a pointer to this data. First, we mentally separate the offset into 4 bytes: 00 C9 AB 34, and then we reverse them: 34 AB C9 00. Now, add 08 to the first offset byte, which is now the last pointer byte, and you get 34ABC908. There’s your pointer!

As another example, imagine you found a pointer saying “849AFD08”. Subtract the 08 from the last byte, reverse them, and voil

2 Likes
2

~CHAPTER 1: Maps~

I might as well have started this thing with a load of theoretical stuff, but I instead chose for a more practical approach. In fact, you’ll be able to create a (almost) completely custom chapter at the end of Chapter 3. The first thing you need for a chapter is obviously a map, and that’s why this first chapter will be about maps and how to code them.

Map Data
First off, for those who didn’t know, all FE maps consist of tiles, which are squares of (in this case) 16x16 pixels. The game draws these tiles from tilesets (also called object sets) which are collections of tiles around a certain theme. The colours are only applied to the tiles afterwards, so a particular tileset could look completely different in different maps, depending on the used palette. However, each map can only use tiles from one tileset, and can only use one palette.

Before coding your own map data, you’ll need to know how the data is built up. To see an example of what map data looks like, use your hex editor to look at offset 0036AF00. This is the starting byte of the Prologue’s map data. Before the information about the actual tiles starts, there are 7 other bytes. In the case of the Prologue, these are 10 2E 01 00 00 0F 0A. The 2nd, 3rd, 6th and 7th of these bytes differ from chapter to chapter. The 6th and 7th ones are respectively the horizontal and vertical dimensions of the map, measured in tiles. The 2nd and 3rd bytes actually store a single value, so you’ll have to reverse them to read it: 012E. This value tells the game something about how many tiles should be loaded in total for the map, but I don’t know exactly how it works. Anyway, the general formula to find this value for your own maps is: length * width * 2 + 2. You might want to use a hex calculator for this. (Shouldn’t be difficult to find an online one.)

After this, the tiles that are on the map are listed. There’s no reference to their location on the map whatsoever, they’re just listed from left to right moving from top to bottom on the map. Each tile’s reference is just its number in the tileset, and it takes up two bytes (which are, as usually, in reversed order). Note that only numbers ending in 00, 04, 08 and 0C refer to valid tiles, the rest isn’t usable in a map. There’s a good reason for this, but I won’t be explaining it here in order not to overcomplicate things.
Additionaly, there’s a 00 added in after the first 3 tiles’ references, and beyond that after every fourth tile.

As a really random example, a very small map’s data could look like this: (the seperation 00’s are in bold print) (note that a map as small as this can’t exist; every map must at least be large enough to fill the screen)

10 2A 00 00 00 04 05 10 05 14 06 2C 01 00 7C 0D
48 09 2C 0F 64 08 00 A8 04 38 00 08 03 94 0A 00
50 07 90 08 A8 01 A8 01 00 74 05 C8 02 D0 09 D4
09 00 30 0B

By now, you might have noticed that the map data of the Prologue, which we were looking at earlier, doesn’t quite match this format. In fact, none of the actual game maps do, since they’re compressed. Because of that, we can’t just go ahead and change existing maps; instead we’ll have to create our original maps to replace them, but seeing that we were going to do that anyway, that’s not really a problem.

You might also be wondering how you could possibly know which actual tiles the numbers refer to. For that, you could try ripping all the tiles of the tileset you want to use and collecting them into a table like I did with this one… but looking up every single tile of a custom map you want to code in a table like that would require extremely much time, so I’m going to explain a simpler method to you in a minute.

If you prefer just to go ahead and code a map manually, you should be able to do that knowing what you know at this point, but I advise you not to overwrite the existing map data, and to expand the ROM so that you have empty space to put your map code in instead. Repointing the pointers to map data to point to your new map is something that will be discussed later.
I strongly advise you though, to just read on and learn a far easier way.

An all-powerful shortcut…
The easy way I was referring to, involves designing your map in Mappy Map Editor, using the FE7 tilesets the link to which is in the prologue of this guide. How to use Mappy to design a custom map should be fairly clear, but here are a few advices that’ll definitely make life easier:

  • Adjust the tileset window’s size in such a way that tiles like castle’s or villages align in so that you can easily see how to use each tile.
  • First pick a tileset, then start a ‘new map’ and load the tileset again. If you don’t, a tileset might load incorrectly if you load it after loading another one first. It’s not unlikely that you’ll only notice this once you first see your map in-game and realise it doesn’t look at all like what it should’ve been, so I strongly suggest that you pay attention to this.
  • Always remember to set tile size to 16x16 pxls in the ‘new map’ window.
  • Never create maps with dimensions exceeding 43 x 36 tiles, as the game might not be able to load them if you do.
  • Remember exactly which tileset file you used as you’ll need that information later. In fact, you should probably write it down somewhere.
  • Don’t use layers. If you want to use doors that can be opened or walls that can be broken, just make it look the way it should at the start of the chapter, and you’ll learn the rest later. If you want to use removable roofs, I can’t tell you how to do those, since I don’t know it myself. =P
  • Ignore the fact that the animated tiles don’t perfectly connect, since I didn’t rip all of them when they were at the same animation frame.

Once you’ve finished creating a map, export it as a .mar (map array) file. If you now get an error message telling you there are more than 1024 tiles in the tileset, you’ll know that you haven’t been paying attention to my second advice above.

Now, we’ll manually convert this .mar file into the format Rekka can understand. I’ll describe this process step by step to avoid confusion. I’ll use Cygnus here, since I don’t know the exact functions to use in other editors.

  1. Open the file in Cygnus
  1. Choose the ‘Tools->Modify’ function
  1. Set the ‘number of items to modify’ to something high enough so that the entire file is highlighted, set the item type to ‘Word (2 bytes)’, set the action to divide, the action value to 8 and make sure Big Endian is not checked.
  1. Press OK. The hex editor will now divide the value of each pair of bytes by 8. (if it asks whether it should extend the file because your ‘number of items to modify’ was greater than the total file, choose ‘no’)
  1. Insert a ‘00’ byte after the first 6 bytes, and another after every 8th byte beyond that (not counting the 00 bytes you inserted as one of the 8)
  1. Insert 10 XX XX 00 00 YY YY at the start of the file, with YY YY being the map dimensions (in hex!) and XX XX being length * width * 2 + 2 (all in hex). Remember to reverse the bytes!

At this point, your file is ready to be inserted into the ROM. To keep things nice and clean, we’ll just expand the ROM and insert this in the newly created open space. Inserting it can be done by just using the copy/paste functions of your hex editor. Obviously, the game won’t be able to use your map now, since it has no way of knowing it’s there. That’s why we’re going to need to make a pointer to it.
Remember how there’s a ‘map used’ byte in the chapter data? (you could use my NM module to find it) Clearly, this byte is not an actual pointer to the map itself; it’s a reference to a pointer in the pointer table starting at 00C9C9CC. You’ll learn to remember this table’s offset, as a lot of important pointers, including those to tilesets, map palettes and event data are in there.
Let’s say you wanted your map to replace the prologue’s map. As the ‘map’ byte in the chapter data says 04, the fourth pointer in the table is the one you’ll need to change. Make it point to the location of your own map intead of to 0036AF00 like it does right now. Note that a pointer to an expanded area of the ROM will end in 09, since the address starts with 01 instead of the usual 00 (and you have to add 08 to it).

If you hadn’t realised it already, know that replacing the prologue’s map pointer with yours won’t mean that your map has to be used for the prologue. If you want to, you can change the map reference bytes of various chapters’ chapter data around to change which map is used by each chapter.

Finally, change the Object Set, Palette, Tile Configuration and Tile Animations settings in the chapter data to correspond with the tileset you used for your map. (Again, I advise using my chapter data editor). If you’re not sure which tileset or palette it is, check its (=the tileset’s) file name; it matches the values you need to enter.

Changing tiles - about chests, doors and more
Your map is now in the ROM, but if there are chests, doors, villages, snags or walls in it, you’ll have to do some extra things in order for it to work properly. We’ll have to edit, or rather, replace a bit of data that describes which tiles of the map can change to other tiles (like a closed chest changing to an opened chest). It allows you not only to make the door/chest/wall/snag tiles themselves change, you can also change the surrounding tiles, if you want to.

You might have noticed the chapter data byte labeled ‘Triggerable Map Changes’ in my editor. Like a lot of values in the chapter data, this refers to a pointer in the table at 00C9C9CC. This pointer points to the data we’re going to edit now. If the chapter you want to use your map for has a 00 at this byte, just take a reference number from another chapter. Remember though, that if you’re going to make more than one custom chapter, you can’t use the same number twice. (Or… in fact it could be done if you very carefully chose which ones to combine, but I advise against it)

Anyways, let’s take a look at the data these pointers point to. I’ll use the data for chapter 2 as an example here, which is at 00CE1D20 (since the byte in the Chapter Data says 0E, which means the 14th pointer of the table, which points to 00CE1D20).

The data looks like this:

Offset ---- Data
00CE1D00 – -------- -------- -------- 80072C0D
00CE1D10 – B40D280D 30090000 240C0000 300D240D
00CE1D20 – 000D0001 02000000 0C1DCE08 010D0001
00CE1D30 – 02000000 101DCE08 02080102 03000000
00CE1D40 – 141DCE08 FF000000 00000000 00000000

The underlined byte is the byte that the pointer points to. It’s the start of what is essentially a list of all the changes the map could possibly undergo during the chapter. Each element of the list consists of 12 bytes in this format:

GGHHJJKK LL000000 PPPPPPPP
In which:
GG = Identification number (as in, the first element of the list is 00, the second is 01, the third is 02, etc.)
HH = Horizontal coordinate of the top lef tile of the part of the map that changes
JJ = Vertical coordinate (note that coordinates are counted from the very top left tile of the map being ( 0, 0 ))
KK = Horizontal size of the part of the map that changes (measured in tiles)
LL = Vertical size
P = Pointer to the tile references of the tiles the defined part of the map needs to be filled with if it changes

The bold-printed bytes are the starting bytes of each element of the list for the chapter 2 map-change-data. As you can see, the list ends with ‘FF000000 00000000 00000000’. So should yours.
If you read the pointers in the example, you’ll also see that the tile data is right before the list. Although this is always the case in Rekka, it doesn’t need to be so. For your custom map, you might just as well first do the list and add the tiles after that. Remember though, that in any case, the pointer in the pointer table points to the first byte of the list.

Making your own list like this shouldn’t be too difficult, and I advise you to make one in the expansion part at the end of the ROM (if your map already took up all the new space, expand it further =P). Note that the game doesn’t need to know what triggers the tile changes, it just executes any change it can find in the list that includes the tile a chest/door/pick/attack/visit command is used on, at the moment that command is used in the game. This means that the areas of the map that can change cannot normally overlap eachother, or things will go wrong.
The only exception to this rule would be a situation in which the same tiles are changed multiple times throughout the chapter, which is the case in the cutscenes of chapter 2, where the door at the top right of the map is closed at one point and opened at another point. This is why that part of the map is listed twice in the example data above.
Using this for a cutscene is rather tricky though, so I recommend against doing that, but there is another kind of situation in which you will need to include a certain part of the map twice no matter what. I’m talking about villages. Since they can either be visited (so the gate closes), or destroyed, they must be listed twice. The first one is the change that takes place if the village is destroyed, and the element listed immediately after that should be the change that happens if the village is visited. Also, the ‘destruction map-change’ must cover the whole village, whereas the change executed upon visiting only replaces the open village gate for a closed one.

Getting the right tile numbers can take a bit more time than the list, even though it works in the same way as the tile numbers in the map data itself: the tiles are listed in order of appearance from the top left to the bottom right tile of the indicated part of the map that will change.
There are no seperator 00’s at all, as the list already tells the game how many tiles to ‘read’.
Anyways, to find out the tile numbers of the change-able tiles after their change, you’ll need to either consult a table like the one I showed you before (I haven’t made tables like that for every tileset, so don’t ask me for them >_>), or just use Mappy to export another .MAR with the tiles you need to know the numbers of all in one row, and then convert the byte pairs by dividing them by 8 (in hex!) to find out.
Oh, and if a certain tile within the area you indicated in the list doesn’t need to change, you can just put 00 00 in its place.

Once you’ve finished your tile data and the list, repoint the pointer to it (the one in the pointer table, remember?), and your map should now be playable. Unfortunately, your chapter isn’t, so you’ll need to have a bit of patience and wait for the next two chapters before you’ll be able to actually enjoy your custom chapter. =P

1 Like
3

~CHAPTER 2: Units~

The character list, class list, level/allegiance list and the item list were taken (and in some cases slightly modified) from the lists coming with the Nightmare modules downloadable at FESS. Credit to whoever made those lists. (I couldn’t find out who did)

Yay. I gotta love this chapter. There’s very little for me to explain, and loads of work for you to do. XD That is, assuming anyone is actually seriously attempting to follow the steps in my guide. >_>
Anyway, this chapter will cover unit data, which is the data that determines which characters are loaded onto the map, at which locations, with what items, etc.

We’re not going to bother with any pointers this time. Instead, you can just find a bit of empty space at the end of the ROM and put all your data there. The pointers and the events that actually load the units will be covered in the next chapter.

Before you start coding, it’s a good idea to make a list of the units you want to have in your chapter. The unit data contains the following information (so that’s what you should have in your list)

  1. Character
  2. Class
  3. Level
  4. Allegiance
  5. Loading location
  6. Location to walk to after having been loaded (so that’s the actual starting position)
  7. Inventory
  8. AI settings (not for player units, obviously)

Now, to code that data, you’ll need 16 bytes, so that’s one line in your hex editor, for each unit. Units that need to be loaded at the same time should be grouped together, and each group needs to be seperated by a white line ( = 16 times 00).

The 16 bytes for each unit are as follows (in this order):

  1. Character
  2. Class
  3. Leader character (for enemies only, it seems)
  4. Level and allegiance
  5. Loading location X-coordinate
  6. Loading location Y-coordinate
  7. Starting location X-coordinate
  8. Starting location Y-coordinate
  9. Inventory Slot 1
  10. Inventory Slot 2
  11. Inventory Slot 3
  12. Inventory Slot 4
  13. AI byte 1
  14. AI byte 2
  15. AI byte 3
  16. AI byte 4

Once you’ve finished coding all the units you want to have in your chapter (remember that identical reinforcements that appear multiple times only have to be coded once), there’s one more thing left for this chapter to cover. The ballistae, if your chapter is going to have any. To code them, just take some empty space after your unit data (at least 16 bytes after it), and write a code like this for every ballista:

01 XX YY ZZ 00 00

This code loads a ballista at the start of the chapter at a horizontal position of XX, a vertical position of YY, and of ballista type ZZ (34 = ballista, 35 = iron ballista, 36 = killer ballista)

Each one of your ballista codes has to be right after the other, or else the game won’t load them all. Also, ensure an additional 00 is left open at the end of all of your ballistae for the chapter.
Again, don’t worry about the pointers to this yet, those will be covered next time.

4

~CHAPTER 3: Events~

Well… it’s about time to arrange the last few things for your custom chapter to become playable. Not meaning that those few things are unimportant. In fact, the event data - yes, that’s what I’m talking about here - forms the backbone of any chapter. It determines what happens at each point in the chapter.
Unfortunately, event data is fairly complicated when compared to what we’ve been doing so far, and, truth be told, I only know a few things about it myself, really. However, if you want to find out how to program more complex events than the basic things I’m describing here, feel free to explore the existing events a bit . Those start at 0xCA7A40, but for clarity’s sake, I strongly advise you to start making your own events in some empty space instead of replacing the existing stuff there.

Reinforcements
We’ll start with the simplest part: reinforcement events. First off, collect pointers to all groups of units (not the ballistas) you coded in the last chapter. Then, make a code like this for each of them:

32000000 INSERT POINTER HERE 3B000000 0A000000 00000000

It doesn’t matter whether you put all these codes in a row or at completely different places, so just arrange them in whatever way is clearest to you. Erm, yeah, that’s all there is to reinforcement events, really.

End-chapter scene
Since only reinforcement events don’t make a chapter, we’ll at the very least also need to create an end-of-chapter event, which ends by taking the player to the save-screen before proceeding with the next chapter. For the rest, how it’ll look is up to you.

This taking-the-player-to-the-save-screen event is coded as follows:

8100XX00 02000100 01000000 0A000000 00000000

In which XX is the chapter reference number of the next chapter.

So that’s how the end-chapter scene must always end, but what about other things you might want to happen before that?
Let’s say you wanted to have a dialogue right before the save-screen thing. Then you’d have to add
0D000000 XXYY0000 right in front of the other code to load text XX from text bank YY. I know I haven’t explained much about text yet, so don’t worry if you don’t understand it right now.
But what if you wanted that dialogue to be shown with a background behind it instead of the map?
In that case, you’d have to put a 0500XX00 code, in which a different XX will load a different background, right before the 0D byte. If you’re going to have multiple dialogues and you want to return to the map view at some point, you could use 09000000. And if you wanted to change the music too, you’d have to add a 7800XX00 code, with XX being the track to be played.

As you might have guessed by now, there are many more event codes you could use to put together your own cutscenes, but I hardly know any of them, so I can’t really explain them to you either. So if you really badly want to add fancy animations, camera movements, effects or whatever, you’ll have to try and find out the code for yourself. Obviously, the most logical way to do that would be to try locating the event data for an occurence of that event in the original game. =P

The things I’ve described so far can of course not only be used for end-chapter cutscenes, they can be applied to any cutscene occuring at any time in the chapter, including the chapter’s intro scene. However, you’ll have to experiment with that on your own to find out more about the exact structure of the event data; I can’t tell you much about it since I haven’t examined it a lot yet. >_>

Some other event stuff
If you want to have cutscenes for villages, or houses, you’ll also need to create those. You should be able to construct simple ones using the information above. As for item giving, it’s certainly possible, but you’ll have to look for the right code yourself doesn’t know . Sorry. XD

1 Like