ChampionAsh5357

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.

Those two fields are independent of each other. Specifically, one handles the base speed of the entity while the other handles its implementation within a movement controller.

I should've put the word map in there. Basically, each biome has an associated registry key which is universally unique. You could grab the registry key of the specific object and pass that into a map to grab an associated object or interface which would allow you to do some custom mechanics for the biomes. It works the same as if it was attached to the object itself, minus a little extra time.

No, that wouldn't be feasible as this data driven system gets more developed over time. It would be just as easy to store a simple key interface that executes when a player is within a biome as needed without having to AT to extend the biome class.