Choonster

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).

Java's tutorials do use the term "static nested classes".

If the handler is a static nested class (which it should be), attempting to access instance fields of the message results in a compilation error.

When you use nested classes depends on your code style. There's not really a specific area where you need to use them, they mostly behave just like normal classes. One common use is nesting the IMessageHandler in the corresponding IMessage class to keep the message and its handler together.

If you're not using Forge, why are you asking for help on the Forge forums? If you want to modify the base classes directly, you need to use MCP. Your edits will likely make the mod incompatible with Forge and any other JAR mod that changes the same classes.

In short: You don't. Forge exists to allow compatibility between mods, editing base classes leads to incompatibilities. You can usually achieve what you want in some other way, e.g. with an event or by replacing a field. If you tell us what you're trying to achieve, we can tell you how to do it. It is possible to modify base classes using ASM, but this is highly discouraged and you won't get any help with it here.

args was length 0, so attempting to access index 0 threw an ArrayIndexOutOfBoundsException. You're already checking if the length is 0 before printing the help text, you just need to return from the function after doing that instead of trying to access index 0.

That chat message is sent when ICommand#execute throws an exception. The exception is logged when this happens, so look at the log to see what happened.

No. If you look at the code that calls it, you'll see that it's only called when the Block changes.