Snake's Pit of ASM (and Other Stuff)

[Raymond]

Is the Anima Triangle ASM supposed to clash with the Skill System Patch?

I patched both of them into a clean FE8 rom, but then when I tried to test the new rom, VBA got softlocked because the initial Seth vs. Valter cutscene wouldn’t start (and even if I removed it, trying to start any combat would just softlock the game) and no$gba just crashed.

I tried to patch them both in different orders, but it doesn’t change anything.

Both patches seem to work properly on their own, but combining them seems to just fuck up the rom, which I’m not sure is supposed to happen, since FEBuilder doesn’t list them as conflicting patches and because I’ve seen hacks with both Skill System and Anima Triangle in place.

[Snakey1]

@Raymond

Is the Anima Triangle ASM supposed to clash with the Skill System Patch?

I believe- actually I know that Anima Triangle conflicts with the somewhat recent skill addition, Tri-Adept. You should be able to get around this by not installing that skill. This is another conflict that I need to handle.

@ShinKuma

Curious question but could this be done across the board for all tomes to have its own internal triangle on top of standard?

Could you elaborate on this?

[ShinKuma]

My question would be like when you were able to create a triangle within the anima table of magic. Could it also be transplanted into the light magic and dark magic table as well?

[Snakey1]

Sure. All my ASM does is check if the current weapons used match what’s defined as fire, thunder, or wind based off of lists of item IDs and set WTA accordingly. There’s no reason why this concept couldn’t be applied to different tomes.

[Snakey1]

Prep Screen Menu Editor

Screenshots

This will allow you to easily edit the menu options in the prep screen. In vanilla, these are loaded in a somewhat hardcoded fashion, but this includes some ASM and a CSV that allows you to edit and conditionally change these items.

How to: Spookify your prep screens

Like I said, the first part of this is some ASM. It handles building the menu options that you define in a modular fashion.

ALIGN 4
#inctext lyn "PrepScreen/PrepScreen.elf" "PrepScreen/Hooks.elf"

I hope this looks familiar by now. Nothing else is required.

The second half is the CSV that defines the conditions, name text, description text, and effects for your menu items. Heap the CSV with your other tables; as is, it is set up to function exactly how vanilla does. This data DOES NOT exist in this way in vanilla. This is a completely new table so the user can more easily define how the menu appears.

Each menu item appears as an entry in the table, and each item will be loaded in the order that they appear in the table. I’ll go through what each column does:

ID
I wouldn’t edit this for vanilla values, but each menu item has an ID associated with it. If you make new menu items, they will need an ID. I suggest using 5 or 6 since those are unused in vanilla. Within this ASM, the ID seems arbitrary as long as you don’t repeat them.

 0 = pick units
 1 = items
 2 = save
 3 = link arena cancel
 4 = support
 5 = ? (one of: fortune, ranking)
 6 = ? (one of: fortune, ranking)
 7 = check map
 8 = start battle?

Credit @StanH doc.

Name Text
Pretty straightforward. This is the text that will appear as the name of the item. (“Pick Units,” “Check Map,” etc.)

Usability (Whether to display)
This is reserved for a usability routine that returns false if you do not want the menu item to display at all (see images 1 and 2 how “Support” is not shown). Return true if you do want this option to appear. A 0x00 entry will always display the menu item.

Usability (Greyed out if false)
You know how in Valni and Lagdou, the “Save” option is greyed out an unusable? Do that to your menu items with this. Point to a routine that returns false to grey out and true to remain normal. Again, 0x00 will always display normally. PrepScreenSaveGreyUsability is included as an example and to emulate what vanilla does to grey out “Save” during the Valni and Lagdou chapters.

Warning for these usability options: Do not forget |IsPointer! It got cut off in my screenshot.

Desc Text
This is the text ID that will be shown when hovering over the menu item as the description text.

Greyed out desc text
Self-explanatory. This is the desc text that will be shown if the menu item has been greyed out.

Effect
This is the effect routine for each menu item. To be honest, I haven’t analyzed these a whole lot yet, but that’s what it is.

Finally, a terminator entry of all 0s is necessary as the last entry.

And that’s it really. I hope to have a little more analysis of the effect pointer.
One warning: you CANNOT display more than five menu options at a time. The graphics freaks the fuck out if you try. It’s fine to have more than five items in the CSV, but make sure via usability that more than five never show up simultaneously.

BONUS: Eliminating a Valni/Lagdou headache.

You know how in the top right of a prep screen, it shows “Chapter” followed by the chapter number? This is true except in Valni and Lagdou where it shows “Tower” and “Ruins” instead respectively.

ORG $96B1C
SHORT 0xE00A // Eliminate "Tower" in prep screens
ORG $96B3A
SHORT 0xE003 // Eliminate "Ruins" in prep screens
ORG $96B4C
SHORT 0xE003 // Eliminate "Ex.map" in prep screens

