Huichelaar's Assembly Adventures

“Yeah, it’s not a bug it’s a feature!” Jk.

On a different note, has anyone tried assembling Adaptive BGM? I’m curious if it works for others. Currently, I’m also looking into obtaining an EA buildfile for the Changing Battle BGM By Chapter patch, so that one doesn’t need to use the FEBuilder patch.

2 Likes

I just wanted to clarify with the adaptive music - so the regular/Ablaze versions can only have a total of 12 instruments combined, right? Not each one gets 12 separately?

Yes, that’s correct.

2 Likes

I’m having trouble replicating your bug:
2020-05-22_17-06-04

Could you give a .ups patch of your romhack?

1 Like

Just from that gif, though, I do notice a significant amount of lag drawing movement squares (and maybe elsewhere) only while the danger zone is active. I don’t know if it’s related to that bug, but it looks like something to look into nonetheless.

Good luck sorting that out! Always love to see new hacks like this, and we’ve been long overdue for something like this.

Yes, as I mentioned in the opening post, unfortunately the calculation of the danger zone takes quite some time even at lower enemy-counts (maybe it’s related to the size of the map). I’ll see if I can optimize the calculation some.

The reason why it takes so long for the RangeDisplayGFX to show up right after the unit is moved is because the Danger Area is recalculated at this point (before the player has committed to an action). This then happens again if the action is canceled or executed, because the Danger Area needs to be recalculated again.

1 Like

This looks awesome. Fantastic work with this. Couple of questions:

Could you possibly include a .UPS example file? Makes it super easy for anyone who wants to test it out on vanilla to just download and patch. I’m new to romhacking, totally dependent on FEBuilder, and buildfiles intimidate me. (There are guides on that, and of course I will check those out at some point…)

Any chance we’ll get a FEBuilder patch anytime soon? (Not even sure how those even get released - is it just 7743 going through everybody’s ASM threads and tweaking things to put it into FEBuilder?)

Thank you so much for making this. I’d love to use it in my romhack.

Thanks for the UPS patch suggestion! I added UPS patches in both dropboxes, and added some instructions to the opening post w.r.t. using the patches. Personally, I’m also very new to ROMhacking and I very much love using FEBuilder as well. I used FEBuilder to extract the UPS patch, so hopefully it will be able to adapt it to a clean ROM (it did on my end at least).

I’m also not sure about how hacks get adapted to the FEBuilder patches repository. Maybe I need to send in an application. I’ll ask 7743.

This may sound like raining on a parade, but I was just wondering if the GBA sound files store measure data from the MIDIs. If that’s the case, maybe this ASM could be modified to wait for a measure to complete then transition to the equivalent measure on the corresponding song? Apologies if this sounds stupid.

I don’t think it sounds stupid at all. I’m not sure either whether the sound files store measure data, I’ve only ever used mid2agb on midi’s, I’ve never actually taken a close look at the .s files it produces.

In theory, if some indication of which measure is being played is stored somewhere in RAM and is also used when a song is initialized, then it could be possible to have the newly initialized song start at the measure the previous song ended on. One would have to find some free byte (maybe more, depending on how many measures a song can have) in RAM to store the currently playing measure at, in order to find out when the measure changes. Or, probably better, add some lines to the function which changes the measure.

I’ve looked a good while at the second musicplayer (0x03006650 onwards) but couldn’t find something like this. It could be there. I’m not planning on looking for it though. Maybe in the future, probably not.

Alrighty, I added Danger Radius to the main post. This here is an updated version of Danger Area. By allowing one to select individual enemies’ danger radii instead of all of them at once, it can limit lag. This patch allows FOW, but reverts to the more vanilla DangerZone (expressed in rangedisplay squares) when FOW is active.

Finally, Danger Radius is compatible with vanilla FE8U. I’m still working on a version that’s compatible with the SkillSystem.

2020-08-02_18-13-42

9 Likes

Righty-right, now there’s a Danger Radius version that is compatible with the SkillSystem, as of August 5th 2020.

As always, if you run into any issues, please let me know!

2 Likes

