Draco18s

1) that boolean shouldn't be a class property: there may be multiple players breaking blocks at the same time. 2) you never modify the break speed.

That causes updates to the itemstack every tick, which isn't efficient.

It is currently considered good practice to use the registry name to set the unlocalized name: Item my_item = new MyItem().setRegistryName("myitem"); my_item.setUnlocalizeName(my_item.getRegistryName());

By the way, your main class is basically empty. Your item won't ever show up in-game because none of your methods ever get called.

You want it to run in Eclipse, I take it? Yeah, there's a runtime argument you need to add to the run configurations. -Dfml.coreMods.load=path.to.main.coremod_class I'm still pretty sure you can overhaul the combat system without coremodding, though. By the way... You will get virtually no help writing coremods.

You kinda need to register an entity renderer too.

For example: https://github.com/Draco18s/HarderStuff/blob/master/src/main/java/com/draco18s/ores/recipes/NEIIntegration.java

Compare written world time to the currnet world time + delay amount. If greater: Do your effect and write the current world time to the ItemStack's NBT. Else: Do nothing

That will crash a dedicated server. The server may not have a keyboard attached or know what a keyboard is. Not to mention having no fucking clue about the remote connection's keyboard status. You will have to implement this as a Capability / IExtendedEntityProperty that's set on the client via the Keybind class (don't ever directly reference the Keyboard: there are Keybinds for a reason, use them) and then use packets to sync. Then hold on a moment, you're looking at the shift key. Shift makes the player sneak. player.isSneaking done. Jesus.

There is not. You would need to handle every mod individually.

The right-click method has an ItemStack parameter and returns an ItemStack. Just return a different item stack.

All of this is bad: public ItemBase init(FMLInitializationEvent event) { GameRegistry.register(this); if(event.getSide() != Side.SERVER) { registerModel(); } return this; } private void registerModel() { ModelLoader.setCustomModelResourceLocation(this, 0, new ModelResourceLocation(TheMod.MODID + ":" + name, "inventory")); }

Mind there's also Smelting recipes (Furnace.getSmelting() iirc) and brewing recipes. Mods then may add their own recipes devices (grinders, sifters, macerators, crushers, extractors, compressers, canners, electrolyzers, injectors, washers, mixers...).

Even with no attached source you'll still get code hinting.

"Using" and "Reading" are two separate things: Eclipse can still use the jar to validate code that you right, it just can't show you the source.

The book is just an item that displays a GUI. In that GUI you can make it draw whatever you want.

Item.getItemFromBlock... gets...the item form of the block...

You gave it a model for the item but not the block. Also:

Along with that, don't use item.getUnlocalizedName().substring(5) , use getRegistryName . Then go punch whoever told you to use getUnlocalizedName.

Yes. Because you have a common class ( BlocClearInventory ) that contains sided code ( registerRenders references Minecraft.getMinecraft() ). As soon as the server reads your block class from the disk, it needs to make sure that the class is valid code. This includes loading every class referenced by your class. This means that it will then attempt to load the Minecraft class, which won't exist. This is not a question of "where is it called from." This is a question of "does the code exist." Your class contains CLIENT SIDE ONLY code. The mere existence of that code crashes the dedicated server, even if you never call the function from anywhere ever. This is why the registerRenders code must be moved out of the block class and into the ClientProxy.

Have you registered your block model with the rendering registry?

That's because you're looking at the raw bytecode for the mod, not the source code. If you wanted to read .class files as code, you'd need to decompile it first (fortunately Java is an open source format, albeit complicated). Or you can write it as a mod, as diesieben suggests.

I'm not quite I see the error. I apologize, I didn't realize your main class was named "Chest." What I saw was the openGui command that vanilla uses to open chests, not the mod-specific openGui. You should refactor -> rename your main class so it's some like "MoreChests" or better still "MoreChestsBase" or "MoreChestsMain" so it's clear that it's your base or main mod class file.

If you smelted to a custom item then you'd be able to tell. But yeah, smelting isn't supposed to give you a lot of exp.

You need to add BOP to your gradle.build file under Dependencies