Choonster

Entities can only collide with your block if it has a collision bounding box smaller than a full cube. Block#onEntityCollidedWithBlock will never be called if your block has the default bounding box. Either give your blocks a bounding box with a maximum y coordinate slightly less than 1 (look at BlockSoulSand for an example) or override Block#onEntityWalking instead. Note that flying or sneaking players don't trigger walking.

Since it's a client-only method, it may be possible to directly check the player's held item to see if it's the same stack as the argument.

LivingEntityUseItemEvent is only fired for items that are continuously used like bows, shields, etc. PlayerInteractEvent is fired when a player left- or right-clicks something. Don't subscribe to either of these events directly, use the appropriate subclass.

You can't just render from an arbitrary method that's only called once, you need to render the effect every frame from a dedicated client-only class like a Render , LayerRenderer or TileEntitySpecialRenderer .

If you want to do something similar to a vanilla feature, look at the implementation of that feature. In this case, the purple beams shown when the Ender Dragon dies are rendered by LayerEnderDragonDeath .

You need to break down your object and the objects it's composed of into the basic data types supported by NBT: compound tags for complex objects, list tags for collections, string tags for strings, numeric tags for numbers and numeric array tags for collections of numbers. You should implement INBTSerializable on classes that can be serialised to NBT. To attach data to an ItemStack , Entity or TileEntity (or any other ICapabilityProvider ), use the Capability system. To attach data to a dimension or save, use World Saved Data.

The FML log should tell you what went wrong when loading the model. If you don't know what to make of it, upload the log to Gist and link it here. There are several issues with your code: Don't use the deprecated GameRegistry.registerBlock / registerItem methods, use GameRegistry.register . This requires you to register an ItemBlock for your Block instead of doing it for you. Don't use unlocalised names for registry names. The whole point of the registry name methods being added in 1.8.9 was to stop people from doing that. Set your registry names in your Item constructors. If the Item class is used by multiple instances, take the registry name as a constructor argument. If the Item class in only used by one instance, you can hardcode the registry name in the constructor. If your registry and unlocalised names are the same, I recommend setting the registry name ( setRegistryName("myItem") ) and then setting the unlocalised name to the full registry name ( setUnlocalizedName(getRegistryName()) ). This will result in your item's full unlocalised name being item.modid:myItem.name , which includes your mod ID to avoid conflicts with other mods. Don't use ItemModelMesher#register to register models, use ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition in preInit. You're using an internal class from Jline for your logging, this is a bad idea. Use FMLPreInitializationEvent#getModLog to get a Logger with your mod ID as its name, then use this for logging. Your @Mod class is in the client package, but it's not a client-only class.

I have. There's a branch for each Minecraft version since 1.8 (excluding 1.8.8, which was quickly replaced by 1.8.9); though only the latest version is actively developed.

All blocks and items are registered in the same way.

World#isRemote tells you whether the current method is being run on the logical client or server. This page explains sides in more detail.

Read the doc comments of the deprecated methods, they tell you what to use instead. The registry system was overhauled in 1.9, you now register every IForgeRegistryEntry implementation ( Block , Item , Biome , etc.) by calling GameRegistry.register .

Upload it to Gist and link it here.

The chunkX and chunkZ arguments are chunk coordinates, not block coordinates. Multiply them by 16 or shift them left by 4 to get the corresponding block coordinates.

IvToolkit 1.2.4 is for 1.8.9, not 1.7.10. If the website you downloaded from said it was for 1.7.10, it lied. Make sure you only download mods from their official source (usually a Minecraft Forum thread or Curse page).

You can try prefixing the path with a slash, i.e. "/assets/hpspells/speech/spells.txt"

Use EntityLivingBase#isPotionActive(Potion) to ensure the potion isn't already active before applying it. Your effectPlayer method is already doing something similar, but it's never called from anywhere. The int argument of Item#onUpdate is the inventory slot containing the item, passing it to EntityLivingBase#removePotionEffect is a bad idea since it expects a completely different data type (a potion ID).

HarvestDropsEvent#harvester is a field of type EntityPlayer , so it will always be a player. It may be null , though; the doc comments of the event explain this.

It looks like your mod ID is NtbMod , but your mcmod.info file uses ntbMod . These must be exactly the same as each other.

That's a basic Java error, the method expects an Item but you're passing it a Block .

Why did you copy vanilla models into your mod instead of just using the vanilla models directly? Your repository doesn't include the tum:item/handheld model. Define "renders weird", preferably with a screenshot.

Are you sure the file's path in the JAR is exactly the same as the path you're trying to load, including case? Paths in JARs are case-sensitive, paths on Windows (NTFS) drives aren't.

Never use unlocalised names for anything other than translation/display, they're not unique and can change at any time. The default model loaded for every Item is the one with its registry name ( IForgeRegistryEntry#getRegistryName , inherited by Item and Block ), so use that as the default location for your models. Unlocalised names have nothing to do with models. Don't use ItemModelMesher#register , use ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition in preInit. If your item model is located at assets/<modid>/models/item/<name>.obj, use new ModelResourceLocation("<modid>:<name>.obj", "inventory") as the model location. Forge allows item models to be loaded from variants of blockstates files, so you could use new ModelResourceLocation("<modid>:<name>", "<variant>") to use the model from the "<variant>" variant of assets/<modid>/blockstates/<name>.json. I have a more detailed description of the model loading process and how model locations are mapped to model files here. Forge's blockstates format may also be useful here.

AdvancedModelLoader no longer exists, OBJ and B3D models are now part of the baked model system. This means that you can use them anywhere you'd use a JSON model and you don't need a TileEntitySpecialRenderer . To use an OBJ/B3D model, tell the appropriate loader that it can load models from your resource domain (mod ID) by calling ObjLoader#addDomain or B3DLoader#addDomain in preInit from your client proxy (or a class called from it). You can then specify your model just like you would a JSON model, but include the .obj/.b3d file extension. Forge itself has a test mod with some examples: code, assets

The hopper uses the same baked model system as regular blocks, you can change your block's model and textures from its blockstates file.

To clarify: IBlockAccess is an interface implemented by World that provides access to blocks, TileEntities , biomes, etc. IBlockState is a collection of properties and values representing the current state of a Block