Draco18s

Don't do things that consume lots of system resources.

If you want your slots to be discriminatory, you need to write your own subclass. eg: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/inventory/SlotDust.java

Change Slot to SlotItemHandler.

You need to use packets. The server doesn't know dick about keybinds and the client's NBT data gets overwitten by the server's copy.

You can do both. But registering the class object means the methods have to be static. (You can also register via an annotation this way) Registering an instance, they must not be.

Also, make sure your texture is 256x256 (you can leave the non-UI parts fully transparent)

Use the registry events. In the Register<Block> event, create your blocks. In the Register<Item> event, create your items. Magically, everything will work, because the Block event fires first.

Your "can extract" properties aren't serialized anywhere. They just sort of...exist. Trying to apply that property to your block succeeds...but the values aren't encoded in metadata (nor is there enough space) so setBlockState(...withProperty(CAN_EXTRACT_UP, true) doesn't actually change anything. If you want the values to be stored in the tile entity, you have to override getActualState(). On top of that, getPropertyFromFacing() goes entirely unused and suggests that your "can extract from" values directly map to the current facing...meaning you don't need the CAN_EXTRACT_xx properties at all! All you had to do was match the enum facing passed to getCapability with the block's current facing!

Not a TE, but the process is much the same: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/client/gui/GuiContainerOreCart.java The function at line 71 handles the buttons.

ok, this is just awful code, right here: https://github.com/Lance5057/Tinkers-Defense/blob/master/src/main/java/lance5057/tDefense/TinkersDefense.java#L60 I shouldn't even have to explain why.

This is super old code (for 1.7.10) but it might be enough to get you started. https://github.com/Draco18s/HarderStuff/blob/master/src/main/java/com/draco18s/wildlife/integration/NEIIntegration.java https://github.com/Draco18s/HarderStuff/blob/master/src/main/java/com/draco18s/wildlife/integration/RackNEI.java

I fucking hate this: @Mod.EventHandler public void init(FMLInitializationEvent e) { proxy.init(e); } @Mod.EventHandler public void postInit(FMLPostInitializationEvent e) { proxy.postInit(e); } NO. DON'T PASS OFF THE EVENTS TO YOUR PROXY. FUCK. JUST DO THE STUFF RIGHT HERE.

1) ALL block methods are deprecated. Deprecated means "do not invoke" as you are supposed to only call the same methods from the IBlockState object, not the block class. You are perfectly fine implementing and overriding these methods. 2) https://minecraft.gamepedia.com/Redstone_circuit#Power

Yes, because: super(ModBlocks.cropCorn, Blocks.FARMLAND); Your item has a reference to your block and your block has not initialized yet, so this field is null.

Your project does not contain either a client or server proxy, yet you are telling Forge that you need them: https://github.com/Sarelm/Dynams/blob/master/Dynams.java#L27-L28

Required by Forge that all non-vanilla loot pools have a name. This is so they can be identified. None of my code deals with finding a pool by name (I don't need it and vanilla pools aren't named helpfully--they get an autogenerated name). Not necessarily unique, but I think it needs to be unique relative to that table. I'd say "don't inject raw json data." But yes, it would. I don't think so. I'm not sure where LootEntryTable falls in the grand scheme of things off the top of my head.

Yep. Read your errors. The fifth or sixth one down is this: This is why you should install a JSON editor plugin in Eclipse.

You don't need to. The baked quads are already available.

If you change files, you need to make a commit and then push to remote. The blockstate file is still your original: https://github.com/LordBard42/ModTesting/blob/master/main/resources/assets/lnm/blocktates/ruby_block.json

I'm voting to close as "Too Broad" Wait, this isn't Stack Overflow. That said, this is pretty much up to you. You can do it via setter methods in the capability if you want.

Also please do not attach your files to your post. Either: Add them in a code block as part of your post Use Pastebin Or even better than both of those: upload your entire mod as a working GitHub repository. It would, however, appear that you have not included the "normal" variant in your blockstate JSON file. https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/resources/assets/harderores/blockstates/dummy_ore_zinc.json#L11-L18

You haven't annotated these methods such that the event bus knows about them.

You do not appear to be registering your seed at all. Additionally: Problematic Code #10

You should be using the JSON system. The reason not to ("minimize the number of files") directly contradicts the reason for the JSON system: to allow recipes to be modified via data resource packs.

Its usually customary to post your code and any errors you get, because we're not psychic. I mean, you might be and won't need those things from people you're helping... But we're not.