Snake's Pit of ASM (and Other Stuff)

[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.

[Ysor]

Any plans to add the Support rework?

[7743]

There is not for now.
It is a patch that significantly changes existing data structures, so it takes a lot of effort to import.

[Ysor]

I understand, figure I’d ask

[Snakey1]

Modular Supply
This is pretty straightforward. This hack allows you to define a list of characters who can use the supply for each chapter. This also considers whether the armory man lets you send items to the supply or whether you discard items when getting an item with full inventory.

How to: Pull a chapter 5x and surprise players by making them drop the elixirs they worked so hard to get.

Go ahead and download the whole ModularSupply folder from my Dropbox in the OP. Include ModularSupply.event and integrate the csv you find there. This is the csv indexed by chapter, and each entry is a pointer. A null entry means no one can use the supply.

	ALIGN 4
	NormalSupplyList:
	BYTE Eirika Ephraim 0x00

Each pointer is a list of character IDs who can use the supply. This is a sample list. Don’t forget to terminate with 0!

That’s kind of it. There are no known conflicts, and this was made with CHAX. (Shoutouts to everyone helping me out with C. Thank you!)

In other news, my hacks that conflict with the Skill System have been integrated into the Skill Sytem buildfile, resolving the conflicts. If you are using it and wish to also use my hacks, please update the Skill System, go to _MasterHackInstaller.event, and uncomment the hacks you wish to use. My installation directions in previous posts have been updated accordingly.
This includes:

Anima Triangle (conflict with Tri-Adept)
ModularEXP (conflict with Paragon)
Conditionally Loading Portraits (conflict with RandomMugs3)
Stairs (mov debuff incorporated into MSG and unit menu incorporation)
Raid (unit menu incorporation)

In other other news, a small yet important fix has been made to Support Rework where bonus stats wouldn’t be gotten correctly from the bonus table.
And in other other other news, coming soon is support for dancing and summoning EXP modification in ModularEXP and defining item gets from base support convos in Support Rework.

Please let me know of any bugs with the supply stuff or Skill System things that probably were may have been may fault!

[Snakey1]

It’s been a while, but I’ve got a small little hack.
Set Scripted Battle Number Display
Tired of scripted battles having more or less damage dealt than the number displays in the battle screen? Or 100 hits missing? Or 0 crits? All from battle units having variable stats or being too lazy to set the characters’ stats? No more!

Had a fun testing environment here
All the numbers you see here are set in my events while setting up the scripted battle rounds using the following macro (defined in the installer for you):

SetScriptedBattle(AtkHit,AtkDmg,AtkCrt,DefHit,DefDmg,DefCrt)

To make a number appear as --, use 0xFF in the macro.
To clarify: this does NOT affect the results of the scripted battle. This only changes the display.

Just get everything from the Dropbox in the OP, include “ScriptedBattles.event”, and you’re good to go!

Next on my plate in terms of big ASM is stuff with Support Rework to make base supports more versatile and maybe not necessarily tied to supports themselves. Could use some optimization as well.

Ability to define an event to play instead of a text ID being shown in a generic event
Add an optional ASM condition slot for event conversation
Add an optional text ID to show for the menu text instead of autogenerating if defined
Add a bitfield saved somewhere (prep screen proc state?) that says whether a convo has been seen or not
Disallow repeating viewing convos with this bitfield
Maybe allow them to define an optional music change in the base support table for the base convo?
Let the user define conversations that have an icon (usually to denote which give items or w/e they want)

As well as some MSS stuff for displaying support data on the stat screen spookily.
I’m open to suggestions here, so let me know what you’d like to see in Support Rework if you’re interested. I’m looking for feedback!

[Sme]

Doesn’t Ability to define an event to play instead of a text ID being shown in a generic event cover Maybe allow them to define an optional music change in the base support table for the base convo, as you can just play the music with the support event?

[Snakey1]

That’s what I was thinking, but it may be a lot of trouble to make a new event if someone frequently wants to do a music change. This is the generic event.

CallBaseConvoEvents: // This is called assuming the text ID to show is in memory slot 0x2
		EVBIT_T 0x4
		CALL $9EE2E8 // Sets the background of index in slot 0x2. Set by BaseSupportConvoX.
		MUSI	
		SADD 0x032 // Move slot 0x3 into 0x2
		TEXTSTART
		TEXTSHOW -1 // Shows text in slot 0x2. Set into slot 0x3 by BaseSupportConvoX.
		TEXTEND
		REMA
		ASMC BaseSupportIncreaseSupport|1
		MUNO
		FADI 0x5
		CLEAN
		SVAL 0x5 0x1 // Used by the base support proc to see if the events are finished running.
		NoFade
		ENDA

So I was hoping to avoid a small edit like that requiring rewriting a new event.
I’m also thinking using an event file to contain the base support convo table would be superior to a CSV. Actually I’m pretty certain I’m gonna make that transition.

[Snakey1]

Generic Base Conversations
So I’ve had a functional base conversation system integrated with Support Rework, but there was no way to have base conversations without messing with support levels and having Support Rework installed. For the past… couple weeks or so, I’ve been completely rewriting the base conversation system and splitting it from Support Rework.

FE8 Base Conversations

Do the titles text, music, etc. seem random to you? That’s because they pretty much are. Head into the “How to” > Example section to see how I pulled this off!

Supported features:

• A base conversation table that’s easy to use. Not a disgustingly massive CSV anymore!
• Displaying a specified background (Required with the generic event)
• Defining an optional ASM usability pointer for each menu item
• Defining a title for each base conversation
• Defining an ASM text getter if no title is detected
• Having music to play during the conversation. If none is specified, MUSI/MUNO will be used
• Showing text during the event (the conversation itself, also required for the generic event)
• Giving an item to a character (if the character doesn’t exist, no effect)
• Loading units into your party (define a pointer to UNIT data)
• As a catch-all, defining a custom event to play instead of the generic event (more advanced conversation techniques, i.e. TEXTCONT, multiple text IDs/backgrounds, etc.)
• Defining an importance value for each conversation (number of exclamation points on the far right to show for the menu item similar to stars in Tellius)
• B press handling on the menu to go back to the prep screen
• Specify an event ID to use with similar behavior to chapter talk events
• No known hack conflicts including the Skill System!

---

How to: Uh I don't have a joke for this one; you guys write the text not me.

As always, you’ll find all materials you need in the folder link in the OP.

This comes with my Prep Screen Hack installed. It’s required for making the prep screen usability function properly.

You’ll need to integrate the CSV with that hack. This hack replaces the support viewer handler proc, so you don’t need to change the effect pointer. You’ll need to make the “greyed out” usability BaseConvoUsability|IsPointer. You can change the text to whatever you like with the other fields.
Doing this makes sure that the player can’t enter the convo viewer screen if none are viewable.

Now that that’s out of the way, you’re going to want BaseConvos.event included in your buildfile.
There’s pretty much nothing you need to worry about from this file unless you don’t want text IDs 0x2D through 0x34 consumed. These are used by default, but you can use any other text IDs by having those text IDs defined in your text buildfile.

For allocating those text IDs:

## BaseConvoTextID1
[X]
## BaseConvoTextID2
[X]
## BaseConvoTextID3
[X]
## BaseConvoTextID4
[X]
## BaseConvoTextID5
[X]
## BaseConvoTextID6
[X]
## BaseConvoTextID7
[X]
## BaseConvoTextID8
[X]

What you really need to concern yourself with is BaseConvoTable.event. This is where you’ll define the behavior of your conversations.

Example behavior shown in the video (don't mind my nonsensical debug text):

Chapter(MilitaryAccept3)
	Entry
		bg(0x30)
		name(Military3AcceptNameText)
		text(Support1Text)
		music(Aquatic_Ruin)
	Entry
		bg(0x2F)
		name(Military4AcceptRetreatNameText)
		text(Support2Text)
		item(SilverSword,Zaheva)
		music(Venus_Lighthouse)
		importance(2)
	Entry
		name(Military5AcceptRetreatLeaveNameText)
		event(BaseConvoTestEvent)
	Entry
		bg(0x2D)
		name(Military6AcceptRetreatLeaveNameText)
		text(Military1BeginningText)
		item(Elixir,0xFF)
		music(Derris_Kharlan_Appear)
		importance(2)
	Entry
		bg(0x2C)
		name(Military7AcceptRetreatLeaveNameText)
		text(Military1SylvaineBriefingText)
		importance(1)
	Entry
		bg(0x2B)
		name(Merc1NameText)
		text(Military1EndingBeginningText)
		music(Last_Battle_Decision)
		unit(LoadBaseConvoSylvaine)
		importance(3)
	Entry
		bg(0x2A)
		name(Merc2BanditNameText)
		text(Military1ForrestBattleText)
		item(SteelBlade,Madeleine)
		music(Green_Emerald)
		importance(1)
	Entry
		bg(0x29)
		name(Merc3BanditNameText)
		text(Military1ChristinaBattleText)
		music(Oil_Ocean)
		unit(LoadBaseConvoChristinaForrest)
		importance(3)
Chapter(MilitaryAcceptRetreat4)
	Entry
		bg(0x10)
		name(Military6AcceptRetreatLeaveNameText)
		text(Support3Text)
		music(Casino_Night)
	Entry
		bg(0x13)
		name(Military7AcceptRetreatLeaveNameText)
		text(Support1Text)
		music(Heavens_Gate)
...
// Later at the bottom of the file...
ALIGN 4
BaseConvoTestEvent: // Refer to the generic event in BaeConvos.event.
EVBIT_T 0x4
SetBackground(0x10) // REQUIRED, Load a background!
MUSC A_Tragic_Decision
TEXTSTART
TEXTSHOW Military4AcceptRetreatTactDecisionText // Example usage of a custom event: TEXTCONT with music changes.
TEXTEND
MUSC Emergency
TEXTCONT
TEXTEND
REMA
FADI 0x5 // This fade is highly recommended.
CLEAN // This is REQUIRED.
SVAL 0xB 0x1 // REQUIRED to mark when events are finished running.
NoFade
ENDA


LoadBaseConvoSylvaine:
UNIT Sylvaine ArmoredWyvernLord Sylvaine Level(9,Ally,True) [0xFF,0] 0x00 0x00 0x00 0x00 [SilverLongbow] NoAI
UNIT

LoadBaseConvoChristinaForrest:
UNIT Christina Cavalier_F Sylvaine Level(9,Ally,True) [0xFF,0] 0x00 0x00 0x00 0x00 [SteelBlade] NoAI
UNIT Forrest Cavalier Sylvaine Level(9,Ally,True) [0xFF,0] 0x00 0x00 0x00 0x00 [ShortSpear] NoAI
UNIT

I’ve tried to make this as easy to use as possible with macros. Start writing convos for a chapter with the Chapter(chapter) macro. Head each individual new entry with the Entry command.
The two required components of each base conversation are the bg and text components. Bad things will happen if you don’t define these. All other fields are optional (though the name field for the title of the base convo is required unless you have a text getter).
Visit ConvoTableDefs.event for all available macros! Any others not mentioned here are optional. These macros can go in any order you like within a single entry. The order in which the entries are written are the order in which they will appear in the conversation viewer.

Quick note on custom events:

You may have noticed the event field which allows you to play a custom event instead of the generic event. This is a “catch-all” in case these macros don’t suit your needs (TEXTCONT, multiple items given, multiple text IDs, etc.). This is extremely versatile, though there are a few requirements to make your event run properly.

• EVBIT_T 0x4 is needed at the beginning of the event.
• Loading a background is necessary at the beginning of the event.
• Fading before exit is highly recommended.
• After the fade, the commands CLEAN and SVAL 0x1 0xB are necessary before exit.

There can be no more than 8 base conversations per chapter! This is due to graphical limitations.
Finally, you’re going to want this defined somewhere in your text buildfile. This is the text that displays at the bottom of the base conversation screen.

## BaseConvoSelectConvoText
Select a conversation.[X]

This is completely independent from Support Rework, but that doesn’t mean I haven’t designed parts of it to play nicely with that future integration. Like the text getter for titles as well as allocating some of the convo entry space for future use there. Support Rework acting as an extension of this (or maybe the other way around idk yet) will be coming in the future.

I’m open to suggestions for whatever you may want to see in the generic event. The code for this was written in C, so let me know if you have questions about that or about the system in general. (Shoutouts to @StanH for the pretty amazing CHAX system that made this revision way less painful than it would have been with handwritten asm again!)

(Also while I’m here, I may as well mention I fixed the bug with the prep screen hack where the greyed out description text would not be gotten properly. I’ve also updated Repointers.event with a couple fixes/aditions.)

[GratedShtick]

I guess the joke would be “How to: have normal conversations before you go out to fight.”

[authenticmaniac]

Awesome work there! Making conversations that much more fun.

Also just wanna say this, Christina is hot damn.

[Zanryu]

Ya God damn right.