Choonster

I have a few examples of capabilities in my test mod. 1.8.9: API, implementation. 1.9: API, implementation.

As the big red text at the top of the home page says, post the FML log.

It would be easy enough to create your own mob spawner block, but replacing the vanilla one will be difficult. In theory you could use the substitution alias system to do this, but I don't think it actually works properly for blocks. There's no easy way to achieve what you want, but it may be possible using the work around I described previously.

Unfortunately BlockEvent.HarvestDropsEvent is fired after the Block and its TileEntity have been removed from the world (unless the Block specifically delays the removal, which BlockMobSpawner doesn't). This means that you don't have access to the TileEntity from BlockEvent.HarvestDropsEvent . A possible workaround would be to cache the TileEntity in BlockEvent.BreakEvent and then use it in BlockEvent.HarvestDropsEvent to create the dropped ItemStack .

In FluidUpgCActiveLava you set the fluid's name to "ActiveLava" , but in the blockstates file you use "activelava" .

Look at TileEntityMobSpawner and MobSpawnerBaseLogic to see how they read from/write to NBT. ItemBlock will call TileEntity#readFromNBT with the "BlockEntityTag" sub-compound of the ItemStack when the block is placed. You can see an example of this here. The NBT structure changed slightly in 1.9, look at the 1.9 branch of the repository for the updated code.

If you mouseover the line with the error, Eclipse should tell you exactly what's wrong with it. In this case, the arguments you're passing to EnumHelper.addArmorMaterial don't match its signature. Look at the EnumHelper class in your IDE to see the signature of the method.

Look for the net.minecraft.item.ItemArmor class inside the forgeSrc library. If it doesn't have sources attached, you haven't set up your workspace properly. This page explains how to properly set up a ForgeGradle workspace.

Use your IDE. In IntelliJ IDEA you can press Ctrl-N to bring up the Find Class window, this allows you to search for classes by name. Eclipse probably has a similar feature. You can also browse the forgeSrc library in your IDE to find the ItemArmor class and the ArmorMaterial enum inside of it.

soundOnEquip is the SoundEvent to play when the armour is equipped, yes. Look at the ArmorMaterial enum itself to see which SoundEvent s are used by vanilla armour.

There's no difference in this case, no. I can't think of any better way to do what you want.

Minecraft will automatically load a model for each Item (the one with its registry name), but it won't actually use that model unless you tell it to with ModelLoader.setCustomModelResourceLocation / ModelLoader.setCustomMeshDefinition . I do this automatically in my mod: Every Block or Item is added to a Set as it's registered (here and here). I then register models for the Item s (including ItemBlock s) with custom model names and add these to a Set (here and here). I then iterate through the Block s and Item s that haven't had models registered and register the default model for each one (here and here).

Use the one-argument constructor of CreativeTabs instead of the two-argument one and it will automatically use the next free ID for you.

You'll either need to create a new TileEntitySpecialRenderer that renders signs your way and register it for TileEntitySign.class using ClientRegistry#bindTileEntitySpecialRenderer or use ASM to modify TileEntitySignRenderer . Side note: Why are you using 1.8.8? 1.8.9 has received far more updates and 1.9 is now the recommended version.

I explain how to register items and their models in 1.9 here. The log should tell you exactly what went wrong with the model/texture loading process. Try following this troubleshooting guide to figure out what went wrong (though the error messages may be slightly outdated). If you still can't figure it out, upload your FML log (logs/fml-client-latest.log) and item/model registration code to Gist (with syntax highlighting) and link them here. A full repository of your code would also work instead of posting individual classes.

thank you, but i guess Choonster was faster hehe. What larsgerrits said still applies to my post: Once you've created your own GUI, you need to use the IGuiHandler system to open it.

Move the client-only code to your client proxy (or a class called from it).

If a class, field or method is marked with @SideOnly(Side.CLIENT) , it doesn't exist on the dedicated server and can't be used in common code. You must ensure that you don't reference client-only things outside of client-only code (e.g. your client proxy or a World#isRemote check). This page explains sides in more detail. This thread explains why you shouldn't use @SideOnly yourself. In this case, you tried to use IStateMapper outside of client-only code.

If your mod works on the client but crashes the dedicated server, you're most likely using client-only classes from common code. You've given us very little information to work with, so we can't really be more specific than that. Show us the crash report and the classes mentioned in it.

Ah, this is an issue with the sub-command system I wrote. Specifically, SubCommandHandler#registerCommand overrides a vanilla method and gets reobfuscated at build time (so it becomes something like func_0021_b ); but ISubCommandManager#registerCommand doesn't. Since there's no longer a SubCommandHandler#registerCommand method to implement the interface method at runtime, an AbstractMethodError is thrown. The solution is either to give the interface method a separate name and implement it in SubCommandHandler or to remove the interface and call SubCommandHandler#registerCommand directly. I've fixed this here.

That is the only place flag 8 is checked, yes. World#markAndNotifyBlock is the only other place that checks flags and it only checks flags 1, 2 and 4.

ContainerEnchantment#canInteractWith checks if the block at its position is Blocks.enchanting_table and the player is within 8 blocks of it, so it can't be used with your block. You need to create your own Container that extends ContainerEnchantment and overrides canInteractWith to check for your block instead. You also need to create your own GuiContainer class that renders like GuiEnchantment but uses your Container instead of ContainerEnchantment .

Those are the flags for World#setBlockState . Vanilla seems to use the same values for World#notifyBlockUpdate ; but as I pointed out, only RenderManager (the client-side IWorldEventListener ) checks if flag 8 is set. PathWorldListener (the common IWorldEventListener ) and WorldManager (the server-side IWorldEventListener ) ignore the flags completely.

You'll need an IModel and ItemOverrideList as I said in my previous post. Probably an ICustomModelLoader as well. You'll also need a texture for each digit so you can generate the BakedQuad s for the number. I don't know that much about the rendering system, so I can't help you much more than this.

Vanilla mostly uses 3 but it looks like the only place the argument is actually used is in RenderGlobal#notifyBlockUpdate , which only checks if (flags & != 0 . This is false for 3, but true for Integer.MAX_VALUE . I don't fully understand the rendering code, but it looks like this value controls whether the RenderChunk updates now ( true ) or later ( false ).