Animefan8888

I don't think it would be to noticeable in SinglePlayer, but on a server with several people it could cause some problems depending on the server. Considering it is (36 + 4(if armor)) * numPlayers * 20 iterations every second. Then possibly multiple conditional checks. If done right it wouldn't make much of an impact, though doing the above would be significantly better.

No that is wrong. Using new ItemBlock(block) would use an unregistered Item and the real Item would have a model.

That is why you would do both.

If you do EntityPlayer#inventory.currentItem you get the currently selected slot. Plus ItemTooltipEvent is only fired when the item is hovered over in an inventory.

You could use the PlayerTickEvent and only check the held item(s offhand maybe?) and armor slots if necessary, you do not need to iterate through the whole inventory. You could use the PlayerContainerEvent.Open/Close, but that will not do anything unless it opens or closes. You could use the ItemTooltipEvent if you want it to be displayed there and do some packet stuff accompanied with the afformentioned PlayerTickEvent.

Where are you calling ModelLoader.set...?

Capabilities make everything more organized, it becomes much easier to interface with.

Yes, the other one would have worked just as well, but the parenthesis did not need to be there. How much experience do you have with Java?

Look at the bottom where it says Common Mistakes.

That works, but why are there parenthesis around the block.getRegistryName() (Uneeded)

Take a look at this.

block.getRegistryName returns a ResourceLocation so you don't do new ResourceLocation(block.getRegistryName)

Attaching Capabilities is just like registering an Item pretty much. You are telling the game that the Entity, ItemStack, etc will have it. When this is called the object does't exist. So data cannot be saved to it. The data needs to be added specifically to each ItemStack in this case and is different between all of them. The Capability is not saved to the Item for this reason as they as well as Blocks are singletons.

ChunkEvent.Load is called whenever the chuck is loaded, when it is first generated to when it is reloaded from disk. ChunkDataEvent.Load is for when the Chunk is loaded from disk used for saving infomation to a chunk. And you should be using ChunkEvent.Load.

Instead of using 'modid', block.getUnlocalizedName().substring just use block.getRegistryName() which should be lower case anyways.

Is there anything in the console? And just to clarify the only problem is with the item? If so show where you register the model in code.

Ahhh, shift clicking the item out of the crafting table doesn't work while editing the result through the event. This is a problem with the Container#mergeItemStack because it uses ItemStack#copy and places that into the new slot or just modifies the current slot with a matching item. This can be 'fixed' by overriding the Items using substitution, using the Right Click/Player Tick, or whenever the vanilla ContainerWorkbench opens replace it with your own version that overrides the mergeItemStack method and applies the data to the stack when it comes out of the result slot or even using a custom Slot for the result instead of the vanilla one which will allow you to modify the Stack any way you want.

It says blocks and Nuke is capitalized.

Now you need a variant called "explode=false" and another called "explode=true", because you have two BlockStates one where the value is true and the other where it is false.

You can most definitely attach NBT data or Capability Data to ItemStack in the PlayerEvent.ItemCraftedEvent. Then there is the PlayerInteractEvent if you want to do a Right Click bind, ItemCraftedEvent for when it is crafted, or the TickEvent.PlayerTickEvent for when the item is held.

Does it work?

You must register your models in the ModeRegistryEvent with ModelLoader.setCustomModelResourceLocation().

"normal" specifies a variant, each variant can only have one model, and multiple submodels. It is also missing a "inventory" variant. And the "y": num is specifying a rotation which is pointless unless your block is rotatable like a furnace.

You could get the player in many ways, you could have it linked to a certain character upon creation (Item#onCreated) which could be reset by placing it back into a crafting table (Custom IRecipe implementation) or on right click (Item#onItemRightClick) you could bind it, or even as soon as it is held in the players hand via Item#onUpdate.

Sadly it wasn't the main error. The problem is with your BlockState JSON. Check this out it will help you understand them a lot better, and if you have any questions after come back and ask.