Draco18s

By the way, don't implement ITileEntityProvider. Use the hasTileEntity and getTileEntity methods already present in the Block class.

You should probably start invoking those methods, yes.

Use your debugger, then.

You need to pass an array of properties, e.g: @Override protected BlockStateContainer createBlockState() { return new BlockStateContainer(this, new IProperty[] {Props.AXEL_ORIENTATION, BlockHorizontal.FACING}); }

Use SlotItemHandler. Duh.

HMM. public void getSubBlocks(Item itemIn, CreativeTabs tab, List<ItemStack> list) { for (final EnumAxis axis : EnumAxis.values()) { list.add(new ItemStack(this, 1, axis.getMeta())); } } I wonder what THIS does...

Packets, basically. The client asks the server "hey, were's my bed?" when it logs in. When asked, or when the bed is set, the server sends that client the information. You don't need to do anything with the AbstractClientPlayer because when the client asks the server, the server already knows which non-abstract player is asking (due to the message context).

Try searching.

client proxy: no renderOverlayEvent: yes

My guess: Your TE has an inventory that contains null items. in 1.11 you can't have null ItemStacks, you have to use stacks of air.

No code, no help

Call ModelLoader.setCustomModelResourceLocation(...) for your item.

Tada! A working example.

You want it to appear full bright, yes?

Your block class should already have it in the constructor.

Are they blocks that have a FACING property? You can set the default blockstate to face a different direction (West, IIRC).

Your "server" proxy should be your common proxy that you already have. There is no reason to have a dedicated "dedicated server" only class as 99.999% of the time you will want to do "servery stuff" on the client to during Single Player and LAN games.

Set the unlocalized name to the registry name: blockOrItem.setUnlocalizedName(blockOrItem.getRegistryName())

My usage is different from Selim's. But if you're making ores that you want to be made of any material (gravel ores, sand ores, sandstone ores, granite, diorite...) then you need to have a base+overlay if you want to match altered textures in the case of resource packs. You always want your overlay to paste on top of whatever the "stone" block is.

Compare: To: https://github.com/Draco18s/ReasonableRealism/tree/master/src/main/resources/assets/harderores/textures/blocks/ore And that's just 10 ores in that image.

Option A: - 192 textures for [material] + [ore] Option B: - 12 material textures + 16 ore overlays Hmm...

Yes I do. And I don't know if you can draw over the item. I was telling you how I did something similar. You would probably need to override drawScreen and possibly replace drawSlot.

gradlew setupDecompWorkspace eclipse is identical to running both commands one after the other.

ServerChatEvent... ClientSideOnlyClass reference... Hmm.

This is literally gibberish. The IItemPropertyGetter interface sets up a callback method which is invoked when the item is rendered, all the time, every time. Unless you somehow think that during preInit (before! The title screen) there is a player object and a world to look at...