Choonster

Minecraft#currentScreen contains the current GuiScreen , but you shouldn't need to check this; just display the GUI when you receive the packet. That's why I told you to send a packet rather than calling EntityPlayer#openGUI .

A Block can only have one default state. Any setter methods in Block will set that value to be used for every state of the block. Instead of calling the setter methods in the constructor, you need to override the getter methods to return the appropriate value based on the state they receive as an argument. The methods you need to override are Block#getBlockHardness , Block#getExplosionResistance(World, BlockPos, Entity, Explosion) and Block#getSoundType(IBlockState, World, BlockPos, Entity) .

Ah, that makes sense. Minecraft#loadWorld spawns the client player in the world, firing EntityJoinWorldEvent and opening your GUI. The Minecraft#displayGuiScreen call after that replaces your GUI before you can see it, so it looks like it was never opened. This means that you'll need to show your GUI slightly later in the login process. I suggest subscribing to PlayerLoggedInEvent (fired on the server side) and checking if the player has built their character (i.e. finished with the character builder GUI). If they haven't, send a packet to the client to open the character builder GUI. This should be received after GuiDownloadTerrain has been hidden by the SPacketPlayerPosLook handler.

Rather than using a hardcoded metadata value, you should call EnumDyeColor#getDyeDamage on EnumDyeColor.WHITE to get the white dye (bone meal) metadata.

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.