Huichelaar's Assembly Adventures

I’m not sure if the menu command can take an argument and compare the value in the argument to zero, but if it can, you could compare the byte in 0x0300 0006 to zero. If 0x0300 0006 holds value zero, then no enemy units have their DR set. If it doesn’t hold zero, then at least one enemy unit does have it set. I’m not sure if this gets you closer to what you want to have though.

On a related note. I added a DangerRadius2.s and corresponding .dmp to the asm folder of both versions. If you replace all instances of DangerRadius in FogDR.event with DangerRadius2 you’ll get the following functionalities as well:

  • Pressing select on a tile not containing an enemy unit will disable all enemy unit DR’s if at least one enemy unit’s DR is set.
  • Pressing select on a tile not containing an enemy unit will enable all enemy unit DR’s if no enemy unit’s DR is set.

I’m glad to see you got it working! What did you do exactly to get it to work?

1 Like

Oh, damn! Really? That’s perfect! That’s exactly what I wanted to do, and you did it just like that!

I mean, it doesn’t matter now, but like I said, there’s a hack out there that allows you to have a menu command call an event. So, the event it called first your “select all” command, and then the “refresh fog” command.

Ah cool, good job! As it turns out someone else requested a similar functionality before you did, so I was already working on it, that’s why it got here so fast. I’m glad everything worked out in the end!

How serendipitous. Anyway, thanks for all the help

1 Like

I was testing the Danger Radius patch and it has the same problem of the 127 might.
But now I know it wasn’t because of Elbow Room, the problem is the Charge skill (The one that gives +1 might for every 2 squares moved)
I removed the skill and the problem was gone. I should have tested that back then, totally my fault.

Yeah, I can reproduce the problem now! I’ll try to fix it asap.

EDIT:

Alright @Mikey_Seregon, I think I got it fixed now. Please tell me if you still run into issues!

On a different note:

  • I added an UnsetAllDangerRadius ASMC and corresponding macros.
  • All ASMC macros that used to take one argument, can now also take two arguments. If there’re two arguments, they are interpreted as coordinates (first X and then Y). Clearer details in main post. Be aware that these macros use SCOORD which may not be defined in every release of EA (it wasn’t originally in mine).
  • All ASMC’s except for CheckDangerRadius will also call RefreshFogAndUnitMaps (0x0801A1F4). Hopefully this will fix @Mkol’s issue without requiring them to call RefreshFogAndUnitMaps in their events.
2 Likes

It’s working now.
Thanks!

1 Like

I found a glitch with the new hack. Essentially, escape markers won’t appear unless they are within someone’s toggled range. (https://i.gyazo.com/3948cb6f587ad90eaff28f55b8dc939f.png) If someone’s toggled range is turned off, the escape icon doesn’t appear. (https://i.gyazo.com/c57f1893f5616fab847322e44b102920.png)

EDIT: If it matters, I’m using “DangerRadius2.dmp,” not “DangerRadius.dmp”

Thanks! I’ll look into it!

Actually, could you maybe send me a .ups patch or buildfile, so I could reproduce the problem on there? I don’t happen to have a ROM with an escape objective.

1 Like

The icon is below the first boss

1 Like

In case you’re using buildfiles, could you try disabling or commenting out any reference to Engine Hacks/QualityOfLife/DangerZone/DangerZone.event?

In the standard SkillSystems Engine Hacks/_MasterHackInstaller.event file there should be the two lines:

//Danger Zone (select button)
  #include "QualityOfLife/DangerZone/DangerZone.event"

I’m not sure if this is the case for your situation, but if so, could you comment out the lower line of these? If after building the problem persists, please send me a new .ups file

I’m actually using FEbuilder.

In that case, could you try applying the SkillSystem patch before inserting the FogDR.event?

It seems the skillsystems’ DangerZone patch wrote a hook where FogDR wrote a hook. These two patches are not compatible, but unfortunately installing SkillSystem also installs the DangerZone patch.

If you first apply SkillSystem and then FogDR, the FogDR hook will overwrite the SkillSystem hook, which should disable the SkillSystem DangerZone.

Alternatively, you could re-apply the FogDR patch, if you don’t want to go back to a version before SkillSystem was applied.

After further testing though, I think the problem lies elsewhere after all, I’ll investigate some more

1 Like

I believe I DID reapply the fog hack after installing the new skills system. I can try it again later if you want

EDIT: I tried reapplying the fog hack and it didn’t change anything

Yeah, I found the issue. I added some new files, and updated some others, could you redownload the whole thing and try again?

1 Like

Works! Thanks a ton.

Btw, maybe you should make dangerradius2.dmp the default instead of having to delete Dangerradius.dmp? Just a thought

1 Like

Fair enough. I switched their names, so now the one with the extra functionality is the default.

2 Likes

I found 2 bugs in the Danger Radius patch.

  1. The radius works fine the first time you turn it on, but after killing some enemies and then turning it off and on, the radius resets as if the enemies killed were still there. The radius doesn’t get updated.
  2. The radius doesn’t get updated when you play without animations.

Thanks! I’ll look into it. Could you DM me another .z7 or a .ups patch with a savefile?

EDIT: Glad we managed to solve the issues!

Alrighty, I’ve been working on a custom chapter opening for the past month. Am excited to finally share it! I’ve updated the first post.

29 Likes