Aversion Obelisk won't work when incontrol is present with config files
misterplus opened this issue ยท 17 comments
Issue Description:
Aversion Obelisk won't prevent mobs from spawning when incontrol is present with config files
What happens:
When incontrol is present without config files, the aversion obelisk works as expected. But with configs for incontrol, it stops working completely.
What you expected to happen:
The aversion obelisk should still work correctly.
Steps to reproduce:
1.Install Ender IO and incontrol
2.Write any correct rule config for incontrol
3.Aversion obelisk doesn't work
...
Affected Versions (Do not use "latest"):
- EnderIO:1.12.2-5.2.59
- EnderCore:1.12.2-0.5.76
- Minecraft:1.12.2
- Forge:2847
- SpongeForge? no
- Optifine? no
- Single Player and/or Server singleplayer, should be in server as well
Your most recent log file where the issue was present:
https://paste.ubuntu.com/p/xC89tST46H/
[pastebin/gist/etc link here]
Just in case the author of incontrol wants to say something, I'll link the other same issue here: McJtyMods/InControl#209
That's a bug in incontrol then. They need to fire the correct events for us to tell them that they should not spawn.
FYI, In Control listens to this event to add spawns under certain conditions:
WorldEvent.PotentialSpawns
But the actual spawning is left to vanilla Minecraft
FYI, I'm trying to prevent zombie pigman spawning on netherracks in the nether.
@SubscribeEvent
public void onEntitySpawn(LivingSpawnEvent.CheckSpawn evt) {
^ our code. If that stops working, you're messing up mob spawning events.
Sec, I'll link the code. It's just a handful of lines...
PotentialSpawns? Let me look that one up.
Also, blazes and wither skeletons are still spawning as well. Seems like every mob is not preventable.
Nm, I know what's wrong. It's a user error. In Control also catches CheckSpawn on lowest priority. That means my CheckSpawn comes last and the reported used 'allow' there which will replace whatever EnderIO set. So he needs to use the correct setting in In Control. This is not a bug. It's just a feature that allows In Control to override things but this is easily preventable. So all is ok here :-)
You end your config with:
{
"result": "default"
}
That will set spawning rules to default for everything. Get rid of that
Let#s call it a feature that's not blatantly obvious about what it actually does ;/
Also, do you really intentionally override what other mods have set? Maybe only set ALLOW if it was DEFAULT, not when it was DENY?
A config like this: https://paste.ubuntu.com/p/q4S9ppBswv/ allows pigman to be blocked by the obelisk, but not wither skeletons and blazes, I'm guessing this is intentional now? Seems a bit too harsh for a mod interaction.
PS: also, "default" for not leaving it at DEFAULT but set it to ALLOW? Talk about weird naming choices ;) ;)
The idea is that In Control takes full control so it has to be able to override other mods. People are using it to do exactly that. Currently there are four possible results:
- 'allow': allow the spawn no matter what
- 'default': allow the spawn but still have the default vanilla rules of not spawning in a block
- 'deny': deny the spawn no matter what
- no result: keep whatever there was
I think he can solve his problem by removing all the 'allow' rules. And only keep the 'deny' rules
BTW, I have no extra tag for "caused by other mod but not technically a bug there", so I'm leaving the "bug in other software" tag on as it fits best.
https://paste.ubuntu.com/p/249NnMgMqm/ A script like this works, just remove the "result": default/allow