Draco18s

Why not put the "is this enabled?" inside (as the first check) each event handler? Adding/removing subscribers at runtime is not possible as far as I know, due to performance reasons.

I already explained why. The item instances are different.

I think the problem is here: https://github.com/Yamahari/ILikeWood/blob/master/src/main/java/yamahari/ilikewood/items/WoodenScaffoldingItem.java#L57-L59 That call invokes: https://github.com/Yamahari/ILikeWood/blob/master/src/main/java/yamahari/ilikewood/blocks/WoodenScaffoldingBlock.java#L84-L86 Different wood types have different items.

https://github.com/Yamahari/ILikeWood/blob/master/src/main/java/yamahari/ilikewood/items/WoodenScaffoldingItem.java#L28 Oh geezus effing christ. If you're going to copy-paste vanilla code at least refactor all of the local variables so the code is fucking legible.

Yes, because when it errors it stops loading your mod for being improperly formatted. This is not a "stop the presses and burn down the building" error, its a "throw the drunk out" error.

blocks use loot tables now, so this is not helpful.

Almost certainly something else is happening. After removing the line, and it works, add the line back, touch nothing else. Does it break again? Try commenting the line instead of removing it. Try changing the strings being passed to the resource location. Make it private. Don't make it static.

File a bug report with the mod, because that's not kosher.

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/client/gui/GuiContainerSifter.java#L25

Creating a custom entity does not make the existing entity now your custom one. Its just dead code.

https://github.com/BlakeBr0/MysticalAgriculture/blob/master/src/main/java/com/blakebr0/mysticalagriculture/crafting/ModRecipes.java#L112-L122

No, because the super class does not return useful values. You need to return the correct values. Yes. Blocks cannot store data. Block classes are singleton instances, meaning that the data is shared across all blocks of that type. That's why you have a TileEntity for per-location specific data. Yes, essentially. There is already a "base block class" its called Block. "CustomName" is still a hard-coded string. And also a bad name.

I don't think Eclipse shows INFO level logging by default.

Forge also supplies an easier way of opening a GUI, not sure what the current name is, but it was Player#openGui(...). You'll still want to look at the vanilla gui classes to see how to handle player input and saving the data though.

player.openBook() would be implemented in more than one place. One would be server side (EntityPlayerMP) and one would be client side (EntityPlayerClient, I think). That's where you need to look.

You can get it by looking at their resources. Its just their modid and the filename of the recipe json. You will probably want to replace it with a dummy recipe instead, so that it's not missing (for advancements, etc) https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/util/RecipesUtils.java#L105

You have 64 characters worth of length available. Use it.

I don't remember many details back in 1.5.2, but I know for a fact that harvesting being affected by the block's material was true in 1.7.2 because I remember having this exact issue way way back then. I modded some in 1.5 and 1.6 as well, but not as much as I did in 1.7, so I'm pretty confident in my statement that materials affecting harvesting has been true for a long, long time.

There are some Forge-available functions to add new values to enums, though I'm not sure what the class name is, as it may have changed between 1.12 and 1.13 and you didn't say what version you're working with (1.12 by the docs link, maybe? Then it would be EnumHelper). Be aware that enums are sometimes optimized by the JVM and adding new values may have unexpected behavior.

If you don't register things the way you're supposed to, when you're supposed to, GOD ONLY KNOWS what'll go wrong.

Most things (like the FML lifecycle events, registering blocks, etc) are so wildly different, along with other changes such as the flattening of metadata and so on that it will be easier to start from scratch.

ForgeRegistries.BLOCKS.register(block); What? No. Bad modder, no cookie. The whole point of the registry events is that you use event.getRegistry().register(...) Ditto for your ModItems class. Similarly, this is useless: if (!event.getName().equals(ForgeRegistries.BLOCKS.getRegistryName())) { return; } https://bitbucket.org/chriss199815/whatdoiknow/src/b5f75d284115320e57b10671a8c1825fef6f716b/src/main/java/de/chriss1998/wdik/init/ModBlocks.java#lines-79 Use @ObjectHolder do not assign to fields yourself.

Just so we're clear: This is not your error. Its just the last thing the JVM vomits up when shutting down. It will always do this. It will do this even when quitting the game normally when there are no problems. Trying to "solve" this error is pointless. Its not even an error. It says so. It's a warning. This is: As such, making your thread title a thing that isn't your problem helps no one.

Your registry event method (the one that's actually registered) does nothing: @Mod.EventBusSubscriber(bus = Mod.EventBusSubscriber.Bus.MOD) public static class RegistryEvents { @SubscribeEvent public static void onBlocksRegistry(final RegistryEvent.Register<Block> blockRegistryEvent) { // register a new block here LOGGER.info("HELLO from Register Block"); } } The one that actually does something, isn't registered as an event handler: public static void registerAll(RegistryEvent.Register<Block> event) { // Verify we are getting the correct registry event. If not, just silently return. if (!event.getName().equals(ForgeRegistries.BLOCKS.getRegistryName())) { return; } // This could be on one line, I typically break before each chained method call on // Block.Properties. You can break up the line however you like. If extending a block class, // I usually create the Properties in the new class' constructor, instead of here. blueStone = register("blue_stone", new Block(Block.Properties.create(Material.ROCK) .hardnessAndResistance(1.5f, 6f) .sound(SoundType.STONE) )); }

Because of the way you wrote your code ("take the current block state, discard its metadata, create an item stack"), you created a block that doesn't exist. Notice how your oredict code loops over several metadata values for the same block: But that none of those are the same as what you said you right clicked. This is why PickBlock() exists.