ChampionAsh5357

Read the javadocs on the method and use a bit of inspection to determine how to grab the generation builder and attach the ConfiguredFeature. Features can now have multiple placements as a warning.

Use Forge's network system.

Along with what I already mentioned, you need to sync the data to the logical client with a packet whenever the value changes.

Not deprecated iirc, but it's used within damageItem which already handles everything Wouldn't matter, item damage should be handled on the container item itself just like you have done. So, where you are doing it is where it should be done if I'm not mistaken.

Yes, if you want to edit an entity's AI, you should add or remove goals within EntityJoinWorldEvent. This will need to be done for every instance a zombie spawns, so this is necessary. However, you do need to grab all goals. Both of these are incorrect statements. You should take a look into Reflection or Access Transformers and apply what you know to what you need.

Clever way of damaging the item. However, you should not call Item#attemptDamageItem. Just call ItemStack#damageItem and then return the item after that, no checks required. Also, I do not believe the Consumer can be null, that should just point to an empty Consumer.

Then just reuse the code present in the other object or if the object doesn't have any design issues extend it. If they are separate, they should not be related to one another. You shouldn't need an instance of the codec as you shouldn't be reading/writing a block state to make it similar to another.

You've created a shape for every single rotation and it will change dependent on it. There is nothing wrong here, you've already done what you asked. However, once again, that's a bit too many defined and combined VoxelShapes for one block. As for non-related critiques, do not hardcode the property parameter within the constructor, and the property should be public in case you would like to access or set the state in a location from outside the block itself.

You haven't answered either of my two questions. How are you viewing the data? If you're grabbing it from the logical server, it will be present. However, the logical client would need to have the information synced across the two threads. You also only attach the capability on the client player meaning that it will never be stored or found on the server. This means that nothing in your above code will work.

One, where are you trying to view this data? Two, what is the ultimate goal you are trying to accomplish? Three, take a look into how Optionals work. Using orElseThrow is very pointless and should be instead switched for ifPresent.

If I'm not mistaken, there is some way to specify a portion of the screen to apply the shader to in the JSON using an intermediary layer to apply the shader to. As for how, I do not remember. I just remember there being something similar to that when I was doing research about them at the beginning of the month.

That's simple enough. The models you are registering doesn't have an assigned tint index for the specific face. For each face you want to be tinted, you need to set the tintIndex to the specific index being checked within the event itself (or any number if you're not checking for a specific one, most people go with 0). cube_all does not have a tint index specified for any of it's faces.

Global Loot Modifiers is what you need to look into.

Please don't dm me next time. I've already answered your question there.

If you used Blockbench to make animations, then you would need to follow the documentation provided by GeckoLib as that's what you are asking for. This would be unrelated to forge unless you did the interpolation route, which is not supported by Blockbench.

That would be done via a capability. You would store the entity type of the model the player is using and whenever that value changes, sync it to all players tracking and self. You will need to sync whenever a new player starts tracking the entity. From there, the rest is just handling the client rendering such that it uses the entity provided in probably RenderLivingEvent$Pre and not the stored instance of your player.

This is more appropriate to global loot modifiers. You are modifying the table by appending an entry to it.

Custom animations are handled through values stored on the entity model specifically for the client. Then the values are interpolated such that there is a smooth animation between ticks. Doing this by hand takes a lot of calculation, time, and effort. The other way would be to find a library that supports making animations in one form or another. One of these libraries is GeckoLib which is integrated into Blockbench.

You did half of the effect. You also need to override isReady. Second, if you are planning something similar to instant health, you should extend InstantEffect and override affectEntity and performEffect instead. isReady is already handled within InstantEffect.

The other issue is that you're using argument non-statically. You can chain arguments with then and add the argument in each one, then call execute.

You cannot have a diagonal voxel shape. The closest you can get is approximation. Also, you should use the least amount of voxel shapes as possible. Large amounts of voxel shapes tend to impact the game in a negative way. Finally, I can tell you generated the voxel shape via block bench. This is more of an opinion, but just use VoxelShapes#or instead of constructing the stream. Makes little to no sense to do so in my opinion as the approach is exactly what the method does anyways. If you're talking about the misalignment, that's probably because you need to create a voxel shape for every possible rotation and then change it via it's block state.

For reference, my opinion on using large textures is to have them delegated in a resource pack to be shipped with the mod while the main mod has the 16x16 textures for those with less powerful computers. High quality images mapped to objects tends to have a large effect on the processing speed of the game.

Biomes are final classes now. The event hooks into the construction process of the biomes and hijacks it's creation allowing for extra entries or fields in the builders to be set. So, the builder contains the methods to add the features. Also, you do not need to register the ConfiguredFeature. That's more for getting the JSON generated ones to grab the feature for the specific biome. Finally, Problematic Code 1. You cannot be certain that the feature is present when constructing a static version of ConfiguredFeature. If your class is loaded before the Features are registered, then it will be problematic. This is not to mention the registries might be frozen at that point. However, this is irrelevant as you do not need to register it. This is just for future case.

The end would be handled through the event while the custom dimension would take in the biomes to generate and those biomes would have the feature. On the event itself.

It does help if you could find a "controlled" argument somewhere in your declared arguments.