ChampionAsh5357

Armor with custom armor models are an absolute pain to correctly implement with no understanding. So, to counteract that, I have decided to write a detailed account of how to create your armor and your model correctly. Please note: I will not go over the specifics of any particular modeling software or anything that should already be known about items. I expect that you have made at least one item before and know how to register it. Here is the link if you would like to take a read. Please let me know if there is anything I need to correct or update.

1.12.2 is no longer supported on this forum. Please update to a later version. LTS is 1.15.2, 1.14.4 is in a grace period until 1.16.x has a recommended build.

Setting a global variable to a local variable does not make it local. You're having the same issue as the other person where you are trying to render everything custom and then adding child models. The top 64x32 area is reserved for the biped model rendering. Everything beneath that is space to render your own model on top of. If you are creating a texture that uses basic armor texturing, use the biped model area. Else, create your own model and attach it.

Yeah. The default armor model uses that 64x32 area. If you are constructing a texture that doesn't specific change the default model of the armor, then it would be applied just like any other armor texture. I believe that has to do with the double child model and a case of lucky mistakes. When declaring the width, height, or depth of your model, it adjusts the scale of the texture needed to be wrapped. In the example I took from you, a width and height of 5.0 and 4.0 are fine. However, .26 is not so much. Even though in the tabula it will look normal, Minecraft will actually take your image, scale it up, and reference it as if it was literally 0.26 instead of what tabula outputs. So in your case, to have a correctly mapped texture, it would need to be scaled up to 6400x3200 to correctly map those decimal values. Also, a model with a size of 0.0 will not render anything. I believe it needs at least a 0.005 thickness to stop flickering.

But it's the same issue as before? The top half of the texture is 64x25, 7 pixels short of the default 64x32. The default biped model renders the 64x32 area as its texture. Anything you add "must" be below that 64x32 area if you dont want it interfering in the default model. (I put must in quotations because there is some empty space throughout the model you could use).

The armor in the top 64x32 will be rendered automatically since that is where the original overlay is. The only thing you should be rendering is anything not already in the 64x32 biped model space. I also just opened up your texture file. The mapping is going to be very wrong. A file size of 841x326 does not scale down to 64x32. It differs by a factor of .5 resulting in the half texture offset you see before you.

Look at Goals. All ai has an associated Goal file somewhere. Then you can register them via MobEntity::registerGoals.

I'm guessing you didn't even look at NoiseChunkGenerator::generateSurface. It calls WorldGenRegion::getBiome which gets a biome at a certain position. Then, Biome::buildSurface is called which passes the biome parameter to the SurfaceBuilder. The biome locations are already determined at this point or else it wouldn't be accessible.

Doesn't the function take in an x and z coordinate? If I go up, I find that the entire chunk is iterated through in NoiseChunkGenerator::generateSurface and passes the x and z coordinate of each block into the function. This means that the function does get called 256 times. It also gets the specific biome the surface generator is calling from at that coordinate.

I just said call the parent. So you would do bipedHead.showModel instead of helmet.showModel because the childs are rendered via the global renderer.

There's a registry for that. ForgeRegistries::SOUNDS I believe.

If you want to do showModel, then you would call the parent (e.g. bipedHead, bipedBody whatever they are called) and then showModel. If I'm not mistaken, this will show the default armor overlay as well. So the incorrect textures may have something to do with that afterwards.

So you're trying to access a RiverBiome, for example, while the surface of the biome being built. If the biome hasn't been built before, and the method is just getting called, the biome would be generated before or after your custom one. So, you're trying to access something that won't properly exist until the chunk is completely built. You would need to get a specific coordinate after the chunk has generated. I believe this is how biomes are generated.

1.14 is unfortunately unsupported on the forum now. On a quick side note however: 1.16 introduces a state system for light value which should hopefully improve the lag issue.

When you do ModelRenderer::addBox, it takes in a starting x, y, and z position. Just changes those to match where you want the model to be. Rotation should be handled by ModelRenderer::copyModelAngles.