ChampionAsh5357

The best I can think of is a makeshift old redstone block where each state is its own separate block. Overriding the `Block::isIn` function is pointless since it doesn't take in a blockstate. This just leaves `CampfireBlock::func_226915_i_`, however this can't event be accessed since its specific for SOUL_CAMPFIRE. If you wanted to do a combined implementation, then you would need to override `Block::isIn` to return true if a SOUL_CAMPIRE is passed in and have your block extend CampireBlock. From there, you would need to put it in BlockTags::field_232882_ax_ which is also known as campfires. You could then override all the methods to make your block act the way its supposed to. That's the only two options I can really think of in the current state.

Use PlayerInteractEvent$EntityInteractSpecific. From there, kill the entity and add a new one. Right clicking entities is handled by the specific entity when interacted with.

Append to BlockTags::field_232865_O_ also known as piglin_repellents.

All the methods are unmapped as they now pass in a MatrixStack. This allow the text to be mapped to a location much better. So, you're parameters currently are String, float, float, int. Your new parameters are MatrixStack, String, float, float, int, so you would use FontRenderer::func_238405_a_.

Completely missed this, needs to be the mod event bus.

Are they never called or do you just not see the result because you never set the tint index on your models?

Fluid::getBlockState and then schedule a Fluid tick directly afterward. This will force to fluid to update and flow.

I thought LoadComplete was supposed to be avoided for modders. Also, DeferredWorkQueue because thread-safety is important.

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. This thread is old and outdated, please do not refer to this anymore.

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.