ChampionAsh5357

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.

Then you can use x and y rotations to get the same result. See this for more information.

There's about a thousand errors the first of which is this: [22:14:21] [pool-3-thread-1/ERROR]: Error occurred applying transform of coremod apothasm/container-repair.js function apothanvilcontainer java.lang.NullPointerException: null Try removing the mod and testing again.

Wherever the twitch app caches the Minecraft instance and grab the debug.log from the run/logs folder there

You should never need access to an id of the dimension. Use the registry name. The ids are supposed to be abstracted away such that you should never have the need to call them.

Since they are all unique models, I don't think a multipart could simplify what you've shown currently. You could find out which variations of the model result in similar states or states that differ by rotation such that you don't need all of these. Then you can simplify.

Grab the data on first call instead of immediately. Then you'll have an instance of the entity to grab everything from. The entity type is used to create a singleton from the entity. If you needed a specific attribute map of a type, then you should grab that from GlobalEntityTypeAttributes and calculate there. What is the use-case for this?

You need to set the render layer of the block within your FMLClientsetupEvent via RenderTypeLookup::setRenderLayer.

Well the initialization method holds a client only method for registering screens which would be handled in FMLClientSetupEvent. It should also use enqueueWork which is provided by the event itself instead of calling DeferredWorkQueue directly. I would suggest reading about it and determining for yourself. In the most cases, client, common, and dedicated server code should be separated. Also, you might want to consider renaming your classes to better match the current class names of Forge. It's perfectly fine. As long as you understand the underlying language, we can explain how it works.

DistExecutor#unsafeRunForDist iirc or one of the other methods that specifies sided running.

You should never use OnlyIn. Properly isolate your client code in a different class.

Yep, you don't properly register the ContainerType. You are calling the initialization before the ContainerType is even registered. This is not to mention that the container type will remain null until the constructor is called. This also brings up logical sides and handling. You are trying to construct a random instance without a true container and compressing them all into one file. Please properly adhere to separation of concerns. There are a few issues, but technically, it will work regardless of the non-forge way of handling.

I'm guessing the ContainerType isn't registered. However, you should provide a repository with your code so there is no guessing required.

Within the source provided when you set up the workspace? You can also find the block registry references and grab the class from there.

Just look at the sign or banner block and mimic.

The simplest way to have a block rotate if there is no extra data is to store a blockstate on it. You can have 8 facing values where the model rotates depending on the way it's facing. The mathematics would be handled similar to that of a sign or banner if you need examples in the source.

You're trying to give a singleton a changing state. You need to add a tile entity and store the data there to do your checks.

If you copy and paste the line directly and try to add imports automatically, the IDE assumes that the lambda inside is invalid first and doesn't apply the imports. So you will need to manually add the imports in or force the automatic import somewhere else.

Check your imports. Usually that fixes the issue.

It works exactly as written. And yes, also in 1.16.

Well the question you asked was can you add new colors of dye. The answer to that question is yes, you can if you wanted to. You would just need to rework the entire color system since it was only made to handle the 16 colors. There was no interfaces to mention or classes to reference, anything you reference will most likely need to be redone and rehandled from scratch. Also, 1.12.2 is not supported on this forum. Please check the banner to see the currently supported versions and update accordingly.

Sure, you can create your own dye system that can enumerate through all 16 billion colors if you want. You just need to make the system and handle it accordingly.

Grab an instance of the IRenderTypeBuffer from the Minecraft class and grab the IVertextBuffer from that. You are missing quite a few RenderSystems for this to properly render and the system is there to allow you to avoid using those methods directly. That should probably fix most of your issues.