Leaderboard

Everything is in the source code. World generation isn't handled by the Block class, it's handled by dedicated world generation classes. If you look for usages of Blocks.DIAMOND_ORE, you'll see that it's used in BiomeDecorator#decorate to create a WorldGenMinable instance. This is later used in BiomeDecorator#generateOres to generate veins of Diamond Ore.

Keep in mind that the onItemUse() method will be called twice: once on the server, and once on the client. That's why you're getting two outputs, since both calls are sending a message. You can check which side is calling the method from the World#isRemote member. In your case, the world is a parameter called w, so you can check w.isRemote to see the side. If isRemote is false, it's the server, if it's true, it's the client. For instance, if your code only does things on the server, you can simply bypass it on the client by putting this snippet at the top of your method body: if (w.isRemote) { return EnumActionResult.PASS; }

You can combine bools and integers in metadata. You just need to bitwise your data together.

EntityRegistry.registerModEntity has nothing to do with rendering/textures. It belongs in common code, not client-only code. The registryName argument is a registry name, not a texture path. The entityName argument should include your mod ID. The mod argument is the instance of your @Mod class, but you're passing the RenderManager instance (which is still null in preInit) instead. This isn't a mod instance, so the game crashes with a NullPointerException when Forge tries to get the mod ID to write to the log.

onArmorTick is common code, Minecraft.getMinecraft() is client-side-only, you can't do this. You have to set up a KeyInputEvent listener and send a packet to the server when the key is pressed. The server then checks to see if the action is valid, and if so, performs the resulting behavior.

Do you actually know Java? You can't just type an arbitrary name like that, you need to pass the method a ResourceLocation and a String. The ResourceLocation must have your mod ID as the domain. If you don't specify a domain, it defaults to minecraft. Entity registration must happen on both physical sides, so it should be done in your @Mod class or a class called from it. Render registration must be done by calling RenderingRegistry.registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) in preInit. This must happen only on the physical client, so it should be done in your client proxy or a client-only class called from it.

Well, thank you very much for this advice! I wrote my code based off of a YouTube Modding Tutorial, which would explain the ridiculous messiness. I guess this mod is gonna be put on halt until I know more Java and more about Forge. I'm gonna try to mess around with the code and try to do everything you all said, but if I can't figure it out, then I'll have to just wait until my brain is a little wiser in the area of code. And thank you, sir, for your comment! I will definitely go out of my way to learn more from this coding class. As for your tax dollars, I'm not sure if they go towards dual-credit college students, but I will nonetheless make your volunteering worth the while! Thank you all!

Have you tried looking at how Ender Pearls do this?

If you must register recipes in code (which I recommend against doing), use the registry events.

This is custom class and method. Logger is not necessary. If you want to make a logger like many modders do, create an object of type Logger (make sure to import one from log4j library, not java) and initialize it with LogManager#getLogger("mod's id or name") (again, make sure to use log4j one). Everyone usually does that in main class, or in utils. Use logger#info() to log information, logger#warn() to log a warning, etc.

You need to save the BURNING property to the metadata in DualFurance#getMetaFromState and then load it from the metadata in DualFurance#getStateFromMeta. You shouldn't be manually changing the TileEntity like you do in DualFurance.setState, just set the state to currentState.withProperty(BURNING, isBurning). Since you've overridden TileEntity#shouldRefresh to return true only when the Block changes, the TileEntity will automatically be preserved when the burning state changes. Vanilla only does this because it uses separate Blocks for the two burning states instead of one Block with a boolean property.

No, that is not what that is for. What that is for its when we should delete the tile entity and all of its data and create a new one.

Have you done this:

Any time you change from "burning" to "not burning" or from "not burning" to "burning" you need to call those methods.

You need to tell Minecraft that the status has changed. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/entities/TileEntityTanner.java#L95-L98 Don't forget to override shouldRefresh (neccessary if you're dealing with metadata states at all) https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/entities/TileEntityTanner.java#L231-L233

Use ItemStackHandlers. I don't know how ItemStackHelper.loadAllItems(compound, this.inventory) does its thing, you may be using it wrong.