More than 7 support partners in FE8?

Hey all,

This has been an idea nagging at me for a while so I really want to put this to bed once and for all: allowing for more than 7 support partners in this game.

I recently noticed codes existed for FE8 that referred to 8th, 9th, 10th support options for characters in FE8, despite no character having more than 7 partners. I thought perhaps this was leftover from FE6 or an earlier time in development, and could be taken advantage of.

Setting Eirika’s byte for number of supports (0x8AEBC1) to 08 read her initial support value with Ephriam, 1E, as the character ID for Myrrh, which I expected from experimenting previously with this.


I have no idea where the C rank is coming from–it’s not from misreading an initial value, seemingly-- and I suspect that must be important in some regard because of problems I encountered later.

At first, setting Ephraim’s growth rate to F1 read Eirika’s 8th support initial value as already being at A rank. I was able to tamper with this using said codes to confirm these were values the game actually read as associated with an 8th support slot. It made me excited, that perhaps “all that needed to be done” was find a way to tweak how the game read the support data to be like FE6, in groups of 0A rather than 07.

Unfortunately, that was where I ran into more problems.

While the initial value of the support was A when I started a new game, (I inserted Myrrh into the first map using FE Builder’s extend list function for the player units) quitting and resuming put the rank back at C.

myrrha sighmyrrhc

I take this to mean that while the game does have short term memory to store 8th, 9th, and 10th supports, it doesn’t commit this to the actual save file. Please correct me if I am wrong, or if it possibly has to do with my sloppy, inexperienced map editing. How big a hurdle this is I assume would depend on the structure of the save file itself and how the game knows what to save–which I am unfamiliar with, if anyone could enlighten me I would be very grateful.

Another, more head-scratching hiccup occurred when I looked at the in-game support menu in an old save file.


I…really don’t know what to say about this besides just wondering why it’s being read differently from the Extras menu and if that can be fixed.

In sum, my main questions are:

  • Is there a way to edit how the game reads its support information to be like FE6? (in intervals of 0A)?

  • Is there room to store 8th, 9th, 10th supports in the save file as in the short term memory? (Is that distinction even correct?) How could I tell the game to save this?

  • What is going on with the ingame supports menu?

I fully expect the answer to be that this is not possible. But I think understanding how and why would help quiet my head about it a bit.

Thank you for any insight any of you may be able to provide.


You’re correct in saying that there are memory limitations to support data. I’m not sure if you’re familiar with RAM character data structs, but they’re essentially what hold the data for each character throughout the game, including their class, stats, inventory, weapon levels, whether they’ve moved this turn, and yes, supports.
This is not the same as save data, however. Whenever save data is updated (after movement, battle, etc), it copies a bunch of data from these character structs (among other things), and efficiently packs what it needs to save into the .sav file.

If you want to allocate more data for supports, you would need to jump both of these hurdles. Save data sounds scary, but you’re in luck because Stan’s Expanded Modular Save hack would make this trivial.
Making more room in the RAM character struct (or potentially elsewhere in RAM) would be more difficult. This is what support data here looks like in vanilla. (Taken from Teq’s Better Notes.txt -> Character struct):

Location Type Data stored
0x32 Byte Support #1
0x33 Byte Support #2
0x34 Byte Support #3
0x35 Byte Support #4
0x36 Byte Support #5
0x37 Byte Support #6
0x38 Byte Support #7 (For non-player units, has char byte of leader)
0x39 Byte Bitfield; each bit is a support partner (in the order they appear in) and is set if a support has been obtained in that chapter

(Wow this table thing is kind of neat in Discourse. I just happened upon it/it autogenerated when I copy/pasted.)
Anyway, each RAM character struct is 0x48 bytes long, and it’s kinda packed except for 2 free bytes. As is, this doc suggests there’s room for 7 supports, though I had some interesting occurrences with the 7th byte when working with my Support Rework. For example, it’s unioned with enemy leader bytes, and apparently vanilla doesn’t clear that byte after you change an enemy’s allegiance to a player. :roll_eyes:
If you can’t put extra support data within the character struct, you can put it elsewhere in RAM similarly to what the Skill System has done with where it stores rallies/debuffs. Both options would require editing any functions that read/set support data. Either one would require using Expanded Modular Save to ensure that this new data gets saved/loaded from your save file.

