1234567890num

This looks amazing and might finally let us not deal with hex and pointers ^_^. I made a PR that clarifies some of the unknowns with what I discovered but hidden within the thread including FE10Data.cms' ChapterData. I hope mess files and script files can have modules written soon.

Not sure if it's even possible to change how the game reads the data.

You need to install those modules using pip.exe (and command prompt), which should be in the Scripts section of your Python directory. I don't think you can just download the releases from github to make it work. My script uses struct module, which should've been included automatically on Python. Just run it on Python and everything should be self-explanatory (hopefully).

If you wanna do things manually, you'll need to know the format of ItemData entries (the one in the first post is outdated). 00 02 AA A0 Pointer -> IID_FLORETE - Item ID, determines what item it is. 00 02 E7 18 Pointer -> MIID_FLORETE - Name ID, determines what text is shown as the name. 00 02 CC E7 Pointer -> MH_I_FLORETE - Desc ID, determines the text shown in the description. 00 03 42 D0 Pointer -> sword - Determines weapon rank used. 00 03 42 D0 Pointer -> sword - Determines damage type. 00 03 16 08 Pointer -> N - Weapon rank required. 00 00 00 00 - Blank - EID used for magic. 00 02 9A B8 Pointer -> EID_FLORETE 00 00 00 00 - Blank - EID used for Laguz weapons. 00 - Unknown 10 - Item Icon. 00 C8 - Cost per use. 0E 5F 0F 05 2D 04 - Might, Accuracy, Critical, Weight, Uses, Weapon Exp. 01 02 01 - Min range, Max range. 01 - Unknown 00 00 00 04 - Unknown 03 - Amt of Attributes 00 - Amt of SFXC 00 - Gives Stat Boosts (Boolean) 00 03 43 1B Pointer -> valuable - Additional attributes (can be a few or none) 00 03 41 6E Pointer -> eqB 00 03 42 C8 Pointer -> stormsw [SFXC would go here if there's any] [Stat Boosts would go here if there's any] You need to add the amount of SFXC by 1 and add a pointer to the corresponding SFXC. However, the entire file after that will be offset by 4, so you'll have to change most pointers. I made a Python script to do that for you (Add Free Bytes Others.py). The offsetting problem will also happen when you try to add Worm into the forge and Dark Magic into the weapon store. You can also use the same script for that.

- You need to add SFXC_BEAST, SFXC_DRAGON, and SFXC_FLY into those weapons. Honestly it's complicated and the info in the first post is VERY outdated, so you're better off using HeartlessSeph's tool to do this. - I made a post about shopdata here. Keep in mind that if you want Worm to ALWAYS be available, you'll have to add it into EVERY SINGLE FSHOP/WSHOP ENTRY. - No idea, but you can make them rejoin later (albeit you can't pick which party they go to anymore). - No idea. Something to do with FE8Data.bin but nobody ever delve into it much yet.

So it is. Should be fixed now. Thanks.

Which link?

My zmap scripts add 104 bytes (68 in hex), which is the data for each unit. It does not add any data regarding that new unit or the string/object list. So if you want to add them, you should do some repointing (or use my other script). In conclusion: use zmap scripts to free up some spaces for new units before using other script/manually adding new bytes for the new pid/iid. Yes, free bytes others is the better way to add things to shop. HeartlessSeph's tool does not require any extra pointing. It does rebuild stuff from scratch and may change the order of the data. No big deal for normal play, but if you want to make a patch it can bloat the patch size. Mounted unit's Mov penalty is in FE10Data. Particularly the ChapterData. However, last I checked it's not shown on the program, so check my post above for details.

The ones still listed above are unknowns for now. As for the rest, all of them are editable on decompressed FE10Data. You can either use HxD or use Heartless Seph's tool here. Locking the skills should entail changing the number of SID and SFXC table entries in SkillData into 0, but I haven't test this.

Turns out the problem was that the new file wasn't in the encoding that supports Japanese texts. I guess xlsxwriter takes care of that problem automatically. I found out a bit more about your FE10Data Editor. In your Biorhythm Data, compared to the data in the first post of this thread: the numbers in your Hidden Item% are actually the Skill Activation%, the numbers in your unk[4] are actually Hidden Item%, while the numbers in your Skill Activation% are actually unknown. Also, back in Chapter Data, I was half-correct; the 6th byte is the group's BEXP stash. I also found out that the 7th byte is the group's Convoy from 0-6 (0 is No Convoy, the rest follows the same order as the BEXP stash). The 8th byte is the mounted units' Mov addition (on indoor maps they're set to FE, which is -2); you can use this to add Mov, but the final Mov are all still capped at 20. I don't know how to change groups (as in actual units), but I'm pretty sure it's not in ChapterData or Scripts.

Yeah, it works. I also figured out that the "SIDTables" are actually mandatory requirement to equipping the skills with the 00/01 being Must/Mustn't respectively (like mustn't have the skill already equipped, must a dragon, etc). "SFXCTables" are similar but they're optional; only one of them are needed to fulfill the requirement. Regarding your FE10Data editor, I do have some comments. First of all, for some reason some of the support type tables have a value of 65280-ish. In PersonData your unk1 is the starting Lv (although the game chooses the higher one within this and the corresponding zmap file) and the basemov doesn't work. In JobData your unk1 and unk3 are Armor weight and Mount weight respectively (which can also be negative). In ChapterData the Chapter#s determine the used BGM+Shop files, Mess file, and Script file respectively. Your Loss Conditions (Maniac) all have the number 1. There's also Win Condition 3 and Loss Condition 5 for each difficulty that isn't used (and you skipped as padding) since there's only 6 lines available and the texts will overlap if you put in too many. Finally, within your 8 bytes of "unknowns", the 1st byte is the Map ID (which brings you to the Debug Map if tampered) and the 6th byte is the group you're following in order from 0-5: Dawn Brigade, Crimean Knights, Greil Mercenaries, Laguz Alliance (Crimea + Greil), Everyone (Dawn + Crimea + Greil). How did you decode the Japanese texts in Python?

What exactly did you do? I removed that and now nobody can equip it, not even Elincia. I couldn't figure out how to bypass the Ragnell & Ike check entirely, so I ended up just copying the part of the function after the check (where Ashera dies for real) into the part of the function where Ashera revives and nullifying the function's bytes that comes after that. Skips all the Ashera-killing fanfare, but it works well enough.

Mucked around the zmap files a bit and I found out about the unit data. Taking from VincentASM's example on the first page (and based on Wooster's analysis on the fifth page), These units are divided into groups. The most common zmap groups are mikata (PC), teki (default enemies), zoen (reinforcements), midori (green units), and ki (yellow units). For mikata, all of these are unimportant except one: Starting and ending XY co-ordinates. Remember that the first byte in a group's definition (more details here) shows how many units are in that particular group. So, if you want to add deployment slots/enemies/yellow soldiers, here's what you have to do: Grab the appropriate zmap file Find the group definition and modify the first byte to reflect the number of units you want it to be Add 68 hex bytes for each unit within that group. You can put it anywhere in that group as long as it's not within the other unit's data. Repoint ALL the pointers in the Unit Data since you're moving all the strings in the object list. If you see above, there are at least 8 for each unit so...yeah. Repoint SOME of the pointers in the Pointer List and Group List. At least for this one you don't have to deal with pointers toward data before your new unit. Adding whatever data you want for the new unit. If you only want to add deployment slots, you can just copy paste another ally unit's data wholesale, changing only the XY coordinates. Making sure the new pointers are all properly documented on the Pointer List Making sure the headers are all correct As you can see, it's a lot of work. However, I made a script that can do step 2-5 for you, so the work isn't THAT much. The link also has a similar script that you can use for similar file types (mess, shopitem, decompress FE10data) but it's less automatic. PS: Tower deployment map is emap0407d, not bmap0407a. An unrelated note: @LordMewtwo73 Did you figure out how to make Mercy equippable to others?

There's SID_IMMORTAL and SID_INVINCIBILITY. They're in her unit block in zmap407e. Seems like the former is the one tied with Ike/Ragnell and the latter is the one tied with the auras. I guess I could remove the SID_IMMORTAL to let anyone kill her (haven't tried it yet), but that still leaves the question about how to make both Ike and Micaiah be able to kill her. E: that didn't work Also, does anyone know how to guarantee Lehran's recruitment (remove his requirements)?

@LordMewtwo73 How did you make Ashera killable without Ragnell? Would it be possible to make it so that either Ike or Micaiah can kill her? Or so that anyone can?

Speaking of main.dol, how do you make sense of it? E: And script.cmb files too, for that matter.

A decompressed FE10Data has the same file format as a .bin. I explained that file format a few posts above. The important thing in your case is making sure that all the pointers in the data between the skill you add and the skill you remove are properly listed in the Pointer List.

Shop files determines what's sold in shops/bargains. It doesn't determine how much each item is sold/bought for; that one's from FE10Data. It's a .bin file, so it mostly follows the same format as zmap. Obviously, the Unit Data will be different; it's replaced by Shop Data, which has a different format for each type of shops. Each shop in each chapter is part of its own group. Bytes 00 - 27 are the header. Bytes 20-23 and 24-27 are pointers toward a date and name respectively, but they're never used. The date is the only difference between shopitem_n, shopitem_h and shopitem_m. Which means that all 3 files are basically the same and you can swap them out at your leisure. Bytes 28 - E3 are part of SHOP_PERSON groups. Each group consists of 4 bytes. In order, they determine who watches over the weapon shop, items shop, selling shop, and forge for that particular chapter. The values are: 1->Muston, 2->Aimee, 3->Jorge, 4->Daniel, 5->Daein, 6->Crimean. Sometimes the value is 0 because they don't expect you to visit that particular shop in this chapter (aka it's normally unavailable). Bytes E4 - 23A4 are part of WSHOP_ITEMS groups. They determine what's sold in the weapon shops. Each item is represented by a pointer followed by 4 null bytes (00 00 00 00). The length of each group vary, unfortunately, so making a Nightmare module is difficult. Bytes 23A8 - 2FFB are part of ISHOP_ITEMS groups. They determine what's sold in the item shops, including bargains. Normal items follow the format from WSHOP, but bargain items are not followed by 00 00 00 00. Instead, it's followed by 01 XX 00 00 where XX is an increasing number within that group. I don't know what they do; changing them seems to do nothing. The groups in this section are also not uniformly sized. Bytes 2FFC - A8EB are part of FSHOP_ITEMS groups. Each group is 720 bytes (2D0 in hex) long. It's a bunch of pointers that follows the pattern MIK->MDV->IID. MIK are the weapon types, and MDV are the weapon materials/tiers. The only weapon I manage to add is Worm; adding another weapon will crash the game. But at least you should be able to enable/disable the other forgeable weapons. Bytes A8EC - A97F are part of FSHOP_CARD groups. The number of cards is defined in the first 4 bytes (A8EC - A8EF). After that, each card is represented in 12 bytes (C in hex). The first 4 bytes is a pointer toward the MESS name. The 5th is bonus Mt, 6th is bonus Acc, 7th is bonus Crit, 8th is bonus Coins, and 9th is the % chance of getting it. The last 3 bytes are junk data as far as I know. PS: @VincentASM Can you update the OP? It is pretty old. PPS: I made some Python scripts that you can use to check zmap, mess and shop files.

Mess files are what determines the game's texts. All the english ones begin with "e_", with the japanese ones still left on the game for whatever reason. Most texts are stored in e_common, with glossary texts stored in e_dic and the story/base conversations in their relative chapter (e_c[chapter]). Its format is the same as bin files, which I covered here. The Unit Data, Pointer List, and the date section of the Header are missing, which makes the Object List start at 20, Group List right after that (at the address pointed by bytes 04-07) and Footer following it. Each text is an object referenced in a group. The groups are then recalled by the script before being displayed in the game. For example, the text that shows "EXP" has the name "BMI_EX". For most files, all you need to know is that 00 signifies the end of the object (and also group in this case) while 0A signifies a line change (which can sometimes break the game for reasons unknown). Conversations are more complicated. I figure out that they always start with 05 46 4C 7C before listing everyone in that particular conversation being separated by 7C before ending with 7C too, after which there's a bunch of stuff I don't understand. 11 10 are used for breaks (where you need to press to continue), 02 65 63 for eyes closed, 02 65 6F for eyes open, and 02 6D 63 2E 2E 2E 02 6D 64 for ellipsis. There are still a bunch more stuff I don't know what they're used for, but this should be a good start to customizing conversation contents.

If you want to spread a hack around, I suggest using xdelta. The extra work needed on the user is slim when you only changed FE10Data, but if you change a bunch of other files too (zmap, mess, scripts, shops, main.dol, etc) it increases a lot.

About the zmap footer and the ??? Part, I found out that the length of the ??? Part divided by 8 = the number of objects on the footer = bytes 0C-0F. The footer objects usually have the names: date, mikata, teki, and zoen. Anyone with Japanese knowledge knows what they might mean? E: I just remembered that ENG Hard/JAP Maniac have autoleveled enemies. Not sure how it works, but MAYBE it can be used to autolevel Tormod and co?

My version is the one with Muarim's glossary having Mist's instead, and this works. For posterity, you change the addresses 026628 for weapon triangle and 0F5550, 1151C0 for map affinity. You know you got the right addresses if they originally have the value 28 00 00 02 (change it to 28 00 00 03 to enable the feature). Still no idea about EXP/BEXP formulas and battle save, though.

Looks like he also makes a guide on how to change the EXP formula. He doesn't leave any guide on how he found those values, so I guess you're out of luck. You'd probably have to find them using Debug Mode yourself. I don't know how to do that, so I can't help you there. But hey, if you do figure it out, at least you can change both EXP and enemy range using a similar method. And, you can probably figure out the weapon triangle, map affinity, or even what the skills do in the meantime.

Where did you found that instruction?

Well, the good news is that I found how to add initial items to units in battle. The bad news is that it involves pointerception. Step 0: Understanding the dispos files structure. The dispos files are divided into 6 parts: Header, Unit Data, Object List, Pointer List, Group List, and Footer. Each step correspond to a section, and more detail will be given there. These structures are also applied toward mess and shop files, although the details are a bit different in each. Step 1: Adding the object to the file (Object List) (Ignore if the item's IID is already in the list) Objects include SID, JID, IID, PID, SEQ, etc. At various points, the game points to these objects. When the game reads an object, it stops at the byte 00, so make sure not to forget it when adding a new object. More details on pointers/objects in this post. You can easily spot Object List as it has a bunch of legible strings in the middle of the file. It starts with a date/time and ends with "invalid". Just add the object you want into this section. Since there are a bunch of pointers into this part, if you want to avoid a major headache you should put the new item's IID after the "invalid" object. Do not replace anything. And do not forget to add 00 at the end. Step 2: Adding the items to the unit (Unit Data) Unit List starts at 28, with each unit taking up 104 bytes (68 in hex). The specifics can be found here, along with a little bit of my findings here. The part after the pointer to "invalid" is the item section. Just turn those into pointers toward whatever thing you want them to have. Do not add anything; just replace them. I don't know what'll happen if you try to point them to objects the game doesn't recognize as items, though. Step 3: Adding the new item pointer to the file (Pointer List) (Ignore if you're just swapping/deleting items) You can easily spot Pointer List by as it has a bunch of increasing numbers located right after the Object List. Those increasing numbers point toward all the pointers in the file. Usually the first two pointers on this list are 00 00 00 00 and 00 00 00 0C (pointing to the pointers at 20 and 2C respectively). Note that this DOES NOT count the pointers found inside the Group List (more on that later); only on the Header and Unit Data. An important thing to note is that this section MUST start at an address multiple of 4. If this is not the case, most likely as a result of Step 1, then you'd have to add a bunch of garbage bytes as padding. If you wanted to add items to a unit, you'd have to create new pointers for the new items. Just add them into the appropriate slot. Do not replace anything. If you skip this step, the item you add will be the same as whatever item is pointed by the pointer that is actually listed. I don't think it matters if you put the new pointer out of order, but for easier organization I'd suggest you don't do that. Step 4: Accounting for the new file size (Header) (Ignore if you're just swapping/deleting items) The header has a length of 24. Bytes 20-23 is a pointer toward a date, for purposes unknown. Bytes 00-03 shows the file size (in hex). Bytes 04-07 is a pointer toward the start of Pointer List. Bytes 08-0B is the number of pointers in the Pointer List (in hex) aka the size of Pointer List divided by 4 (in hex). Bytes 0C-0F is the size of Group List divided by 8 (in hex). Bytes 10-1F are all 00 (unused because you can't point toward those addresses). An incorrect heading will cause the game to crash/freeze, so we need to change the bytes 00-0B such that it follows the state of your new file according to the rules above. Do this and we're done! Step i: Irrelevant stuff (Group List and Footer) We're already done, but there's still 2 sections left. I'll post them here for posterity. The Group List comes right after the last pointer in the Pointer List. It contains group pointers, 8 bytes each, which is counted by the header (see above). Groups can be dates, allies, enemies, green units, etc. This section also must begin at an address multiple of 4. The first 4 bytes are a pointer toward the beginning of the objects in the group. In most cases, the very first one points has the value 00 00 00 00, which means it points to the address 20 (which is a pointer to a date, as stated above). The rest of the groups are started with 4 bytes that defines the group, after which the unit lists begin. The first byte shows how many units are included in that group. The second byte is always 07. I have no idea what the rest means. The last 4 bytes are special pointers that determine the group name. These pointers are special in that they don't need to be added 20 to show the correct location. It's also special in that it starts at the beginning of the footer (aka the end of the Group List). So if the footer starts at 16A4, for example, then a 00 00 00 00 in this section points at 16A4 and a 00 00 00 28 in this section points at 16CC.