ChampionAsh5357

Then I would put a breakpoint where ItemColors calls the egg list to add them and see if your eggs are present within there.

Have you tested with a new world instance?

It's a map... Modifying information within an object doesn't require you to replace it. Only if you're modifying the outer object itself.

Not really, you are only using the value once so it'd be a waste to AT into the field. As I've mentioned, use ObfuscationReflectionHelper::getPrivateValue and store the map. Then, do the required operations on the map itself. Since we're changing the elements the map refers to, we can just store the overarching object.

You are not storing the map itself but now a copy. Store the private value of the map and put elements into that.

Just store the map as a map with one reflection, this is just unnecessary. Use breakpoints to determine whether or not the entries are being put in the map. Also, the null entry within the map should be removed afterwards.

That's because the spawn egg entry being pushed into the map keep replacing the null key value. As such, only the last egg is ever considered. You need to reflect into the map to add your spawn eggs with the corresponding entity type during common setup.

For reference, everything being described is a vanilla system. Forge only has one or two hooks that are relevant and those are clearly documented. Blaming Forge is the same as blaming any mod loader for not knowing how to use the base program. However, that's more or less the issue building off of an obfuscated program. That's what the forums are for: explaining concepts that may not be clear to some programmers compared to others. You're always welcome to post a question about how to navigate through vanilla's system and sure enough if there are people who can comment and help, they will.

Well, that would make sense. You check if the type is boss health and then check if the type is not boss health if it is boss health.

How are you verifying this claim? Are the registers attached to the mod event bus?

Use the check during the different element types to cancel the associated rendering. Also, subscribe to either $Pre or $Post, not both. Otherwise, you are just rendering the information twice.

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