Choonster

A better example of saving data in the ItemStack when the block is broken is Forge's patches to BlockFlowerPot. This delays the removal of the TileEntity until after Block#getDrops is called, allowing you to access it there and store the data.

That should be the method to override. Have you actually replaced the vanilla RenderPlayer instances with your own? A better way to do this would be to subscribe to RenderLivingEvent.Specials.Pre, which is fired just before a living entity's nametag is rendered. You can cancel this to prevent the nametag from being rendered.

The unlocalised name has nothing to do with models, it's only used for localisation. The registry name is what determines the default blockstates file/item model location. I have an explanation of the model loading process and where models are loaded from here.

That output doesn't appear to match your code. Where did the "false" message come from? What did the first System.err.println call output? It appears that chunkPollution is indeed null. Is the ChunkEvent.Load handler definitely being called? Was it called for the chunk that produces this error?

If the goal is to have a separate blockstates file for each value of a property, you can do that by creating an IStateMapper using StateMap.Builder and registering it with ModelLoader.setCustomStateMapper.

It sounds like Eclipse is showing you NullPointerExceptions being thrown in external code that it doesn't have source code for. Restrict the breakpoint to your message handler class by doing the following: Show the Breakpoints view (Window > Show View > Other... > Debug > Breakpoints) In the Breakpoints view, right click on the exception breakpoint and select Breakpoint Properties... In the Properties window, select Filtering in the left column and then click Add Class... Type in the name of your message handler class, select it in the search results and click OK. Click OK in the Properties window.

You shouldn't need to set the class/line or add any null checks, the breakpoint will be hit as soon as something throws a NullPointerException. Once your code throws the exception and hits the breakpoint, look at the debugger to see what's null.

Look at the documentation or use your search engine of choice. If it's anything like IDEA, the Debug window should have a button that shows all breakpoints. Clicking this will bring up a window that also allows you to create new breakpoints.

That's strange. Can you reliably reproduce the NullPointerException, or has it only happened once? Try removing the breakpoint on the line that throws the exception and replacing it with an exception breakpoint for NullPointerException. If the breakpoint is hit and the exception is being thrown on the same line as before, look at what's null. That's normal, keySet and values are only created when they're first requested.

Now that I look at your code closer, the IChunkPollution couldn't have been null on line 80 if it wasn't null on the previous line. Set a breakpoint on that line and look at the values of the local variables when it's hit, which of them is null?

You're using the state that's equivalent to metadata 0, which is the default state (standard dirt). Coarse Dirt is a different variant of Blocks.DIRT. Don't use metadata values. Use Block#getDefaultState to get the default state, then use IBlockState#withProperty to get the IBlockState with BlockDirt.VARIANT set to BlockDirt.DirtType.COARSE_DIRT.

That's not the full log, it's only the first three lines of it.

You should be able to create an ItemStack of Items.WRITTEN_BOOK with the appropriate NBT data and then open a GuiScreenBook with that ItemStack, passing false as the isUnsigned argument.

The IChunkPollution for that chunk was null. Are you creating a default IChunkPollution in ChunkEvent.Load when the Chunk doesn't already have one? This is required for client-side chunks, since ChunkDataEvent.Load only fires on the server.

It gets fired once when the player starts watching the chunk and won't be fired for that player and chunk again until they stop watching it and then start watching it again. It's not fired constantly while a player is in the chunk. Access the holder capability through the World and then use it to get the energy storage for the chunk. I created helper methods in CapabilityChunkEnergy to get the IChunkEnergy for a Chunk or World and ChunkPos.

I believe diesieben07 meant "Is it actually called at runtime"? Set a breakpoint in each of the GuiHandler methods and try to open your GUI, are the breakpoints hit? In the code on GitHub, GuiHandler#getClientGuiElement always returns null. It should return a new GuiBlockBreaker instance when the ID matches.

Please post the latest version of your code and the latest FML log (logs/fml-client-latest.log in the game directory). It's not the direct cause of the error, but you're passing a ResourceLocation to EntityRenderer#enableLightmap (when you invoke it via the Method) even though the method doesn't have any parameters. EntityRenderer#enableLightmap is also a public method, so there's no need to invoke it via reflection. When you do use reflection, mark the field containing the Field/Method object as final.

You should be able to handle FMLMissingMappingsEvent and use FMLMissingMappingsEvent#getAll to get all the missing mappings before remapping any with your old mod ID to your new one.

The error says you're asking for a method named field_110922_T, but the code you posted doesn't use this name. Did an old version of your code use this name? Try rebuilding the mod in your IDE to ensure it's using the latest version.

Any mod that displays an energy value on the client needs to sync it somehow. If it's an energy bar in a GUI, this is usually handled through the Container (which syncs the value when it changes). If it's rendered outside of a GUI, it could either be always synced when the value changes or synced on demand when the value needs to be rendered.

The server and client(s) each have their own IChunkEnergy/IChunkEnergyHolder instances. The server handles any modifications to the energy amount and syncs the new value to the relevant clients so they can render it on screen (with the Chunk Energy Display item held). If there was no packet, the client-side GUI wouldn't be able to display the current energy amount. Forge's energy capability doesn't have any kind of automatic client-server syncing built-in.

You're right, I missed that. Looking into the code further, it appears that using a single version rather than one or more version ranges creates a VersionRange with a single Restriction (Restriction.EVERYTHING) that matches everything and completely ignores the version you passed it. In addition to this, NetworkModHolder.DefaultNetworkChecker (the default implementation used to check if the remote mod list is compatible with the local mods) allows the client to connect to a server without the mod installed. I'm not sure of the reason behind either of these. You can work around the latter by providing your own NetworkChecker, just annotate a method with @NetworkCheckHandler. See the doc comment for the required signature.

No problem, I'm glad it's working.

Use the Gradle Shadow plugin. You can see how I use it to shadow one of my mod's dependencies here.

You're passing the wrong arguments to the ItemStack constructor in ItemChip#getSubItems. The constructor expects (item, amount, meta), but you're passing (item, meta, amount).