been a bit, let’s go
[ASM] Conditional Nos/Resire Palette (FE8)
Some time ago, someone wanted to recolor Nosferatu to be a light spell. And so, Tequila produced a way to replace the Nosferatu palette with a new, light-themed palette. However, there have since been fairly regular questions as to using both palettes at once. And thus, this came to be.
If a weapon has the Nosferatu spell anim and has Light or Staff as its weapon type, it will use the lighter palette. Otherwise, it will use the standard Nosferatu palette.
Just #include NosResire.event
to install. Shouldn’t conflict with anything other than repointing/replacing the Nosferatu palette.
[ASM] More Shop Types (FE8)
Normally, there are only 3 kinds of shops: armories, vendors, and secret shops. The way each works behind the scenes is a table for which portrait to use based on the shop type ID and a table containing the number to add to the armory text ID for each case that it needs to get the text ID to display. This is horribly inconvenient when wanting to make more shop types, and as such, this rewrites this system into 20(!) text ID tables indexed by shop type. It also repoints the portrait table for you, into its installer.
#include MoreShops.event
and you should be good to go. This shouldn’t conflict with anything that I’m aware of.
As-is, it’s set up to mimic vanilla behavior for the first 3 shop types (0-2), and as an example sets shop type 3 to use armory text in every case and use the arena man portrait. Note this does not touch music, as not to conflict with other hacks that touch shop music. However, without rewriting a shop music hack to account for more than 3 shop types you’ll find vendor music on every new shop type.
Calling a new type of shop isn’t the easiest thing to do without assembly, so you’ll likely need to use this in conjunction with other hacks for implementations of new shops. However, setting this up really isn’t that difficult:
How to call a shop
Calling a shop is very simple, as all you need to do is call the function MakeShop 0x80b4240
. This takes 4 arguments:
- r0 is the char struct of the unit visiting the shop
- r1 is a pointer to the shop list for the shop
- r2 is the shop type
- r3 is an unknown value; the function saves the value passed in r3, but I can’t find a time it ever uses it and giving it various values appears to have no effect. I’d recommend keeping this as 0, just to be safe.
Call the function with this information, and it’ll handle the rest. Very simple!
Speaking of hacks that would require this…
[ASM] Shop Unit (FE8)
By utilizing the above shop type expansion, this turns a unit into a shop that can be visited by any other unit adjacent to them. This uses shop type 3, as you can see by the default case for this shop type described above.
#include ShopUnit.event
, and add a menu command for accessing the shop with functions ShopUnitCommandUsability
and ShopUnitCommandEffect
. As it does not hook into anything, it cannot conflict with anything.
Note this does not check allegiance, so you can make enemy/NPC units be shops as well. For the specific use case that this was made for, any unit on a list brings up the same shop. However, rewriting the command effect piece slightly would allow for unit-specific shops.