search

FatherToast / SpecialAI

Adds additional AI patterns to mobs to make the game more challenging. 'Passive' mobs will fight back, monsters will break light sources and wooden doors, some mobs gain random extra abilities, and villages are more... village-y.
8 stars 7 forks source link

[1.12.2] EntityAIBreakDoorSpecial is forced onto mobs #26

Closed SirSquidly closed 1 year ago

SirSquidly commented 1 year ago

Tested in singleplayer, 1.12.2 Forge 14.23.5.2859, with Special Ai version 1.1.0_for_mc1.12.2.

Oceanic Expanse has an incompatibility as the semi-complex Drowned cannot use AIBreakDoor, and is specifically had it removed. Special AI forces EntityAIBreakDoorSpecial, resulting in an expected crash.

Looking here are Special AI's code, I don't think this AI behavior is supposed to be applied to mobs not explicitly added to thedoor_breaking mob list. I could be misinterpreting it.

Adding oe:drowned 0.0 oe:pickled 0.0 to the AI list fixes the crashing.

Here is the crash log.

FatherToast commented 1 year ago

Hm, interesting. Must be something different about how the mod spawns drowned that breaks it. I can fix the crash from my side, but their drowned will probably still be incompatible with the door break AI.

SirSquidly commented 1 year ago

Hm, interesting. Must be something different about how the mod spawns drowned that breaks it. I can fix the crash from my side, but their drowned will probably still be incompatible with the door break AI.

Drowned are spawned like any other WATER_CREATURE, so this would theoretically affect entities like vanilla Squids or other mods' fish. Also, Drowned specifically don't have AIDoorBreak to prevent this crash.

Thank you for the fast reply as well!

FatherToast commented 1 year ago

Okay, I have made this completely impossible to cause crashes in this exact manner for future updates.

That said, I just realized this is in 1.12.2, which I am unable to support anymore, unfortunately. In my current source, it was doing an instanceof check before casting, but it wasn't storing the #getNavigation result, which means if the navigator changed between calls, it could crash. I don't have the 1.12.2 source, so I'm not sure if it is doing this check in that version at all (probably does not, hence the crash).

Either way, I'll close this out as there's nothing more I can do. I'm glad that adjusting the config avoids the problem, at least!