WuestMan

This is a great source of examples for different subjects. There is code and readme for each of the examples. https://github.com/TheGreyGhost/MinecraftByExample You will probably want to look through the "Containers (Inventories)" examples. Links to the examples can be found by scrolling down the readme file. Happy coding!

The block is considered solid by default. By calling that method is considered not solid.

This can be set through the block properties during block construction. If you follow the usage of that function and backing fields you will see that the result is returned from the isSolid function. Yay complexity! public BlockFoo() { super(Properties.create(Material.Rock) .func_226896_b_()); }

After futzing around for a while on this and testing things out. Setting the render layer based on block state wasn't necessary.

Been about a week. Bump?

So I started the update from 1.14.4 to 1.15.1 and got stuck pretty early with the rendering changes. I have a block which changes it's visual state when it receives a redstone signal. This doesn't seem to work well with the new code layout. I found that I have to use RenderTypeLookup#setRenderLayer now instead of overriding a method on my block, good. However while reviewing that class (RenderTypeLookup) I noticed the "canRenderInLayer" method does nothing with the block state passed in except get the block associated with the state. client setup method @Override public void clientSetup(FMLClientSetupEvent clientSetupEvent) { RenderTypeLookup.setRenderLayer(ModRegistry.BoundaryBlock(), BlockBoundary::canRenderInLayer); } RenderTypeLookup#canRenderInLayer - This is called in chunk rendering. public static boolean canRenderInLayer(BlockState state, RenderType type) { Block block = state.getBlock(); if (block instanceof LeavesBlock) { return field_228388_c_ ? type == RenderType.func_228641_d_() : type == RenderType.func_228639_c_(); } else { java.util.function.Predicate<RenderType> rendertype; synchronized (RenderTypeLookup.class) { rendertype = blockRenderChecks.get(block); } return rendertype != null ? rendertype.test(type) : type == RenderType.func_228639_c_(); } } BlockBoundary#canRenderInLayer /** * Queries if this block should render in a given layer. */ public static boolean canRenderInLayer(Object layer) { // NOTE: This code is in a partial state. Need to find out how to get block state to determine if the block should be rendered this pass. boolean powered = false;// state.get(Powered); RenderState renderState = (RenderState)layer; // first part is translucent, second is for solid. return (layer == RenderType.func_228645_f_() && !powered) || (layer == RenderType.func_228639_c_() && powered); } I was using the canRenderInLayer method as a shortcut so the model wouldn't have to be loaded (trying to be efficient). So I guess my question would be. Should I even worry about this or is there a hook or something that I can use instead? Note: I have another block which becomes invisible if it receives a redstone signal (changes block state) or if it's interacted with (it phases out and then back in). Any help or ideas would be appreciated! Thank you!

Did you register your TESR with your TileEntity using [ClientRegistry.bindTileEntitySpecialRenderer]? This has to happen after you register your TileEntity.

Why are you checking (!world.isRemote) twice? You have it in your onItemRightClick method and the loadStructure event. Unless you are planning of calling "loadStructure" from other places, this second check is unnecessary. In loadStructure, does it ever get past your null check or is the "template" variable always null? If it is always null, step into the "templateManager#getTemplate" method and see where it's trying to load your structure file from. This part seems unnecessary since the block is staying the same state.

This is the way I was doing it in my mod to set the mob spawner to spawn zombies. // Get the tile entity at this position. TileEntity tileEntity = world.getTileEntity(pos); // Always check to see if the tileEntity is of the type you expect before casting. // I am not doing it here on purpose. TileEntityMobSpawner spawner = (TileEntityMobSpawner)tileEntity; spawner.getSpawnerBaseLogic().setEntityId(EntityList.getKey(EntityZombie.class));

I was able to register recipes by copying the logic from 1.11.2 and making some adjustments to the code to include the new required name field which is used for the recipe book. There are other additional changes here as well. It isn't complete since the names are not friendly but I needed something in order to register new recipes for vanilla objects since I didn't see a way to do that this early in the release. NOTE: You will have to watch out for duplicate names otherwise you will get errors when starting minecraft when it's registering your recipes. Shaped Recipe: Shapeless Recipe: Example Usage: Info: ModRegistry is a class I created for registering all of my mod specific things. Shaped Recipe Shaped Recipes within a loop. Shapeless Recipe

There is a built-in utility for storing BlockPos as NBT data. To create an NBTTag from BlockPos: net.minecraft.nbt.NBTUtil#createPosTag To read BlockPos data from NBTTag: net.minecraft.nbt.NBTUtil#getPosFromTag

Fixed with build 13.19.0.2137 Thanks for the quick turn around!

With 1.11 it doesn't seem like Tile Entities can be registered anymore through the game registry as the code within the GameRegistry.registerTileEntity method is commented out. Inside of the TileEntity class the method to add tile entities to the registry is set to private. This is causing a problem with my TileEntity as I am writing NBT data as part of my TileEntity.

I recently updated my mod from 1.8.9 to 1.9 and most things are working except for the right-click harvesting I implemented. This worked perfectly in 1.8.9 but the PlayerInteractEvent no longer fires on right-click. I have confirmed that my event method fires during a left-click. This is my first post so please be gentle . Code from CustomEventHandler Snipped code From CommonProxy While trying to look through the Minecraft code it seems that in NetHandlerPlayServer in the processRightClickBlock method it's not calling "net.minecraftforge.event.ForgeEventFactory.onPlayerInteract" when it calls "this.playerEntity.interactionManager.processRightClickBlock(". Code from NetHandlerPlayServer below.