Draco18s

Hence giving it an intelligible name.

This isn't valid Java. Also name your locals with nice names so you know what they are. You don't have to use the obfuscated decompiled names. Yes, because: Your FlamingSword is not a subclass of anything.

"minecraft:block" is the type of missing object. Blocks is a vanilla registry. The item that is missing is the next bit: "mcore:dark_dirt" Show how you register your blocks.

Look at existing implementations? F4 in Eclipse brings up the type hierarchy for a selected class.

And you can create your own triggers. They aren't even hard. I haven't actually done it since 1.12, but I don't see why that interfaces would have changed all that much. It's borderline "copy one that exists, write your test() function do check what you want, taking whatever parameters you want, and fix the syntax errors until all syntax errors are gone, and call test() trigger() from a context appropriate location."

Define "manually"

I WONDER IF THESE THINGS ARE RELATED

See this part? That's the generic "random block" called Block that all blocks inherit from. LogBlock is a subclass of Block.

This does, of course, ignore the Unbreaking enchantment if your item is allowed to have it.

They're json data files.

Your FreezeEffect class does not have a zero-parameter constructor implied by FreezeEffect::new.

So every tick while (the potion effect) condition is active.

You've subscribed to the wrong event bus.

vx, vy, and vz represent a unit vector. Multiply by the desired magnitude.

does not equal same goes for the other three values. You need to rotate around the direction of travel to get the effect you want and right now you're rotating around a fixed vector. A constant, divided by a constant, multiplied by a constant times a constant. Sounds like a constant to me. Specifically Math.PI/22.5d. Or you could just do an integer loop from 1 to 45 and multiply the loop index by that constant instead of doing a loop over a double.

You are rotating around vector3.UP (that is, the axis that points vertically) and then doing something weird by adding the same value to Y and Z (this literally makes no sense) and what you want to do is rotate around a vector that points in the direction the player is facing. https://stackoverflow.com/q/31225062

Use Capabilities.

Check how the ice block does it.

Yes

Almost certainly the second one. The problem with attack events is that there are multiple types of attacks with varying sources and varying targets. Figure out if the event is relevant, and if so, do things. Don't muddle things up with checking if you can get data out that's relevant, then check if you got data out. If(!(event.getTarget() instanceof LivingEntity)) return; if(event.getPlayer() == null) return; Done. Now you can get the target and the player, casting the target into a local variable, and check anything you'd care to check.

Uh, dude. This has nothing to do with the deeper methods. Your code had 8 instances of kb.HCtrl and 6 of kb.HShift. There's only 3 scenarios your code needs to consider: No keys pressed Control pressed Shift pressed Checking control before shift insures that tip2 appears above tip1 and each scenario has two states that have no bearing on the other scenarios: whether or not the given string is present. If the string is empty, draw nothing, it doesn't matter if tip0 is empty and the user is pressing shift, we aren't displaying tip0. That's literally it. The only other check you might consider is if you added no tips (i.e. even though shift is pressed, tip1 is empty) then display tip0. But that's just a matter of removing the if(no keys) and replacing it with int oriignalSize = tooltip.size; and then a new last line of if(tooltip.size == oriignalSize && !tip0.isEmpty()) tooltip.add(tip0). That is a crash. Just because Minecraft did some processing before it actually exited doesn't matter. The game still encountered a fatal error and terminated. It was just writing log files, closing streams, and shutting down network channels. No. Exogenous exceptions are external to the program (in this case, Minecraft + all mods). Any issues that crop up as the result of your code and another mod somehow not playing nice is almost certainly Boneheaded. Who's at fault depends on who made an assumption that wasn't true. If the method you are calling says it returns an object of a given type, you can be assured that it is of that type and has the methods it says it has. If it doesn't, then someone else made a boneheaded decision to violate the Type contract. Do not assume that someone else might do this, because it isn't your problem to clean up after their mistake if they do. It's a bug, they need to fix it. If your IDE and compiler aren't telling you to surround code with a try-catch, then do not surround code with a try-catch. Do not assume that variables mysteriously become null between one line and another. Use the most specific type you can when you can.

This is a bunch of nonsense. Your mod toml file is a single file. Eg: https://github.com/Draco18s/ReasonableRealism/tree/1.14.4/src/main/resources/META-INF

Your original code was doing that anyway. And again, premature optimization. So instead of 2 checks per key, you have...6 for shift and 8 for control. The two methods do the same thing, except that mine uses a minimum number of checks to arrive at the desired result. If the object isn't null and conforms to a given type, then you can assign it to a local variable of that type and operate on it as if it was that type. If any of that is not true, crash and die, because it wasn't valid Java code or a cosmic ray corrupted RAM. You don't design your code to fail safely in this situation because the situation is not safe. FakePlayers are still Players. Item is still a nullable Type...There's almost no reason to use ever Object as a declared type. The only time it really gets used is when the actual Type doesn't matter and could be anything. You aren't dealing with an anything, you're dealing with ItemStacks and Items. (1) Vanilla doesn't use events, it's a Forge syste. (2) Forge code won't crash in that case, the modder that Did a Bad causes the crash. Forge does proper type checking and enforces it. (3) It is not your job to save the game from a modder that Did a Bad. https://ericlippert.com/2008/09/10/vexing-exceptions/ Other modders doing bad things do not count as exogenous conditions, exogenous is your code checks to see if a file exists, then before it can read it, another program or system deletes it (disc ejected from drive, internet disconnects, system goes into read-only mode). Other modders doing bad things is fatal. (And Java lacks the non-vexing try-versions of functions the article talks about (eg. int.Parse vs. int.TryToParse), so I removed that point).

Don't use IInventory, its sub-interfaces, or any class that implements them. Use Capabilities. You do not need to implement IItemHandler manually, an implementation already exists.