Minecraft 1.15.2
LWJGL 3.2.2
Fabric 0.8.2+build.194
Carpet Mod 1.3.19

When you die while attempting to craft something while the recipe book is open, the game crashes (java.lang.NullPointerException: Ticking screen).

Last four crash reports:
crash-2020-04-16_18.58.42-client.txt
crash-2020-04-16_18.59.55-client.txt
crash-2020-04-16_19.10.51-client.txt
crash-2020-04-16_19.19.23-client.txt

Steps to reproduce:

1. Have some XP on you.
2. Go near a crafting table and have some gold, iron, or any other craftable item materials on you.
3. Run: /script run death_handler(player) -> modify(player,'health',0);
4. Run: /script run __on_statistic(player, category, event, value) -> ( print(player+' | '+category+' | '+event+' | '+value); run('xp add @p -'+max(1,floor(value))); if(run('xp query @p levels')==0&&run('xp query @p points')==0,death_handler(player)); )
5. Open the crafting table and recipe book.
6. Craft as much as you want until the player dies from losing all of his/her XP.
7. The game crashes.

Edit: Also happens with the following items:

• Crafting Table (as originally stated)
• Furnace

A similar crash also occurs when you leave the recipe book open and opening the crafting table UI causes you to die: crash-2020-04-17_12.09.05-client.txt

Umm, I think it is fixd, I followed reproduction steps and it didn't work. it didnt crash

i take it back, i was just doing it wrong

tried as all - coudn't reproduce. 1.16. running carpet only (in the ide). Did you have other mods installed as well?

Java 8 Update 241
Minecraft 1.15.2 or 20w16a
Carpet Mod 1.3.19b
Fabric Loader 0.8.2+build.194
LWJGL 3.2.2
(The crash may only happen on specific versions of the above software, therefore you should try to have the exact same version. This includes Java)

1. Create new world in Creative mode with cheats on.
2. Look straight down.
3. /setblock ~ ~-1 ~ crafting_table
4. Open the crafting table.
5. Open the recipe book.
6. Close the crafting table UI.
7. /script run __on_statistic(p,a,b,c) -> modify(p, 'health', 0)
8. Open the crafting table.
9. Crash (player dies while recipe book open) -> crash-2020-04-19_20.03.47-client.txt

got it. forgot the 'open recipe book' step.

ok, its a vanilla issue that never has a chance to surface cause dead players cannot access crafting table. That's a sideeffect of a scripting language where you expose the possible behaviours to less intended cases. I will try to find a workaround. If I manage to reproduce in-game without scripting, will definitely report that to the Mojang team.

yes you can test in vanilla man. I think it sohuld just be a case of having a load of repeaters and then pressing a button which leads to command with /kill gnembon and then quickly rush over to ur recipe buk and then it's a simple matter of opening before rpeater reaches command block

but alas, that does not reproduce bug, as I guess player exits gui before dying, which is how you skirt around this bug in vanilla, and since you cannot modify player nbt to set health to 0 except via scarpet, this is actually not possible (at least I think) in vanilla, cos then (I think) first the player dies, then health is set to 0, whereas in modify(p,'health',0), first player health is set to 0, then player realises, oh wait, ive got 0 health, maybe I should go kill myself, and then you dont exit gui I guess, while all vanilla kill methods (which I've tried, eg. wither roses, campfire) will call the normal death method, which means that you do normal stuff, whereas scarpet sorta skims round the fine details.

Therefore, if there is no way to recreate this in survival, instead of creating a bug report, which has about a 10% chance of being viewed, a further 10% chance of being considered, and a further 10% chance of being acted upon (totalling in 0.1% chance of any change, of which there is a probability that it wont be a smart one, based on prior experiance with bugfixes, with exception to 0ticking)

In stead, I think it would be more practical to just make is so scarpet will call regular death, even for modify(p,'health',0). In fact, gnembon, if you want, I'll make the pr myself.

after that complex explanation, I actually read gnembon's message and saw that, lo and behold, he'd summarized it using about 22.8% of the text I used to write the same thing.

/script run __on_statistic(p, a, b, c) -> modify(p, 'health', 0)
simpler to reproduce

will probably handle that specific usecase in the API with a note what it causes. Would probably be enough to send a close screen to the player when health is 0, or maybe deferring setting that health to 0 to the end of tick as sufficient. The bug is properly client side, but carpet should assume there is vanilla player on the other side