Choonster

You need to have a solid understanding of Java before you can make a mod. You cast null just like you cast any other value. This tutorial explains inheritance and casting.

I'm not going to give you the code, even for something this simple. You need to cast the null argument to Class<? extends ItemBlock> . Do you know how to cast?

No, I don't think that I am. Then I'm not sure why the Native class is being loaded. Is this right GameRegistry.registerBlock(candyPlant, null); because it is telling me that: The method registerBlock(Block, String) is ambiguous for the type GameRegistry This is one of the rare occasions where you need to cast null to the appropriate type ( Class<? extends ItemBlock> ) to avoid ambiguity. Without the cast, that call matches both the (Block, String) and (Block, Class<? extends ItemBlock>) overloads. The cast tells the compiler which one you're trying to call.

slotIndex is the inventory slot that the Slot represents. slotNumber is the index of the Slot in the Container . If a Container has slots from two inventories (e.g. a chest and a player), slotIndex will be 0 to X for the first inventory and 0 to Y for the second inventory, while slotNumber will be 0 to X+Y. I don't think there is.

You'll also need to set Slot#slotNumber to 1.

You'll need to subscribe to GuiOpenEvent to detect when the player opens a GuiEnchantment and perform the same Slot replacement on the client-side Container ( GuiContainer#inventorySlots ).

You should be able to subscribe to PlayerContainerEvent.Open to detect when the player opens a ContainerEnchantment and replace the lapis Slot in Container#inventorySlots with your own Slot that allows other items to be placed in it.

What properties/elements does it have? I cannot find this model in the assets so I am unsure what I need to supply in terms of textures. The model loader also does not like the variants I tried to specify in my blockstate json. (see edit) I also wish to render a bottom piece, like carpet, under the water (textured like planks). Can I add an elements object? Edit: I had malformed json (somehow the json plugin did not detect this). However upon fixing, it still throws "missing variants" exceptions but does load up a model in-game. It doesn't exist as a file in the assets, the quads are generated by ModelFluid at runtime. It implements IModelCustomData , which means that it accepts custom data from the blockstates file (via the "custom" object). The only key it uses in this data is "fluid" , which is the name of the fluid to render (this controls the textures and whether it's rendered as a gas). If you don't specify this, it defaults to water. You can see the blockstates file I use for my fluids here. If you post the full log with the exceptions, I may be able to tell you why they were thrown.

You can't reference client-only classes like Minecraft from the server. MinecraftServer#isSinglePlayer will return true if the server is either the integrated server (single-player/LAN) or the dedicated server run with the --singleplayer argument. MinecraftServer#isDedicatedServer will return true if the server is the dedicated server.

Are you referencing any classes in the com.sun.jna package? This is normal in the development environment. Forge forces the profile properties to filled when the integrated server starts, but there aren't any properties to fill because you're not using a real account. When a player's skin/cape texture is first requested, Minecraft sees that the profile properties are still empty and tries to have them filled; but Yggdrasil rejects the request because the previous request was too recent. If you don't want a Block to exist in Item form, simply don't register an ItemBlock for it. In 1.8.9, call an overload of GameRegistry.registerBlock with a Class<? extends ItemBlock> argument and pass null as that argument. In 1.9+, Block and Item registration are separated; so simply don't create or register the ItemBlock .

Thank you! Now I'm trying to work out what to do about IStorage and NBT. There are NBT-related methods in a bunch of different classes - in my default implementation (via ItemStackHandler ), in InventoryProvider , and in InventoryStorage . Do some of those need to cross-reference each other, and if so how? Also, do I need to actually manually call any of those methods, like in my EventHandler , or will they be called by Forge automatically anyway? The IStorage implementation should have its own NBT reading/writing logic, like CapabilityItemHandler 's IStorage does. The default implementation of your capability should also have its own NBT reading/writing logic if it implements INBTSerializable . The ICapabilitySerializable should either use the IStorage or the instance's INBTSerializable methods to read/write NBT. Forge will automatically call the INBTSerializable methods of an ICapabilityProvider you attach with AttachCapabilitiesEvent or return from Item#initCapabilities . If you provide a capability from your own TileEntity / Entity , you're responsible for reading it from and writing it to NBT.

