ChampionAsh5357

PlayerRenderer#getModel?

You don't. Just assume if nobody is being dumb that all logic will be uniformly spread over a period of time. MC logic should be done relative to ticks anyways so you won't have to deal with desynced real world timing.

Don't simplify. Provide an exact paste of the entire class. Simplification means you're filtering out code you think might not be relevant but might be actually causing the error. It's preferable if you can provide a repo to your codebase instead of just snippets though because the above error suggests that you're trying to refer to an unmapped field.

Look at a reference of the perspectives test. If that's the case, you're probably not overriding the render method. Put an override annotation on the method. If it fails, find the correct method signature and adjust.

I'm guessing this is for a TileEntity? If so, it's called once every tick so its constant in terms of MC. As for the time between those ticks, it usually is approximately the same unless some bad logic is causing the ticks to lag behind.

1. I didn't even look at your class, I looked at the item being registered to which there is no reference to your subclass. 2. The sound is null because it doesn't exist. SoundEvents are objects that need to be registered and then pointed to in the sounds.json. You cannot create them on the fly.

Look at PlayerRenderer#render*Arm, copy the logic, change the texture being passed into the RenderType.

I just told you there is no association. The item model manager has no concept of any models that are not part of an item. If you want to add a special model, you have to pull it directly from the ModelManager and not from the ItemModelMesher. This doesn't explain why it can't be part of the item. You could just use the gui model for the gui transform type and specify the other json mdoel as the first person right/left hand using the perspective model json. The notion of having a completely separate model from the item being thrown imo is outdated and should be respectively attached to the item render itself.

So, why are you trying to make the bullet json separate from the item itself? You seem to be under the assumption that #addSpecialModel attaches the model to your item. It just attaches the model to general ModelManager. However, this seems completely unnecessary as you could just specify this as the item model.

1. Create a subclass of the item, override the method and append to the text component list. 2. Click on it. Armor stands are made to take any ArmorItem. 3. Create a model texture for the horse and put it in the ResourceLocation specified by your second variable (note you can't just put 'silver' for that value, supply it a resource location with your mod id).

This needs to be registered in ParticleFactoryRegisterEvent. FMLClientSetupEvent is too late.

Inside RenderHandEvent. You just need to do all the logic instead of parts of it.

The inventory of a block is dropped by #onRemove in all vanilla cases.

Recipes have been data driven since 1.12. If you want to develop a recipe system, it is highly recommended to go the datagen JSON system. The only edge cases is if there is some custom logic that is so specific that it needs to be represented in code instead of genericized down to JSON.

The method still exists, it's just under a different name. Forge was originally shipped using the MCP mapping set; however, it switch to mojmaps as of the 1.16.5 RB. So, fields/methods/parameters have different names now (classes will too in 1.17). You can use the forge-bot in the forge discord or the Linkie bot in the linkie discord to translate between the two mapping sets. In this case, the method is called 'setupAnim'.

1. Don't use OnlyIn, properly side off your code. 2. You never register your entity renderer, the static method isn't called anywhere so nothing happens. Register it within FMLClientSetupEvent. 3. Attributes are never registered, same reason. Use the EntityAttributeCreationEvent for this.

Probably because entity textures are bound using a batched rendering system and not on the fly. You need to handle the rendering of the model yourself, not delegate it to the PlayerRenderer.

Where and in what context? Also what is Registry#location?

If you put an override annotation on the method, does it give you an error. If so, why do you think that error is there? How can you resolve it? Is the method signature correct? Are you providing the correct method name based on the mapping set you are using?

There is no ViewProjection class within 1.16.5. If you're asking about how to draw 2d objects in 3d space, look at how name tags are rendered on an Entity (can be found in EntityRenderer).

You would need to handle some rendering logic via RenderHandEvent. The layers are only applied in third person as you can never see the player in first.

This statement is a bit incorrect. The methods still exist, they just use a different mapping set (MCP) than what forge ships with the mdk by default (mojmap). You can use forge-bot on the Forge Discord or Linkie on the Linkie Discord to translate from them. I would probably use a chunk capability instead and tick logic on loaded chunks since you'd have to check every block if it's loaded other than checking the loaded chunks. You could also use a world capability to store the chunks that have an active capability for more efficient usage.

You can check an updated resource here on the community docs.

The color needs to be specified using IParticleData since that would be dynamic data which you can look at the example in RedstoneParticleData. Textures are usually any subclass of SpriteTextureParticle. The spawning of the particle is definitely covered on the documentation. Show what you currently have. You're asking for specific behavior instead of something more generalized.

Where are you setting this information? How are you setting it? When are you setting it? Makes sense since it's called on both logical sides.