ChampionAsh5357

Currently, the way to implement a custom spawner is to tick a custom spawning class via WorldTickEvent on the logical server. Minecraft has 5 spawners that are marked as 'special' meaning they extend ISpecialSpawner. These are first passed into an immutable list within MinecraftServer::func_240787_a_ and then stored as a variable within server world to be called when a chunk is ticked. I suggest a new hook that takes in a list of these 5 existing spawners along with a parameter for IServerWorldInfo. This could then be past into a new event which allows the user to add a spawner. As an option, a user might also be able to remove the other 'special' spawners as well to replace with their own. Afterwards, the hook would return an immutable list containing the special spawners. The event should not be cancelable and should not have a result. It would also be fired on the MinecraftForge::EVENT_BUS. This hook would only be called once during the initialization of the logical server as opposed to being called every tick as an alternative. If this seems like a valid event to be implemented, I will get started on creating a PR for 1.16.

As prior amateur, I can attest to this. Currently, I am trying to improve my skills and knowledge by being active on these forms and verifying all of what I want to say. I believe the only tutorials currently recommended are those by McJty. If you need help on a problem that you cannot deconstruct by yourself, you should always turn to the forms or the forge discord.

It's not necessarily how many collision boxes there are, its more of how complex the shape is. The most complex shape a collision box could have 2048 boxes. These would not intersect and create new boxes. This many boxes would probably drop the speed yes, but more in specific circumstances. The collision boxes mostly matter when constructing and destroying the block. This is when the collision boxes get updated so breaking many in succession quickly would cause lag. However, a bunch of them existing in the world wouldn't really cause a slow down. As a person who's generated complex collision boxes in large quantities, here is my take on collision boxes. You want to try and reduce the complexity as much as possible. Also, they should be initialized only once using a variable so that the calculations aren't done every time the block is created/destroyed. You can have as many generate as you want. Just realize that you have to balance the complexity of your shape with the efficiency of harvesting and placement in the world.

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.