Carry On

Carry On

Mods
108M Downloads

NullPointerException on player replacing a block with a carried TiledEntity

Nexonus opened this issue ยท 3 comments

commented

Hi, I've just installed the mod but I've noticed an odd crash happening each time the player replaces a block with a tiled entity having a GUI screen. Here's a quick summary of the issue. Hope I can help! :)

Expected Behavior

  • When a furnace block is placed and player opens up the GUI (opening it very quickly after the block is placed), a properly aligned menu should show up and a NullPointerException shouldn't be triggered.

Actual Behavior

  • When the player holds a furnace block (And they place it on top of a tall grass block, or any other replaceable tile) the GUI opens up exactly at the same time as the tile entity is placed. This presumably causes the game to refer to a non-present pointer of the Recipe Book causing a NullPointerException and an immediant crash.

Steps to Reproduce

  1. The player needs to pick up any tile entity with a recipe book (ex. blast furnace, smoker, furnace)
  2. Afterwards place it on top of any replaceable block - for example tall grass or a flower.
  3. When done, the game should freeze and crash. This will not work for crafting tables, but it seems to cause chests to play an opening animation for a short period of time.
  • I recommend to check for a condition when a block is replaced, this seems to cause the issue. Almost as if the player placing down a carried block caused them to open up a tiled entity's container.

Version of Minecraft, Carry On, Forge/Fabric

  • MC 1.19.2
  • FORGE 43.3.0
  • MOD 1.19.2-2.1.1.22

Screenshots encouraged

Screenshots displaying this: "oddly aligned GUI for furnace and blast furnace". Notice - this won't work for crafting tables.
crash1
crash2

Crash report:

crash1_report.txt

commented

Oh, maybe #569 is this issue, not IW compatibility issue.
And 1.20 is normal, no crash.

commented

I'm pretty sure I didn't have IW installed.
This happened on vanilla Minecraft blocks which similarly to IE's soot can be replaced - But it seems to cause the same behavior, so good catch :)

commented

From what I can tell, this is likely connected to forge 1.19.2, as I cannot reproduce this in 1.20 anymore. My code that handles this interaction has stayed the same however. I remember this happening in 1.18.2 as well, but I cannot reproduce it in 1.20 anymore, nor can I fix it in 1.19.2 or in 1.18.2, sorry.