Choonster

The direct damage of the Large Fireball is hardcoded at 6.0 in EntityLargeFireball#onImpact , but the explosion power is controlled by the public EntityLargeFireball#explosionPower field. If you want it to deal a different amount of damage, extend EntityLargeFireball and override onImpact to do the same thing as EntityLargeFireball#onImpact but deal the appropriate amount of damage instead of 6.0.

Using the latest snapshot of ForgeGradle instead of the 2.0.1 stable version may help, since the snapshot includes a recent fix that correctly builds Minecraft with debug information which was previously missing. To switch to the snapshot, follow the instructions in the comments at the top of build.gradle (you may need to download a recent MDK version and copy the code from its build.gradle if you deleted the comments from yours).

All events in the net.minecraftforge.fml.common.gameevent package are fired on the FML bus ( FMLCommonHandler.instance().bus() ) rather than the Forge bus ( MinecraftForge.EVENT_BUS ). Event handlers only work if they're registered with the right bus.

Have you registered your event handler with the appropriate event bus (the FML bus in this case)?

Just get the player's position ( Entity#getPosition or Entity#posX / posY / posZ ) and add a random offset ( Random#nextInt ) on each axis.

One of your mods has added an item ( WeightedRandomChestContent ) to the loot table for the dungeon chest with the minimum quantity set higher than the maximum quantity. You'll have to remove any mods that add dungeon loot one-by-one until you can find the one causing the issue. You could use an IDE's debugger to find the item with the invalid values, but that won't be very easy to do unless you have programming experience. In future, please post logs (and code) using a paste site like Pastebin or Gist.

Unfortunately none of the scenarios you listed have events, but there are some workarounds and related events listed below. As an example of a possible alternative: Immersive Engineering's Lightning Rod doesn't actually detect lightning strikes, it just checks if there's a thunderstorm and spawns a lightning bolt that hits the net of the Lightning Rod. EntityJoinWorld will fire when any entity joins the world (this includes newly spawned entities and entities in chunks that have just been loaded). If it's an instance of EntityAnimal , Entity#isChild will return true for any child. If it's an instance of EntitityAgeable , EntityAgeable#getGrowingAge will return -24000 for brand new children (the growing age is incremented/decremented towards 0 each tick). Use PlayerTickEvent to check the height of the player ( Entity#posY ). This is fired once per player per tick on each side. Use WorldTickEvent to check the world time ( World#getWorldTime ) each tick. This is fired once per world (dimension) per tick on each side. If you only care about one dimension (e.g. The Overworld), you may want to use ServerTickEvent instead. This is fired once per tick on the server.

If you're using IntelliJ IDEA and none of your resources are working in the development environment (but they are working in the release/obfuscated environment), you need to add the following code to your build.gradle (source): idea.module.inheritOutputDirs = true If this isn't the case, I'm not sure what your issue is.

You're trying to access a field or call a method of a null value on line 115 of JavaGetUrl , which causes Java to throw a NullPointerException . The message of the exception isn't relevant in this case, only the type and stack trace tell you what went wrong. is is null , probably because URL#openStream threw an exception. You should check if it's null before trying to call close on it. You may also want to use a try-with-resources statement to auto-close your InputStream .

As far as I can see, there's no specific Entity method that's called when the entity is unloaded. Entity#setDead will be called, but that's also called any other time the entity is killed/removed (e.g. if it falls out of the world or is killed with /kill ). Is there a specific reason you need this?

One of your mods has added an item ( WeightedRandomChestContent ) to the loot table for the dungeon chest with the minimum quantity set higher than the maximum quantity. You'll have to remove any mods that add dungeon loot one-by-one until you can find the one causing the issue. You could use an IDE's debugger to find the item with the invalid values, but that won't be very easy to do unless you have programming experience.

PART is a PropertyEnum of EnumPartType , but you're trying to assign an int value to it ( this.part ).

If you look at the stacktrace, it's being called from PlayerControllerMP#onPlayerDestroyBlock ; so it's likely the block's breaking sound that's causing the issue. Updating ForgeGradle or following my previous debugging instructions should provide further information as to what the issue is.

RenderGlobal#playAusSFX (called from World#playAuxSFXAtEntity ) is throwing an exception, but a NullPointerException was thrown while generating the crash report. Put a breakpoint in the catch block of World#playAuxSFXAtEntity and run Minecraft in debug mode. When it hits the breakpoint, the throwable variable will contain the exception that was thrown.

3.4028235E37F is equivalent to Float.MAX_VALUE / 10 , so multiplying it by 10.0F produces Float.MAX_VALUE . Anything larger than that would overflow. I'm not entirely sure why it's multiplied by 10 before rounding to an integer or why it doesn't use a double instead of a float to store the pre-rounded value.

I meant post the crash report, though having the code on Gist makes it a bit easier to read. The exception type and stack trace should tell you what went wrong even if the message doesn't.

The crash report should tell you exactly what went wrong. If you can't figure it out, upload it to Gist and link it here.

To store multiple values in your metadata, you need to use bitwise operations to combine the values into a single integer. The problem here is that metadata is restricted to 4 bits, but the 10 possible values of EnumRailDirection require 4 bits to store and the 3 possible values of EnumPartType require 2 bits to store. This means that you can't store both values in the metadata, you may need to store the PART property in your TileEntity instead. You can still have it as a property of the BlockState (and thus decide the model based on its value), just override Block#getActualState to return an IBlockState with the PART property's value retrieved from the TileEntity at the provided location. Look at BlockFlowerPot for an example of an enum property stored in a TileEntity instead of the metadata. Edit: I didn't realise you were using separate instances. Either use separate instances or store the PART property in the TileEntity . Like GotoLink said, there's no need to do both.

Do you understand how the code works? You have an instance of your ItemQuinqueCase class stored in a static field of some class (e.g. TokyoGhoulMod or ModItems ), return a new ItemStack of this Item instance from ItemQuinqueDoujima#onItemRightClick . Do the same in ItemQuinqueCase#onItemRightClick , except return an ItemStack of the sword instead of the case. You don't need the ItemQuinqueCase field if the result of the swap is hardcoded, I just used that to demonstrate two items that use the same class swapping to each other.

If the model's shape is working, it's an issue with the texture being invalid or missing. If the block is appearing as a cube, it's an issue with the model being invalid or missing. Which is it? If you're using the vanilla blockstates format, you need to define the model for every possible combination of property values. The ones that are listed as missing are the ones you haven't defined a model for. You can also use Forge's blockstates format, which lets you specify how each value affects the model instead of defining the model for every combination of values.

Override Item#onItemRightClick to check if the player is sneaking ( Entity#isSneaking ). If they are, return an ItemStack of the other Item ; else return the result of the super method. You can see a basic example of this here.

There should be some errors in the log telling you what went wrong. The Grey Ghost has a guide to troubleshooting block and item rendering here.

Yes. I'd recommend creating a separate class each for your blocks and items and using those classes to instantiate, register and store your Block / Item instances. You can see an example of what I'm talking about here. You should keep the registration out of the constructor, that way you can more easily use the same class for multiple block/item types.

You've created a recipe for an ItemStack with a null Item . This is because you've registered your recipes before instantiating and registering your blocks. You should instantiate and register your items and blocks in preInit (don't instantiate them in field initialisers) and then add recipes in init.

Forge's Blockstates format can reduce the number of individual models you need to write.