ChampionAsh5357

So, you're holding `Item`s in a HashSet but the generic is just an Object? You are also checking if some ItemStack is contained in a set of `Item`s.

Look in the source itself from the workspace you set up. There should be javadocs within most of the forge classes that are exposed to the user explaining what they do.

The logic is flawed. When an IIntArray is tracked, it creates a new IntReferenceHolder which send the data from the client to the server. To know where to store the data, it grabs the index of the reference holder from the container and sends that over with the changed value. So, if you do not have the same number of reference holders on both sides, then you will either be missing data or having always empty data.

There is now a multipart API to use for handling this: https://github.com/MinecraftForge/MinecraftForge/pull/7554.

Ah wait, I just saw the if statement. You're checking if the world is not the nether or end when executing the code. And then you check within that if you are not in the nether. So basically you're just saying spawn both of these in the overworld.

Vein sizes using OreFeatureConfig should never be below 6. Otherwise, the ore might not spawn. Vein sizes of 2 and below will most likely never spawn. This is not to mention an ore that spawns at the lowest levels of the nether will probably never spawn because lava is not a valid candidate block to replace.

That doesn't remake the method. Look at how renderItemAndEffectIntoGUI is defined and rewrite it to take some MatrixStack to define the rotation and/or scale to render.

Just remake the method then to take in a preexisting MatrixStack and then modify that as needed. The method does call renderItem after a bit of prework.

The items are models and not icons. They have been rotated, translated, and scaled to that position to be drawn. You still have yet to answer what is the end goal here and why it should be done.

This is not always the case, you can use chests as an example there. The texture is bound when creating the vertex buffer through the RenderType. To specify where on the texture, you use UV coordinates.

You can look within ContainerScreen to see how ItemStacks are rendered. If this is not the end goal, can you explain in more detail what you are exactly trying to do?

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.