Torchmaster

Torchmaster

64M Downloads

[1.16.5] Apotheosis Bosses spawns not blocked by Mega Torch

KajesLorian opened this issue ยท 12 comments

commented

Minecraft 1.16.5
Forge 36.1.0
Torchmaster-2.3.7
Apotheosis-1.16.4-4.5.2

Apotheosis Boss mobs spawn above ground in areas with Mega Torches placed.
Submitted a bug report with Apotheosis here: Shadows-of-Fire/Apotheosis#360

commented

I believe this is happening again in 1.18+, probably because bosses now fire off of SpecialSpawn.
https://github.com/Shadows-of-Fire/Apotheosis/blob/1.19/src/main/java/shadows/apotheosis/adventure/boss/BossEvents.java#L49

commented

Ah crap, I didn't even see your message. Thanks for reporting it. I'll look into improving the reliability a bit, but I will probably redesign the whole blocking logic with 1.20

commented

A 1.20 redesign of the logic should fix most issues, the spawn event chain was rebuilt from the ground up for 1.19.4+

commented

Could this become a feature that can be turn on and off through config please?

commented

Hello we were also trying to deal with this issue, is there a way to download 2.3.8 as a jar? Or are we waiting for the release for a bit still? I can't make sense of the files the link takes me to. Thanks for the great mod!

commented

I'm actually waiting for 1.17 to wrap things up in 1.16 but i guess that will take a bit more time.
Anyway, version 2.3.8 is still available from the Release Section on this Repository. Check the link I've posted above or just go to the releases section:
https://github.com/Xalcon/TorchMaster/releases

commented

Lol I'm blind, clicked on about 90% of the things before someone pointed it out to me. Thanks!

commented

Increasing the priority may work in this case but will break support for mods that don't check if another mod in the chain has already blocked/allowed a spawn. I'll need to look into apotheosis, maybe we can work something out that works for both sides.

commented

I've taken a closer look into the inner workings of Apotheosis and this less a bug and more a design decision on their end as well as a limitation on how spawning works in general.

The way Torchmaster works is by subscribing to CheckSpawn events which is used to check if an entity is allowed to spawn (duh!).
Apotheosis is using this Event as well and checks if an entity is a monster (lets call it MobA) and does some player distance and collision checks. If the checks succeed, it will attempt to spawn a boss monster (MobB). The issue here is, the spawn attempt checks for MobB do not create additional CheckSpawn Events - it simply assumes that if no other Mod in the CheckSpawn Chain blocked MobA, MobB can spawn as well, which is not necessarily the case - and all mods afterwards in the chain are simply ignored.

I could put my event handler higher up in the chain - which would block the spawn attempt of MobA and effectivly MobB as well, but will break support for Mods that "do it wrong". Technically, Torchmaster should be at Priority Highest to clearly communicate to other mods that torchmaster doesn't want a certain mob to spawn. Apotheosis on the other hand wants to replace the entity being spawned. It blocks MobA to spawn MobB. Now, spawning a mob inside a CheckSpawn EventHandler is weired at best. But creating additional CheckSpawn Events during an CheckSpawn EventHandler could cause all sorts of bugs (and even deadlocks/infinite loops if implemented wrong).

I dare to say CheckSpawn should only be used to Check if the spawn should be allowed. If auxiliary tasks should follow, like spawning mobs, this should happen after the CheckSpawn event, i.e. in the next tick. Now, I do understand that this is a special case since Apotheosis wants to effectivly replace the entity (spawn MobB instead of MobA), making this much harder to implement properly (if not impossible). If Torchmaster runs after Apotheosis (with Apotheosis intending to spawn the Boss in the next tick) and Torchmaster blocks the spawn of MobA, Apotheosis would have no clue about that.

how can we fix this? To be honest, I would love if Torchmaster could just run at Highest priority and trust other mods lower down the chain to do the right thing. Apotheosis is doing it right by checking if another mod in the chain already modified the event result. But there have been mods in the past that completly ignored what other mods where doing higher up the chain and overwrote the result even though their check failed and wasnt supposed to change the result at all.

My suggestion would be, that I move my EventHandler higher up in the Chain, probably at higher or highest priority. This event handler will allow apotheosis to replace the entity if torchmaster decides to not change the spawn result.
To support mods that ignore event results (Allow, Deny) set by mods higher up in the chain, I would register another optional event handler with lowest priority that does some sanity checks (i.e. did someone override my result?) and then act on those results depending on configuration settings.

@Shadows-of-Fire: Regarding changes to Apotheosis:
I'm not sure if there is anything Apotheosis can do to not spawn an entity during CheckSpawn without causing deadlocks or other bugs. I would like to suggest to switch from lowest to low priority though so that my optional fallback event handler can handle mods that "do it wrong".

commented

I've created a quickfix with my event handler running at HIGH priority which should fix the compatibility issue with apotheosis.
I would like to also re-add support for mods that plainly do it wrong, so I will not upload this version to curseforge but you can grab version 2.3.8 from the github release page: https://github.com/Xalcon/TorchMaster/releases/tag/refs%2Fheads%2Fmc%2F1.16-2.3.8
Could you test if this version works with apotheosis?

commented

Will do, and thanks for this! I'll let you know how it works for me.

commented

That fixed it! I noticed no Boss spawns within Mega Torch range over the course of three nights, and they still spawned fine outside of range.