V0idWa1k3r

No. ITickable isn't a magical interface that will deliver updates to everything you put it on. This will NOT work with a Block since the game won't iterate through ALL the blocks to deliver them the ticks. ITickable is for entities and tileentities.

assets/bm/models/ancient_gem.json != assets/bm/models/item/ancient_gem.json

Don't compare string instances using ==. Use the equals method.

...Why? I told you to remove the recipes based on their registry name. Why are you turning it into a string? You are even getting said registry name a line lower

RenderPlayer is very specific since it is attached to a "skin" identifier(steve or alex) You can get the map from Minecraft.getMinecraft().getRenderManager().getSkinMap() The value of a given key in said map will be the RenderPlayer instance.

You can add a layer to the renderer at any point after which the renderer itself is created. So maybe postinit would be fine? You would need to debug it.

Well, since RenderPlayerEvent fires every time the player is rendered(aka every frame) you are adding a new layer each frame...

...Only cancel the event when you are actually in liquid? Let vanilla take it's course when you are not in it.

Wrong subforum. Don't remove while iterating like that. In most cases you would crash with a CME. Don't access a registry like that. Remove the recipes during the appropriate registry event. This will always be true. Remove the recipes based on their registry name, not their output.

I meant show, sorry. Read the docs on the FogDensity event: /** * Event that allows any feature to customize the fog density the player sees. * NOTE: In order to make this event have an effect, you must cancel the event */

Your code looks fine to me at a first glance. Could you provide a link to your github repository so I can debug it locally?

Wrong subforum. You needed to go here Please read the EAQ and provide the appropriate log.

All I can tell you is one of your blocks has a null registry name. Can't tell you which one since you've never provided the code for said blocks.

https://github.com/Thegametutor101/Pixelmon_Project_School/blob/Pixelmon_Main/java/pixelmonMod/entities/throwableEntities/pokeballEntities/renders/RenderThrowablePokeball.java#L24 As I've said you are creating a new instance of RenderItem. Don't ever do that. Take the one provided by Minecraft. Don't do it in the costructor or you will crash later with an NPE.

Well, you haven't provided your up-to-date code so I can't tell you what's wrong. Although if I were to guess you are doing something strange yet again, like creating a new instance of RenderItem for whatever reason.

This is too late to register the renderer. Register it earlier

You've never registered the network tracking parameters for your entity type in the builder, so the clients don't receive updates about it as a result and don't even know it is there.

This indicates that you haven't registered your renderer.

Sure, just don't construct it every frame. Yes it is. Please don't post copyrighted code on the forums. We can all see this class in our IDE, there is 0 reason to post it here.

Please keep this forum in english, thank you. 3000 is way too big for a durability multiplier. For some armor pieces this would overflow over the max short value which will cause the maximum damage to be negaive which will cause issues.

That package doesn't exist. In net.soroos.ben.linguism.guide.capability.CapabilityHandler you are attaching it to EntityPlayer instances which encompasses both the client and the server players.

Capabilities exist on whatever side you want them to exist since you are the one attaching them. For example - If you only attach your capability to an instance of EntityPlayerMP then sure, it will only exist on the server. But you don't usually want to do that. If you attach it to an instance of EntityPlayer then all players will have it - EntityPlayerMP(server-side player), EntityPlayerSP(client-side player), EntityOtherPlayerMP(client-side other players). That seems like a better idea, yes.

Don't do this, the server should be in control as to when to send the data to whom. A malicious client could easily abuse requests. The capability is attached both on the server and on the client, so store it in the client capability.

Don't use ItemBase. Well, you are not setting your item in use. You are just clicking it which does nothing. Bow uses EntityPlayer#setActiveHand

Pass your EntityType, obviously, that's what it is asking of you. Don't use a static initializer for it. Use the ObjectHolder annotation to get the reference to your EntityType, or store it in a field and pass said field.