Choonster

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.

Implement the methods like EntityHorse does and Minecraft should automatically call them when the player is riding your entity.

I've never tried to make a mountable entity myself, but I'd recommend implementing IJumpingMount like EntityHorse does and let Minecraft handle the keybindings and networking for you.

It hasn't changed much since older versions, though numeric armour slots were replaced with the EntityEquipmentSlot enum. Create an ArmorMaterial using EnumHelper.addArmorMaterial . The first argument is the name of the enum value, which should include your mod ID to avoid conflicts with other mods. The second argument is the texture name, which should be in the format "modid:texture" . Look at LayerArmorBase#getArmorResource(Entity, ItemStack, EntityEquipmentSlot, String) to see how this is used to determine the armour texture. The rest of the arguments are fairly self-explanatory. Create an instance of ItemArmor (or a class that extends it) for each item. The renderIndexIn argument of the ItemArmor constructor is never actually used for anything, so it should be safe to pass -1 for this argument. You can see the base class for my mod's armour here and implementations here and here. These implementations have specialised functionality (replacing your other armour or deleting itself when unequipped); for regular armour with no special functionality, ItemArmor or ItemArmourTestMod3 would suffice. The ArmorMaterial is created here and the armour items are registered here.

The same way you do for any other block, i.e. use ModelLoader.setCustomModelResourceLocation / ModelLoader.setCustomMeshDefinition with a ModelResourceLocation pointing to an item model or a variant of a blockstates file.

Create an ItemStackHandler field and initialise it with a new instance. Read it from and write it to NBT like any other field of your TileEntity using the INBTSerializable methods. If you don't want hopper and pipes to interact with it, don't expose it as a capability. Instead, create a regular getter method so your GUI code can access it. I'm not that familiar with the GUI system myself, so I can only provide basic advice. You'll probably need to implement each page as a separate GUI and have buttons/tabs to switch between them. When the player clicks one of these, send a packet to the server to open the new page's GUI. Tinkers' Construct's tinker table GUIs have similar functionality to this (though each tab is for a separate block), consider looking at how that's implemented. You'll want to create your own capability to store the materials and attach it to players using AttachCapabilitiesEvent.Entity . I'm not sure exactly how you plan for these materials to be dropped, but you should have access to the player that most recently attacked the entity.

Block#damageDropped is called from Block#getDrops , so the TileEntity won't be intact when it's called unless you delay its removal. This method doesn't have World or position arguments, so you can't use the TileEntity anyway.

Blocks and items should be registered in preInit, not init. Use the dependencies attribute of your @Mod annotation (as Ernio said) to ensure your mod loads after BoP. Edit: It was Ernio who originally mentioned the dependencies attribute, not diesieben07 as I said previously.