Draco18s

Find existing usages of RayTraceResult.

Search the vanilla code for other references to it.

Don't. Because it happens during chunk load, the chunk hasn't loaded yet, so it pauses the load to fetch the chunk you're referencing, which is the chunk that contains the cauldron which is currently paused waiting for it to finish loading. Do that check in an update tick.

That was posted in May of 2017, so MC 1.10 most likely. Recipes were much more...run-time accessible at the time. How that particular mod did things I can't say (I can't even find the mod description, just a link to the twitter of the guy that made it).

You can get an idea of how I handle it here: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/HarderOres.java#L134 (I needed to support Silk Touch on a property that made no sense to be separate blocks) Magic registry stuff (old event-style rather than new DeferredRegister style): https://github.com/Draco18s/ReasonableRealism/blob/033da26f8ba4bcd25b0911aa9775764f12d7dbbe/src/main/java/com/draco18s/hardlib/EasyRegistry.java#L57 getPickBlock (reg names were dynamic, so this is a bit ugly): https://github.com/Draco18s/ReasonableRealism/blob/033da26f8ba4bcd25b0911aa9775764f12d7dbbe/src/main/java/com/draco18s/harderores/block/ore/HardOreBlock.java#L80 getStateForPlacement: https://github.com/Draco18s/ReasonableRealism/blob/033da26f8ba4bcd25b0911aa9775764f12d7dbbe/src/main/java/com/draco18s/harderores/block/ore/HardOreBlock.java#L90 I had to do some custom shenanigans for the loot table as well. But if your three items are sensibly named I don't think you need to do much that vanilla doesn't already support. It was just easier for me to write a loot condition that got the blockstate's numerical value and did a lookup on the item than it was to specify a 1:1 relationship in the loot table.

Why do you have this? Your class isn't the one being called by the JVM.

Yes, but you need a custom BlockItem that knows what state needs to be set.

Do you ever call getList()?

if cap IS the enderchest, then it CAN'T be null and vice versa.

Honestly this is a perfectly valid blockstate block. All three "versions" are a tea_kettle, but with some stateful information (full, empty, hot).

Your IDE should tell you to simplify this to Hand.MAIN_HAND

It doesn't. Welcome to The Flattening.

There are two hands.

First, second, third, and fourth.

Then why do you keep building piston contraptions?

Hooray! You did the same thing again! Only this time with lambdas! Lets put it this way, you have a chest on one side of your house with raw beef in it and have just built a new kitchen and you want to move all that beef into a new chest in the kitchen next to a furnace. Which makes more sense? A) Use pistons to move the old chest to the new chest's location. B) Take the beef out of the chest and place it in the new chest.

The fact that the code is inside "the separator" (or in my case, the millstone) I don't need to check if the block is the block I care about because the only time this will get called is if the player clicks on that type of block. They right click on a door? The door class gets the call, not the separator.

Take the items out of one capability and put them into the other.

https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/block/MillstoneBlock.java#L57

"Assign this local variable to the reference stored in this other local variable. Now, recycle these local variables." You haven't actually done anything except create two pointers to the same capability data (which you then feed to the garbage collector).

Your capability contains item stacks, right? Why not move the item stacks from one capability to the other?

This doesn't actually give the new player entity the capability data. Because orElseGet returns a value (in this case, your local variable, backpackHandler) in the event that the original getCap call returns null. No reference is made between the player object and this handler and as soon as your method returns, the inventory is lost. You need to copy the inventory from one capability to the other.

*Squint*

I wonder how entities and blocks do it and maybe it is applicable.

Loot is done with loot tables now, which handles the "random selection" process for you.