ChampionAsh5357

This is relevant to you since the data is synced to the client only when you tell it to be. Otherwise, it will remain forever empty on the client.

Apologies, but 1.12.2 is no longer supported. You can check the currently supported versions in the blue banner above. Please update to one of those if you would like to receive support.

No, that is applied for every living entity so essentially you would be checking as many times as there are entities instead of once per tick.

1. Not afaik. 2. The entity is was already added and deferred to load at the correct time already. Follow the event call and you'll see that entities are loaded at a very specific point when processing. Trying to add your own entity at any point in this process would mean you could be loading a chunk that's already loading. 3. No, that is much more difficult.

Reading the javadoc on the event tells you: "Note: This event may be called before the underlying Chunk is promoted to ChunkStatus#FULL. You will cause chunk loading deadlocks if you don't delay your world interactions." As such, you should probably keep a queue of entities added along with the world and position you would like it to spawn at. Then, on the next tick in probably WorldTickEvent, check if the chunk is loaded at the position of spawning and if so spawn the entity. Otherwise, recycle into the queue until next tick.

It triggers but only when the spawn placement is valid. Since there is no sane way of replacing the spawn placements, you most likely cannot do this unless you build your own spawner currently. However, I would say this would be a valid candidate for a PR to expand the conditions to an optional tag.

I'm confused on why you are using reflection. Everything above does not need it. All are public except for the method which just returns itself so it doesn't matter. They are all forge registry entries which you can register normally.

Did you register `RECIPE_SERIALIZERS` to the mod event bus in your main constructor? Also: 1. Do not static init SMITHING_RECIPE_SERIALIZER, just use the registry object. 2. You shouldn't be doing this with getRecipes. Just call the method when needed. 3. registerType and RecipeType are unnecessary, just call IRecipeType#register.

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?

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, the player is knocked into the air since it just takes a sample of the set delta movement. Falling on a block is a different matter as this is called during the Entity#move method after all replacement logic on the delta movement has been applied. This allows the block to do whatever to the delta movement. I apologize for any inaccuracies in this assessment.

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?