Choonster

I don't use Eclipse, I don't know exactly how you refresh your project after updating. Does it work without running the eclipse task?

What do you mean? Set a breakpoint in Minecraft#displayScreen and remove your other breakpoints. It should be called once with your GUI and then called another time with a different GUI. Does this second call happen? If it does, post a screenshot/video of the debugger showing it.

Don't run cleanCache , that deletes the entire Gradle cache; just run setupDecompWorkspace and then refresh your IDE project. For IDEA this can be done from the Gradle window, for Eclipse you may or may not need to re-run eclipse .

Post the full FML log (logs/fml-client-latest.log) in a spoiler as well as your entity registration and entity class.

Use MCPBot to find method and field names.

That's not the problem, it's just a method name. The value returned by the method is eventually cast to GuiScreen , not GuiContainer .

That's still your GUI. What I suspect is happening is the following: [*]You call EntityPlayer#openGUI from your event handler [*]FML calls Minecraft#displayGuiScreen with your GUI to display it [*]Something else calls Minecraft#displayGuiScreen with a different GUI, which replaces yours. I want to know whether step 3 happens and if it does happen, where does it happen from?

You need to properly implement BlockSlab#getTypeForItem by returning the EnumType for the ItemStack 's metadata. You also need to properly implement Block#damageDropped by returning the item metadata to drop (this should be the metadata value of the EnumType ). Your Block#getStateFromMeta and Block#getMetaFromState implementations are incorrect. You need to use bitwise operations to combine and extract the properties from the metadata. I suggest you look at BlockStoneSlabNew for an example of this.

That's where your GUI is opened from. Is it replaced by another GUI after it's opened? If so, where is that GUI opened from?

That's vanilla code, not the OP's code. If Minecraft#displayGuiScreen is called with a different GuiScreen after your GUI is displayed, where is it called from? Look at the stack in the debugger.

EntityPlayer#openGui indirectly calls Minecraft#displayGuiScreen on the client side through FMLNetworkHandler.openGui , FMLCommonHandler#showGuiScreen and FMLClientHandler#showGuiScreen . Set a breakpoint in Minecraft#displayGuiScreen , is it ever called with your GuiScreen ? Is it called after that with a different GuiScreen ?

That's where FML opens the GuiScreen that was returned by IGuiHandler#getClientGuiElement . Does it reach Minecraft#displayGuiScreen ? Is Minecraft#displayGuiScreen called afterwards with a different GuiScreen (or null )?

The basic gist of what I was saying is don't cast unless you have a reason to and you know that the value you're casting is actually an instance of the type you're casting to. Container#inventorySlots is a List<Slot> . Slot is completely unrelated to IContainerListener , so don't try to cast a Slot to IContainerListener . Container#listeners is a List<IContainerListener> . You don't need to cast values from this to IContainerListener because they're already that type.

That looks like it's a line from FMLNetworkHandler.openGui . EntityPlayerMP is the server-side player class, client-side players won't be instances of it. The client-side GUI opening is handled in one of the else if blocks lower in the method.

The second argument of the ModelResourceLocation is the variant, this corresponds to a variant in your blockstates file. Use "half=bottom,variant=true" as the variant to use that variant of the blockstates file as the model. It's best to group related blocks into variants of a single Block instance where possible to reduce the number of block IDs you use. The block ID limit is rather high (4095), so it won't affect everyone using your mod; but there have been large modpacks in the past that reached the limit.

You could use Capabilities or World Saved Data to store a per- World Map<ChunkPos, Lifeforce> that contains the Lifeforce for each chunk. Edit: Fixed incorrect closing tag.

So it reaches the EntityPlayer#openGUI call? I suggest you set a breakpoint in Minecraft#displayGuiScreen to see whether your GUI is being opened and then instantly closed.

This new code isn't much better. Why are you storing data in a file in the OS user's home directory instead of using the data storage mechanisms provided by Minecraft/Forge (entity data or capabilities)? There's no need for a ConcurrentHashMap if you only access it from one thread (the client thread). There's no need for any Map if you use the proper data storage mechanisms. Since you're opening the GUI on the logical client, you should only do it if the player that joined the world is the client player ( Minecraft#thePlayer ). I suggest you put a breakpoint in the onJoin method and step through it in the debugger to see why it's not working.

Then open it on the client. Note that you'll need to set the flag on the server, so you may only want to set it when the player has finished with the GUI rather than when they're first shown the GUI.

Container#listeners contains the Container 's IContainerListener s. Since generics were added to the vanilla codebase in 1.8.9 (or more accurately no longer stripped by Mojang's obfuscation process), you don't need to cast values when retrieving them from collections; the returned values are already the appropriate type. Only cast values when it's required and you already know that the value is of the type you're casting to.

Calling EntityPlayer#openGUI on the logical server (when World#isRemote is false ) will do nothing if IGuiHandler#getServerGuiElement returns null . For client-only GUIs with no Container , you need to call EntityPlayer#openGUI (or Minecraft#displayGuiScreen ) on the logical client (when World#isRemote is true ). Having the shown field in your event handler is a bad idea and will almost certainly screw things up. The value won't be unique to a player (so only the first player to join a world will have the GUI shown) or save (so only the first save loaded by the physical client will have the GUI shown), and won't persist between reloads (so shutting down the physical client or server will reset it). To store a single one-time flag per-player, you can use the EntityPlayer.PERSISTED_NBT_TAG sub-compound of Entity#getEntityData . Make sure you use a key unique to your mod, e.g. by prefixing it with your mod ID. For anything that's more complex or used more than once, use Capabilities.

What exactly do you mean by that?

1.9.4 changed TileEntity syncing a bit, the initial chunk data sent to the client now includes the update tag ( TileEntity#getUpdateTag ) of every TileEntity in the chunk; the update packet ( TileEntity#getUpdatePacket ) is only sent afterwards. This document by williewillus explains the changes in more detail. ICrafting was renamed to IContainerListener .

Forge's documentation explains sides in more detail here.