Please check any boxes that apply to you and your issue

• I use a translator application to post this issue.

• This is a crash. Please upload, Pastebin, Gist or copypaste the whole crash report along with this issue.

• This is a mod incompatibility. If I do this in vanilla Forge with only Et Futurum Requiem installed, it works normally.

Version number of Et-Futurum-Requiem (IMPORTANT)

EFR 2.5.0 e2c1d1c and various previous versions

Describe the issue (IMPORTANT)

Random crash that occurs on ANY entity at complete random. Happens with any entity, vanilla mobs, modded ones, particles, non living entities, you name it. ANY entity... More likely to happen when more entities are loaded. Have a world with exclusively 200 pigs in a hole, one of them will eventually trigger it. I've been forgetting to mention it here but this started in commits like a week ago. At the time no entity mixins had been updated. I can't think of what else could cause it, especially not in MoveEntity. I tried adding a null check to the step fix and it didn't fix it although I doubted that would do it.
I'll do a bisection test momentarily but sometimes I put issues here just so others can see. I have gotten a report that it apparently happens with bees enabled. This issue, likely sometime between bees and the last week.

Yes, this is EFR's fault, it happens even in a blank instance only with it. Still unsure when or where this issue is, all I mnow is this issue comes from EFR. Betting this is me stupidly missing something in plain sight. For now opening an issue report so I can keep track of all I know so far.

Various crashes, all on the same spot with different entities
crash-2023-08-22_23.28.36-server.txt
crash-2023-08-25_22.31.21-server.txt
crash-2023-08-25_22.31.22-client.txt
crash-2023-08-25_22.47.52-server.txt

Changing title to be more ambiguous because the code that is enabled when bees are enabled should not have any relation to this.

Random thing uh what happened to "deepslate_lit_redstone_ore"? I kindof access that one in GT6 and its gone now.

Caused by: java.lang.NullPointerException
at net.minecraft.item.ItemStack.func_77976_d(ItemStack.java:187)
at cpw.mods.fml.common.registry.GameRegistry.findItemStack(GameRegistry.java:371)

Edit: You are registerign a NULL ITEM to the Game Registry there, this is a big bug!

Deepslate lit redstone ore no longer has an ItemBlock. Blocks are allowed to not have inventory items (itemblocks), vanilla lit redstone ore, lit redstone lamps and other technical blocks also do this because they are unobtainable and do not need inventory items.

Sweet berry bushes and lava cauldrons were coded this way when they were added to EFR. It isn't a bug and is allowed by Forge.

Vanilla is the only one allowed to do that though, mods are not. That will crash the Game Registry when other Mods try to access the registered Object. Also pretty sure all the Vanilla ones DO have an ItemBlock registered to them, even if its just the default one. either Forge or NEI fixed that one.

Worked just fine, no one has had issues with past blocks that had no ItemBlocks. Probably suited for a different issue anyways.

They do not, you cannot give lit redstone lamp or lit redstone ore because hey do not have ItemBlocks. There is no inventory item. You will not find it.

And if you try with my itemless blocks it's the same thing. Mods that try to access it won't find it because it's not there. Trying to find an item that does not exist returns null as intended.

It does not crash when you try to give it, it just recognizes there is no item registered to that block.

I'll discuss more tomorrow morning in our DM if you think it is a huge issue.

Update: Only happens in dev

The particle one still can happen outside of dev. This issue gets more confusing as time goes on.

Dumb question, does your Bee or Particle not have a Bounding Box or Collision Box? Because you definitely add a NULL to the AABB list at the Collision Box, which is exactly what the Stacktrace is saying.

Pretty sure it doesn't but I can check in the morning. I do set size in constructor then never modify the bounding box again. But that still won't explain or fix it happening on other entities. If the bb was null they'd crash nearly instantly but this can happen after a while of no new entities spawning.

Some of those crash reports are on other entities, and can happen even in a superflat where bees will NEVER spawn. Try it, go in dev and throw like 20 pigs in a hole and it will eventually happen.

Back to the Entity Crash at hand, I got THIS crash after spamming a bunch of bees. And the TWILIGHT FOREST BUNNY did it somehow now. Are you sure its not some random mixin you added that causes this?

java.lang.NullPointerException: Ticking entity
at net.minecraft.entity.Entity.func_70091_d(Entity.java:600)
at net.minecraft.entity.EntityLivingBase.func_70612_e(EntityLivingBase.java:1490)
at net.minecraft.entity.EntityLivingBase.func_70636_d(EntityLivingBase.java:1814)
at net.minecraft.entity.EntityLiving.func_70636_d(EntityLiving.java:367)
at net.minecraft.entity.EntityLivingBase.func_70071_h_(EntityLivingBase.java:1611)
at net.minecraft.entity.EntityLiving.func_70071_h_(EntityLiving.java:206)
at net.minecraft.world.World.func_72866_a(World.java:2070)
at net.minecraft.world.WorldServer.func_72866_a(WorldServer.java:648)
at net.minecraft.world.World.func_72870_g(World.java:2034)
at net.minecraft.world.World.func_72939_s(World.java:1887)
at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:489)
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:636)
at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:547)
at net.minecraft.server.integrated.IntegratedServer.func_71217_p(IntegratedServer.java:111)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:396)
at net.minecraft.server.MinecraftServer$2.run(MinecraftServer.java:685)

A detailed walkthrough of the error, its code path and all known details is as follows:

