So basicly, can the support rework and generic baseconvos coexist? And can one change parameters after applying or do I have to be sure from the get go what I want to do with it?
It is really complicated for me(Reason I usually stay away from build files unless I have to use it), but it will surely help me in a hack I want to make this year that is supposed to be a retelling of FE4 in a…“weird way”.
Base convos and support rework do not go well together in their current forms, but I am working on rewriting support rework for many reasons. One of the goals is to have it integrate nicely with base convos. (The others involve splitting the features of it into toggleable parts.)
The system is designed for a buildfile, so it’s easy to apply the hack early on and make changes (add and modify individual base conversations as you go) if you’re using a buildfile from the start. If you’re mainly using FEB, this is more tricky. You could make changes to your base convos and reinstall the entire hack every time, but that would be a waste of space. Alternatively, you could install the hack once, find the location of the BaseConvoTable, then only install your new table each time you want to make changes to it.
I do use FEBuilder, so rip me I guess
HP Bar Palettes
Supports mid-battle palette changes!
@Tequila told me to do it blame him for this one, but make any colors you like!
Think you can do better than these palettes? You probably can, so try out your own!
Firstly, shoutouts to @anon30371999 and @anon686116 for the initial research and finding out this curiosity!
It turns out in vanilla FE8, there are actually different palettes allocated in ROM for different allegiances. They’re just all the same. You may have noticed 2 palettes are cycled through: a darker one, and a lighter one. (If you look even closer, there are a at least one more generated intermediate palette which appears to be an “in-between” for the 2 extreme palettes.)
What else is interesting is there are palette banks in RAM for both sides’ palettes. This means one unit can have an HP bar palette independent of the other unit. These palettes are almost always the same with the exception of excessive HP units (like the demon king) which have a bluer HP bar (which should still be supported in this hack).
So what this hack does is allow you to define default palettes by allegiance and by ASM usability via a small table as well as change the palette as it updates (like during losing HP, etc).
As always, download from the OP.
This hack should be pretty straightforward. You’ll mainly concern yourself with the HPBarTable. this is a terminated list the hack uses to get what palette to show. It uses the first valid hit it finds. If none is found, it uses vanilla default.
You’ll see in the example included:
ALIGN 4
HPBarTable:
HPBarEntry(0,BlueDarkHPPalette,RedDarkHPPalette,HPBarIsLowHP)
HPBarEntry(0,BlueDarkHPPalette,BlueLightHPPalette,0)
HPBarEntry(1,RedDarkHPPalette,RedLightHPPalette,0)
HPBarEntry(0xFF,0,0,0)
The first parameter is the allegiance (0 = blue, 1 = red, 2 = green, 3 = grey). The next 2 parameters are pointers to the dark and light palettes to show respectively. The last parameter is an optional ASM usability pointer that only allows this palette if it returns true. In the example, I check if the unit’s HP is below 50%. If so, then I allow the entry that replaces the light palette for that dark red palette.
The environment in which the function is called is always after all rounds are rolled and the battle structs are updated. This means the battle structs contain all of the stats after the battle. If you’re trying to check current displayed HP, you’ll only get post-battle HP if you try the battle struct.
.global HPBarIsLowHP
.type HPBarIsLowHP, %function
HPBarIsLowHP: @ r0 = battle struct. r1 = which side they're on. Return a boolean.
ldrb r2, [ r0, #0x12 ] @ Max HP.
@ ldrb r1, [ r0, #0x13 ] @ Current HP. @ THIS DOESN'T WORK BECAUSE THIS IS ACTUALLY HP AFTER THE BATTLE.
ldr r0, =BattleHPDisplayedValue
lsl r1, r1, #0x01
ldrh r1, [ r0, r1 ] @ This method should get the HP that's being displayed.
lsr r2, r2, #0x01
mov r0, #0x00
cmp r1, r2
bge HPBarLowHPFalse
mov r0, #0x01
HPBarLowHPFalse:
bx lrYou can get the HP bar images via FEBuilder export (or steal the examples), then edit the palettes to your heart’s content. Fair warning! These palettes are shared among other things in the battle screen like displayed numbers and the “Hit, Atk” etc text. Only edit the colors you need to!
Have fun, and please let me know of any issues that arise! I’m not super familiar with how palettes are handled, so I’m probably doing something wrong in here, but hey it seems to work.
all in a days work ;D
Funnily enough, @Runa and I simultaneously found an issue with my hack for setting scripted battle number display when explicitly defining an item with FIG1. That should be taken care of now. No functionality/utility changes. Just redownload from the same link in the OP if you’d like to update.
I’ve been hanging on to this for a while because it just seems so niche, but eh may as well release it.
You know in FE8 events how almost (?) anywhere you can use a character ID as an event parameter, you can use certain key values instead?
If you use 0 (0x0000), it gets the leader character.
If you use -1 (0xFFFF), it gets the active character.
If you use -2 (0xFFFE), it gets the character at coordinates stored in memory slot 0xB.
If you use -3 (0xFFFD), it gets the character stored in memory slot 0x2.
If none of these keys are detected, it tries to get the character struct by character ID.
Do you ever wish you could define your own custom event parameter functions? This hack is for you! By default, this hack should reproduce vanilla behavior except that as a side feature, recursive event parameters are supported. By that I mean…
SVAL 0x2 0x0000
CHECK_EXISTS 0xFFFD
This should check if the leader character exists (which it always should now that I think about it…? Maybe this is a bad example lol)
Anyway,
This should be pretty straightforward. Basically, this hack un-hardocdes the GetUnitStructFromEventParameter (0x0800BC50) function and instead searches a list of keys and function pointers to run for each key.
Go into EventParameters.event, and you should be greeted by a small list:
ALIGN 4
EventParameterTable:
// These mimick vanilla behavior.
EventParameter(0,EventParametersGetLeader) // Gets the party leader via $33258.
EventParameter(-1,EventParameterGetActive) // Get current unit.
EventParameter(-2,EventParameterGetCoordsInSlotB) // Get unit at coordinates in memory slot 0xB.
EventParameter(-3,EventParameterGetUnitInSlot2) // Get unit in memory slot 0x2.
// Custom ones can go here.
// EventParameter(-4,EventParameterGetFirstUnit) // Get the first character struct. Uncomment for this functional test entry.
WORD 0 0 // Terminator.
The first four entries in the list just mimic vanilla behavior. The -4 entry was mainly used for testing. If you’d like to add your own entries, they can go anywhere in the list, but the handler function will find the first key that matches. Otherwise, it will try to get the character struct by character ID. It’s up to you to write your own ASM (or C) function that handles each custom key. Each function takes the key as the only parameter and should return a character struct pointer (or null if none is found). Don’t place any entries after the terminator.
I think that’s it? EventParameters.event is the only file you need to include. As always, download is in the link in the OP.
That’s all for now. Stay healthy, friends!
I have absolutely no idea if I’ll ever need to use this but uhh
Cool work!
I may be wrong, but I believe it’ll come in handy for warping units or if you wanted custom village visit events, among others?
Now, I know what you’re thinking. Can I still rely on my hardcoded items that open doors and chests and all that nonsense? Sure, sure. Or… you could use… Modular Door and Chest Openers! Huh? Huh? Didn’t see that coming, did you?
Okay maybe not that exciting, but it’s about time for something that unhardcodes door keys, chest keys, and lockpicks.
Let’s say you wanted to make a 5-use door key without affecting the 1-use door key in vanilla. Here’s how you could do it.
Download the files from my download link in the OP and include DoorsAndChests.event.
You’ll see a new list, gTerrainUses, which links terrain IDs, an item to “open” that terrain ID, and a usability routine (like for thieves and lockpicks). By default, it mimics vanilla behavior, and an example implementation of a 5-use door key is included.
Note that this will affect opening a door or chest from the unit menu only. For creating behavior of opening a door or chest from the item use menu, be sure to update your item usability and item effect tables accordingly. (For the 5-use door key example, copying those pointers from the 1-use door key was sufficient.)
For a bit more in depth on how this function works, it would seem that the unit menu door and chest routines both share a function (0x08018A9C, what this hack hooks into) to get an item ID from the unit’s inventory that can open that terrain. If you wanted, you could make custom terrain-opening actions that use this hack and its modularity.
Also thanks to @anon686116 for reporting this one, but in my stairs hack, if a unit died on some stairs, it would disallow using the other end of that staircase to get there. That should be fixed in my independent installer, and I’ll have a PR to the Skill System version soon.
As always, lemme know if anything borks, and stay safe!
I noticed something the other day that was VERY naughty…
Seemingly due to a mistake in overwriting a bit of the vanilla pool here, you’ll see that the old anti-huffman patch does illegal reads and writes! (Not only is it an invalid address, it’s not even aligned. 
) In vanilla, these are supposed to reference gCurrentTextIndex presumably for optimization to avoid decompressing text more than is necessary.
This shouldn’t affect any functionality. Though I wouldn’t want to leave a loose end like that lying around, so I’ve whipped up a quick and more modern version of the Anti-huffman patch. (Credit Hexator and Nintenlord for the original version.)
I don’t even need a spoiler for this. Just downaload the files from my link in the OP and include Antihuffman.event. That’s all.
Quick note: This still uses the bit of space at 0x464470 just like the older version to preserve functionality with Autonewline.
I forgot to update this, but I’ve made a couple changes to generic base convos. There’s a new eventID field that you may add to each base conversation. I’ve phased out the old janky system that would try to store which convos you’ve viewed in RAM that was just outright bad. I’ve tested this a lot, and it seems completely stable. Behavior with the event ID works as if it was just a chapter talk convo. I’ve also fixed a bug with returning to the prep screen theme upon exit. Get the new version from my download link in the OP!
I’ve finally finished my “Support Rework Rework” that enhances Support Rework and splits it from base conversations instead using a sort of plug-in system. I’ve actually had it finished for a while, but I’ve been sitting on it idly waiting for bugs to crop up. I’ll be releasing that pretty soon.
How’s a QoL debug ASM C hack sound today?
Loop through character IDs, viewing their default classes and potential classes from the promotion branch table! Also includes the option to try to read from the triple promotion hack list. This is intended to make debugging animations and palettes a whole lot easier.
Down press increments the character ID, and up press decrements. (There’s an optional MaxCharacterID definition to prevent reading bad character data.)
Right press first loops through usable weapon animations (including the unarmed animation), then tries to read other potential classes.
B press ends the viewer. (I know that there’s weirdness with the active unit upon return, but don’t- don’t worry 'bout it.)
This is what I added to my unit menu:
MenuCommand(ClassDisplayNameText, 0, GreenText, 0x4F449, ClassDisplayUMEffect)Get the hack from the link in the OP. Just add your unit menu entry and #include ClassDisplay.event. I’ve had a weird things happen with the platform not sliding in on VBA, but it seems to work fine on mGBA for me.
EDIT: Oops mixed up MaxClassID with MaxCharacterID. Definition has been changed to be MaxCharacterID as it should be since we’re iterating through characters. Sorry about that.
Have a good day!
I found a minor bug with the Base Conversations patch.
I have set the opening event like this:
BeginningScene:
-Some Events-
CALL $591FD8//Call the prep screen
SETVAL 0x2 0x35//Black BG
CALL $9EE2E8
CenterTutorialTextBox
TUTORIALTEXTBOXSTART
TEXTSHOW 0xB55//Yes/No Text
TEXTEND
-Conditional Event-
CALL $9EE2C4//Remove BG
EVBIT_T 0x7
ENDA
So, the events after the prep screen call should run after you press start in the prep screen. If you don’t check a base conversation the events work as intended:
But after you check a conversation the game proceeds to run the events after the prep screen over the prep screen.
Alternatively I could put the events in a Turn 1 event, but after the prep screen it fades to the map, and I want to avoid that.
And I don’t know why those random tiles appear in the black screen.
Huh yeah I’ve only tried putting events in a turn 1 event to achieve what you’re trying to. Can I see the parameters for your specific conversation?
It happens with any conversation.
Chapter(Ch9)
Entry
bg(0x10)
music(EncountersAndReunions)
name(JugdralInheritorsTitle)
text(JugdralInheritorsText)
importance(1)
eventID(0x21)
Entry
bg(0x0A)
music(Sorrow)
name(KnightVowTitle)
text(KnightVowText)
importance(1)
eventID(0x22)
Entry
bg(0x12)
music(OneHeart)
name(PheraeLineageTitle)
text(PheraeLineageText)
importance(1)
eventID(0x23)
Entry
bg(0x10)
music(CatsAtPlay)
name(WhateverForTheCommanderTitle)
text(WhateverForTheCommanderText)
importance(1)
eventID(0x24)
Huh I’ll look into that for you.
Today I’m proud to release something I’ve been teasing unreleased for far too long out of fear of it being buggy, but today I’m confident enough for a casual release.
TableManager.exe is a new CSV assembler for EA buildfiles. Although similar in functionality to c2ea, TableManager is more versatile and friendlier. Download the exe and source code from my link in the OP!
The primary feature of TableManager over c2ea is being able to combine multiple “ROM tables” that are indexed together into a single CSV file. Distinguishing where everything needs to be written to is accomplished by linking Nightmare modules to CSVs similarly to c2ea.
While c2ea assumes that you want to write the data in your table into the ROM just as it appears to you, TableManager allows you to organize rows and columns as you see fit in your CSV without necessarily affecting what you write to the ROM.
ORG TableLabel + (FarLeftCellOfRow)*(EntrySize) format. The ultimate implications of this are that you don’t need to know the values of custom indices to work with them in CSVs, and you can reorder rows in any way you like! You may also leave empty rows.Run the .exe with the -h flag for more info on command line parameters.
To use, you must pass in a table options file and an intended output file like so:
echo: | (TableManager.exe TableOptions.s TableInstaller.event --error_on_missing)
This is the command I use in my batch to assemble my CSVs. (The extra flag is something I like to use. Again use -h in the command line for more flags.)
This file is a file that TableManager reads in order to understand how you want each CSV to behave. Here’s how it works.
CSV (FilepathToCSV) header.CSV header, you may link an arbitrary number of Nightmare modules with TABLE (LabelForThisROMTable) (FilepathToNMM) (OptionalAddingOffset) (Optional INLINE or FIXED to override the CSV INLINE setting for this TABLE only). The optional adding offset is to allow tables that are indexed together but with an offset to be combined into a single CSV file. This is most specifically included for the item usability/effect/target switch case tables. For example, I use TABLE ItemUsabilityTable Items/ItemUsabilityTable.nmm -0x4B for the item usability table because each index in the ItemUsabilityTable is 0x4B behind the ItemTable.INLINE (True or False) If False, the assembler will try to write to the vanilla offset in the Nightmare module.WRITE_SEQUENTIALLY (True or False). If not writing sequentially, 0-space will be allocated using FILL in EA for the entire table, and entries will be filled in as the CSV describes them.MAX_ENTRIES (MaxNumEntries) declares how much space you want to allocate for a table if you’re not writing sequentially. This is ignored if sequential writing is enabled.Check the .py source code for a more detailed explanation on what each code does.
A few other notes:
ASSERT when writing each row to ensure that every index that’s being written to exists. For example, if you try to give an iron sword (item ID 0 or 1 or something?) an item usability pointer, EA will give you an error because this assertion will fail because that entry in that switch table doesn’t exist. You probably don’t need to worry about this, and it should never cause problems for you. It’s just a failsafe.0x0A Manakete in the left cell of my row, TableManager reads this as 0x0A. This can be used to have sorts of comments on what a row is if you’d like to use hex indices.Rather than have BORING examples here, I invite you to check out working examples of TableManager in my Avenir Github: https://github.com/Snakey11/Legends-of-Avenir/tree/master/CSV/Tables
I don’t pretend to be a good Python programmer, so I probably made plenty of mistakes. I thiiiink I handled most errors I would expect, but please please let me know if you encounter weird traceback errors, if you see unintended behavior, if you have suggestions, or if something was confusing!
Have a happy Halloween! 
Made a quick QoL hack for dialogue for all you avatar hacks out there. 
This hack lets you add some text control codes (definable in textprocess definitions) that inject gendered pronouns into text (i.e. He, She, Him, Her, His, Hers, he, she, him, her, his, hers). Each control code is associated with a pronoun pair, and an event ID is used to determine which to inject. (I kinda hijacked how [Tact] works.)
This isn’t entirely necessary for doing this since you could just have separate text IDs for different cases or use TEXTSHOW2 shenanigans but ew. This should be cleaner and quicker.
This isn’t limited to gendered pronouns really. I intentionally made the system modular for more general use.
Download from the link in the OP!
Lemme know if you encounter any issues. I don’t think this should conflict with anything.
By request, I’ve updated TableManager to be able to handle specific vanilla tables being considered inline or fixed, overriding the pattern of the CSV declaration. For example, say you wanted your vanilla character tables to be written to their original offsets but your custom character-indexed tables to be written to free space. You could do the following:
CSV Characters/CharacterTable.csv @ Things indexed by character.
TABLE CharacterTable Characters/CharacterTable.nmm
TABLE MagCharTable Characters/CharacterMagicTable.nmm INLINE
TABLE CharLevelUpSkillTable Characters/CharacterLevelUpTable.nmm INLINE
TABLE PersonalSkillTable Characters/PersonalSkillTable.nmm INLINE
TABLE EscapeQuoteTable Characters/EscapeQuoteTable.nmm INLINE
INLINE False @ The default inlining is false here.
WRITE_SEQUENTIALLY False
MAX_ENTRIES 256
You can accomplish the exact same thing with:
CSV Characters/CharacterTable.csv @ Things indexed by character.
TABLE CharacterTable Characters/CharacterTable.nmm FIXED
TABLE MagCharTable Characters/CharacterMagicTable.nmm
TABLE CharLevelUpSkillTable Characters/CharacterLevelUpTable.nmm
TABLE PersonalSkillTable Characters/PersonalSkillTable.nmm
TABLE EscapeQuoteTable Characters/EscapeQuoteTable.nmm
INLINE True @ The default here is inline.
WRITE_SEQUENTIALLY False
MAX_ENTRIES 256
So to use this new functionality, just optionally append either INLINE or FIXED to make an exception to the CSV INLINE setting. I’m updating the original post’s documentation, and let me know if there are any issues!