Choonster

Call setBlockBounds in your constructor. Look at the method definition in the Block class for the arguments.

Item#getRegistryName already includes your mod ID. Don't add it again.

Refresh the project from the Gradle window (this is needed after running setupDecompWorkspace to allow the project to use the new Forge version), then synchronise the project from the Project window (this is needed after running genIntelliJRuns to bring up the prompt to reopen the IDE and use the new run configurations). You then need to edit the run configurations to use the classpath of the <ProjectName>_main module.

The RenderItem instance is created between preInit and init, so it can't be used in preInit. Instead of using ItemModelMesher#register , use ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition . These must be called in preInit. Never use getUnlocalizedName().substring(5) in your code. Registry names are IDs, they must not change. Unlocalised names can change at any time. The default model loaded for every Item is the one with its registry name, so use Item#getRegistryName as the default model location.

Right click somewhere in the Project window, then select Git > Repository > Branches in the context menu. Select the branch to checkout from the popup menu that appears.

Clone the repository, then checkout the desired branch using a Git client (e.g. IntelliJ IDEA, GitHub Desktop, command-line Git).

So equipping a vanilla saddle on a vanilla horse shows your subtitle? I can't reproduce this. In the process of writing a reply, I looked at your GitHub repository and noticed you'd already done it. If you encounter further problems with Git, try looking for the solution first. If you can't find it, post here and I may or may not be able to help you. Any further questions not directly related to the custom entity should probably be posted in a separate thread.

So I gave your test code a shot and now I just fall through the block. I do get withered though haha, but I'm passing right through it like it doesn't exist. Are you using 1.8.9 or 1.9? My code is for 1.9, for 1.8.9 you'd need to call Block#setBlockBounds with the coordinates instead of creating a static field and overriding Block#getCollisionBoundingBox .

I just tested this here, the smallest possible offset (to 4 decimal places) is 0.0011. With an offset of 0.0010, the player can only collide by walking into a corner of the block rather than anywhere on any face.

If you want entities to be able to collide on all sides, call Block#setBlockBounds in the constructor with OFFSET as the minimum coordinates and 1 - OFFSET as the maximum coordinates (where OFFSET is some small value like 0.125). This removes the need to override Block#getCollisionBoundingBox . In 1.9, create a static final AxisAlignedBB field with these coordinates instead and override Block#getCollisionBoundingBox to return it.

Please pay closer attention to my posts. I said you should use the minecraft:entity.horse.saddle sound event as a sound in your own sound event, not the minecraft:sounds/entity/horse/saddle.ogg sound file (which doesn't exist, as you've seen). I even gave you an example of what you needed to put in sounds.json. You can see a working example of this here. As for the warning: When the server receives a CPacketVehicleMove , it calls NetHandlerPlayServer#processVehicleMove . This calculates the distance between the mount position sent in the packet and the server's last known mount position. If the difference between this distance and the magnitude of the mount's motion vector is more than 10 (actually if difference between their squares is more than 100), the server logs that warning and sends a SPacketMoveVehicle to the client to reset the mount's position to the server's last known position. If your mount uses the same motion/networking code as the Horse, I'm not entirely sure why this would happen.

Numeric armor slots were replaced by the EntityEquipmentSlot enum. The enum values should be self-explanatory.

An entity can only collide with a block on a given side if the block's bounding box is inset by a small amount on that side. Soul Sand is only inset on the top (i.e. the maximum y coordinate is less than 1), so entities will only collide on the top.

Entity#setCurrentItemOrArmor was replaced by Entity#setItemStackToSlot .

There is no Block#onEntityWalking method in 1.8+, so your method doesn't override a super method and is never called. This is why you should always use the @Override annotation, you would have gotten a compilation error telling you this. Use your IDE to auto-generate override methods. Block#onEntityCollidedWithBlock(World, BlockPos, Entity) is called when an entity that can trigger walking (i.e. returns true from Entity#canTriggerWalking ) walks on top of the block. Block#onEntityCollidedWithBlock(World, BlockPos, IBlockState, Entity) is called when an entity collides with the block in any direction.

