ChampionAsh5357

You post a bump an hour after you say something, don't. Provide a paste to your world generation files along with the debug.log detailing the error. Saying something doesn't work provides no context towards the actual problem.

So you're using a nonexistent method reference. Your second parameter is passing in a RegistryObject instead of a Block.

And so? A tutorial will not be written for everything you want to do. This is why you must inspect what I said and deduce how to use it. You're already given the event needed to attach the feature to a pre-existing biome. Now what you need is a ConfiguredFeature, which the class Features should provide many examples of.

Please stop posting in the forge gradle subforum. These threads should be in modder support. Also, what version are you using? This seems like something from 1.12.2 based on the mapping name.

Read the error and it should tell you what you need to do. A tiny bit of inspection is all that's needed.

Provide the debug.log in a paste.

The supported versions are in the blue banner above. Please update to one of those versions mentioned to receive support.

The supported versions are in the blue banner above. Please update to one of those versions mentioned to receive support.

For the client yes, the server will grab the data when initially loaded if I'm not mistaken.

It's called whenever a te is loaded. Sometimes it's also called whenever synchronizing from server to client.

Well, in my opinion, it's just as computationally efficient to use the RecipeManager and scrap the reload listener as it pretty much is a simple stateless filter. The only benefit here is a transition from O(n) -> O(k) where n is the number of recipes while k is the number of specific recipes. So, it all depends on if you want to cache your data, which still doesn't technically need a reload listener. Yes. You can technically invalidate cache without the need of a reload listener. However, I will not argue nor complain that the current implementation isn't okay as well. It's just better if you understand the reason why compared to using just a simple baseline.

Aha! So you are doing a bit of an assumption. The data is still present on the server as it should be; however, whenever the chunk is reloaded, you need to sync the value back to the client. Please see this section.

Vanilla syncs the RecipeManager to the client; however, you are just handling the server implementation. If you want to continue this way, you can just send a packet to execute the same code with the client side RecipeManager. There technically doesn't need to be anything sent as well since the data is already synchronized. As I already said, JSONs within the recipes folder will be automatically loaded and stored within the world instance. What you are doing with your reload listener is waiting for their completion and caching the results, something that is not necessary as you can just call the RecipeManager and grab it there. A reload listener should be used to grab data from resources. What these resources are depends on what you are specifically trying to grab.

How are you verifying this claim? This works fine if I'm not mistaken.

Apologies, although it is a bit confusing of the 5 different implementations of event bus attaching. You might want to verify the event is being called. So, then you shouldn't need a custom reload listener. Your recipes already have datapack support, this just sections of the recipes without the need of grabbing the world instance. Are you sure that the reload listener isn't being called? Because I believe you're misinterpreting not being called with not being synced to the client which if that's the case then you need to send a packet to transfer that information or update the client values with those from the client synced RecipeManager.

Either through the method you mentioned or the message builder within the channel itself. Both the method mentioned and the message builder have the option to specify the direction of packet sending, although it is optional. Does it need to? Those are helper methods the user can construct. Specifically, this is handled via PacketDistributor::ALL.

The following function is used to calculate the amount of entities to spawn: min + randInt[0, 1 + max - min). If you have a min and max of 1, at least one entity will spawn and at most one. However, there is no limit on how many times the spawner might be called. Also, entities can despawn or not spawn due to specific conditions as well which might reduce the amount to spawn. So, it's just a simple case of confirmation bias.

Well yes, that's what happens when you don't subscribe to the event bus. As for your recipe implementation, I do not understand why you just don't create an IRecipe instance with your own match wrapper as it would be much simpler since the reloads are already handled for you there.

Please provide the full console output instead of a snippet and provide it in a paste.

Apologies, I don't believe you need to register them.

Sorting a list is a Java concept. Take the time to learn about comparators and how to use them.

Just sort the NonNullList within ItemGroup#fill. How you sort is all dependent on you.

You have to do it the vanilla way with the registries in WorldGenRegistries. However, I don't believe this would be needed as dimensions are independent of all others. It's not like you're adding something to a pre-existing biome which would have some major issues, this is just a new dimension. So, you can register it for reliability concerns, but I believe it's not as necessary as some other things.

The current version of forge to use should be the latest minor which can be found on the forge download page. The current version of mappings to use can be found on the forge discord itself within the pins of the modder-support-116 channel.

Use RenderSystem or IRenderTypeBuffer accordingly. OpenGL is being isolated to make implementing a new render pipeline easier iirc.