Leaderboard

Technically there are 4 different names: The original source (only Mojang has this) The obfuscated names, aka Notch names (these are generated by the compile process and look like aa.bbcfa, you would see these if you opened the vanilla jar in JD-GUI, these will be arbitrary as source code changes) The SRG names (these are the ones you're seeing, generated by the decompile process with names like p_12345_c and func_765432_f and are generally stable as the source code changes and new versions are released) The MCP names (these are community supplied via MCPbot, mapped to SRG names)

It is fired for everything.

The tooltip gets updated every render frame. You can query the current time from the world (getInformation is Side-Only so you can safely use Minecraft.getMinecraft() if necessary) and calculate the duration.

You can check if the current screen (Minecraft.currentScreen) is an instance of GuiIngameMenu

No, Biomes are a full registry, use the Register<Biome> event and just register yours as the name that you wanna override. All other methods are hacky and you shouldn't do it. But it more sounds like you just want to add a variant to the jungle biome instead of overriding it... Just make them 1/10th the weight of the vanilla one.

Yes this is kinda intentional. Honestly I think ItemStackHolder shouldn't need to exist anymore. So when I was doing the rewrite I didn't touch it. Private field support was a ADDED functionality I added when I re-worked the registry stuff. So ya, no real change here, just don't use ItemStackHolder on private fields.

ob·fus·ca·tion ˌäbfəˈskāSH(ə)n/ noun noun: obfuscation; plural noun: obfuscations the action of making something obscure, unclear, or unintelligible. "when confronted with sharp questions they resort to obfuscation" The Minecraft source is obfuscated. That's where the unreadable parameter names come from (effectively). MCP is the community's mapping of these machine-generated names back into human-readable forms. You can try updating your mappings, and if that doesn't give names to the code (potentially breaking references -- be careful), you could consider contributing mappings yourself. But for the most part, trivial methods and newer methods have fewer/worse names because people haven't bothered to give them names again, because their effort was better spent on one of many other useful tasks.

Have you considered posting this in Support and Bug Reports?

The thing is is that we have told you multiple times what you need to do, but you keep doing things that don't make sense in java and/or refuse to do what we tell you to do. For example, you're still trying to call Item.registerItems, even though I told you that this was reserved for minecraft's items and you should never ever ever call this yourself, and you should not even have it imported. This is what is resulting in your crash. Example two, you still haven't made your registry method static. Also, you need to annotate the method with SubscribeEvent, else the method won't be called (you should also not be calling it manually, in case you were thinking you should).

I'm not insulting you, I'm just stating the obvious...

BlockRedstoneDiode::calculateInputStrength is the method you are looking for, not it's update tick. You can adapt the code from that method to check all faces instead of just the input one.

Check how vanilla does it at BlockRedstoneDiode. I believe it has something to do with the fact that Block::canConnectRedstone is actually irrelevant when it comes to recieving weak power and is relevant when it comes to sending it.

No, no it does not. It means the exact opposite.

Imports can be static. Also, let's not go out of our way to call out this guy on every mistake he makes. Whether he's new to java or not, we should not get abusive.

And...you know...all those other things...

You're running into these limitations of Forge's blockstates format, so it's treating the individual colours as properties instead of fully-defined variants. I suggest moving the individual colours to be values of a "color" property instead of being fully-defined variants and using "color=" + colorName as the ModelResourceLocation variant.

Forge's blockstates format assumes that all non-array values of "variants" are objects with at least one property. The "snowy=false,variant=dirt" variant is an object without any properties, so the deserialiser (ForgeBlockStateV1.Deserializer#deserialize) calls Iterator#next on the object's entry set iterator and causes a NoSuchElementException to be thrown. To fix this, add a property to the variant (even a dummy value not used by the format will work). Forge's blockstates format also assumes that any object values of "variants" with an object as their first value aren't fully-defined variants. All of the variants in your blockstates file that specify custom textures have an object as their first value, so the deserialiser condenses them together instead of treating them as fully-defined variants. To fix this, add a property before the "textures" property in each of the variants (again, dummy values will work here). These assumptions aren't really documented anywhere (except a comment in the deserialiser mentioning the second) and I didn't know about them before this. Both the Forge and Vanilla blockstates formats expect models to be specified in the format "[domain]:[path]", which will be converted to assets/[domain]/models/block/[path].json. You have an extra block/ prefix for the default model. You can see these fixes applied to your blockstates file here.