Positive, any perceived order after Blocks -> Items could change at any time.
I've seen people that know what they're talking about (including Lex) say it a million times.
I got into minecraft modding recently and was surprised by how hard it is to find useful up-to-date information. Because of that, I decided to document my learning journey and write a book about Minecraft modding for beginners. It applies to Minecraft 1.16.1 and the latest version of forge.
Keep in mind it is still a work in progress. More chapters will be added in the coming days. Suggestions and questions also are welcomed.
Link: https://thebookofmodding.ml/
Because you never know when a static block will execute, and if it executes too early, Forge can't insure that it has full control over the object.
(Forge does lots of lots of behind the scenes magic and dangerous sorcery that you, as a modder, don't need to worry about, but that if it isn't done in order, things break)
AFAIK, #handlePerspective returns the called model. So
public IBakedModel handlePerspective(ItemCameraTransforms.TransformType transform, MatrixStack stack) {
// any code
return original.handlePerspective(transform, stack); // will return `original`, which will bypass whatever custom model you have.
}
You'll have to replicate what #handlePerspective does to the model before it returns the same model. IIRC, it calls ForgeHooksClient.handlePerspective on the model, which actually does the transforming of the model.
That is precisely what that event is for. If you set the result the Pre event to DENY, then the plant won't advance to the next growth stage.
You can find a (complicated) example here:
https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderfarming/EventHandlers.java#L103
That takes into account biome temperature, rainfall, and neighboring plants to determine whether or not to grow. The net result is that crops of the same type grow at approximately the same speed, and its influenced by the ambient conditions (and different crops have different ideal conditions).
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.
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.
You're not allowed to reach across logical sides.
It is a nullable method that only returns the current world if IChunk is an instance of Chunk. I'm pretty sure Chunk is not the instance of IChunk called when constructing a biome for the first time.
The noise would make sense as its supposed to MAGNIFY the biome being created and fudge the sides to more fluently transition in.
Didn't I just mention this?
So question. If you're inside the SurfaceBuilder::buildSurface method, I believe it takes in a Biome as a parameter for the current biome. If so, why do you need to get the biome somewhere else? You're generating the surface for that specific chunk in that specific biome. If you're calling it to read from a different chunk, why?