ChampionAsh5357

So then create a Set of items that can be added to the bowl and then check if the bowl contains the item being clicked on it. You can use ItemStack#getItem to get the item from the hand to check.

A good way to do it would be to make the entire thing data driven and pull the data from there; however, it's better to have it working. Just create the set or map like normal and populate it. Do not copy vanilla with the decompiler artifacts. What are you attempting to do?

With capabilities. You can also look at an unofficial version here. Either or, a block does not create energy nor produce it, it is just the container for the TileEntity that handles the dynamic data. From there, you can look at the methods and see which one inserts and which one extracts energy from the object. Do not forget to read and write the data and invalidate it in their appropriate methods. You can use one of the existing TileEntity classes (e.g. ChestTileEntity) to see how to handle that.

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.