Draco18s

I had as a draft, "I'd be surprised if it doesn't use the ASM library." But as I haven't messed with it or even looked at it, I wasn't confident enough to say that it did. Good to know I was right.

Core mods are when you make changes to the minecraft source code (vanilla, Forge, other mod) using the Java ASM package (as D7 mentions, its now done via JavaScript, but the general idea is the same, even if that JS doesn't directly interface with the ASM package). It literally lets you rewrite the compiled bytecode of any class in any way you want.* They are useful when the effect you want to achieve cannot be done in any other way. For example, lets say I want to change how long a Minecraft moon phase is in the overworld. Currently that is defined (something) like this: public int getMoonPhase() { return (totalWorldTime() / 24000) % 8; } Gosh, that 24,000 looks awfully magic and awfully unchangable... *But hoo boy does that sound dangerous. What if two people modify the same section of code in different ways? Well, you get a conflict, the game crashes,** and no one's happy. This is why core mods are a last resort, only to be done after a request for Forge to insert a hook for modding has failed. They are only to be done with extreme care in very specific ways in order to insure that conflicts are minimized. As such tutorials do not exist. **What happens when a coremod change fails? Well, the game crashes and reports the original code as being at fault! That makes it impossible for anyone to track down what actually happened and why because the original code is incapable of throwing that error and there are no fingerprints left over from your grubby mits going in and changing things.

Uh, it works fine:

Man, if only I knew what line the crash was on and what the error was.

Don't. I forgot that that was my class. Just create it yourself in your own project: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/hardlib/api/internal/ModItemGroup.java

Yes, look at how nametags are rendered.

To make it visible in the other direction, draw it again on the other side.

Install a JSON plugin for your IDE of choice so it can show you dumb errors like that.

Always mod for the latest version of Minecraft (in this case, 1.15.2)

This is wrong. You need your mod ID in there. assets/beyonders/models/... assets/beyonders/textures/...

You can't change the blockstates that a block has when making an override.

Because your item group is created the minute your first item gets constructed, which is before the fields in your ModItem class have been given values via the @ObjectHolder annotation. This is why ModItemGroup exists: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/industry/ExpandedIndustry.java#L59

Which you can calculate from the player's position and look vector.

I wonder how the Ghast does it.

That's still true of a class in its own file.

You need to determine which half is being broken, and if it isn't the half with the TE, get the half with the TE, and tell it to do the thing that needs to be done.

I did https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/HarderOres.java#L244

Correct. You can still place blocks on top of fences, after all. Whether or not pathfinding from mobs will respect the additional height is questionable (it might be coded to check for only fences, or only blocks in the fence tag, or...). Also, You are making a WIDE block. Collisions outside the 1x1x1 cube will not work at all in the X and Z directions. It only works for TALL blocks (16x24x16 only!!!! Note that it does not even extend to a full 32!!!!).

Technically it can be up to 24 "pixels" tall (because of fences) but seriously don't rely on it.

Use tags IMO. Rails do, fences do.

Yep, you're going to have to hack Minecraft's itemstack UI renderer. Have fun!

That would probably work better, yes.

You mean this one? at com.Invilis.items.EpicItems.registerItems(EpicItems.java:165) "But the error is on 197!" you say. Except that its not. Its on 165. Because 165 is the starting line for the registerAll() method and the carriage returns don't change that. As far as the JVM knows all of that is on the same line. Also, don't assign to your mod items fields directly. Either use a DeferredRegister or use the @ObjectHolder annotation.

It unfortunately can't be, because when trying to print out what block causes a problem, it queries the registry name. If that's null, the query ends up returning Air.