Jay Avery

What values have you changed? Post your code.

No event is necessary. Look at vanilla BlockSlime. Block#slipperiness is a float field which you can set in the constructor. The bouncing is controlled by the methods onFallenUpon, onLanded, and onEntityWalk.

Look at the crafting table.

A crafting grid doesn't require a TileEntity, all the action happens in the Container. As demonstrated by the crafting table.

You shouldn't need a packet to do this. getDrops is called after the Block has been removed, which means the TileEntity has also already been removed so you can't get the colour information there. Instead you can override harvestBlock and use the TileEntity parameter (which should be an instance of your TE) to get the colour and spawn the drops yourself.

The Side parameter in registerMessage should be the side which receives the message - but you're sending the packet to the server. Where/when do you actually send it? It should also be surrounded by a world#isRemote check to make sure it's being sent only from the correct side.

This is the proper approach. Create a method in your proxy which returns the Minecraft instance on the Client-side only, then use this in your code after the isRemote check. The Server-side implementation should really throw an exception (since the method must never be called server-side).

That is an extremely broad question. There is plenty of information out there about making TileEntities, Containers, and GUIs. Do some research and get started, and come back when you have specific problems.

Got it! I think you'll need to give the player a capability to keep track of the property. (The forge docs has information about capabilities if you're not familiar with the system). Then, when your custom block is placed, you check the player's capability and define the behaviour depending on the property. If your blocks are placed with ordinary ItemBlocks, then you can override Block#getStateForPlacement and it will be handled by vanilla ItemBlock behaviour. If it's a custom item then you'll probably need to override Item#onItemUse to manually place the block with the appropriate state.

I don't fully understand your issue. Can you explain your aim in gameplay terms, instead of describing how you want to code it?

Well, you've already changed the part that isn't hardcoded - like you said. But it doesn't work properly. If you want to find all the places the maximum stack size in enforced, you could try stepping through the debugger while picking up, dropping, combining, etc stacks in the inventory to find where it happens. But if you just want a simple test mod, I'd recommend trying something else!

No it's not...? What image are you using?

This isn't valid syntax for the forge blockstates format. The "normal" variant has to be inside a "variants" object and defined as an array (with square brackets around the curly brackets). Look at the documentation for a simple example: https://mcforge.readthedocs.io/en/latest/blockstates/forgeBlockstates/#general-structure-of-the-format

The maximum stack of 64 is hardcoded in various places - it will either be very difficult or possibly require a coremod to increase.

In that case:

I can't find your texture image on your github. What size is the image? If it's not 256x256, you need to use Gui#drawModalRectWithCustomSizedTexture instead of Gui#drawTexturedModalRect.

Instead of a map you'll probably have to make an object for each recipe which contains the list of inputs and the output, and store a collection of those objects. Then search through the list of recipes to compare against the available inputs - using more or less the same technique that ShapelessRecipes uses.

You mean the constructor isn't getting called? Where do you initialise your blocks?

I originally misinterpreted and thought your recipes were one input -> multiple outputs rather than the other way round. Now I think that a Map alone may not work. The get method looks for equal objects, and two arrays will only be equal if they contain exactly the same element at every index. So if they contain the same elements but in a different order, or the inputs array contains all the required inputs plus extras, the recipe will fail even when it should succeed. I'd recommend taking a look at the vanilla ShapelessRecipes class which does a similar many->one thing. You might even be able to adjust your code to use ShapelessRecipes as it is, without needing to make your own implementation. The diamond helmet thing is not a problem in the way you think. When you print the Item to the console it writes ItemArmor@etc because ItemArmor is the declared type (there is no ItemDiamondHelmet class), but this doesn't change the Item's actual identity. If you print Items.DIAMOND_HELMET alone it will give the same output. And you can confirm that they are the same object by checking Items.DIAMOND_HELMET == new ItemStack(Items.DIAMOND_HELMET).getItem(), which will evaluate to true. This all works because Items are singletons so every diamond helmet is the exact same Item object. The short version is that Item doesn't override toString, so you don't get much useful information by printing an Item to the console as-is.

Ah I see. A Map will definitely make this easier, you won't have to compare indexes or search for recipes manually.

So you want the messages to happen with a delay when the player joins the server?

That crash report seems to be referring to a line that doesn't exist (line 56 of this 55-line file https://pastebin.com/2cReqiL6), are they both the most up-to-date versions of the class and the crash report? Either way though, I am confused about your recipes system. Why aren't you just using a Map of inputs to outputs? Honestly I have no idea! I guess for some reason it might be useful to check whether a stack can be stored before actually storing it...? I've certainly never used it that way, but I guess it wouldn't exist if there wasn't a potential use.

Can you please just describe what you intend to happen for a player, without referring to the code involved.

A delay from what in-game event or stimulus? Yes. You need to count ticks, but the way to do that is different depending on the context, which still isn't clear.

Ah, I was wrong in my previous post - the ItemAxe(ToolMaterial) constructor is hardcoded to only accept vanilla materials, so that constructor won't work. I don't think there's any other solution - you have to manually specify the damage and attack speed when you create an instance of ItemAxe. You can do that by storing that information elsewhere associated with your material (like you've done), or you could put literals in the constructor wherever you initalize your items, or you could give you custom axe fixed values for base damage and attack speed (rather than varying by material). A more concise and expandable way of storing your damage and attack speed values would be two Map<ToolMaterial, Float>s.