ChampionAsh5357

You did something wrong in your mod then. Please link your repo so we can see the code.

Make a separate thread for different problems. Update to latest minor. Do some functional programming correctly with the ER constructor.

The same way as you start any other modding environment.

vemerion is completely right. And you do it, the same way, again.

1.12.2 is not supported on this forum. Please update to at least LTS 1.15.2 to receive support.

In the source within your IDE.

You would need to use Import... -> Existing Gradle Project and then direct to the folder where your mdk has been extracted to.

Maybe look inside the class itself. That could always help. Don't ever try and take the easy way out by trying to find some tutorial that tells you exactly what you need to copy-paste. Apply your knowledge in Java and adapt to the current situation.

I never said cast your instance to anything. You should probably look over the LazyOptional class and check out the method I'm referring to.

RenderTypeLookup#setRenderLayer in your client setup event should do the trick. Also, update to the latest minor.

You seem to have copied the apache libraries that are already present in forge as well.

I believe you would need to set the configurations to only include whichever you need using configurations = [project_configs]. That's why I said create a configuration called shade before so that you could call that.

Hmmm, my only guess is that it's iterating through the apache commons package directory and skipping yours. As for how to fix this, you might have to do something more with relocate, but that is the best I can think of.

In the development environment or the finalized jar?

If you only copied over the relevant files from a different project, then those source folders won't exist normally. You will need to create them manually and then rerun your gradle commands to tell everything that "hey, I exist now".

First of all, Code Style 4. Second of all, copy-pasting code doesn't teach you anything. It's just a lazy-excuse of the current level of understanding you are lacking. Third of all, update to the latest minor. There are new ways of handling biome spawns, basically Problematic Code 11. Fourth of all, if you can't find the method in your version, it probably means the mappings aren't updated. Fifth of all, to negate the fourth point, you should try and add a new JigsawPiece to add an entity spawn to the village. It's all handled via nbt files nowadays and you can construct your piece to be generated along with the village. How to do this is left as an exercise for you. Sixth of all, don't use him as a style guide. He promotes bad practices in Java. Seventh, relearn Java first, then come back to modding. It's better to have a good foundation else you're gonna pick up bad practices. Eighth, you're more or less trying to find an answer without attempting to dive into the source code of Minecraft and problem solve your way through it. I'm not trying to be rude, but not understanding what you're doing is a detriment to your overall ability. This is the advice I will give you, I hope you take it to heart.

You shouldn't need to edit the buildscript at all. Plugins are applied using the plugins{} block although what you are doing will work as well. I believe the keyword to use is shade instead of shadow with shade being a configuration. You would also need a shadowJar{} block to specify where to relocate the files to.

Well technically, that's what you have to do by shadowing the jar into your own using Gradle. This allows others to use your mod without requiring some dependency that might or might not already be on their system.

First, that is not how you do generation first of all, see Problematic Code 11. Second, you can't create a configured placement without specifying a placement. What are you configurating? Third, there is some placement called "count" and some placement called "range" and a combination of those two will get your ore generating correctly. Fourth, you could've just looked in Features and looked at how ores do it. Fifth, there is no fifth point, fix the generation again (first point is important). Sixth, use upper camel case for class names. Seventh, use lower camel case or snake case for non-static final fields. Eighth, don't reconstruct a list many times when the information is static. Make it a global field.

That could be handled by a LayerRenderer so that you can split the texture to differentiate the two resolutions easier. Fair enough, you just want the smallest size you can so that it can run fluently for anybody who's using your mod.

Not being rude, that's more a result of poor animation rather than textures. If handled correctly, there should be no way to overlap the body. This is less related to Minecraft and more taking a texture, masking by color range, using some sort of neural algorithm to determine whether the pixels represent a line or not and then editing the values to achieve the effect you want.

Not true, it's just better to use ratios, widths, and heights that are a power of two. All data is sent and processed in a stream of bytes, so modifying a stream of byte data before it reaches it source is more than possible. A better answer is don't. You have a model and you can apply any texture to it within the renderer. Just use that instead of editing some other texture data. You can do some clever logic with the renderers in the model to achieve your goal with no hassle, just requires a bit of time. Why couldn't you?

As a personal note whenever it comes to textures of anything, always try to use the smallest size possible to represent your entity (e.g. 64x32 is the smallest for most entities). You can then ship another resource pack with your mod that displays the high quality textures. This negates the issue of lag from older model cpus/gpus when loading your mod. As a side note, avoid using non-powers of two in your texture. It causes some fun math issues when scaling the texture. With a ratio of 1:1.1953125, making smaller textures might as well be difficult when mapped. In this case, the smallest texture I could make is a 153x128 texture.

I would definitely recommend reading over the forge docs on this then. This is basically what you need to do for the fluid stack to send it across the network and then update the value in the container itself. The detect and send method just sends the information to the client. The track int arrays are a result of those values being sent using that method. You are basically hooking into detect and send, getting if the fluid stack has changed, and if so sending a packet to the container. I have already outlined above what packets you should need. If you need an example, ServerPlayerEntity should have the defined versions of the IContainerListener methods. You can see how the packet is structured and model yours similarly.

I would have suggested that. However, there is a slight issue. You would need to stop the sound every time it's about to play which since it's not the same sound, you would need to stop all sounds. That would stop your sound as well causing random cuts in the ambience. This is why I suggested making a PR to whatever handles music in 1.15.2. I remember Mcjty mentioning it's an enum that needs to be extensible and probably a method hook to an event to handle when should it change.