Any chance you could add event commands to turn this on as well?

Eg.
Sval 2 (unitID)
CheckDangerZone

  • Returns 1 if true - currently displaying the Danger Radius for unit of mem slot 2 or unit of coords xxyy

Sval 2 (UnitID)
SetDangerZone

  • Displays the Danger Radius of unit s2 or unit of coord xxyy until turned off

UnsetDangerZone

  • Turns off the displayed danger radius for unit s2

SetAllDangerZone

  • Turns on the Danger Radius for all enemies

I want players to know this feature exists, therefore I’d like to start chapters with this feature on where feasible & have a little ingame explanation of it.

Great work with this. The improvements you’ve made sound really valuable, too! Thank you for making this. :grin:

Edit:
A couple more that I personally would find useful but aren’t really necessary to most people. I am sorry for asking for so much!

CheckInDangerZone

  • Checks if unit of s1 is in attack range of unit s2

CheckDanger

  • Returns 1 true if unit of s1 is within attack range of any enemy. (Discluding staves?)
2 Likes

Events seem like a bit of a rabbit hole to go down into. I’ll see what I can do, but I haven’t looked into eventing before.

2 Likes

Alright, so I implemented the first four event commands that you mentioned, although I named them slightly differently. You can find the relevant ASMCs in the evro folder. I also made a macro for each of 'em which you can see in the evro/EventRoutines.event file. Do tell me whether I got their functionality right. As long as you #include “FE8-FogDR/FogDR.event” before your events, the event commands should be available (although they’ll probably be available either way).

I won’t be creating the last two event commands. They’re kinda tricky, and require me having a deeper understanding of both the vanilla method of calculating attack ranges for dangerzone and the rangerework changes to this. I may revisit this sometime in the future, but don’t hold your breath.

I’m very curious to what you’re planning to implement with these ASMCs so I’d appreciate it if you keep me posted!

2 Likes

Like everyone else has said, outstanding work, but I was wondering if you could help me with something. My idea was to use the “Set all units range” as a menu command (like “status” or “end turn”), but there is a delay between pressing it and the ranges being toggled. What happens is that when I press it, the tiny icons appear, but the ranges only appear if I click on a unit, then unclick. (https://i.gyazo.com/4e365794a5653d1cf60703007d9a85de.gif) This is the kind of thing that isn’t dealbreaking, but if there was any way around it, it would be cool to hear.

Yeah, it probably needs to call RefreshFogAndUnitMaps (0x801A1F5). I’m not sure where to begin with this. I’ve not yet looked at how menu commands work. If “Set all units range” is a routine in asm could you maybe point me to where I can find it?

If “Set all units range” is a routine in asm you could try hooking into it and calling RefreshFogAndUnitMaps, which doesn’t take any parameters.

Alternatively, I should probably look into setting byte 0x0202BCB0 which could also reset the fog if it’s nonzero.

There’s a hack which lets you call events with menu commands. I’m using the “set all units’ range” macro you made in the event, and if I add that call to the event, then it should work fine. It might be a good idea to make it so that if “set all units’ range” is called, but all units’ range are already called, then all of them are turned off as well, but that’s only a suggestion.

Oh in that case it should be easy, I’ll just add a call to RefreshFogAndUnitMaps in the ASMC.

I’ll just create an “unset all units’ range” variant instead of giving the “set all units’ range” two possible outcomes.

2 Likes

The only problem with that is that I can’t off the top of my head figure out a way to make the menu command know whether all units are displaying range or not in order to know whether to toggle “select all” or “deselect all”. I could either A. have both a “select all” and “deselect all” option in the menu, B. have the event toggle a flag so that when it’s used again, it uses the opposite command (the only problem with this is that if the player manually toggles every enemy, then uses the command, their ranges will be toggled again instead of detoggled) or C. not use the deselect command at all. I wonder if you could make an assembly hack where it returns whether every enemy is toggled or not. Oh, and thanks for the help so far!

EDIT: Success!
(https://i.gyazo.com/4b8034e2b5f2a7dc27ce500c54f5bd21.gif)