Project MMO

Project MMO

10M Downloads

[1.19.2] Server crashed & infinite loop of death after breeding ProductiveBees bee

Hiranus opened this issue ยท 4 comments

commented

Describe the bug
Server died and wont launch because it instantly dies again.

Expected behavior
Server doesn't crash.

To Reproduce
Steps to reproduce the behavior:
In my case I bred Pink_slime Bee and Kamikaz Bee. You will need ATM8 pack with added PMMO if you want to recreate exactly same scenario, but I don't think its 100% needed. I would do more testing but game wont launch.
Versions:

  • Minecraft: 1.19.2
  • Loader: forge-1.19.2-43.2.11
  • PMMO: pmmo-1.19.2-3.1.0
  • All the Mods 8-1.0.17

Additional context
crash-2023-06-18_00.06.35-server.txt

commented

@Hiranus do you have breed reqs turned off? I'm looking into this issue and want to be thorough in my fix.

commented

This was written by creator of Productive bees on his discord when I showed him crash report:

the fault is with pmmo
they assume that a field has a value despite being marked as nullable
if you report it to them it's this line https://github.com/Caltinor/Project-MMO-2.0/blob/1.19/src/main/java/harmonised/pmmo/events/impl/BreedHandler.java#L42
and BabyEntitySpawnEvent::getChild() which they call, can return null

commented

@Caltinor it seems that this can be recreated with PMMO and ProductiveBees or any other mod that adds mobs species that can be breedable, but for some reason this specific animal is not. In my case I tried to breed breedable bee (pink_slime, but can be any other bee) and non-breedable bee (kamikaz bee). Its similar case as if parent was neutered but breeding still occurred.
Breeding code is launched, but because one of the parents can't have children, child is set to null, but PMMO assumes that some child will be there and it freaks out.

After crash loop I tried fix it by setting:
"BREED Req Values Generate" = false
"BREED Xp Award Values Generate" = false
but it didn't do anything. I had to remove PMMO to get my game to launch.

commented

I see. I asked about the req, because the method that gets called in the crash actually gets called once before the line where it crashes and the only escape parameters are if reqs are off or if you use a fake player (like create deployer) to do the action. If you don't have reqs off or meet any of those conditions then the entity is becoming null versus started null and that's a different fix.