Cadiboo

https://github.com/Tfarcenim/Extra-Anvils/issues/15

instead of event.getRegistry().register(new BlockItem(ModBlocks.FIRSTBLOCK, new Item.Properties()).setRegistryName("firstblock")); use event.getRegistry().register(new BlockItem(ModBlocks.FIRSTBLOCK, new Item.Properties()).setRegistryName(ModBlocks.FIRSTBLOCK.getRegistryName())); This eliminates the chance of getting the registry name wrong. Change your ModBlocks class from public class ModBlocks { @ObjectHolder("mytutorial:firstblock") public static FirstBlock FIRSTBLOCK; } to @ObjectHolder(ColoredTorches.modid) public class ModBlocks { public static final FirstBlock FIRSTBLOCK = null; } You're game is currently crashing because ModBlocks.FIRSTBLOCK is null. It is null because you've hardcoded the name of the block to "mytutorial:firstblock" when it should be "coloredtorches:firstblock". This means that the field never gets filled with your block, and you're item block tries to use a null block in getTranslationKey, causing a crash. Putting @ObjectHolder on your class with your modid means that you don't need to hardcode each name above each field, instead the name of the object is gotten with yourModId + ":" + nameOfField.

Update your Forge. BetterAnimals+ requires a more recent version of Forge. You version (2552) is extremely outdated, the latest version is 2838.

Don’t use that... that will break completely for anything that isn’t 100% standard. In 1.12.2 you would use RenderItem#renderStack. I’m not sure what the 1.14 replacement is, but it should be pretty easy to find by looking at the ingame GUI renderer or the item group renderer.

https://github.com/Cadiboo/NoCubes/blob/13aa301762258b4c56a0b738d2f569e226970597/src/main/java/io/github/cadiboo/nocubes/client/ClientProxy.java#L31-L51

You wouldn’t. Do you really need to load the 12 chunks near every entity that spawns?

Forge is trying to load a class file compiled with Java 12. Forge currently doesn’t support this apparently. Forge is planning to update to ASM 7 soon, which will fix this. I’m not sure which file it’s trying to load, so I’m not sure what you can do about it.

I’m pretty sure that this loads new chunks.

I would render the entity and then render the fire separately

You can use the DistExecutor to run stuff and you can check FMLEnvironment.dist.

You'll be able to play the world

Go poke Mojang

I would guess that Reference.BOUNDING_BOXES is empty. Place a breakpoint down and see

Doesn’t it exist and isn’t it called “lateinit” or something?

Do that code, but in a for loop.

Don’t do this. Register the configs to your ModLoadingContext and subscribe to the config change event.

I think that ElectronWill’s night config has documentation that covers this

I've noticed that on 1.13+ the sources don't always get attached properly for every file (or IntelliJ is doing its indexes wrong). IntelliJ comes with a built-in decompiler so this isn't really an issue for me though. Eclipse also has a decompiler plugin that you can install.

NBT is for saving stuff to/ reading stuff from disk (and also unfortunately for transferring item stack data over the network - horrible design). Capabilities are for dealing with data at runtime. Capabilities usually get saved to NBT when the game shuts down, and are usually read from them when they are created. NBT is about the data in files, Capabilities are about the data at runtime. Because of this you almost always want to use Capabilities

https://github.com/Cadiboo/NoCubes/blob/7622103b18c6f8114f3d33343d833a0457666ae6/src/main/java/io/github/cadiboo/nocubes/client/ClientEventSubscriber.java#L534-L544

Find out which mod is using tons of memory, and tell the author.

Spot the difference between "intercraftcore:models/block/block/ore_faces/ore_2.json" and "intercraftcore:models/block/ore_faces/ore_2.json"

you need to define all your variants in your block state. The variants can point to whatever models you want

If you can avoid using a native library, do. The entire point of Java is to run on anything and not be constrained to a single platform.