This’ll ensure that it always shows “Chapter” even in chapter IDs that were Valni/Lagdou.

No go and make a base convo system… or maybe prevent the player from viewing the map in a prep screen for a chapter. Spread your evil!

[Snakey1]

Two things:

Firstly, I’ve updated ModularEXP to support EXP from staves. The way staff EXP is handled is completely different from combat, so another routine has been added to handle that. No need to change the installation method whatsoever, just redownload the .asm and .elf files.

Also, I’ve slightly modified how 0 EXP is handled. The routine will always output a number between 1 and 100 inclusive… UNLESS you multiply by 0 at some point. This means that if you want to conditionally eliminate EXP gain, you can multiply by 0.
Let me know if you find any bugs!

Secondly, I figured I may as well post something I’ve been sitting on for a while.
Do you use buildfiles? Do you detest PFinder?
Well I’ve uploaded “Repointers.event” which can be #incuded to repoint all of the major data tables… or use it as documentation or something.

Currently Supported Tables

Item Table
Item Target Table
Item Usability Table
Item Effect Table
Class Table
Character Table
Spell Association Table
Promotion Branch Table (This was a pain tbh)
Chapter Data Table
Standing Map Sprite Table
Moving Map Sprite Tables
Death Quote Table
Battle Quote Table
Spell Table
Summon Character Table (Also kind of a pain)
Text Table
Character Forcer Table
Sound Room
Portrait Table

Let me know if there are tables I’m missing.
This is very similar to the file I use to repoint everything for LoA, so it’s pretty well tested. If it does cause problems, however, don’t hesitate to let me know!

[Snakey1]

Another update: (Shoutout to @7743 for a tip) StairsASM (FE7 and FE8) no longer requires bl range. This doesn’t alter its functionality in any way; it just means fewer headaches when installing it. Just redownload the installer files, and you’re good to go!

[mykelsss]

@Snakey1, could I get some help with those instructions for the FE8 Stairs? I know nothing about EA, and am using the Skill System buildfile instructions.

