Draco18s

That would be wrong. First, the object holder annotation will fill the values in for you, and second you can initialize them with a value from anywhere you like, you just can do that from a static place. The fields can still be static, but you can't call new there.

Don't use static initializers. Because they can be called at unpredictable times, Forge won't necessarily associate them with the correct mod.

Log file?

Haha, I meant like my whole project dude, not the one file. You're good.

That is exactly the thing I linked. My point was that going from 12 -> 13 and 12 -> 14 is 99% the same.

Yes 1.13 was kind of interim and temporary. 99% of the docs are still useful for 1.14, though there's the occasional thing that had its name changed that isn't noted in the 1.13 docs. See https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a Its a lot Correct. Get used to the idea of writing your own loot functions. They aren't that bad, honest.

1) You do not need a class called BlockBase or ItemBase because "base" block and item classes already exist. They're called Block and Item. A "base" class that saves you from having to write a few lines of code over and over again is an anti-pattern. What happens if you want to write your own Fence block? Well, now you can't inherit from BlockBase because BlockBase isn't a Fence and you'd have to copy all of that code. But you can't inherit from FenceBlock because now you have to write all your BlockBase code again. 2) You do not need IHasModel. Two very very simple reasons. One: all items need models, no exceptions. Blocks that need item models also (gasp!) have items and all items need models. Two, the information that you expose in the methods specified by IHasModel are already public. So you perform a completely pointless instanceof and class cast to call a method that does nothing useful. See this method: https://github.com/LotteWiltshy/lottycraft-mod/blob/master/LottyCraft/src/main/java/com/lotty/lottycraft/util/handler/RegistryHandler.java#L21-L30 Watch this: @SubscribeEvent public static void onModelRegister(ModelRegistryEvent event) { for(Item item : ModItems.ITEMS) { Main.proxy.registerItemRenderer(item, 0, "inventory"); } } HOLY SHIT BALLS BABY JESUS, IT FUCKING WORKS Except, for you know, the ModelRegistryEvent is SideOnly(CLIENT) so you can't actually have this here.... Oh, also: https://github.com/LotteWiltshy/lottycraft-mod/blob/master/LottyCraft/src/main/java/com/lotty/lottycraft/init/ModItems.java#L13-L14 Problematic Code #14

I never put a license in my git repos because I never know what to license it as. I have no qualms with people looking at my code to figure out how I did what I did, or even borrowing sections (enjoy the loot func!). Its the "copy and redistribute large portions" that I don't appreciate.

Code Style #3 & #4

I've got you bro. First off, I went the route of keeping density as a block property, but I register unique Item instances for each one: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/HarderOres.java#L107 Which calls: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/hardlib/EasyRegistry.java#L56-L65 The lists there are used later in the Registry Events to register everything, but it keeps my main class cleaner and easier to read (though that hasn't stopped me from screwing up a GUI screen, by referencing the wrong bloody container type). I then created my own loot functions to deal with the silt touching and density quantities. https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/loot/function/BlockItemFunction.java https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/loot/function/HarderSetCount.java (I should probably relocate those into the library) Which results in the following loot table: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/resources/data/harderores/loot_tables/blocks/ore_hardiron.json#L29 Line 32 is more or less irrelevant, but its required. It gets replaced with the correct item when the blockitem function gets run. My set_count function is also going to be a little different than yours, you might not need any data parameters (the divisor in mine).

That is an intentional texture choice designed to stand out as THIS IS WRONG, FIX IT so that things that are broken don't go into production. Magenta/black checkerboard is a pretty standard missing texture texture these days, dating back to Counter Strike: Source. Anyway, you're going to need to include more of your code, namely where you register your item models. Post a working github repo as the best way to provide us with all of the necessary code and resources.

Of course not. You both: a) did not do the operation on the server b) did not inform the server

Don't use Youtube tutorials. They are the literal worst. You also still haven't asked the question and none of us want to go watch Harry's crap to see what Harry did. We need to know what you did.

Sorry I was thinking of the stone cutter.

Huh? No they're not. They're read from data files.

That sounds like a job for recipe JSON data files

Post it on github.

How am I supposed to debug your code? You didn't post it.

Because this is less mod compatible. Two mods overriding the same block, someone wins and someone loses. Even if those two overrides are for completely unrelated things.

I don't. While that particular mod never got a 1.12 update (and a 1.14 update is as unlikely) the fact that those fields are locked down pretty hard is annoying for those of us who actually want shovels to freaking matter. Blocks.IRON_ORE.getDefaultState().getBlockHardness(null, null) As dirty as it seems passing null there, virtually no blocks should rely on it. No vanilla ones do.

I...haven't actually verified that my things are loading in the order I set, but https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/resources/META-INF/mods.toml#L21

Define "doesn't work" You should use damageItem so that Unbreakable enchantments work.

When you put in your mod blocks class fields and then don't assign those fields values, they stay null forever. Yet you are trying to reference them as if they were not null. Unfortunately you haven't posted enough code in one place to adequately tell you what you've done wrong, only what has gone wrong.

See:

Yes, same reasons. There's already a base item class, called Item.