Great! I was thinking about having vanilla seals for regular classes and special seals for future hybrid classes.
1 Like
I think I found a bug.
If you use an item that heals fatigue based on might, and the value becomes negative, it causes the fatigue value to loop.
I believe this section of the fatigueitem.s file is the culprit:
@apply fatigue modifier
mov r1,r4
add r1,#0x3B
ldrb r2,[r1]
sub r2,r0
strb r2,[r1]
Because there is no check if the subtraction results in a negative number, it just stores the looped value.
Nice catch, I likely forgot the “if <0 set to 0” check because I did s drinks first and they don’t need a check like this. I have fixed this and updated the download package, the only changed files are FatigueItems.s and FatigueItems.lyn.event.
1 Like
forgot to release this lol
[ASM] Fixed Damage Weapons (FE8)
A la crossbows. Configurable list of weapons that ignore user’s atk in mt calc and just use the weapon’s mt directly.
Download
To install, just #include "FixedDamageWeapons.event" and add POIN FixedDamageWeapons to the end of the skill system pre-battle calc loop.
19 Likes
Yet another step closer to a Radiant Dawn demake
Map affinity when
6 Likes
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.
Download
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.
Download
#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.
Download
#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.
19 Likes
[ASM] Aum/Valkyrie/Bifröst (FE8)
The staff that revives an ally that doesn’t have a consistent name.
Download
Comes with staff usability & effect functions, AumUsability and AumEffect; set them to the appropriate tables for the item you want to be Aum and you’re good to go.
Note that this won’t let you pick which unit you want to revive. When you use this staff, it looks for the first dead unit in recruitment order and revives them. If no units are dead, it cannot be used. It does not track the order units die in.
26 Likes
So this is basically Bifröst.
1 Like
shtick can read confirmed
2 Likes
I mean in the essence that with Aum and Valkyria you can choose who to revive, whereas bifröst just picks one and be done with it.
Occasionally I wish that I lose my ability to read because of some of the things I stumble upon.
2 Likes
So for example, if there’s 2 dead units, one who died in chapter 1 and another that died in the current chapter, the staff will revive the unit who died in chapter 1?
1 Like
It will revive whichever one you recruited first. It checks in the internal unit order, which is the order the units were loaded or recruited.
2 Likes
petition to make it rng-based
4 Likes
Oh sweet, Aum. This will be very useful for GFE-
oh wait…
4 Likes
so you’re most likely reviving the weakest of your dead units
It may be more accurate to just say whoever is higher in the deployment list which can be shuffled around depending on who you’ve brought to chapters etc. i.e. if you never use Garcia, by endgame, I think he’ll be pretty low on the deployment list despite being an early recruit.
1 Like
I have a few questions about this. It’s still really cool, but I am curious on how the revival process works.
- Do resurrected units retain their pre-mortem inventory, or is it wiped?
- Do resurrected units retain their supports? On top of that, how does it interact with supports in general? (Usually GBAFE wipes the support between an alive and a dead unit, the only exception being Pent/Louise in 7 as both units are removed at once to prevent this)
- Given something that temporarily increases stats (say, a Pure Water), if they die and get revived, how does it interact with that?
They retain their inventory, their supports should be wiped (this doesn’t touch how that works at all so it’s just vanilla behavior), pure water specifically is denoted in a section of unit data that gets wiped between chapters so it would not persist between chapters, and would likely continue decrementing behind the scenes on the same chapter
I think I may have found a bug with fatigue, but I am not sure how best to replicate it.
From the best that I can observe, when you are recruiting a unit who was once a red or green unit after a certain amount of turns have passed, the unit in question will not join with 0 fatigue to start. Somewhere it seems that a value of some kind is getting written to byte 0x3B. I’m not sure from where or how this is happening.
It’s entirely possible that something in my own hack is causing a value to be written here, but to the best of my knowledge nothing writes to that byte in the character struct.
The best solution, if possible, in my opinion would be to update the turn ally routine to set a units fatigue to 0 as part of that change. I would try and do this myself, however I don’t have enough knowledge about how to exactly read the event assembler code to find where the routine is in the rom. Of course, you could always use a different BYTE if one is available.
Writing an ASMC to set that value sounds rather simple
2 Likes