ChampionAsh5357

I will make sure to include this as a note in my explanation. Congrats on getting it fixed.

Sort of. The mounting can still be disabled. Only dismounting is bugged. The issue is that the client does not tick the PlayerEntity unless it is not riding an entity causing the movement flag to always be set to true.

Dismounting an entity on client causes an infinite loop. Further testing reveals that only the player is affected when dismounting and can still control the riding entity. Server information syncs to client on game reload. ClientPlayerEntity movement input is no longer being sampled nor is livingTick even called. ClientPlayerEntity overrides isSneaking making setSneaking for setting the flag pointless on the client. This is most likely a bug.

Well that's an easy problem. You call textureHeight and textureWidth too late. For the biped model, it still uses a 64x32 image. So, your texture is compressed and scaled to that. You need to set it within your super like so: super(modelSize, 0, 128, 128); This makes it so that the default biped renderer knows that its supposed to be just taking the 64x32 area into account rather than the entire 128x128. Due to the lack of understanding of ModelRenderer and custom armor models, I spent the entire day creating a detailed explanation of it and how it should be rendered. I would recommend taking a read through it as it should go over everything you need to know.

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.