ChampionAsh5357

This is not applicable for 1.16.2+ as the system was changed. First, you will need to register your Configured Feature within the associated WorldGenRegistries. I would suggest looking at how the Features class does the registering and borrow the method. Note that this should be deferred until FMLCommonSetupEvent. For reference, the register event is not thread-safe, so it should be wrapped using the synchronous work queue provided in the event (e.g. enqueueWork). From there, you can attach the feature to the biome(s) of your choice using BiomeLoadingEvent. You can grab the generation settings builder there and add a feature during a specific point in the generation process, in your case most likely UNDERGROUND_ORES.

You have to answer that question yourself. What are you attempting to do in a generic form? I see you trying to keep a specific item in the crafting table and not be used. Is that the only case or does this expand to any item for a specific recipe? These are questions that need to be answered.

Depends on the complexity of the recipe. If there is no requirement for dynamic manipulation, you can get away with making a custom recipe with serializer and building a json off of that. You haven't created the recipe serializer. Take a look at ShapedRecipe for that. Also, every method within IRecipe except for basically two (I'm not counting the getters) has documentation associated with it. The other two gets the items that are supposed to be left over in the inventory using container items while the other gets the recipe ingredients.

Afaik, it was marked deprecated by Mojang with no real replacement as of yet without rewriting the blit methods. So, currently it is ok to use as is similar to how DeferredWorkQueue was used statically until Forge 34.

Since I can't reproduce the error, I have relatively no clue what it could be. Apologies.

You do realize that this could be done within the gradle buildscript if you set it up properly.

You could always read the documentation on how to use deferred register.

If the fluid was not synced across logical sides, then it would not appear in the picture I sent. It also updated as normal on both sides, so afaik there was no desynchronization. As such, I don't think its the issue. Can you describe the exact process done to the jar from being built using `gradlew build` to opening within the vanilla launcher?

The client spec should be the only config to be applied on the physical client side. Common specs take precedent on whichever physical side holds the logical server. As such, they can consider to be accurate when being applied to the logical server. A common spec should be used when applying to a logical server if it should modify all instances of the underlying world being played. If its a per world configuration, then a server config should take priority. This is not true. This means that you are trying to execute logical server code on the logical client, which leads to desynchronization. If you really do need to sync the common configuration, you can send a packet. Here is also an unofficial version of the packet docs as well for more reference.

Hmm, this is quite strange. However, I cannot reproduce the error:

Structure blocks are your friend here. I suggest using them to generate what you are looking for.

Can you verify if the built mod is actually binding the renderer to the tile entity? Can you also verify the render method of the fluid tank is actually being called? Finally, can you use the same Forge version in both environments? That last one shouldn't have an effect, but it removes possible variables from the equation.

The EOL of the file is in windows CR LF format. You should find a text editor that can convert the EOL of the file from CR LF to LF. This should fix the issue.

If the cauldron block renders correctly, would you mind removing the fluid tank @OnlyIn annotation? It shouldn't be used regardless.

Events are for interfacing with pre-existing systems within Vanilla. As you are the creator, you can implement the required logic on the block itself. Now let's discuss the logic. This is irrelevant since the data is stored on the nbt instance of the tile entity and not the item itself. You should also probably read up on capabilities. I am attaching a community written version of the docs as the forge docs are still outdated on the manner. Finally, all you are trying to execute should be done on the logical server. None of this seems to require the logical client in the slightest. This can seemingly be done using Block#onBlockActivated and grabbing the associated tile entity to do the logic.

Please supply the debug logs of both environments and the relevant repository in question.

It's not guaranteed to return a proper value. You should pass the biome instance into the biome registry held within DynamicRegistries and do a reverse lookup instead to grab the associated resource location.

You need to set the render layer via RenderTypeLookup::setRenderLayer to cutout within the client setup event.

Method 1: annotation on common setup does nothing, registry event still on forge bus Method 2: same as method 1 Method 3: same as above Method 4: crash on startup Method 5: same as method 1 Essentially, you did the same thing over and over. You read the resources but ignored my comment.

There a few things wrong with code style here. You are trying to execute the registry event on the forge bus and the common setup on both buses. You might want to review events and figure out how to fix this issue.

As, I've already explained, you need to download some JDK 8. Then, attach it to your IDE of choice and use that to compile the jar.

First, you do not have a Java Development Kit installed. Second, take the time to learn the language if anything. Probably not the best idea to come to the forums saying you do not wish to learn.

We currently have the ability to add fluids to all entities, but no real system to handle the fluid itself. Specifically, I will be talking about the associated physics as the client side effects are simply just fluid checks with events. The relevant common code effects can also be matched using the many provided events added by Forge. There are a few places where relevant tagged data would need to be check for custom fluid handling, but its less important for the purposes of this post. To make a minimum viable fluid with unique physics, one must apply two methods provided within the entity: Entity#handleFluidAcceleration which does exactly what it says and Entity#func_233571_b_ which grabs where the entities eyes are within the fluid level. Both of these are used in different places. The first is used within the entity tick via Entity#func_233566_aG_. The second is used to determine if the user might be jumping off the ground within a fluid, moving through fluid, swimming in fluid, etc. Exposing this would result in some class object or registry that would store the associated fluid tag, a function given the entity and returning the acceleration, a consumer containing the entity if the fluid acceleration returns true to update a specific state. The fluid code would also need to be patched within LivingEntity#livingTick to check the tags for the correct fluid the entity is in when jumping and whether or not entities can swim within it. I want to discuss what would be the optimal way of storing and handling these instances. Creating an event is out of the question as its unnecessary ticks for a portion of the code that can be handled with a registry. It would also be good to consider fluids in some sort of dynamic context where existing hardcoded traits could be genericized in some fashion. However, most of this code dances in the realm of tags, so there would need to be some discussion on how to handle and comply with Forge's stance on tags.

The method still revolves around TextureStitchEvent$Pre and overriding #getBackground. Please show your slot implementation.

1.12.2 is not supported on the forums. Please see the above banner for supported versions.