PlayerEvent.NameFormat is fired when a player's display name is retrieved for the first time (or refreshed by calling EntityPlayer#refreshDisplayName ). You can use this to change the player's display name.

That looks correct apart from the unimplemented methods. I suggest extending ItemStackHandler for your default implementation so you don't have to re-implement all the IItemHandler logic yourself. You can still override methods to add custom behaviour as needed. I also suggest making the InventoryProvider#inv field private (so it can't be accessed by external classes except through the ICapabilityProvider API) and final (so it can't be replaced).

You should still be able to use ModelFluid for non-fluid blocks, you just need to provide the BlockFluidBase.FLUID_RENDER_PROPS unlisted properties.

Your ICapabilityProvider class needs to store the instance of ICustomInventoryCap that it provides from getCapability . I recommend separating the Capability field and ID from the default implementation of ICustomInventoryCap ( CustomInventoryDef ). In my code I create a dedicated class for each capability to handle registration and store the Capability instance (though there's no requirement to store it in a single place, @CapabiltiyInject will inject the instance anywhere). In my new mod, I store the Capability in an API class instead of the registration class. The OP needs their own capability so they can store an IItemHandler inventory with an EntityPlayer . EntityLivingBase already provides CapabilityItemHandler.ITEM_HANDLER_CAPABILITY , so attaching a provider for it with AttachCapabilitiesEvent won't work.

Vanilla liquids bypass the baked model system, they're rendered by BlockFluidRenderer . Forge provides the ModelFluid model ( forge:fluid ) to render modded fluid blocks with the baked model system. If you extend BlockFluidBase , you can probably override BlockFluidBase#getFluidHeightForRender to control the render height.

Forge already patches EntityLivingBase and various subclasses to provide CapabilityItemHandler.ITEM_HANDLER_CAPABILITY . This takes priority over custom providers attached with AttachCapabilitiesEvent , so attaching providers for CapabilityItemHandler.ITEM_HANDLER_CAPABILITY to living entities won't work. What you need to do is create your own interface that extends IItemHandler (it doesn't need to define any new methods) and register a capability for it. You can then use AttachCapabilitiesEvent to attach providers for this capability to players. The ICapabilityProvider you attach to an external object with AttachCapabilitiesEvent should be a new instance of your own class, not the ICapabilityProvider that the event was fired for. It also needs to implement INBTSerializable to load the capability from and save the capability to NBT. Forge provides the ICapabilitySerializable interface for convenience, this is simply a combination of ICapabilityProvider and INBTSerializable . For examples of capabilities, you can look at the capabilities provided by Forge (look for usages of CapabilityManager#register ), the capability test mod or my own mod's capabilities (API, implementation).

There is no BlockStateContainer#getBlockHardness method because BlockStateContainer doesn't implement IBlockState itself, it contains the Block 's valid IBlockSate s (hence the name). There is a BlockStateContainer.StateImplementation#getBlockHardness method that implements IBlockState#getBlockHardness . You don't actually need to use the BlockStateContainer.StateImplementation class, you only need to use the IBlockState interface implemented by it.

Despite being deprecated, it's the correct method to override. See LexManos' post on this here. Block#getBlockState returns the Block 's BlockStateContainer , which isn't what you need here. Use Block#getDefaultState to get the Block 's default IBlockState , then call IBlockState#withProperty get an IBlockState with each property set to the appropriate value.

Subclasses in a different package to the parent class can only access protected fields and methods from the parent class on this , they can't access protected fields and methods on other instances. Since you can't access the field, override the getter method instead: Block#getBlockHardness . Rather than calling this method on the other Block directly, call IBlockState#getBlockHardness on the state of the block you want to get the hardness for.

I suggest you look at how NBTUtil.readBlockState and NBTUtil.writeBlockState read/write an IBlockState to/from NBT.

Items still use metadata, that hasn't changed. Instead of overriding a method to return a different icon based on the metadata, you now register a model for each metadata value by calling ModelLoader.setCustomModelResourceLocation in preInit. This thread has links to various tutorials.

JEI is explicitly not a coremod.

JSON isn't the only model format, you can also use OBJ and B3D (which are mainstream formats rather than Minecraft-specific ones). The animation system should work with any of them. Unfortunately I don't know enough about models/animation to help you much further.

This thread offers several solutions to something similar: hiding a block unless a player is holding a specific item.