Choonster

No, my code passes the Fluid to the BlockFluidClassic constructor. You're trying to pass the Block to its own constructor.

In getRemainingItems , you're overwriting the damaged tool with the default container item returned by ForgeHooks.getContainerItem . This will be null unless the item has a container item specified. You should only call ForgeHooks.getContainerItem when the item isn't a tool.

The actual exception that caused the crash is being hidden by an exception thrown from the crash report code. This is due to Minecraft being rebuilt without debug information by ForgeGradle and has been fixed in ForgeGradle 2.0.2. I'd suggest updating the plugin in your build.gradle, re-running setupDecompWorkspace , refreshing your IDE project and posting the new crash report. Edit: The itemstack argument of isTool will be null if there was no item in the slot. Check that it's not null before calling ItemStack#getItem on it.

Post the isTool method and the crash report. I'm guessing you're calling ItemStack#getItem on a null value.

That simply declares a field and assigns the default value ( null ) to it. At that point, you haven't created a Block instance or assigned it to the field. BlockFluidClassic doesn't have a (BlockFluidClassic, Material) constructor anyway, so why are you trying to pass the mercury block to its own constructor? Side note: Use the [nobbc][tt][/nobbc] tag (or the Tt button) for inline code.

Recent versions of ForgeGradle put the MCP mappings in ~/.gradle/caches/minecraft/de/oceanlabs/mcp/<mappings_type>/<mappings_version> (replace ~ with %USERPROFILE on Windows).

Looking at Thermal Dynamics in a decompiler, the fields in TDItems are never actually initialised. To get a duct ItemStack , get the appropriate Duct from the TDDucts class and then use the Duct#itemStack field.

EntityLivingBase#getHeldItem will return null if the entity (the player, in this case) isn't holding anything. You need to check that it's not null before calling ItemStack#getItem on it.

Then use ItemStack#getDisplayName . This will return the custom name if the stack has one, otherwise it will return the item's display name.

What are you actually trying to achieve? Block#setBlockBounds lets you set a block's bounds. Block#addCollisionBoxesToList lets you have multiple bounding boxes and/or change the bounds based on the colliding Entity .

Thanks diesieben07. I found all sorts of references that said event.block when I was doing my research. Here's two examples: http://www.minecraftforge.net/wiki/Event_Reference http://www.minecraftforge.net/forum/index.php?topic=19820.0 But I appreciate your assistance in getting me a quick and accurate response. Those are for 1.7.10 and earlier. 1.8 introduced the blockstate system (i.e. IBlockState ), which largely replaced the old block metadata system (though technically the new system is still just a wrapper around the metadata).

Use ItemStack#hasDisplayName .

I found the source of the problem: not all blocks have a harvest tool/level set, so you need to override Item#canHarvestBlock and Item#getDigSpeed to check the block's Material like the vanilla tools do. You can see my new code here: 1.7.10, 1.8

Yes it is. My resources are in src/main/resources Your build.gradle is telling Gradle to look in $projectDir/src/java and $projectDir/src/resources instead of the default src/main/java and src/main/resources. You should delete the sourceSets block entirely, it's not needed if you use the default locations.

Unfortunately there are no obvious errors in the log. Are you sure your @Mod class is present in the JAR?

Then post a log from when it doesn't load (i.e. from a client with the mod in its mods folder). The debugging suggestion was a separate recommendation to the log posting.

Headcrumbs is trying to use a global entity ID that's already being used by something else. Report this to the author.

Each tick, World#updateEntities updates any loaded entities that aren't dead and removes any dead entities from the loaded entity list. Once there are no more references to the Entity , it should simply be garbage collected.

It looks like your mod loads without issue in that log.

Post the full error and the full class.

I don't know what you are talking about [nobbc][/nobbc] Jokes aside: Either check "Don't use smileys" in "Attachments and other options" or disable BBCode temporarily by surrounding the desired passage with [nobbc][nobbc][/nobbc][/nobbc] (the creation of this involved that tag ). Thanks, I wasn't aware of that option.

BlockFluidNoFlow is my own fluid block class, it's just a fluid that doesn't flow outwards. BlockFluidClassic and BlockFluidFinite are the fluid block classes provided by Forge. The doc comment on each class briefly explains what it does. ModFluids.createFluid creates and registers the Fluid instance (a singleton like Block and Item ) using the specified fluid name and texture name. The Fluid instance defines the physical properties of the fluid like luminosity, density and viscosity (explained in doc comments of the corresponding Fluid fields). ModFluids.registerFluidBlock receives the fluid's Block instance as an argument, sets its unlocalised name to the fluid's unlocalised name and registers it. The Block instance represents the fluid when it's in the world and actually implements the in-world behaviour corresponding to the Fluid 's properties (e.g. light level is controlled by the luminosity, flow speed is controlled by the viscosity). My code doesn't handle the Fluid already being registered by another mod. If a Fluid with the same name as yours (e.g. steam ) is already registered, you should use that Fluid instance and its Block instead of creating your own. I know BuildCraft has an example of this (for 1.7.10, but it should be the same in 1.. Edit: I wish 8 followed by a ) didn't turn into a smiley.

Yes, that's what my ModFluids class does. You can do model registration in the same class as the fluid creation/registration, but I prefer to register all models in a separate client-only class ( ModModelManager ). A Fluid can be either a liquid or a gas. Liquids behave like Water/Lava, gases are just liquids that flow upwards instead of downwards.

Industrial Craft 2 failed to extract its copy of the EJML library properly. If you're using a modpack, report this to the modpack authors. Otherwise, try updating to the latest official build of IC2.

It looks like you've posted the output from the console, but the log file should have some more information about the mod loading process in it. Could you post that? Use Gist if it's too large for Pastebin. You should also try building a deobfuscated copy of your mod (run the jar Gradle task), adding that as a mod in a separate ForgeGradle project, putting some breakpoints in JarDiscoverer#discover and stepping through it to see what's going wrong.