ChampionAsh5357

TERs can be attached via ClientRegistry::bindTileEntityRenderer as long as the TileEntityType has it listed as one of the supported blocks. The rest is just matrix math and three-dimension transformations. ContainerType and ContainerScreen attached via ScreenManager::registerFactory. These can mimic existing containers and screens in the game. There is nothing within container/screen code that is really deprecated for usage currently due to how the system is set up. The block has a state of some kind which switches the rendering used such that TERs are only drawing when absolutely needed and the rest is handled by baked models. NetworkHooks::openGui on the logical server within Block#onBlockActivated and I already mentioned registering. Don't use IInventory, the forge system is Capabilities via IItemHandler. ItemStackHandler is your friend for this implementation. Documentation is only supposed to explain a certain systems added by the library or hook interface in question. Forge does a decent job in that respect (besides from the outdated information). As such, it should not have any reason to give step-by-step instructions on how to do something, just a general overview. A user's analysis skills and observation through the source code to figure this out. Try attempting to make the current system with your best knowledge then come back with specific questions on what parts you might be stuck on. When you do so, provide a repository to the project being referred to so that anyone who wants to help doesn't need to beat around the bush to figure out the answer. If an error is occurring, a paste containing debug.log should also be attached.

You need to hold a supplied instance of the registry object as items will always be registered first. Luckily, RegistryObjects are supplied instances of registry objects.

Reflection is a java concept, as such there's no documentation here. ObfuscationReflectionHelper is a forge added class as a wrapper to deal with changing method names due to mappings. However, this has full javadocs. Sure, a registered object can be grabbed from the associated registry. Although you might want to add that mod as a dependency (either hard or soft) to better handle that case.

SingleItemRecipeBuilder::stonecuttingRecipe

You can isolate the event in a separate class and attach it using one of the many event bus listener methods. Access to client only classes should be checked via DistExecutor. As for after registry events, I already answered that, use the ColorHandlerEvent and register using that. Don't use OnlyIn, its a hack for separating the client and server jars and does nothing to what you're dealing with.

Color handlers are registered in ColorHandlerEvent and should be isolated in some client only class as this will crash on the logical server. If you want an explanation of the error. You're registering color handlers before the registry events are fired which results in an NPE since the block doesn't exist yet.

My only comment would be on OpenClientScreenMessage as the Minecraft instance can just be obtained inside the method itself. This is still 'safe' I believe, but we should avoid calling anything that might only be available on the client that is not isolated in a different class. This is my opinion as it still won't be loaded unless on the physical client.

From what I understand, this is not the correct way to use DistExecutor. For the case where you can't supply a runnable or supplier, DistExecutor#unsafe* should be used instead. This will supply a runnable of what you want to execute (e.g. () -> () -> //Do things). This does not verify nor guarantee that the code is completely safe to access; however, if the runnable executes another method that is isolated in a different class, it is 'safe' since classloading will not occur. So, the proper way to implement the code above is DistExecutor.unsafeRunWhenOn(Dist.CLIENT, () -> () -> ClientScreenManager#openScreen).

You can look at what implements the interface. You can also infer which classes might need to know the light value (for example, the world). To be able to statically project an object, you need to take the position and subtract it from the projected view.

Well, it might help if you enable the lightmap associated with the block. Also, why not render a block using BlockRendererDispatcher? Finally, why do you even need to render a custom version of a block?

Try without RenderSystem::blendColor. If not, try disabling the depth test (disableDepthTest) and depth mask (depthMask). Remember that these should be reset during the teardown phase.

What version is this?

Please link a paste to the gradle log from the erroring build process.

Villagers can be added via VillagerTradesEvent while wandering traders via WandererTradesEvent.

Yes, as you can see it has the obfuscated name which translate to its unique srg name and then finally the mapped name. You will need the srg name as your parameter. The static keyword makes the field/method available at class level meaning you do not need an instance to grab the associated value. So, a null value can be passed in instead.

Setting the alpha state does not enable transparency. You need to set up the blend function in such a way such that the rgba inputs are being blended correctly. This is why I mentioned TRANSLUCENT_TRANSPARENCY.

Well, yes. Now there's a bunch of new caveats. If you really want to attempt this, a similar mod named Hyperbox by Commoble accomplished this. That's probably the best I can do as the process of actually handling is quite complicated and problematic at times.

Ah ok. Well, that would be quite complicated. You would need to create a new key for every dimension you create and store them somewhere for easy access. You would also need to construct the ServerWorld, add a world border listener, update the world cache, and send a packet to the player with the required information. This also requires ejecting players from broken worlds or proper teleportation when needed. There are about a hundred other checks that are also necessary. Although, a question I might ask is that why make this a mod? This seems like more a server plugin.

Apologies, you have to be on the forge discord to access the bot for the commands. Now, if you wouldn't mind answering my question about your knowledge in Java and reflection.

How familiar are you with Java and reflection? Also, read the javadocs on the method, do not supply a mapped name and instead the associated srg name (which can be obtained from forge-bot via '!mcpf <mapped_name>).

You cannot dynamically register new dimension within JSON. I think I'm going to need a clearer goal of the task at hand. What are you trying to accomplish on the user end?

The object itself is immutable, the data can be mutable. The issue is that the field accessor is private. ObfuscationReflectionHelper#getPrivateValue can be used to obtain the Map to which you can put the value during common setup.

Please provide the repository and a code snippet of where your exact problem is as your question seems to be worded incorrectly.

It seems your testing if the value changed using the logger, which will always be the default value when first initialized. This is not to mention that the entirety of the code is reaching across sides and still trying to force load the config.

Please link your repository then. I'm questioning a few things regarding that TextConfig class and context surrounding what you are using on the client and server configuration.