I didn't say anything about replacing the minecraft:entity.horse.saddle sound event, though that's not possible to do from a sounds.json file in assets/<modid> anyway. You need to create your own sound event that uses minecraft:entity.horse.saddle as an entry in its sounds array. Put this in sounds.json: "entity.terrakon.saddle": { "sounds": [ { "name": "minecraft:entity.horse.saddle", "type": "event" } ], "subtitle": "subtitles.tetracraft:action.saddle" }, Then register a SoundEvent for tetracraft:entity.terrakon.saddle and play it when a Saddle is equipped. This should play the sounds defined by the minecraft:entity.horse.saddle sound event but use the subtitle of your sound event.

Create a sound event in your sounds.json file, give it a sound with minecraft:entity.horse.saddle as the name and event as the type and then set its subtitle. This will play a sound from the existing event but use your subtitle. See this page for an explanation of the sounds.json format.

You're playing the saddle equip sound in EntityTerrakon#processInteract . Just play a different sound.

The RenderItem instance is created between preInit and init, so you can't access it in preInit. The solution is to use the ModelLoader methods instead of the ItemModelMesher methods.

ModelLoader.setCustomModelResourceLocation must be called in preInit, as I said in my previous post.

That looks correct, yes.

See here for an example of what I'm talking about. registerBlockItemModelForMeta (which you can see in the same class) is essentially just a wrapper around ModelLoader.setCustomModelResourceLocation . This uses a variant of the block's blockstates file (uses Forge's blockstates format) rather than an item model. To use an item model, use a ModelResourceLocation with the model's location and the "inventory" variant. Use the getRegistryName method to get the registry name of an Item or Block . Most of my mod's items use this method to set their registry and unlocalised names, but some (e.g. Records) have completely separate unlocalised and registry names that they set manually. I use a similar method for blocks.

By default, the only model loaded for an Item (including an ItemBlock ) is the one with its registry name ( Item#getRegistryName ). You're telling Minecraft to use different models for each metadata value of the Item form of ModBlocks.ore , but you never tell it to load any of these models. To tell Minecraft to load a model other than the default one, call ModelBakery.registerItemVariants in preInit. Each argument is either the location of an item model or the location and variant of a blockstates file to load the model from. Don't use ItemModelMesher#register , use ModelLoader.setCustomModelResourceLocation (for metadata-based models, will call ModelBakery.registerItemVariants for you) or ModelLoader.setCustomMeshDefinition (for arbitrary ItemStack to ModelResourceLocation mapping) in preInit. Never use getUnlocalizedName().substring(5) anywhere in your code. Unlocalised names can change at any time, registry names are IDs and must not change. As I said before, the default model loaded for an Item is the one with its registry name, unlocalised names have nothing to do with models. I suggest using the registry name system to register your Block s and Item s: Call setRegistryName to set the registry name, then call the single argument overload of GameRegistry.registerBlock / registerItem to register the Block / Item . Do not use unlocalised names as registry names, but you can use registry names as unlocalised names (this will include your mod ID in the unlocalised name, which will avoid conflicts with other mods). Using registry names now will make it much easier to update to the new registry system in 1.9.

Entity#getEntityData returns a compound tag for storing custom data on external entities. It does not store the entity's own data (e.g. Slime size) and should not be combined with Entity#readFromNBT and Entity#writeToNBT .

So I looked at the code, and it doesn't seem like there's any explicit method call to make entity collision instantiate the wither effect. Soul Sand doesn't apply the Wither effect, it slows down entities. There are only two methods in BlockSoulSand excluding the constructor: one defines the bounding box (so entities can collide with it), the other slows down entities when they collide with the block. When an entity collides with your block, check if it's an EntityLivingBase and then use EntityLivingBase#addPotionEffect to apply the Wither effect to it.