Choonster

ModelLoader.setCustomMeshDefinition and ModelLoader.setCustomStateMapper must be called in preInit, you should move the FluidRenderRegister.init call to the preInit method of ClientProxy . You should be using ModelLoader.setCustomModelResourceLocation and the other ModelLoader methods for your regular Block s and Item s as well as your fluid Block s. All of these methods must be called in preInit. Don't include the .json extension in model/blockstate file locations, that's added for you. The ModelBakery.registerItemVariants call on line 26 of FluidRenderRegister is throwing a NullPointerException because you passed it a null Item argument. This is because you never registered an ItemBlock for ModBlocks.bloodBlockFluid . Calling client-only methods like ModelLoader.setCustomModelResourceLocation from common code like ModBlocks.registerBlockWithItem will crash the dedicated server. Model registration must be handled through your client proxy. Recipes should generally be added in init rather than preInit.

Have you registered the handler on the right event bus? In 1.8 and earlier, KeyInputEvent is fired on the FML bus ( FMLCommonHandler#bus ) and BlockEvent.PlaceEvent is fired on the Forge bus ( MinecraftForge.EVENT_BUS ). In 1.8.8 and later, the FML bus has been merged with the Forge bus.

In ClientProxy#renderFluids , you only register the model for ModFluids.tropical_water and not ModFluids.tropical_water_seafoam . I suggest refactoring your fluid model registration code into a method that takes a fluid Block as an argument and registers a model for it (like this one from my mod). Call this method for each of your fluid Block s. GameRegistry.registerBlock / registerItem are deprecated, use GameRegistry.register . You'll need to create and register the ItemBlock s for your Block s yourself. You can see my mod's fluid registration code here. This uses these methods to register the Block s. You should be using ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition in preInit instead of ItemModelMesher#register in init.

I've written an explanation of the model loading process here. The summary at the end briefly explains how to load models and how to map them to blocks/items. This was written for 1.9, but it's fairly similar in 1.8.x.

Always specify the Minecraft version you're using in the thread title. Scoreboard#func_96528_e / getScores returns a Collection of the Scoreboard 's Score s. In 1.8.8+, the method returns a Collection<Score> rather than a raw Collection . I suggest updating to 1.9 if you're not already using it.

Did you try looking at the source code of the BlockEvent.PlaceEvent class or the fields/methods you can access on the instance you've been provided? Use the BlockEvent#pos field (in 1.8.9 and earlier) or BlockEvent#getPos method (in 1.9) to get the BlockPos of any BlockEvent subclass (e.g. BlockEvent.PlaceEvent ). An IBlockState represents a specific state of a Block . If you only care about the Block itself, use IBlockState#getBlock to get the Block and compare that instead of the state. Are you sure you want to compare the player with == ? A new instance is created every time a player respawns, so plugin (whatever it is) will have to maintain a reference to the current player instance. You may want to store and compare the player's UUID instead: use Entity#getUniqueID to get it and Object#equals to compare it. Edit: Always specify the Minecraft version you're using in the thread title.

If you want to add a recipe to the vanilla crafting table, call GameRegistry.addRecipe with an IRecipe . If you want to add a recipe to a mod's crafting system (e.g. a machine of some sort), use its API. If this isn't what you're talking about, you'll need to be more specific. In future, please include the Minecraft version you're using in the thread title.

You can increase the chance for your biome to generate by increasing the weight of the BiomeManager.BiomeEntry you pass to BiomeManager.addBiome .

Which version of Minecraft are you using? In future, include that in your title. In 1.8 and earlier, ServerTickEvent is fired on the FML bus ( FMLCommonHandler#bus ) rather than the Forge bus ( MinecraftForge.EVENT_BUS ). In 1.8.9 and later, the Forge and FML buses have been merged. Your event handler will only be called if you register it with the right event bus. Every TickEvent subclass (including ServerTickEvent ) is fired twice per tick of its system (server, world, player, etc.): Once at the start with Phase.START and once at the end with Phase.END . Make sure you check the event's Phase so your code only runs once per tick.

Did you register an instance of your event handler class with the appropriate event bus? I suggest reading a tutorial on Forge event handlers, e.g. this one. @SubscribeEvent is for subscribing to events that extend net.minecraftforge.fml.common.eventhandler.Event (e.g. ServerTickEvent , LivingUpdateEvent ) and are posted to an EventBus . @Mod.EventHandler is for handling FML lifecycle events that extend net.minecraftforge.fml.common.event.FMLEvent (e.g. FMLPreInitializationEvent , FMLServerStartingEvent ), this only works in your @Mod class (hence it being a nested type of @Mod ). See the doc comment of the annotation for more details.

EnumHelper and ItemArmor.ArmorMaterial still exist in the same place they did in previous versions. The signature of EnumHelper.addArmorMaterial has changed to include the new fields of ItemArmor.ArmorMaterial , so your current code is referencing a method that doesn't exist.

This has been discussed in a few places before. The solution appears to be adding "custom": { "flip-v": true } to your blockstates file.

Casting an object to a primitive type should compile under Java 7 or 8 (and does for me), I'm not sure why it wasn't working for you. You can find the FML log in <gameDirectory>/logs/fml-client-latest.log. In the development environment, <gameDirectory> is the value of the minecraft.runDir variable in build.gradle (defaults to run). Again I suggest creating a new thread for your issue since it's likely not directly related to Java 8.

The method's return type is IResourceManager , not IReloadableResourceManager . It could theoretically return a completely different IResourceManager implementation (though it doesn't in practice).

I'm not sure I can explain it any clearer than I already have. Is there a particular part you don't understand?

Did you build it by running the build Gradle task? You should create a new thread for this issue and post your code and the FML log.

I just answered this in your previous thread: I don't think there was a need for a new thread.

That will get the first line of the sign text at those coordinates, yes. The signText array may contain null values, so check for null s before calling methods on the IChatComponent s. The toString method of most IChatComponent implementations won't give you the text as a player would see it. Use IChatComponent#getUnformattedText or IChatComponent#getFormattedText (client-only) to get the actual text of the IChatComponent , either with or without formatting codes.

When you first run Find Usages, you should get a dialog box asking you what types of usages to search for and where to search. Change the Scope to "Projects and Libraries" to search in the project and its libraries (including Forge). You can also bring up this dialog box from Edit > Find > Find Usages Settings... or by clicking the Settings button in the Find Usages result window.

In 1.8 the method is still called getTileEntity , but it takes a single BlockPos argument rather than three int arguments.

Add these lines to your build.gradle. Note that ForgeGradle can't reobfuscate lambdas (see this issue), so you need to create wrapper interfaces like this one.

You're calling ItemRegistry.registerItems before you call BlockRegistry.registerBlocks , so BlockRegistry.cornPlant is still null when you call the ModItemSeeds constructor.

Did you try looking at the World class to find the actual method name? In my fresh copy of the 1.7.10 MDK with the default mappings, the method is called getTileEntity . Side note: Always specify the Minecraft version in the title so people know how to help you properly.

The Minecraft#mcResourceManager field returned by Minecraft#getResourceManager is of type IReloadableResourceManager , so it's safe to assume that the method will always return an IReloadableResourceManager . Forge itself makes this assumption in ModelLoaderRegistry#registerLoader .

Wow! That's going to F up almost every block in every mod! As a ghostbuster once said, "OK, Important safety tip." It's trivial to fix once you know that the change has been made, just make sure your block registration method creates and registers the ItemBlock after registering the Block . You can see my implementation of this here.