Leaderboard

In order to let the client communicate with the server, you need to create your own packet. Have a look at my mod: https://github.com/RoyalAliceAcademyOfSciences/SimElectricity/blob/master/src/main/java/simelectricity/essential/utils/network/MessageContainerSync.java And register your custom packet during onCommonSetup(FMLCommonSetupEvent event) event: https://github.com/RoyalAliceAcademyOfSciences/SimElectricity/blob/master/src/main/java/simelectricity/essential/Essential.java If a class contains calls to the Minecraft class, it will crash on the dedicated server. Client-only classes are not available on a dedicated server. In this case, use a DistExecutor (used to be called proxy): public static CommonProxy proxy = DistExecutor.runForDist(()->()->new ClientProxy(), ()->()->new CommonProxy()); https://github.com/RoyalAliceAcademyOfSciences/SimElectricity/blob/master/src/main/java/simelectricity/essential/ClientProxy.java In your case, you should create a ClientProxy class and make a function to return the value of Minecraft.getInstance().objectMouseOver. One last thing, I think you should perform the raytrace on the server side instead of the client side.

Howdy You might find this working example useful https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe31_inventory_furnace It's also for a furnace, in 1.15.2 -TGG

Howdy Rendering of translucent objects is quite difficult because it is important to render the faces in the correct order. Normally, with opaque faces, it is straightforward because you can draw the faces in any order you like. When OpenGL draws a face, it checks the z-buffer to see whether the face is behind any other faces which are already in the scene. With translucent faces, this straight-forward approach doesn't work because the drawing order is important. Drawing face A then blending face B over the top of it gives a different appearance to drawing face B then blending face A over the top of B. For this reason, minecraft sorts translucent faces so that the ones which are furthest away are rendered first. You can see this by browsing through WorldRenderer::renderBlockLayer. I think (but haven't confirmed) that translucent faces still write to the depth buffer. It looks to me like, because you are rendering in last event which is after the translucent blocks have been rendered, your faces are being hidden behind the translucent faces, which have written to the depth buffer and will hence obscure anything that is behind them. This doesn't happen for some "transparent" textures like glass, because these use cutout textures not alpha blending. I.e. each pixel is either fully opaque, or fully transparent and doesn't write to the depth buffer. I don't know of an easy way to fix this, unfortunately. The most robust way to fix it is to render your blocks earlier, i.e. before renderBlockLayer is called in updateCameraAndRender. Perhaps a TileEntityRenderer might be the easiest way. -TGG

In your Forge Source look in net.minecraft.item#Food, and #Foods. You make the food item, and use a builder.

First, extending an interface is arbitrary the way you are doing it. IRecipeType does not need to be extended and can be just declared a static final variable using IRecipeType#register. Second, IRecipeSerializer needs to be extended on a ForgeRegistryEntry class. The reason I say this is even though you might have already done it is that if you looked at the original class, you can see it extends a basic implementation of a registry. So yes, you do need a RegistryEvent using the old method or could update to using DeferredRegister and RegistryObject.

Break it down. IForgeContainerType#create returns an instance of ContainerType based on its IContainerFactory. IContainerFactory has two create methods. One method contains three variables (the window id, the player inventory, and a packet buffer) while the other one returns the packet buffer as null. Because of this, one of your Container constructors must contain only the window id and player inventory or include the packet buffer as well. Similar to the tile entity, this is the default constructor being used to declare the type and will be updated when called correctly. For myself, I just use a new constructor instance of a container type with diamond syntax to assume the generic and then using a method reference operator on the correct class. Otherwise, you could just simply use the standard interface for your class.

https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a#nitty-gritty-random-things-ctrlf-section