First I put the “Stairs” folder into the Skill Systems “Engine Hacks” folder, ensuring the files are placed into the root “Stairs” folder and not the “FE8” folder that comes with it. (I’m guessing this is what I’m supposed to do since I have to add the definition ‘#include “Stairs/Stairs.event”’ and not #include ‘“Stairs/FE8/Stairs.event”’)

Then I add #include “Stairs/Stairs.event” to _MasterHackInstaller.event which I think is where it’s supposed to go:

Okay, so then I have to "Add
MenuCommand(StairsNameText,StairsDescText,GreenText,StairsUsability,StairsEffect)” to wherever you’re installing the action menu like how it is in “Stairs.event” (The skill system’s is at the bottom of
“Engine Hacks/_MasterHackInstaller.event”.)

At the bottom of _MasterHackInstaller.event it says this:

But that doesn’t look like where it goes. So I open up UnitMenu.event instead, which does resemble the Stairs.event.
And I place the line here, because in the Stairs.event the command was just below “UM_Visit” as well.

Then, I have to “delete everything under “//Repoint Unit Menu” in “Stairs.event””, so I delete all of this, since I assume it doesn’t mean just everything below that one subsection:

I add the mentioned lines to text_buildfile.txt. And I think I have to re-run this, so I delete the _textentries and drop “text_buildfile.txt” on to “textprocess_v2.exe”, which does indeed place the entries into “Text Definitions.event”.

But then it gets really dicey, because I have no idea what any of this means:

Lastly, you need to know how to use them in events. They’re not linked to the stair tiles, they’re location events.
#define Stairs(StairID,X1,Y1,X2,Y2) “LOCA StairID [X1,Y1] 0x22 ; LOCA StairID [X2,Y2] 0x22”
Just use the Stairs macro under LocationBasedEvents where (X1,Y1) are the coordinates of one end of the
staircase and where (X2,Y2) are the coordinates of the other end. StairID is the ID of this staircase.
Never reuse IDs between multiple staircases!

After searching through the files, LocationBasedEvents seems to be found in “Expanded FE8 Template.txt”. So I place that whole “#define Stairs…” portion there and also in “Expanded FE8 Template.event”, but I have no clue if that’s correct or not, or if I’m supposed to rebuild something here after doing that.

After all that, I run it and it technically works, though I have no idea if I did everything right:

But how do I access this Stairs macro/event from FEBuilderGBA? I don’t see any new Events. Is it not in the Event Editor?

Thank you!

[Pikmin1211]

Not snakey, but this is made with buildfiles in mind. I don’t think 7743 has added any support for this system via FEBuilder, though you could ask him about it.

[mykelsss]

What’s the ideal thread or process needed to use it? What thread has the procedure? If you happen to know.

Ideally, the procedure, because I feel like utilizing this probably doesn’t require an overall knowledge of EA/ASM or whatever’s needed.

[7743]

Now I am making it, so please wait.

There are still a lot of things we have to do for integration.
It takes time to make routines and stabilize them.

[Arch]

[Snakey1]

Thanks to 7743 for adapting this for FEB. You could theoretically could do this with FEB events currently by manually writing LOCAs (location events), but that sounds messy. I’d wait for FEB compatibility.

Thank you for the detail in your question, by the way. It’s always good to give as much detail as possible around here.

[mykelsss]

Thanks, both of you!

[7743]

I supported to stair expansion of Snakey1 with the latest version.

Actual example.
However, in order to put this in, the menu re-point is substantial, so we recommend backing up before doing it.

install the stairs patch,
then , Make a staircase with a map object.

sample UPS
https://cdn.discordapp.com/attachments/470029781795078175/547344512511508490/Stairs.en.PATCH.20190219180707.7z

[Snakey1]

SummonASM
Tired of summoners being considered inferior to druids? Are they falling behind in EXP? No more!
This hack will allow you your summoners to gain EXP (and level up) from their phantoms’ battles.

Screenshots/gifs

Credit Hypergammaspaces for Val’s mug. Thank you!



I was a little too lazy to make another phantom character oof.

Tested with anims on and anims off (Yes, they use completely different level up systems.).
This has been written for a very long time, but now irrelevant previous arrangements are now null. Just now I’ve had the chance to clean it up a bit.

How to: Make phantoms more than sad cannon fodder.

As always, download the whole “SummonASM” folder from the Dropbox in the OP. Installation is easy. Just include “Summon.event”.

This hack uses the Summon Character Table to find the summoner that created the phantom for granting EXP and level ups. This is a vanilla table! If you are creating custom summoners, ensure that you are installing this CSV (included in the Dropbox). If you’re already working with custom summoners, you should already be using this.
In case you want to repoint this table:

ORG $2442C
POIN SummonCharacterTable
ORG $244A0
POIN SummonCharacterTable + 1
ORG $7AD54
POIN SummonCharacterTable
ORG $7AE00
POIN SummonCharacterTable
ORG $7AE04
POIN SummonCharacterTable + 1

That’s it. This hack should be very user-friendly and easy to install. It DOES NOT conflict with the skill system for once.
No go and promote to summoner without fear of EXP loss, and make good use of phantoms as interesting strategical pawns. As always, please find me with issues or bugs!

[DerTheVaporeon]

Very niceu, Snek-chan! I would love to use this!

...

smh not using the new Illios mug reeg

[authenticmaniac]

BLESS. The long waited time of exp gain from phantom battles has finally arrived, thank you!

[7743]

I supported SummonExp in FEBuilderGBA.
However, since I have not yet ported to FE8J, it is only FE8U.

[Snakey1]

This is undoubtedly my biggest undertaking so far. I am proud to present…

Support Rework

What will this do for you? There are numerous features while being user-friendly.

1. Complete overhaul of the vanilla support data storage system. Instead of growths over time, the user has full control of when to increase supports.
2. Unlimited number of potential support partners. Although you may only have 5 support partners at a time, the number of potential partners is fully defined by the user. There is also no limit to the number of A supports you can have.
3. Support bonuses are no longer determined by affinity. The user can define every single stat bonus for every support level for every support partnership. This is a simple CSV.
4. Support conversations like talk conversations are available for use. Just like a talk conversation in CharacterBasedEvents, the user may define support conversations to occur in specific chapters with simple macros.
5. Base supports! The prep screen support viewer has been completely changed to user-defined base support conversations for that chapter. These are easy to define through a CSV.
6. Easy to use event macros that can alter support data between two characters.

In short, this system changes support growth over time to a system where the user defines when support growths occur through event commands, support (talk) conversations in CharacterBasedEvents, or base support conversations.
Support bonuses are defined by defined bonuses per level per unit pairing instead of by affinity.

Screenshots and gifs

Example of a chapter support convo adding a C support.

Example of support bonuses affecting battle stats (look at MMB stats).

Example of use of SetSupport to silently add support data. Walter is added to the party, and his supports are added like so oof camera error lol:

Example of the base support system.

How to: Have unit relations without meddling in all of that vanilla nonsense.

Installation is actually not that difficult. As always, download the entire “SupportRework” folder from my Dropbox, and #include SupportRework/SupportRework.event. Next, implement both CSVs (“Base Support Table.csv” and “Support Rework Bonus Table.csv”) in your buildfile.

If when you assemble with EA that you’re getting errors with shit like ‘BSupport is not defined’ in your CSVs, you can include “SupportRework/Support Definitions.event” externally early in your buildfile. This only contains those event macro and other definitions.

Lastly for installation, this requires 8 free text IDs. (Assuming you have text installed first, which you should), include this to your text buildfile anywhere.

## BaseSupportTextID1
[X]
## BaseSupportTextID2
[X]
## BaseSupportTextID3
[X]
## BaseSupportTextID4
[X]
## BaseSupportTextID5
[X]
## BaseSupportTextID6
[X]
## BaseSupportTextID7
[X]
## BaseSupportTextID8
[X]

If you do not define these, the installer will automatically use text IDs 0x2D through 0x34. (I don’t think these are used in the base skill system installer, and these seem to be unused.)

Now here's how you use the Base Support Table.

This table is used to define when base convos occur, what characters they’re between, what level they increase to, what text ID they use, and what CG they use.
The table is indexed by chapter ID, and there is a maximum of 8 base support convos per chapter.

Oh god that’s a lot of 0x00s. All the 0x00s mean is that there’s no conversation defined there.
Let’s say that we want to add a base support conversation between Gilliam and Franz in chapter 6…

That’s all you need to do for a conversation.
Whether this conversation will appear depends on Franz’s and Gilliam’s current support level. This conversation will only appear if they do not have a support because units are only eligible for C supports if they do not currently have a support.

Likewise, this B support will only be available if Franz and Gilliam currently have a C support.

Adding more conversations is easy.

The Support Rework Bonus Table is straightforward.

This table defines exactly what bonuses each unit pair gets for each level. I think this one is pretty self-explanatory.

This table is not indexed. My functions loop through each entry of this until it hits the terminator, trying to find a unit pair. If you want a support pair to have bonuses, you must add them to this table! Otherwise, they will get 0 bonuses.
In this example, Franz and Gilliam will get 1 attack, 2 defense, 10 hit, etc. with a C support, 2 attack, 2 defense, 15 hit, etc. with a B support, and so on.

Add as many entries as you want, as long as you end the list with the terminator.

Support talk events are much like regular CHAR macros..

That kind of says it all. You have two macros at your disposal here…

SupportConvo(Level,Character1,Character2,Text)
SupportEvent(Level,Character1,Character2,EventPointer)

The first macro is for a default chapter support convo. Just define the level, characters, and text ID to show.
The second macro allows for spooky event shenanigans. This is the same as the first, except instead of just showing the text, it plays the event you define with EventPointer. Use this if you want to do anything special like special music, giving an item, etc.
Here’s an example:

This conversation is an A support between Forrest and Christina that will play the text ChristinaForrestAText.
Just like base supports, this conversation would only appear in the unit menu if Forrest and Christina have a B support before the conversation. (See base support section.)

Event macros give the user total control over units' support data.

The user has the following weapons of mass destruction at their disposal:

AddSupport(Character1,Character2)
AddSupportNoPopup(Character1,Character2)
IncreaseSupport(Character1,Character2)
IncreaseSupportNoPopup(Character1,Character2)
SetSupport(Character1,Character2,Level)
ClearSupport(Character1,Character2)

AddSupport simply creates a new C support between two characters. A support will NOT be added if there are already 5 supports or if these two characters already have a support. By default, a popup will appear notifying the player: Support level increased to C.
AddSupportNoPopup does the exact same thing without the popup.

IncreaseSupport simply increases a support to the next level. Nothing happens if the support is already at A level. If no support exists, a C support will be added.
IncreaseSupportNoPopup does the same thing with no popup.

SetSupport is the main way to silently set support levels. It simply sets a support level to the defined level. There is no popup. If there is no support between these units, a support will be added at this level, granted that neither already has 5 supports. This is the macro to use if you want to spawn units in who innately have supports (like Pent and Louise).
ClearSupport simply removes the support entirely between these two units. This makes room for another to take its place. There is no popup.

All of these can easily be used to alter support data within events. Remember that enemies and NPCs cannot have supports! do not try to give supports to NPCs or enemies. Protagonists only!

This is used to silently set an innate B support between Muriel and Clara. Muriel had just spawned at the beginning of this chapter.

There’s also a hidden feature that I doubt anyone other than LoA will make use of, but I may as well leave it in. Anywhere you define a character to gain a support, be affected by support data, etc. as 0xFF, my functions will assume that this means the first character struct. This is necessary for LoA because the tactician character actually has 20ish character slots, but they will always occupy the first character struct. This allows us to easily define supports for Tact.

Whew. I think that’s all you need to know. This does not conflict with the skill system, which is actually astounding to me.

This has been extensively tested, but there are many moving parts to this. Please reach out to me with any issues you may find.
Thank you to everyone for your support throughout my time in the community , and I hope to have something else released soon.