Contro's Buildfile Tutorial

Buildfiles are an incredibly flexible method of GBAFE hacking. They give you near perfect freedom in what you can do and how you can do it.
Of course with all that freedom, things won’t be very easy when you start out. But that’s what this guide is here for!

About this tutorial:

In this tutorial, I’m going to teach you the basics of inserting things into your ROM, while walking you through the process of finding information you’ll need and applying it.
Since there are so many different ways to do things with buildfiles, I’m only going to cover one or two, along with how they work, then I’ll let you decide if or how you want to put your own spin on it

The basics:

Ahh yes, the work folder. This is something that you will be familiarizing yourself with very well.
Everything involving the building of the hack happens in this folder. Now, you could start from scratch with an empty folder,
or you could use one of the templates for hacking to give yourself a jumpstart. If you’re starting, I recommend using Mystic’s EasyBuildfile here: GitHub - MysticOCE/EasyBuildfile: Easy, basic buildfile that users can develop from.

If you’re going to start from scratch, these are some common sub-folders that are used:

|-- Engine Hacks
|-- Event Assembler
|-- Events
|-- Graphics
|   |-- Animations
|   |-- Mugs
|   `-- Palettes
|-- Map
|   `-- Tilesets
|-- Music
|-- Tables
`-- Text

For the sake of this tutorial, I’m going to assume you’re using Mystic’s EasyBuildfile.

Okay, now that we have that knowledge under our belts, we need to know about what files we need.
The most important thing for Fire Emblem ROM hacking is an Fire Emblem ROM (FE8 in this case).
We’ve all been through this I’m sure, so I’ll make this short. I can’t tell you where to get a ROM, so you have to get it yourself by legally dumping it. (hear that Nintendo? Now get off my case)

Remember to name the ROM FE8_clean.gba

So now that we have our totally legal dumped ROM of FE8, now we can focus on the Build script (Not the build event file).
This little script normally called something like “MakeHack” automates the process of patching your edits into the ROM while making a copy of the original.
This is really helpful when you want something to be done before the actual building of the ROM. Like processing tables for example.

Now for the build event file. If Event Assembler is where the magic happens, the build event file is the spell book to channel that magic.
From here you get to decide what and where you want things to be. But remember, these are still instructions for a computer,
so you have to play by the rules. What rules? I’ll get into that during the “event language” section.

How to speak Event Assembler:

It’s very important to understand how Event Assembler reads instructions. If you put something in wrong, you’re going to have a bad time.

Here’s some lingo all the cool FE hacking kids are using nowadays

This is where EA is at the moment. the current offset changes as things are done to the ROM, or if you directly go to a specific address. (More on that later)
When ever anything is inserted, it’s data will always be from the current offset, to however much space it takes up.
For example, if the current offset was at 0x20(32 decimal), and I inserted something that was 16 bytes in size, the new current offset would be 0x30(48 decimal)


Bytes are a form of data. Everything in the ROM is in byte form. I’m not going to go in detail about them right now,
but believe me when I say they’re VERY important.

In Event Assembler, bytes can be read in decimal form (0-255), or hexidecimal form (0x0-0xFF).
However, when going into the ROM, everything’s going to be hex…unless you’re editing the ROM as binary or something (Please don’t)


Shorts are pretty much two bytes back to back. If you need to use bigger numbers. Shorts are the next step up from bytes.


What’s better than two bytes? FOUR bytes! Words are four bytes long, so they’re also two shorts in length.


Labels are used to well, label things. Instead of having to remember where every little thing is, you can just reference labels to tell Event Assembler you want to use what’s in that particular label.
The syntax is as follows:

<Things you want in the label>

Let’s just say that you have a byte of data you want labeled. This is how you’d do it:

BYTE 0x64

It’s very important to keep in mind that labels may not have spaces in them, and a colon must always follow the label’s name.

Now let’s talk about some of the things that you can do with an event file.


#include <File name>

This is used to add other event files to the event file “tree”. For example, if you had an event file that adds a portrait of Eirika with green hair, and another that Replaces Determination with Ode To Joy, they could be added to the ROM buildfile by “#include”-ing them.

One very important thing to remember is that if you want an event file to be used, it must either be included in the build event file, or included by a file already included by the build event file.


#incbin <.dmp file>

#incbin” is pretty much like “#include”, but for .dmp files. It basically just dumps the contents of the .dmp file into the ROM starting from the current offset

.dmp files strictly work on a raw hex basis, so unless you know what you’re doing, you shouldn’t edit them.

While including .dmp files can be helpful there are times when something called macros can be easier, faster, and more reliable than than using .dmp files. But there are times when .dmp files work best. We’ll be looking into that later.


#incext <executable to run> <Possible arguments> <File to run on>

So, this one is not so simple considering how much you can do with it. There are some tools that come pre-packaged with Event Assembler that you can use right from the event files themselves.
Say I wanted to compress an image with the Png2dmp program, and then include it. I could do that from within an event file by typing: #incext Png2dmp "myimage.png".

There are many other things you can do with “#incext”, but it’s better to talk about them when they’re relevant.

One last thing of note: you can run these programs yourself and “#incbin” the resulting .bin files so Event Assembler won’t have to do it every time you build your hack. This saves on build time. (I’ll demonstrate this later)


#define <New something> <Old something> | <Name(Arguments)> <Things for definition to do>

#define” is used to either define something, or run a set of instructions easily with one command.
Say I wanted To call Seth something other than 0x02, I could type #define Seth 0x02 to do that. The same applies for lots of other things too.

The second use I mentioned works something like this: #define AnimPointer(Type,Type_Designation,AnimID) "BYTE Type Type_Designation AnimID 0"

This thing right here is what’s known as a macro. Macros are used to turn what would be tedious, and repetitious into something neat and managable.
If you’re curious about this macro, it’s for animation pointers, but I’ll get into that later.


#undef <Definition>

#undef” reverses what #define does, so the definition no longer exists.


#ifdef <definition>
Runs the following instructions if the specified definition exists


#ifndef <definition>
Runs the following instructions if the specified definition does not exist


Runs the following instructions if the previous check was false


Marks the end of a conditional.


ALIGN <Integer>

This is a simple one. Whenever you insert something, it’s placed in a hex address that the game looks up when it needs to.

Trouble is, you can’t just have the inserted things be in odd alignments. Generally, it’s always a good idea to have your
inserted items be in addressed that are multiples of four. That is what “ALIGN” is for.

“ALIGN 4” for instance, places enough blank space for whatever that comes after it to start at an address that is a multiple of four. We’ll see examples of this later, but trust me when I say “ALIGN” extremely useful.


BYTE <byte>

Inserts a byte. eg. BYTE 0x40


SHORT <two bytes>

Inserts a short. eg. SHORT 0x1800


WORD <four bytes>

Inserts a word. eg. WORD 0xDEADBEEF


POIN <address>

Pointers are very important since they well, point to things. There are sometimes when using a direct address just won’t do.
In normal cases (Or if you’re changing the game’s code) pointers are used to tell the game where to read data.

Say you had Seth’s data. The game would need to check it constantly, so instead of putting it in different places, it’s stored in one location that every function can look at after they point to Seth’s data.
Kind of like a library. Instead of having copies of all the books in everyone’s house, they’re stored in one place for everyone to find.


ORG <address>

Say you want to jump to a specific place in your ROM. ORG is how you’d do it. ORG jumps to the specified place in the ROM, and any data you add will be inserted starting from that location.



One thing you might have noticed with ORG is that there’s no way to go back to where you jumped from. That’s where PUSH, and its partner POP come in.
PUSH saves the current offset for you, so you can go back to it later.



POP on the other hand, sends you back to the offset that was PUSH-ed.


PROTECT <startOffset> <endOffset>

While ORGing everywhere, and installing hacks from others, it’s quite easy for things to overlap and cause problems.
PROTECT tells EA to keep the addresses between startOffset and endOffset in mind in case some other thing tries to write there. If this happens, EA will give you an error and tell you what’s trying to write to the PROTECTed address.

ASSERT <offset>

ASSERT <value>

Throws an error if the given value is negative. This is useful for making sure you aren’t inserting data past a set point.
For example, if currentOffset was 0x400 and the end of your free space was 0x200, you could

ASSERT FreeSpaceEnd - currentOffset

and you’ll get an error. If currentOffset were 0x150, you would not get an error because 0x200 minus 0x150 is not negative.


MESSAGE <text>

This outputs a message consisting of what you want. You can even put definitions in here so you can see what’s what when troubleshooting.


WARNING <text>

Does the same as MESSAGE, but displays itself as a warning instead.


ERROR <text>

Does the same as the last two with one twist; If you get an error, Event Assembler stops. This is very nice to make your own errors to suit your own needs.


Like with anything, people who use buildfiles have certain methods to improve the usability and readability of their buildfiles for themselves and others.
You don’t need to do these things for your buildfile to work, but doing them will make using buildfiles much easier and more organized.

ALIGN 4 your labels

This one is very important.
Almost everything that gets pointed to needs to be either 2-aligned or 4-aligned. Since 4 is a multiple of 2, we just ALIGN 4 everything.

Use definitions

It’s much easier to remember names than it is to remember numbers so when you can, use definitions to help keep things straight.
They also make changing things later easier since you just have to change one definition and not a single number in multiple places.

Don’t use spaces in filenames

Lots of computer stuff don’t like spaces in filename, so it’s generally better to avoid them.
(Not having spaces also lets you use make in the future).

Comment your stuff

Whether it’s someone else or future you, if your stuff isn’t commented there will be confusion for why things were done or how to even use what’s there.
Using // to comment stuff is really handy for documentation and I really recommend doing it.


This is more for the technical side of things, but with how many different hacks there are nowadays, using PROTECT to inform you when there’s a conflit is really useful and will save you many headaches.
Using PROTECT is also great for troubleshooting.

Use subdirectories

Organizing using subdirectories/subfolders can help a lot to improve navigation through your buildfile. how much or little you use them is entirely up to you. (I go a bit folder crazy myself).

Editing Text:

Okay let’s start actually changing things in the ROM. I’m sure you’re no stranger to text (If you are, how are you reading this?).
Text editing is a very important part of making hacks. Without it, you’d just be stuck with defaults. And defaults are disgusting.

Head on over to the text folder, and take a look at what we have:

This is the Event Assembler of text. It takes the text buildfile as an input, and puts out all the things necessary for inserting text into the ROM

This is the ROM build event file of text. textprocess uses it to figure out what text you want, and where you want it to be.

-install text data:
This is the installer made by textprocess. For your text to be inserted, you need to include it. There isn’t really a reason to touch it by hand since text process handles it.

-text definitions:
Textprocess makes this to go with text install data so Event Assembler can actually use them.

This is where the text you typed is placed after it’s been handled by textprocess.

The parse definitions are the “dictionary” of codes that you can use to do things like load character portraits, and change how the text is presented.

Okay, now that we know a bit of what these do, let’s change some things around, shall we?

Open up the text buildfile, and take a quick look. See that top line? It’s very important.
The # 0x0903 (The space is important) is telling text process that this text should go in textID 0x0903.
Ignoring the next few lines, there’s something else.

## tells text process that the following text should go in the next textID. 0x0903 was the last textID used, so the next text inserted will be placed in 0x0904.

One thing to note is after either of these on the same line, you can put in a space, then the label of the text, so
# 0x0903 TextLabel1
## TextLabel2

These Labels may not have spaces in them, so no ## Text Label 1. Underscores are allowed though.

Now I could explain how all this text works, or I could point you in the direction of this text editing tutorial by Darrman

Was that a good read or what? (You did read it didn’t you?)

You might have noticed that Roshea has hijacked Eirika in the hacked ROM. Sadly, he’s still labeled as Eirika. Let’s fix that.
First things first, we’re going to have to find where Eirika’s name textID is.

Let’s go into the text dump in the Text folder (It’s inside of “Useful References” if you’re using the easy buildfile)
Since we know that we’re looking for Eirika’s name all by itself, let’s search for Eirika[X]

Now we should have the textID needed. Head over to the text buildfile, and put the name “Roshea” (Or whatever you want really) in Eirika’s name textID.

…Great. Now run MAKE HACK_textonly.cmd, and load up the ROM.
Now Roshea won’t have to suffer from an identity crisis.

If you want, there’s another way to change Eirika’s name.
You can go to the character editor table (the .csv file), and change Eirika’s name value to the label of the text you want. Easy peasy.
Just be sure it’s not too long.



4bpp Images

When you run Png2Dmp on an image with no extra arguments, a 4bpp formatted file of the image is made. This can be inserted in your hack.
The two ways of installing these graphics are:

Use #incext

#incext Png2Dmp "MyImage.png"

or run Png2Dmp on the file in advance then #incbin it

#incbin "MyImage.dmp"

A very small amount graphics are inserted uncompressed in the 4bpp format.

lz77 Images

lz77 compressed image dump files are made when you run Png2Dmp with the --lz77 arugment. They can be installed the same way as 4bpp formatted files.

Using #incext is slightly different than last time, so here’s an example:

#incext Png2Dmp --lz77 "MyImage.png"

Most graphics you can insert need to be lz77 compressed.


Png2Dmp can also output palettes of images using the --palette-only argument. When using Png2Dmp from a console to output a palette file, you must use the -po argument.

Png2Dmp MyImage.png -po <output file name>

You can #incext palettes like so:

#incext Png2Dmp --palette-only "MyImage.png"

Item Icons

Icons are dumped in the 4bpp format, so you shouldn’t use --lz77 to compress them.
There are several ways of inserting item icons, so I’ll only be covering two.

The first method is to use this macro to ORG to the item icon table:

#define SetIcon(ID) "ORG IconTable + ID * 128"

By default, the icon table is located at 0x5926F4. If you want, you can repoint to a different address to have 255 icons total.

The next step is to insert the icon directly after. In practice, this would look like:

#define SetIcon(ID) "ORG IconTable + ID * 128"

PUSH //PUSHing because SetIcon ORGs
#incbin "Images/Swords/IronSword.4bpp"

ID is the ID of the item Icon you wish to insert. Unlike most other graphics, the icon table does not contain pointers to graphics, but contains the graphics themselves.
This makes installation quite simple.

This method is very useful if you have a setup where you can dump an entire group of images automatically (with a script or makefile for example).

The second method is using icon sheets. Since the icon table is a bunch of icons in a row, you can divide the sheet as many ways as you want.
You could do

ORG IconTable
#incbin "IconSheet.dmp"

or even

ORG IconTable
#incbin "IconSheet1.dmp"

#incbin "IconSheet2.dmp"

#incbin "IconSheet3.dmp"

Naturally, you can also use #incext for the same result


For inserting portraits, we have tool named PortraitFormatter that takes a formatted portrait (that looks like this), and formats it for GBAFE to use.

There’s also a macro named setMugEntry that is used to add portraits to the portrait table.

setMugEntry(<mugindex>,<portrait label>,<mouth X>,<mouth Y>,<eye X>,<eye Y>)
  • The first argument is <mugindex>. This is the ID the portrait will use in the portrait table.
  • <portrait label> is the label where portrait data starts, meaning that what’s under it (the mug itself) will be used.
  • The next two arguments <mouth X>,<mouth Y> are the coordinates of the mouth. The game needs this information for the mouth animations.
  • The last two arguments <eye X>,<eye Y> are the same thing as the mouth, but for the eyes.

Insertion of portraits using #incext looks like:

#incext PortraitFormatter "MyPortrait.png"

setMugEntry(0x2,MyPortrait,2,5,2,3) //Example use of setMugEntry

If you run PortraitFormatter outside of #incext, you’ll notice that there are four .dmp files that get created.
These must be #incbin’d in a particular order. (Protip: If you use the -o flag to name an output file, all the .dmp files will be merged together and you can just #incbin that).

Insertion of pre-dumped portraits looks like:

#incbin "My_mug.dmp"
#incbin "My_frames.dmp"
#incbin "My_palette.dmp"
#incbin "My_minimug.dmp"

setMugEntry(0x2,MyPortrait,2,5,2,3) //Example use of setMugEntry

Remember: The order is important.

Class Cards

Class cards are handled very similarly to portraits.

To be inserted, class cards must be lz77 compressed, and you’ll need to include the palette seperately.

To make adding class cards to the portrait table easier, @Snakey1 made an easy to use macro:

#define setCardEntry(cardEntry,cardLocation,cardPaletteLocation) "PUSH; ORG PortraitTable+cardEntry*0x1C; POIN 0 0 cardPaletteLocation 0 cardLocation; POP"
  • cardEntry is the ID the class card will use in the portrait table.
  • cardLocation is the label of your class card’s graphic.
  • cardPaletteLocation is the label of your class card’s palette.

Installation of a class card using #incext looks like:

#incext Png2Dmp --lz77 "ClassCard.png"

#incext Png2Dmp --palette-only "ClassCard.png"


Installation of an already processed class card looks like:

#incbin "ClassCard.dmp"

#incbin "ClassCardPalette.dmp"


Remember that you need to run Png2Dmp on the same .png file twice with different arguments each time. (--lz77 and -po).

Map Sprites

To insert map sprites, first you need to have a properly formatted map sprite sheet. You can find plenty of them in the graphics repository.
Keep in mind there are two sheets you’ll need: One for standing map sprites (Or SMS), and one for moving map sprites (or MMS).

Next, you’ll need to put them somewhere and compress them properly. In this case, with lz77 compression using png2dmp. Like so:

#incext Png2Dmp --lz77 "StandingSprite.png"

You’ll need to do the same for the moving map sprite.

Now that the map sprites are inserted, we have to put them to use. I’ll be using the Easy Buildfile to demonstrate.
The Easy Buildfile offers two ways to use map sprites. First, I’ll cover the CSV method.

Go to Tables/Map Sprite. There, you’ll find some CSV tables for map sprites. For now, open Standing map sprite editor.csv.
Don’t mind the Unknown columns, we’re only concerned about Size and Pointer to graphics.

Pointer to graphics is self-explanatory. You type in your label name as a pointer (LabelName|IsPointer).

Size is a bit different. There are three options for size:

Size0 = 16x16 (16x48 images)
Size1 = 16x32 (16x96 images)
Size2 = 32x32 (32x96 images)

Pick one of these options based on the size of your standing map sprite.

Next we have Misc map sprite editor.csv.
In the Animation Pointer column, point to your moving map sprite.

As for the other pointer (Or Another Pointer), that will be explained soon.

On to the second method courtesy of @Vesly.
Go to Graphics/MapSprites, and open at It contains the instructions to use the map sprite tools in the folder.

Remember how I mentioned the Another Pointer? Well what it does is decide where each frame of the standing map sprite is going to be (among other things)
There isn’t much of a guideline for them, and that’s beyond the scope of this tutorial anyway. What I will show you is a definition for each AP (Another Pointer) used in FE8U:

//Vanilla FE8 AP definitions
#define NormalAP        $81C3D7C
#define GeneralAP       $81C8A80
#define RangerAP        $81CA124
#define ArcherAP        $81D0A7C
#define M_SageAP        $81D1D48
#define FemaleSniperAP  $81D2714
#define WyvernRiderAP   $81D403C
#define WyvernLordAP    $81D5E58
#define WyvernKnightAP  $81D7CC8
#define MageAP          $81D8668
#define F_SageAP        $81D8668
#define GreatLord       $81C52B4
#define JournymanAP     $81E173C
#define DancerAP        $81ED1C8
#define BardAP          $81E8840
#define CyclopsAP       $81F49B8
#define DemonKingAP     $81FD028

It should be noted that you can migrate these map sprite setups to your own buildfile if you want.

Battle Animations

This section is a step-by-step section on inserting battle animations.

What you’ll need

First, we’ll need Animation Assembler.

Next, you’ll need the animation you want to insert. You can find plenty in the Fire Emblem Resource Repository.
The animation folders hold a lot, so I’ll quickly explain what they contain:

  • Animation frames: Combat animations are done in a frame-by-frame style. These are the frames that are used for that animation.
  • Animation sheets: Same as the animation frames, but in a format that when compressed, the game can use.
  • Animation script: These are used to tell the game what frames of animation to use when, and where. There’s a human readable version in a .txt file, and there’s a .bin version. We need to use the .bin version.

If the animation you want to install doesn’t have have the .bin file or sheets, but still has the .txt script file and the animation frames, you can import the animation to FEBuilderGBA, then export as bin. This should output the files we need.

You’ll be wanting to include the Master Animation Installer.event file somewhere in your buildfile as well.

Inserting the animation

Drag and drop the animation’s .bin file onto AA.exe (Or run it in the command prompt if you prefer), and open the generated Installer.event file. Near the top you’ll find AnimTableEntry(0x0) //CHANGE THIS TO THE SLOT YOU ARE REPLACING. I think this speaks for itself. (SLOT = Animation ID)

After that, include the generated Installer.event in your buildfile.

It’s worth noting that quite often the animation .bin files will be named after the weapon type. This means there will likely be a lot of labels with the same name, and that’s a no-no.

One solution is to rename all the labels so they’ll be unique, and another is to include the Installer.event files with curly braces {} around each of them to make sure the labels aren’t global. The latter is recommended as it’s quicker and easier.

An example of using curly braces:

#include "animfile.event"
#include "otheranimfile.event"

Battle Animation pointers

Battle animation pointers tell the game what animations to use for what items/weapons. They follow this format:

Animation ID, Weapon Type/Item ID, Type Designation
  • Animation ID is the animation ID you want.

  • Weapon Type/Item ID is used for one of two things. The first is the weapon type being used, and the second is a specific item.

  • Type Designation decides whether the last option will be used for weapon type (Weapon Type) or a specific item (Item ID)
    The options are:

1 = all items of that type.
0 = Specific item.

The terminator to end the animation pointer list is word’s worth of 0 (eg. 0x00000000). Remember to label your animation pointers (and ALIGN 4 them too)

Here’s an example of Ephraim lord’s animation pointer:

AddClassAnimation(EphraimLord_Lance,Lance,1) //Using 1 for all lances

EAstdlib has a host of animation pointer macros you can use in EventAssembler/EAStandardLibrary/AnimationSetters.txt

To have the game use your new animation pointer, it must be assigned to a class in the class table. This is easily done in the ClassEditor CSV table. Go to the Animation Pointer column (or Battle Anims for skillsys), find the right row for your class, and type the name of your animation pointer label. (Remember to put |IsPointer at the end)

You can also org to the class table and point to your animation pointer like so:


ORG ClassTable + (ID * 84) + 52 //bytes 0x34 through 0x37 is where the animation pointer is in the class struct
POIN AnimPointer


There’s actually a macro for this in AnimationSetters.txt:

#define SetClassAnimation(ClassID,Pointer) "PUSH; ORG ClassTable+(ClassID*84)+52; POIN Pointer; POP"

This is basically what editing the table does, but more laser-focused.
NOTE: if you’re using the ClassEditor CSV, this must be done after the table is inserted, or else it will be overwritten

Battle Animation Palettes

Everyone having the same color palette is boring, so let’s fix that.

Thanks to compression, every battle animation palette is actually five palettes in one (Though only the first four seem to be used).
The palettes are pointed in a word from bytes 0xC to 0x10 of each entry (The first 12 bytes are for text so humans can identify the palettes)

NOTE: The following applies to FE8 only:
There are two other important tables. One for palette IDs to use, and the other for what classes will use those palette IDs.
It’s easier to get an idea of this by looking at the palette association tables.

Making and Inserting Palettes

First, you’ll need a palette string. It should look something like this:

//Colm palette

This is pretty easy to get via FE Recolor, FEBuilder, or…FEditor.

To insert these palettes, we have @Teraspark’s pal2EA tool.

Now let’s do a quick rundown of how this works. Let’s make a new file and name it something like Palettes.event

Here, we can type something similar to the following:

#char{0x3D} "Colm_Thief" set{Colm, 0x1, Thief}

We start off our palette entry with a #. Then we use char to decide what ID the palette will have. In this case, it’s 0x3D
In between the quotes we’re giving the palette a label name, and then set assigns a palette to a unit for a particular class. (In this case, Colm(0x9) when he’s a thief(0xD), which is his base class)
Finally, we have the palette that I mentioned before. pal2EA can compress and insert up to four palettes. One for the unit as a player, enemy, ally, or other unit.

pal2EA has an option to just copy-paste one palette, and just use it for the other factions (Which is what’s done in this example).
If you want to see more details on pal2EA, check out its README.

Here’s a list of what numbers mean what for setting the units’ class palettes (See how that 1 matches Colm’s base class 1 option?):

0 = Trainee Class
1 = Base Class 1
2 = Base Class 2 (for trainees)
3 = Promoted Class 1
4 = Promoted Class 2
5 = Promoted Class 3
6 = Promoted Class 4 (for Ewan)

Now you can run pal2EA on your palette file. It should generate Palette Installer.event and Palette Setup.event. The setup file is the one that should be included.

Spell Animations


Before you can insert spell animations, you’ll need Circles’ Spell Animation Creator (Or CSA).

Once you have it extracted and in your buildfile, don’t forget to #include the Master Spell Animation Installer.event file.

Included is a readme.txt file with instructions on use. Even though it’s there, I’ll walk through the process.
CSA_Creator.exe be in the same directory as the grit folder and the spell animation script and frames to work.
With this in mind, it might be a good idea to make a copy of CSA_Creator.exe and the grit folder, and place them in a separate folder for easier copying.

You’ll need a spell animation script and frames to run CSA on. You can get these from the Fire Emblem Resource Repository.

Once you have the spell animation you want to insert, copy CSA_Creator.exe and the grit folder to the animation’s directory. Then run CSA_Creator.exe on the animation script.
This can be done either through drag and dropping the script onto CSA_Creator.exe or using the console.

You should get a new Installer .event file. Now you can include it in your buildfile (Preferably under the //animations go here line in Master Spell Animation Installer.event).

Once you do this, open the genrerated installer file. Near the top, you’ll find these lines:

#define spellanim_index 0x0 //Change SPELL_INDEX to whatever spell you're replacing
setCustomSpell_dim(spellanim_index) //change to "setCustomSpell_nodim" to skip screen dimming

The name of the defined index is based on the name of the animation script file.
Change the value of the index to whatever spell animation ID you want to use.
If you don’t want the spell to dim the background, replace the setCustomSpell_dim macro with setCustomSpell_nodim.

Assigning Animations

To assign a spell animation to a weapon, go to open Tables/Item/FE8 Spell Association Editor.csv.

Despite this being a CSV, this file represents a list (not a table).

NOTE: The following applies if you are not using the Skill System.

The first thing you should do is go to the top-left cell and replace the address there with INLINE SpellAssociationList.
INLINE is to tell C2EA that this list isn’t at a specific address, and SpellAssociationList is the label name of the list.
Doing this will also repoint the original spell association list automatically, so you won’t need to do it yourself.

Next, you need to add a terminator to the end of the list. Copy this row from the Skill System repository and add it to the end of the .CSV file.

NOTE: Okay, back to where things apply everywhere.

Make a new row right before the TERMINATOR row.
Now fill in the data you want in each column. The names are inconsistent across the Easy Buildfile and the Skillsystem, so I’ll be covering the Easy Buildfile names first:

EasyBuildfile Name SkillSystem Name What it does
Weapon Item ID The ID of the item you want to display the spell animation for.
No. of Chars to Display (1 or 2) Chars to Display (1 or 2) Determines if this is a battle with two people (for combat) or one person (for self-healing)
Ranged Animation to Use Spell Animation The ID of the spell animation you want to be displayed.
Ranged Animation Enabled The second half of the spell animation ID short. Unneeded if you have fewer than 255 animations.
Alternate Pointer Map Effect Proc Used for special map animations. Should be set to 0 in most cases.
Return to original position (map) Damage Decides whether the combat display and damage flash are used. Set to 1 for weapons or the game will hang.
Facing position (map) Facing Direction (Map) Decides what direction sprites will face during map animations. 0 is used for weapons.
Enemy’s flashing colour (map) Color When Hit Decides the color the target will flash when hit during a map animation.
##UNKNOWN## N/A Either unused or padding. They’ll be fine just being set to 0.

With this information in mind, you should be able to fill in the data you need to assign your spell animation.


Reserved x2


Reserved x3


Reserved x4


Reserved x5


Reserved x6


Reserved x7 (I hope this is enough)