Choonster

How you add functionality depends on the functionality you're adding. In this case, there's no event for block collisions so you'll need to subscribe to either PlayerTickEvent (fired only for players, make sure you check the event's Phase before running your code) or LivingUpdateEvent (fired for all living entities). In your event handler, iterate through all blocks inside the entity's bounding box (see Entity#doBlockCollisions ) and check if each one is a rose bush before damaging the entity.

Amadornes has submitted a Pull Request to merge MCMultipart into Forge itself. Until this has been resolved, there won't be a MCMultipart for 1.9.4. ChickenBones' Forge Multipart was never updated past 1.7.10.

Amadornes has submitted a Pull Request to merge MCMultipart into Forge itself. Until this has been resolved, there won't be a MCMultipart for 1.9.4. ChickenBones' Forge Multipart was never updated past 1.7.10.

Unless I'm mistaken, that won't add to the event's drops list. Entity#entityDropItem only captures the drop when Entity#captureDrops is true , this is set to true before the entity's loot is dropped and then set back to false before LivingDropsEvent is fired.

Unless I'm mistaken, that won't add to the event's drops list. Entity#entityDropItem only captures the drop when Entity#captureDrops is true , this is set to true before the entity's loot is dropped and then set back to false before LivingDropsEvent is fired.

ServerConfigurationManager was renamed to PlayerList in 1.9 (see this issue) to match its subclasses and purpose. MinecraftServer#getConfigurationManager was renamed to MinecraftServer#getPlayerList . Most of the name changes in 1.9 and 1.9.4 are documented in this issue tracker.

ServerConfigurationManager was renamed to PlayerList in 1.9 (see this issue) to match its subclasses and purpose. MinecraftServer#getConfigurationManager was renamed to MinecraftServer#getPlayerList . Most of the name changes in 1.9 and 1.9.4 are documented in this issue tracker.

It's not possible to do this 100% reliably, since recipes can change what they output dynamically. The closest you'll get is iterating through the recipe list ( CraftingManager#getRecipeList ), calling IRecipe#getRecipeOutput for each recipe to get its output and checking if it matches the criteria. There may be multiple recipes that result in a given ItemStack or there may be none.

It's not possible to do this 100% reliably, since recipes can change what they output dynamically. The closest you'll get is iterating through the recipe list ( CraftingManager#getRecipeList ), calling IRecipe#getRecipeOutput for each recipe to get its output and checking if it matches the criteria. There may be multiple recipes that result in a given ItemStack or there may be none.

We don't support cracked launchers here. Buy the game.

We don't support cracked launchers here. Buy the game.

Unfortunately the crash happened in vanilla code on a line with several parts that could cause it, so it's difficult to see what actually went wrong. One possibility is that you weren't correctly logged in to the game. Could you upload your FML log (logs/fml-client-latest.log) to Gist and link it here?

Unfortunately the crash happened in vanilla code on a line with several parts that could cause it, so it's difficult to see what actually went wrong. One possibility is that you weren't correctly logged in to the game. Could you upload your FML log (logs/fml-client-latest.log) to Gist and link it here?

That code should crash the client, since the RenderItem and ItemModelMesher instances you use for registering your models are only created between preInit and init. Instead of ItemModelMesher#register , use ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition in preInit. ModelLoader.setCustomModelResourceLocation will call ModelBakery.registerItemVariants for you. Side note: GameRegistry.registerItem / registerBlock are deprecated. Set the registry name of your Item s/ Block s in their constructors using IForgeRegistryEntry#setRegistryName (implemented by Item , Block and other singleton classes) and then register them with the single-argument overload of GameRegistry.register .

That code should crash the client, since the RenderItem and ItemModelMesher instances you use for registering your models are only created between preInit and init. Instead of ItemModelMesher#register , use ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition in preInit. ModelLoader.setCustomModelResourceLocation will call ModelBakery.registerItemVariants for you. Side note: GameRegistry.registerItem / registerBlock are deprecated. Set the registry name of your Item s/ Block s in their constructors using IForgeRegistryEntry#setRegistryName (implemented by Item , Block and other singleton classes) and then register them with the single-argument overload of GameRegistry.register .

Put mod JARs in the mods folder. Don't extract them.

Put mod JARs in the mods folder. Don't extract them.

You're using the wrong model. minecraft:cube is a cube with a separate texture on each side, minecraft:cube_all is a cube with a single texture on all sides. When registering models for the item form, you should use the colour name as the variant of the ModelResourceLocation instead of "inventory" . This will allow each metadata value of the item to use the corresponding block model. I suggest using the existing EnumDyeColor and extending BlockColored .

You're using the wrong model. minecraft:cube is a cube with a separate texture on each side, minecraft:cube_all is a cube with a single texture on all sides. When registering models for the item form, you should use the colour name as the variant of the ModelResourceLocation instead of "inventory" . This will allow each metadata value of the item to use the corresponding block model. I suggest using the existing EnumDyeColor and extending BlockColored .

World#isRemote is true on the client and false on the server.

World#isRemote is true on the client and false on the server.

You need to run the server and the client. The client needs to log you in using your Mojang account. Some errors may trigger when loading the server, some will require logging in with a client and doing things in the world.

You need to run the server and the client. The client needs to log you in using your Mojang account. Some errors may trigger when loading the server, some will require logging in with a client and doing things in the world.

localhost is the address to connect to, yes. You can add the server or direct connect, either will work.

localhost is the address to connect to, yes. You can add the server or direct connect, either will work.