Leaderboard

You could also do. Item::getToolTypes // Which returns a Set<ToolType> Set::contains Check if the Item::getToolTypes contains ToolType.PICKAXE. Generally all Pickaxe Items even ones that do not extend PickaxeItem will have ToolType.PICKAXE in their tool types.

Eclipse doesn't list them there until you've used them once already, click the "Run Configurations..." option to see the full list

That makes no sense. Have you tried looking at Items.ACACIA_DOOR or any other door?

There's not. There probably should be though, considering swords are the correct "tool" for some blocks (like webs). Ditto shears. For some definition of "correct" and "tool."

The issue is that a pickaxe doesn't have to be a subclass of PickaxeItem, someone could make a custom pick that is just an Item with pick functionality. So, while you could check for vanilla picks, or your own pick, you wouldn't really have any way of knowing if it was someone else's pick.

Your code looks fine, my guess is that the tool predicate is returning false. Ie. that the item you're using doesn't match "simpleores:copper_shears" Double check your registry names. Scratch that, this file is in the wrong folder: https://github.com/Sinhika/SimpleOres2/blob/1.15/src/main/resources/data/forge/global_loot_modifiers/global_loot_modifiers.json Should be forge/loot_modifiers not forge/global_loot_modifiers.

No prob, I just opened up net.minecraftforge.event in my IDE, and saw entity.player in there, so looked and saw that event in there just waiting to be used

Not sure if it fits what you need or not (haven't messed with doing any event stuff like this) but there is an AttackEntityEvent that looks promising, and the comments say it is fired when a player attacks an Entity.

Misanalogy. Dos Microsoft support Windows 7? That's 1.12.2.

In the context of a forum, which we're in, it means some attempt to advise or inform in response to a need, or "question". It could also mean physically sustain in some way, it's a polysemous word.

I'm not asking how anyone is capable of modding for 1.12.2, I'm asking how it's the case that there are other forums which offer support for questions about modding 1.12.2 if it's not tenable to continue to offer that support as you guys are saying. Am I being sent to another forum to ask a question you're saying can't reliably be answered under the pretense that another forum could reliably answer my question? It's just confusing, that's all. We can't really get anywhere with this conversation given the forum rules anyways, I just figured I'd satisfy my curiosity about the reasoning behind the "no 1.12.2 support" rule.

Hey again TGG, Thank you so much for the advice (and validation that this is heckin confusing haha). After a lot of fiddling, I was finally able to figure out the string of issues that was causing problems. In case anyone else ends up finding this later in search of help, here's what I ended up doing to solve my issues. Firstly, as it turns out you can't just use the yaw of the head, since that doesn't account for the model rotation. The headNetYaw variable calculates that difference out, so unless you mirror that rotation, you're better off using the variable itself. So I switched back to that method. To get around the issue of having multiple poses, some with fixed head position and some with dynamic, I built in some methods to the model class to check the entity's pose and return the proper value for the head position. I designed them to return either the raw version of the variable (needed for the item rotation), or the calculated one (needed for the rotation of the actual model parts), which allowed me to ensure that the proper result would be returned in both cases. This avoids the issue of having to write up a checker code within the item renderer itself, and that way I only have to worry about changing one set of code if I make any tweaks. Lastly, I finally figured out the biggest stumper, which was the fact that the rotation was still crooked even with the synchronized method. I tested each one individually by forcibly returning zero on the two I wasn't using, and determined that individually, they were all doing what they should be. However, they were messing up when combined. As it turned out, I had the order of rotation different on the item renderer (pitch > yaw > tilt) than on the entity model (tilt > yaw > pitch). Changing the rotations on the item class to match the order of the ones on the entity model solved the problem. So it did indeed come down to the order of transformation in the end. Definitely one of the tripper problems I've dealt with, but I'm happy to report I finally have it solved. Thank you guys again for your help!