So in short, allocating more space for supports is definitely possible but potentially difficult depending on how many supports you want to add.


Thank you so much for your detailed reply, I really appreciate it.

It is good to know that there is a way to allocate more room in the save data with the expanded modular save, even if it’s probably a bit technical with my current limited familiarity with utilizing Event Assembler effectively and such. But since you call it trivial, I’m sure it could be something to teach myself if I just put my nose down in the books enough.

The RAM structure is also very helpful, I am rather surprised there is not room for 8th, 9th, and 10th options though once again that’s likely due to my own limited understanding. Especially since the game seemed to at least in map read some data about an 8th support using the codebreaker codes which inspired my curiosity. I assumed such codes did affect the RAM, so now I’m curious what it is affecting–though I suppose that may be tangential to the topic at hand.

Unfortunately, even if I did resolve issues with both save data and RAM, there is still a problem with reading basic support info from the ROM above 7 partners. The game first lists the 7 (10/0A in FE6) IDs of the character’s support partners, then the initial support values, then the rate at which the support points increase per turn, followed by a byte indicating the character’s total number of support partners and then 2 filler bytes to buffer space to the start of the next support block.

When I changed that number of support partners byte at the end from 07 to 08 for Eirika, the game read Ephraim’s initial value as Myrrh’s character ID as would be expected. It also read his growth rate with Eirika as Myrrh’s initial value, however–meaning even though the support partner number was changed to 8, the game starts reading each set of data at the same place.

This is also expected as all character support blocks have room for 7 support partners (10/0A in FE6), even those who actually have less. I don’t know if you or someone else would be the best to answer this, so I leave it open to anyone, but without changing how the game reads those support blocks to be in line with how FE6 does it (sets of 0A) I would not be able to correctly set more support partners anyhow. Is there any way to change this?

(Also I suppose that last screenshot hasn’t been addressed but I’m crossing my fingers that’s just a bizarre interaction that would go away while addressing other problems.)

Edit: Actually, after examining the RAM structure, I believe the final screenshot is due to the game mistakenly reading the bitfield at 0x39 as the 8th support partner; so it indeed would be solved alongside other problems.

No matter what you do to do this, you’ll be editing ROM ASM functions to get the game to read/set the support data as you want it to. As such, if you want to add more size to the support data table, then you can edit all functions that read from that table to perform the behavior you want them to (consider more space per entry). You’d also need to repoint the support data table (because it would take up more space) and change the data within to match your new format.
This part wouldn’t be too difficult imo.

Directly setting number of supports to a number higher than 7 is not going to work without modification to the structure of support data, which is always 24 bytes in length regardless of the number of supports; 7 each for partners/initial value/growth rate and 1 for number of support partners, then 2 bytes of padding to keep things 4-aligned. Setting # of support partners to 8 will just have it read from (First character ID + 8) for the 8th partner, which is the first byte of the next set of 7 data.

That being said, as long as a character would not be able to possess supports with more than 3 characters at one time then all you would have to do is change support data to a list with a terminator so it can be variable length, then change how the game loads support data into the character struct to load the character ID in along with the support value, which given 7 bytes to work with there is room for in the existing struct. When the game saves this edited support data it would save and load it properly with no modification on that end since it’s still saving and loading the values of all 7 bytes, and everything would work fine.

If you want a max of 8 simultaneous supports, the easiest way would be to 1. Restructure support data to have a max of 8 support slots and 2. Use the byte that’s normally a bitfield for which supports you can’t rank up again on that same map as the 8th support byte, as well as disabling the normal check on that byte. This likely would not require editing save data either, at most it would limit your 8th support partner to a character ID of 0x7F or lower if it doesn’t pack the 8th bit of that byte in vanilla, and even if it doesn’t it’s an incredibly trivial thing to avoid and one you likely would never run into as all playables and bosses generally fit under 0x7F.

If you want more than 8 and/or are intent on keeping that feature, you’ll either need to find free space elsewhere in the character struct (there is little to none) or put it elsewhere in RAM.