Harvesters spawn in nether when spawning is disabled
Laike-Endaril opened this issue · 9 comments
Dimension ID whitelist is set to true (whitelist mode) and list is empty.
Spawn weight is also set to 0.
Note: using mods which add new biome types to the nether, namely Nether Ex. Unsure if this is involved.
If spawn weight is 0 he is indeed never supposed to spawn. First have you restarted the game after changing the config?
Second: share the whole config and the mod list, to see if something could be going on there.
Yes, I restarted the game, after which he still spawned. I then set the 1/x probability to 1/1000, and had him spawn again (did not do a thorough frequency test though)
Here is the config file
And here is the mod list, but you won't be happy with the quantity lol
Forge stable (2768)
I can do more testing on my end later today. Should be able to at least tell you what other mods are involved (if any), so if you want to let it sit until I do that, that's fine. And understandable, given the number of mods. Especially since a few are not the most recent versions, for specific reasons.
Right, so far I've been unable to reproduce in some small dedicated tests:
Harvester's Night only
Harvester's Night + Nether Ex
Harvester's Night + Alternate Spawn System
But I created a new world on my modpack and went to the nether, and he spawned immediately. I also took a look at your source, and yeah...I see that condition you put in for whether the spawn weight is > 0. Pretty sure this is the fault of another mod. Just not sure why the only thing it's affecting is the Harvester. I haven't had any other bosses or mobs spawn in strange ways so far.
I'll keep looking for now.
if (canSpawn == net.minecraftforge.fml.common.eventhandler.Event.Result.ALLOW || (canSpawn == net.minecraftforge.fml.common.eventhandler.Event.Result.DEFAULT && (entityliving.getCanSpawnHere() && entityliving.isNotColliding())))
if (canSpawn == net.minecraftforge.fml.common.eventhandler.Event.Result.ALLOW ||
🤔
Something is probably altering the event result, therefore bypassing the configs (which are used only if the event result is not set to ALLOW by something).
Maybe I'll add some debug code in right there to poll the event listener list and see if it points some fingers for me
.
===============================================================
Edit 1:
@SubscribeEvent (priority = EventPriority.LOWEST, receiveCanceled = true)
public static void checkSpawn(LivingSpawnEvent.CheckSpawn event)
{
if (event.getEntity().getClass().getName().toLowerCase().contains("harvester"))
{
System.out.println(event.getResult().name());
}
}
[17:16:57] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:185]: DENY
[17:16:57] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:185]: DENY
[17:16:57] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:185]: DENY
[17:16:57] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:185]: DENY
[17:16:58] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:185]: ALLOW
Well, I confirmed that something is setting that event to ALLOW, which bypasses your configs. Still don't know which mod is doing it yet; seeing what mods are watching the event is not doable in the way I thought it was doable.
.
=======================================================
Edit 2:
@SubscribeEvent(priority = EventPriority.LOWEST, receiveCanceled = true)
public static void checkSpawn(LivingSpawnEvent.CheckSpawn event)
{
if (event.getEntity().getClass().getName().toLowerCase().contains("harvester"))
{
if (event.getResult() == Event.Result.ALLOW)
{
try
{
Field f = ReflectionTool.getField(EventBus.class, "busID");
Field f2 = ReflectionTool.getField(ASMEventHandler.class, "owner");
for (IEventListener listener : event.getListenerList().getListeners((int) f.get(MinecraftForge.EVENT_BUS)))
{
if (listener instanceof ASMEventHandler)
{
System.out.println(((ModContainer) f2.get(listener)).getModId());
}
}
}
catch (NoSuchFieldException | IllegalAccessException e)
{
e.printStackTrace();
}
}
}
}
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: darkutils
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: alternatespawnsystem
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: betterwithmods
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: betterwithmods
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: quark
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: quark
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: charm
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: charm
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: multimob
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: wearablebackpacks
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: witherskelefix
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: pvj
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: nmsot
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: endreborn
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: betterwithmods
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: clef
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: lycanitesmobs
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: colorful-sheep
[18:07:24] [Server thread/INFO] [STDOUT]: [com.fantasticsource.dynamicstealth.DynamicStealth:checkSpawn:197]: dynamicstealth
I feel like this list should've been far easier to access. Anyway, now I know exactly which mods to check. Hope you aren't getting annoyed at the lengthy posts; I just figure this process could be pretty useful for future debugging of other mods in general.
...
I can't seem to reproduce with only those mods installed, even with identical configs on every mod (copied files)
Which is to say that my debug messages never even occur, meaning the event is normally not called at all. I suppose a third mod is causing the event to be called when it shouldn't be, and then one of these mods is making it return "ALLOW" when it shouldn't.
This time posting to make sure you're not trying to replicate using the shortened mod list, since it would be a waste of your time.
I'll try to avoid any further posts until I've at least found the offending mods, or completely given up on doing so.
Thanks for taking the time to actually look into your own issue, but if you have the Harvester config like that there's another issue: if the weight is set to 0 he should not have a spawn entry in the first place.
So that probably means another mod is making a spawn entry for it. At least I suggest (since you have a mod you can use for debug messages) trying to find the spawn entries for the nether biome and see if they match the Harvester's config. Those should have the same weight as the config and group size of 1, and if the weight is 0 the entry should not even be here in the first place.
I don't know if it's possible to see which one would be adding one, but if there's one then there's already a problem.
I'm actually just adding temporary debug code to uncommitted builds of one of my mods :P
Yes, some mod is creating an entry...is it possible to find out which mod created a spawn entry?
That being said, I at least found something: NetherEx saves spawn entries for nether biomes to json files. These are generated each time you visit the biome though (or at least the first time you visit the biome after loading the world, each time the game is run)
{
"entity": "harvestersnight:harvester",
"creatureType": "monster",
"weight": 5,
"minGroupCount": 1,
"maxGroupCount": 1,
"spawn": true
},
You can see that the weight (5) matches the default weight of the harvester's night config. But I still don't know what's actually adding it.
In Harvester's Night code...
if (HarvestersNightConfig.harvesterWeight > 0) builder.spawn(EnumCreatureType.MONSTER, HarvestersNightConfig.harvesterWeight, 1, 1, ForgeRegistries.BIOMES.getValuesCollection());
So it will add the entry so long as spawn weight is not 0, no matter what's in the dimension list settings. Normally this is fine, because when it checks spawn, it uses said list.
Now if I add in Alternate Spawn System, it bypasses the dimension list due to setting the event result I mentioned earlier to ALLOW, but this is still only when the spawn weight is not 0.
There is some other factor in play that I haven't found. The issue doesn't occur with only these mods installed and a weight of 0.
If you were to subscribe to the SpawnEvent and DENY/cancel it based on the dimension list, that would probably work...but it might prevent explicit spawns in those dimensions (from eg. spawn items) as well, and I would still have this unknown factor possibly messing up some other mod's spawning down the line :P
In any case, I think I might be reaching my limit. I've already spent about 10 hours on this in the last couple days. At this point I think I'm willing to just do a workaround using In Control, and fix any future erroneous mob spawns the same way, if such a thing happens.
The root cause lies outside Harvester's Night, and I honestly don't have any solid suggestions for improvements on your end regarding this. I feel like it's entirely caused by other mods, so I'll close this issue.
Thanks for putting up with my long-windedness
If NetherEx saves spawns in its json, maybe it generated them before you actually configured Harvester's Night, and thus it used its already cached entries instead of finding a new one (that would have been updated by changing the config). At least that's my guess.
Anyway, hope you find either what causes it or at least a workaround.
I did think of that, but it re-generated the entries in the file after I changed harvester config and restarted the game, removing the existing entry (and the harvester stopped spawning). But in the full modpack the issue remained.
I made a 2-line "In Control" script which is working (spawn.json):
[
{
"mob": "harvestersnight:harvester",
"result": "deny"
}
]
This prevents all his natural spawns (probably by setting the aforementioned event result to DENY), but does not prevent him from spawning via item (which is what I was going for). I've added a crafting recipe for his spawn egg, and everything seems to be working atm