ChampionAsh5357

NetworkHooks#openGui, pass in some INamedContainerProvider. Containers are only tied to the player initializing one.

You should have a container when you need to represent modifiable server side data on the client.

1. Transfer what subject? The focus of the screen? It's always on the currently open screen. 2. Changing anything on the client does not work, you would need to send a packet back to the server with the change or have the logic execute on the server (preferably the latter). It's a factory to create a container for a specific circumstance. It's not supposed to be reusable for every single thing you do. If you wanted that, do some inheritance to make it to the point where the amount of code needed to modify is minimal. Screens don't have a registry object, they are only present on the logical client. They can be attached to containers to give a server a client form or they can just be standalone. If you're going to open a screen, you can simply just call the display screen method either in Minecraft or ClientPlayerEntity similar to how the sign does it.

Your carvers seem to be working as intended from what I glance. I would suggest looking at the existing CaveWorldCarver since that most likely has what you're looking for.

As I've explained, the link is dead because the information in the page is inaccurate and out of best practice. Please don't pass around links that should be considered dead. It's not in anyone's best interest for learning how to create good quality programs.

Minecraft does not really have a concept of colored light. As such, if you wanted the color of a specific face, you would need to go into the baked model, grab the top quad, get the color of the quad, and apply the brightness modifier to it. At that point though it's not particularly worth it.

Found the error, and its annoying. The resource location being passed into the rendering handler has the modid written twice, once in the namespace and once in the path. The path does not accept colons, so an error was thrown which was eaten by the lambda and discarded. All you need to do is remove the modid and the colon from the path of the resource location in ModRenderers.

There's nothing that suggests the error is outside of #shouldRender meaning that the entity renderer might be null somehow. However, there is nothing that suggests an error can occur there with the snippets. Would you mind posting a link to your repository on Github, Gitlab, etc.? I'm going to build a local workspace and see if I can't debug it.

The ConfiguredSurfaceBuilder when being passed into the biome. Call the vanilla registry event within common setup. That's when these objects should be registered anyways.

Within runs/logs/debug.log

You can have a subdirectory within the recipes. If you're talking about generating them with RecipeProvider, then you would need to write the handling for that within the #save method or something similar.

Ok, just add a new IRecipeType. Boom, new category.

That doesn't mean you need a custom recipe system. The RecipeManager can support any recipe as long as you give it a recipe type and serializer to work with. The IRecipe class could then be up for interpretation of implementation. As for organizational purposes, the recipe manager will check any subdirectories, so it makes no difference.

Can you provide a paste of the entire debug log? I don't see anything wrong with the code currently. Also, could you provide the entity class?