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 pres

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?

You can already do this within data recipes, it's just not particularly useful since the data is sorted by its type and not its file location. Why make a custom system rather than use vanilla's RecipeManager?

This has to do with very specific circumstances I think. From what I can gather in the codebase, when the fall event occurs, it's near the end of the handling method. As such, the movement wouldn't be applied until the next available tick. However, the player was marked as being on the ground and the jump button not being pressed. That ends up taking precedence and saying, "hey, don't increase the velocity, nothing happened". A special case is when the player takes damage though. A flag gets set to allow the knockback to be applied which takes priority over the being on the ground. As such, th

Is the error still the same? If so, could you put breakpoints within the client setup event where you register the renderer and attribute creation to make sure both events do run and call their methods?

There's a little error that sneaks by here that explains the issue: 'Caused by: java.lang.NullPointerException: Registry Object not present: industry:default_deepslate'. You statically held an instance of a registry object and classloaded the associated object before registry events have passed. Surface builders are registered after biomes after all. Instead, wrap the instance in a supplier. This should be done for all registry objects including the Features. Just make sure to remember to register the configured data during common setup. At some point, I suggest moving to JSON as you

#getPackedLightmapCoords or #getCombinedLight if you don't need the BlockState.

1. The RegistryEvents class needs to have the mod id in the annotation. 2. Your entity texture is doing nothing in the RenderFakeWither class, override #getTextureLocation and supply.

Please link a paste of the EntityType object initialization, where the associated register is attached to the event bus, the renderer, where the renderer is registered, and where the attributes are registered. I know you might have already sent them, but I would like full context rather than pictures of partial snippets. Also, you shouldn't be passing in a new instance of the Reloadable resource manager. Grab the one within the Minecraft instance and pass that in.

I would believe you would use WorldRenderer#getLightColor in some form.

Aha, this need to return NetworkHooks#getEntitySpawningPacket. Vanilla has hardcoded entries for non living entity types. As such, you need to set it to the custom packet so that the entity will spawn on the client and be rendered.

Can you provide the current class files along with the entity class? I have a sneaking suspicion on what's going on.

It's probably called #getEntityModel then, that's the mcp mapping name.