Leaderboard

I am currently trying to create a concept where an item can be combined with another item in some sort of recipe serializer to create it so that one item is rendered like the other. The way I was approaching this was to just attach an nbt which holds an item registry name and then it gets the item when being rendered. The issue is that there is no easy way to override ItemRenderer#getItemModelWithOverrides to set this value. There are registry events but in all cases it would take removing that stack and rendering a different item in multiple different places which is just highly tedious. So, is there a way to hook into this method to have it check for the nbt first before trying to render the item? Any input is appreciated for methodology.

I've split your response into its own thread, now please provide your debug.log using one of the paste sites in my signature

I would recommend going into net.minecraftforge.common.ForgeModConfig and the net.minecraftforge.fml.config package in the source and looking at how they setup and register it. Then all you need to do is register the config in your main mod file's constructor using ModLoadingContext#registerConfig. The best I can do for a visual example is my classes for the Config and Main Mod File.

You should try to create a standard block model for the torch rather than using the one provided in Minecraft. Minecraft does a very strange thing with the torch by creating two extra cubes to render the sides of the torch without uv distortion. I'm not sure why they use this, probably someone more knowledgeable about how Minecraft was programmed could answer that. However, this sort of poses an issue when rendering. The torch by default is rendered as a cutout while the stained glass is rendered as translucent. This means that either the glass will be treated as a cutout (no variable opacity/alpha) or the torch will be treated as translucent (texture might incorrectly render at some places since it is still 16x2 or 2x16 on the cubes). The best way to fix this is just to adjust the torch element so that it is just a single block rather than 3 cubes that render the sides. If you have done that, the code should look somewhat like this for the torch faces: "north": {"uv": [7, 6, 9, 16], "texture": "#torch"}, "east": {"uv": [7, 6, 9, 16], "texture": "#torch"}, "south": {"uv": [7, 6, 9, 16], "texture": "#torch"}, "west": {"uv": [7, 6, 9, 16], "texture": "#torch"}, "up": {"uv": [7, 6, 9, 8], "texture": "#torch"}, "down": {"uv": [7, 13, 9, 15], "texture": "#torch"} This should remove the need for your block to be rendered as a cutout making it valid on any render layer.

Sort of, if you ran the setup command already, then yes. If no, then you need to run the setup command.

In your IDE under "referenced files" you will find the vanilla and forge source files.

Please recognize what version of Minecraft you are using before asking about a class. Some classes have been removed, others have been redone, and finally (in your case) some classes have been renamed. The easiest thing to do would've been to open up a source version with IBlockState (e.g. 1.12.2) and then looked at your current version (1.15.2) and then finding what has changed. In this case, a quick look would have told you IBlockState was renamed to BlockState. Second, the Block class methods are usually deprecated since they only check for that specific block. The BlockState class has the same methods without deprecation since they can check for multiple states of that block. Implementing and overriding deprecated methods are usually okay since most are reused in the BlockState. However, when we are calling those methods we should stick to using the BlockState function calls over the Block function calls. Deprecated methods usually are obsolete for similar reasons. Finally, the error message is probably because you most likely did not generate the specific files required for the workspace you are using. Although, you should use the latest versions since they do have some necessary updates that might fix some bugs you run into later on.

Mojang ships the jre if there where to update java every time a new one come out it will cost a lot in bandwidth and java 8 is LTS so why bother

I made a .txt file and converted it to .bat. I put this into the .txt: java -Xmx3G -Xms1G -jar forge-1.12.2-14.23.5.2768-universal.jar nogui Pause When I run the .bat file this error comes up: Error occurred during initialization of VM Could not reserve enough space for 3145728KB object heap.

The basic entity size (width and height) is defined when you create the EntityType registry object (example). This was also the case in 1.12.2, and hasn't really changed. This width & height is used to set up the entity's bounding box in Entity#setPosition(), which is used for the vast majority of entities (other than paintings, picture frames, leash knots and shulkers, which have their own setPosition() implementations). This bounding box is centred on the entity's X/Z position, with the Y position at the bottom of the bounding box (e.g. your player bounding box is centered horizontally at your feet, on the ground).