Putting kelp roll on cutting board cause chunk to be unreachable
csbrown9338 opened this issue ยท 13 comments
Minecraft version
1.18.2
Farmer's Delight version
1.2.2
Forge version
40.2.9
Description
I made a kelp roll and I saw that the recipe to make a kelp roll slice was to put it on a cutting board and chop it with a knife. Doing so, however, caused the chunk to crash and kicked everyone within that chunk. We were able to get out of the chunk by teleporting everyone to a different player (who was far enough away that their chunk was not affected), but now no one can get in the vicinity, and no where near close enough to try and see if removing the cutting board will solve the issue.
Steps to reproduce
- Create kelp roll
- Right click cutting board with kelp roll in hand
Mod list
Modpack: Dawncraft 1.26
Logs
No response
Minimal instance
- I have tested this on a minimal instance
Performance and shader mods
- I am using performance or shader mods
Please post your crash logs here, so I can see what went wrong.
Testing on a minimal instance, placing items on a Cutting Board works fine. I suspect some other mod is interfering with it.
Unfortunately, I don't have the logs, since I'm not admin
We just removed the cutting board by filling the block it was occupying with air
I can test it on a minimal space, but I will probably do that possibly tomorrow
Thanks for checking anyway. ๐
Tomorrow, if you can, do test this bug in your current setup as well, and save the log. Crashes will always contain the error and stack trace of what happened, so it's easier to identify what caused it.
Actually, thinking about it, I don't think there were any logs available since the server itself didn't crash
When the server host checked, they didn't see anything, or it was too far up by the time they checked
Regardless, I will try it tomorrow with the same versions on a private world
Is there any way to look at logs in a single player world?
A player on our server (also Dawncraft 1.26) is having a similar issue, here is their message (it's a client crash, not server crash)
"me and my friend were cooking food on the "Farmer's Delight" mod, and when he placed potatoes in the pan, the both of us crashed"
This is their log https://mclo.gs/cemFOYN
And their crash report https://mclo.gs/rqt5ZJo
They tried disabling Rubidium and Oculus and "It worked for like 5 seconds and then it crashed me" with this crash report https://mclo.gs/txG7gPH
And one more "Alright so i just tried to join the server and i was able to move my mouse around, but when i started to actually walk i crashed
heres the crash report for that https://mclo.gs/E3P4IE1 "
I tp to that place (I had no issues, the only difference was I disabled all resourcepacks), tried breaking the skillet (the block they say was a pan) but they weren't able to join, then I broke a nearby cutting board, and that worked.
This is the data of the cutting board
"farmersdelight:cutting_board", Count: 1b, tag: {BlockEntityTag: {ForgeCaps: {"improvedmobs:opened_flag": {HasBeenOpened: 1b}}, IsItemCarved: 0b, id: "farmersdelight:cutting_board", Inventory: {Size: 1, Items: [{Slot: 0, id: "minecraft:torch", Count: 1b}]}}, display: {Lore: ['"(+NBT)"']}}}
Have some findings.
- On Dawncraft, if the Excalibur and Excalibur Mod Support packs are enabled it crashes if the cutting board has the torch, without those packs there are no issues.
- Tried fresh 1.18.2 instance with forge 40.2.9 singleplayer, only Farmer's Delight installed and the 2 resource packs. If no pack is enable, the cutting board with torch is no issue. If only Excalibur is enabled it crashes. If only Excalibur Mod Support is enabled it doesn't crash. If both enabled, it crashes
So the root of the issue seems to be the Excalibur resourcepack, which is weird, because as far as I can tell, Dawncraft uses an old version which is the one it has being using since the beginning
I got the crash report from the first time I crashed:
crash-2023-07-20_22.09.51-client.txt
I tried to replicate it twice (in the same setup with Dawncraft), both times, right clicking the cutting board with the kelp roll in main hand didn't cause any crashes, so i tried to do what the other user did and see if the torches were the cause. It's possible that I had a stack of torches in my off hand and accidentally went to an empty slot.
This one is with the torch in main hand:
crash-2023-07-21_18.32.08-client.txt
This one is with the torch in off hand:
crash-2023-07-21_22.13.40-client.txt
My findings and error logs appear similar to jmadarg's
Thank you both for all the thorough investigation you did! It helped a lot. ^^
Yes, it seems to be specifically the custom torch model from Excalibur which crashes; nothing else triggered it. FD 1.2.2 introduced a fix for Cutting Board rendering which affected items with custom perspectives. This "fix" might have introduced a bug related to this custom torch somehow. I'm also trying to see if this bug is related to Rubidium or not.
I'll see what went wrong locally, then get back to you here.
Excalibur's torch model defines cuboids in both its block and item .json's. Apparently, on 1.18.2, this causes handlePerspective
to consider it unchanged, therefore skipping an important PoseStack push. This causes the crash down the line. ๐คฆโโ๏ธ
At least the fix is simple enough. Just gotta test it against a few other items, and a hotfix should be ready. This problem only seems to affect 1.18.2, too; due to how the method works on 1.19 and beyond, it doesn't happen in them.
So... although my changes fix the bug on this issue, they revert the fix on perspective models. There isn't a reliable way for me to control the PoseStack pushes when using the handlePerspective
method without breaking the original fix.
What I'm thinking here is to add a new tag: flat_on_cutting_board
. I was already going to add one, because Trident and Spyglass have wonky rendering unique to them, and they'd be tagged by default; but at least on 1.18, it might have to be used for any items with perspectives.
Commit 18c73e6 resolves this issue with the tag mentioned above. If any items render wrongly upright on 1.18.2, they will need to be added to the flat_on_cutting_board
tag.
This should be out for version 1.2.3 soon-ish, and I might bring this tag on 1.19+ as well, for edge cases.