-- Head --
Stacktrace:
at net.minecraft.entity.Entity.func_70091_d(Entity.java:600)
at net.minecraft.entity.EntityLivingBase.func_70612_e(EntityLivingBase.java:1490)
at net.minecraft.entity.EntityLivingBase.func_70636_d(EntityLivingBase.java:1814)
at net.minecraft.entity.EntityLiving.func_70636_d(EntityLiving.java:367)
at net.minecraft.entity.EntityLivingBase.func_70071_h_(EntityLivingBase.java:1611)
at net.minecraft.entity.EntityLiving.func_70071_h_(EntityLiving.java:206)
at net.minecraft.world.World.func_72866_a(World.java:2070)
at net.minecraft.world.WorldServer.func_72866_a(WorldServer.java:648)
at net.minecraft.world.World.func_72870_g(World.java:2034)
at net.minecraft.world.World.func_72939_s(World.java:1887)

-- Entity being ticked --
Details:
Entity Type: TwilightForest.Forest Bunny (twilightforest.entity.passive.EntityTFBunny)
Entity ID: 5590
Entity Name: Forest Bunny
Entity's Exact location: -714.50, 44.00, 607.50
Entity's Block location: World: (-715,44,607), Chunk: (at 5,2,15 in -45,37; contains blocks -720,0,592 to -705,255,607), Region: (-2,1; contains chunks -64,32 to -33,63, blocks -1024,0,512 to -513,255,1023)
Entity's Momentum: 0.00, -0.08, 0.00
Stacktrace:
at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:489)
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:636)

I'm certain; I changed NOTHING about ANY of the entity mixing when it started happening, or a mixin function would be the source of the StackTrace; mixins actually inject all into separate functions. The issue is somehow coming from an entirely vanilla line.
The small tweak to the step fix was weeks after the issue was already confirmed and did not make it any more or less frequent.

The crashes are happening on this line p_70091_3_ = ((AxisAlignedBB)list.get(i)).calculateYOffset(this.boundingBox, p_70091_3_); which isn't giving me any leads. The crash isn't happening IN the calculateYOffset function, so that means list.get(i) is null somehow.

one of three things can be null:

list itself, which I think is checked for != null earlier though
list.get(i) if there was a null Collision Box added to the List
this.boundingbox which MIGHT be modified by your mixin? only speculation

sadly all 3 of those are in the same line so the nullpointer exception isn't pointing properly.

I made sure to rule out the step fix by completely commenting it out and then trying to reproduce the crash, in which I could. So either the list itself, or the item in it, is somehow null.

The thing is putting a conditional breakpoint there also causes a ton of lag, to the point where the game runs too slow for any reliable test to be made...

Actually we know the boundingBox can't be null or it'd crash a few lines above at List list = this.worldObj.getCollidingBoundingBoxes(this, this.boundingBox.addCoord(p_70091_1_, p_70091_3_, p_70091_5_));, we call a function on the boundingBox which means that line would be the culprit of the NPE if it was null.

We also know it can't be the list itself because if it was null then list.size() would crash a line above where the loop starts instead of the code just below it.

So we've narrowed it down to list.get(i) being null

So what's adding a null item to the list? I've narrowed it down further to getCollidingBoundingBoxes in World.

What adds objects to the list are block.addCollisionBoxesToList, and two entity collision box checks. The former has a null checks and so that's probably not it, I've got my eyes on the code below it which lacks any null checks.

I also noticed this seems to happen in worlds with actual terrain far more. In my void testing wrold which is nothing but air as far as the eye can see except for a small stone platform, I tried the pigs in a small space test and did not get the error, but on a superflat it can happen. Which leads me to believe that the latter two loops in getCollidingBoundingBoxes are the culprit. If we can find exactly where a null item is being added we can possibly find the mixin that's sneaking null items into the list and causing a different area of the code to be blamed.

No, I don't see how it wouldn't throw an NPE there... hm... It seems every time I think I have a lead I just hit a dead end.

Reports that this happened in production. The world I tested on in prod could possibly be a factor in why I didn't get the crash.

Oh right yeah forgot to mention, that TF crash I pasted here earlier was also in prod and not dev.

Ok this crash report is COMPLETELY USELESS!!! I didn't check when spawning particles on the server, and somehow THAT CAUSES IT! This crash report is nonsense, but try it yourself! This actually fixed it! I cannot wrap my head around this? Seemingly instead of getting something like a class not found error, we get THIS misleading as hell error than erroneously blames random entities when bees spawn their nectar! Unbelievable...

But Git Bisect is correct, the line that enabled the nectar causes this issue. It was a bizarre error relating to nectar particles being spawned on the server, possibly throwing the entity list out of whack and generating a completely useless crash report that had me looking at the wrong part of the code for weeks!

Supposedly according to Git Bisect 9004ef60bd23e38cd8dc9501a425ffb635259555 is where it started.
I can be sure of this because villages seem to be susceptible to the crash. I went to a village and after tons of crashing, managed to get 50 villagers in a hole. I can only be in this world for a few seconds before the crash so it's a great way to test it.

So TL;DR the culprit the whole time was bees, specifically ones with nectar, somehow the particle code caused this bizarre error, meaning the entire time it was caused when a bee with nectar was present. Every single thing I claimed to make the issue more likely was likely a coincidence and a red herring, likely what actually was happening was the crashy areas had bee nests nearby which bees picked up nectar from the flowers.

Feel free to reopen if it still happens, but I am 99% sure it fixed it. I commented out the client world check, hot swapped the code and no more tha 5 seconds later the crash cameback.
It appears to be when a bee with nectar is present, the particle code did not check if it was on the server leading to this excessicely bizarre crash log.
Somehow that caused a crash log which randomly "blames" other entities.

I need to still test this, but yeah my twilight forest crash was AFTER i spammed a bunch of bees, and there definitely was vanilla flowers somewhere nearby.

Okay I went back into the crashing world and i was able to see bees with their beebuttparticles flying around, and I did not crash, so I guess it is fixed now.