Choonster

I've added a potion using this class which overrides Potion#renderInventoryEffect and Potion#renderHUDEffect to handle the icon rendering itself (imitating the vanilla code). Both overrides use this method (a wrapper around Forge's GuiUtils.drawTexturedModalRect ) to render the icon. For some reason, just over 1 square pixel of the icon (from the top-left corner) is rendering stretched over 18x18 pixels. What am I doing wrong? Screenshots:

You need to handle FOVUpdate and imitate the vanilla bow's FOV modification if the player is currently using your bow. You can see how I do this here. This is vanilla behaviour. When a player shoots an arrow in creative mode or with a bow that has the Infinity enchantment, the pickup status is set to CREATIVE_ONLY ; i.e. only players in creative mode can pick it up. When a player shoots an arrow normally, the pickup status is set to ALLOWED ; i.e. any player can pick it up. When a mob shoots an arrow, the pickup status is set to DISALLOWED ; i.e. no players can pick it up. If you don't want the arrow to be picked up by anyone, set its pickup status to DISALLOWED .

I believe you'll need to wait for this PR to be merged and set the action result to SUCCESS .

Metadata is limited to 4 bits, 16 possible combinations of values. To store multiple values in metadata, you need to use bitwise operations to put values in or get values out of each bit. Each bit can only be used for a single value. 10 possible values for Fabric Type will require all 4 bits of metadata to store (the highest value is 9, which is 1001 in binary), leaving no room for any other values.

To allow any remote version (including none), set the acceptableRemoteVersions argument of your @Mod annotation to "*" . To make your mod only load on the client or dedicated server, set the clientSideOnly or serverSideOnly argument of your @Mod annotation to true . Setting serverSideOnly to true will prevent your mod being used in single player, which would otherwise work (since single player is just a server with one player logged in). Don't rely on this as a security measure, malicious people can always decompile, modify and recompile your mod.

You have a _JAVA_OPTIONS environment variable setting the maximum memory to 512 MB, delete it.

What makes you say that?

Block and metadata arguments/return values have been replaced by IBlockState arguments/return values, World#getBlock and World#setBlock have been replaced by World#getBlockState and World#setBlockState . You can use Block#getDefaultState to get a Block 's default IBlockState . You can chain IBlockState#withProperty calls to get an IBlockState with each property set to the appropriate value. You can read an introduction to block states here.

You could store some of this data in a TileEntity , you can still access it in the blockstates file if you create properties for the various data types and override Block#getActualState to set them from the TileEntity . I have some examples of this here: Coloured Rotatable Block: Block , TileEntity , blockstates file - Stores the colour in the metadata and the facing in the TileEntity Coloured Multi Rotatable Block: Block , TileEntity , blockstates file - Stores the colour in the metadata and the facing and face rotation in the TileEntity In your case, you could probably have the following properties: Facing - An EnumFacing , probably limited to horizontals. Size - An enum with three values: Small, Medium, Large. Lighting - An enum with three values: None, Lanterns, Torches. Variant - An enum with ten values (whatever the ten variants are). Has Bed - A boolean. Only include this if having a bed is independent of the lighting. If the facing is limited to horizontals, you can store it in two bits of metadata; leaving two bits (four possible values) to store the size or lighting. You can store the rest in the TileEntity .

Most block models extend block/block , which defines the standard display transformations for block models. You should probably do this too. As I said in my previous post, there is no thirdperson display transformation any more; it's been split into thirdperson_righthand and thirdperson_lefthand .

IExtendedEntityProperties was replaced by the Capability system, a more extensible system that allows you to attach capability objects to any implementation of ICapabilityProvider ( Entity , TileEntity and ItemStack are the vanilla implementations). For examples, look at the capabilities provided by Forge itself ( CapabilityItemHandler , CapabilityFluidHandler , CapabilityAnimation ), the Forge capability test mod or my own mod's capabilities (API, implementation).

Yes. Look at the capability examples in Forge itself ( CapabilityItemHandler , CapabilityFluidHandler , CapabilityAnimation ), the Forge test mod that Ernio linked earlier or my own mod (API, implementation). You can also read the official documentation here.

In 1.9+, the firstperson and thirdperson display transformations that existed in 1.8.x have been split into left- and right-hand versions ( thirdperson_righthand , thirdperson_lefthand , firstperson_righthand and firstperson_lefthand ). If that's not the issue, post your models.

I'm not entirely sure what the issue with your shield is, but I can tell you that the pull property getter created by ItemBow only works for Items.BOW . You need to create your own property getter, like this one.

Yes, that's the correct bus. If it seems like it's not working, put a breakpoint in your event handler method and ensure it's actually being called.

Instead of calling Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register(Item, int, ModelResourceLocation) in init, call ModelLoader.setCustomModelResourceLocation in preInit (it takes the same arguments). Instead of registering models in your ModBlocks class, create a class that registers models and does nothing else; then call it from your client proxy.

Don't subscribe to RenderPlayerEvent itself, subscribe to RenderPlayerEvent.Pre . This is the actual event you want and the only sub-event of RenderPlayerEvent that can be cancelled. Attempting to cancel a non-cancellable event will throw an IllegalArgumentException . I suspect you didn't register your event handler, so your method was never being called.

You didn't post your FML log. In future, please upload each file as a separate Pastebin paste or separate files in a Gist. I suspect the issue is that you're referencing the all texture from another texture in the same model, Minecraft will have logged a warning telling you about this ("Unable to resolve texture due to upward reference"). Either create a separate model that extends this one and specify the all texture there or specify it in the blockstates file using Forge's blockstates format (like I do here). Never use unlocalised names for anything other than translation/display purposes. 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 ), so use this as the default domain and path of the ModelResourceLocation when registering your models. You should also be using ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition in preInit instead of ItemModelMesher#register and registering your models in a dedicated client-only class.

Post your code, blockstates file, model and FML log.

Call org.lwjgl.input.Mouse#getEventDWheel from your override of GuiScreen#handleMouseInput to get the scroll amount, if any. I suggest looking at how vanilla and Forge use this in various GUI classes like GuiScrollingList or GuiChat .

Send a packet.

You don't have Forge installed.

Use the Random class, you already have access to an instance of it stored in Item.itemRand .

This can be achieved by setting "shade" to false for each model element (see the wiki) and making the block emit light. You can see an example of this here: Block , model Screenshots: With UI: Without UI:

Whatever it is, it appears to be from BloodUtils.