Leaderboard

You can extend BlockPane to make your block act like a pane or iron bar. Then also copy the blockstate and model files and adapt properly.

If you look at the IBlockState class do you see a method called getPropertyKeys, or is it called getPropertyNames? The method was renamed from getPropertyNames to getPropertyKeys on 2016-11-17. If you see the old name, you should update your MCP mappings to stable_29 (the final mappings version for 1.10.2). If you're using an obfuscated build of EnderIO, it should be automatically deobfuscated to your current MCP mappings. This error suggests that you're using a deobfuscated build or EnderIO/EnderCore are messing with the deobfuscation.

This could work

In your build.gradle: minecraft { ... mappings = snapshot_20170103 ... } Or whatever's current for 1.11.2 - see http://export.mcpbot.bspk.rs/. There isn't a "stable" mapping for 1.11.2 yet.

By default, transparent pixels in textures are rendered black if the opacity is 0%. Otherwise all other pixels are set to 100% opacity. Assuming using 1.11.2, this code will resolve your problem. public BlockRenderLayer getBlockLayer() { return BlockRenderLayer.CUTOUT; } Edit: Goes in your block class

ContainerMessage is being sent to the client, so ContainerMessageHandler will be executed on the logical client side. This means that you can't use server classes like EntityPlayerMP and NetHandlerPlayServer, you need to get the client player instead. I do this using a method in my proxy that takes the MessageContext and returns the player. In the client proxy, I override this to return Minecraft#player if MessageContext#side#isClient returns true or MessageContext#getServerHandler#player if it doesn't. In the server proxy, I override it to return MessageContext#getServerHandler#player if MessageContext#side#isServer returns true or throw an exception if it doesn't (because something has gone wrong if you're getting a client-side MessageContext on the dedicated server). To be safe, you should probably send the Container's ID (Container#windowId) in the packet and check that it matches the open Container's ID in your packet handler before you update it with the packet's data. Vanilla packets like SPacketSetSlot do this.

Because you're modifying the recipe stack. You need to clone it before adding it to the output slot.

Yes, to MinecraftForge.EVENT_BUS.

did you register to the EVENT_BUS ??

In your Container#detectAndSendChanges override, iterate through Container#listeners and check if each one is an instance of EntityPlayerMP. If it is, send your packet to them. In your packet's handler, you can either call Container#updateProgressBar or your own method to update the client-side data.

Correct and (Not sure if i can explain this properly) but as to the texture file you will only need the one provided from the generator. The way animated textures work is kind of like a flip book that works from the top down. Take your image for example there are 12 rows of textures arranged from top down (or 12 pages in the flip book) and each MCMeta index relates to the corresponding texture location (Page number) and the time is how long before switching the next index. The model file sets the UV cords to match the cords on the texture file for all possibilities and makes sure that no mater what index you are on the non moving parts UV will always aligned to correct texture thus it doesnt move, However for moving parts it makes sure that only one of the parts UVs will be placed over a texture the rest will be placed in a blank space in your image so you only see one of the moving parts, then when it switches index the first part will be placed into a blank space and the next moving part will be placed over a texture and this continues for each moving part thus giving the illusion of movement without actually moving any parts. As to the 2 fans and the color that sounds like a prob in the block code and or init method can you post those so we can see what is going on

Someone will probably correct me if I'm wrong, I'm still learning models myself, but I think when you define the textures in a model you have to tell it your modid too. So instead of: "main": "blocks/fan_on" you have to put: "main": "modid:blocks/fan_on". Also keep in mind that your modid has to be lowercase for textures to work. I learned that the hard way. Hope this helps.