Choonster

In the profile editor:

Environment variables are part of your OS, not Minecraft or the launcher. If you don't know how to edit them, use your search engine of choice to find an explanation.

There's no need to get the IBlockState from the world, you receive it as an argument. You can also just use this as the Block instead of getting it from the IBlockState . You should never need to cast the value returned by IBlockState#getValue , it should already return the appropriate type.

Remove the Block#damageDropped override and override Block#getPickBlock to return the appropriate ItemStack of your bookshelf.

The 16 GB argument is being overwritten by the 512 MB argument, which is probably coming from the _JAVA_OPTIONS environment variable. If this environment variable exists, delete it.

Maven coordinates (which the wiki page calls locators) are explained here. The mod list format requires you to specify the groupId, artifactId and version fields, with classifier as an optional extra. The packaging field isn't supported because it's always jar for Minecraft mods. For consistency you should try to use a proper Maven structure, but there's nothing stopping you from making up the groupIds completely. I don't know exactly why the mod list format uses a Maven structure, but it's probably because it's a pre-existing structure that's very popular in the Java community and is used by many mod developers to host their mods in a way that lets other mods can depend on them.

Forge's documentation has an introduction to blockstates here. Use your IDE to find the subclasses of net.minecraftforge.fml.common.eventhandler.Event .

RenderingRegistry.registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) must be called in preInit, as the doc comment says. Item models should be registered with ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition in ModelRegistryEvent (if you're registering your Item s using the new registry events, which you should be) or preInit (if you're registering your Item s in preInit).

Each string in the "modRef" array must be a Maven-style locator composed of three or four parts separated by colons ( : ). None of the entries in your mod list use this format. The wiki page explains how these locators are mapped to file paths:

How is your item being displayed? Is it a pink and black cube (missing model) or a pink and black square (missing texture)? What you have there isn't the proper way to do things, but it should at least work in single player. Oddly, there's no error in the log saying what went wrong. You should be using the new registry events to register IForgeRegistryEntry implementations (e.g. Block , Item , Biome ) and item models/state mappers with ModelLoader .

Your Gist links are invalid. Post the FML log, it should tell you what the errors are.

Add a translation for that name in your lang file. Your tab name should include your mod ID to avoid conflicts with other mods.

You can if you tell the launcher to use a separate game directory for each version.

You have a coremod for 1.7.10 or earlier installed. If you post the full FML log (logs/fml-client-latest.log), it will say which mod this is.

The absolute: prefix is only used for list file paths, i.e. the --modListFile command-line argument and the "parentList" property in the list file. The "repositoryRoot" property is absolute by default, but you can use . for the Minecraft directory or .. for the parent directory (like regular filesystem paths).

That should work, it does for my test mod:

Override IRecipe#getRemainingItems for full control of the items left by the recipe. The items you return from this will be added to the player's inventory if there's no room in the crafting grid for them or dropped on the ground if there's no room in the player's inventory. It doesn't, but ItemHandlerHelper.giveItemToPlayer does.

RegistryEvent and ModelRegistryEvent were added in Forge 1.10.2-12.18.1.2092 (this commit). I explain them here.

If you use the Block(Material) constructor, the Material 's MapColor will be used.

As the name suggests, its primary use is to determine the colour of a block when it's displayed on maps. It's also used in two other places: To colour dust particles (ParticleFallingDust / EnumParticleTypes.FALLING_DUST ) if the Block doesn't have an IBlockColor registered and doesn't extend BlockFalling . To colour banner textures (BannerTextures / LayeredColorMaskTexture ) based on the EnumDyeColor .

Have you registered an ItemBlock for your Block ? It's not done automatically.

The -D option sets system properties, which the -X options aren't. Forge's documentation explains how to give Gradle more memory here.

Block s should be created and registered before Item s. You should be using the new registry events, RegistryEvent.Register<Block> will be fired before RegistryEvent.Register<Item> . If you don't want to call a bunch of setter methods at the place of instantiation, move them to the constructor.

It looks like you passed a null Block to World#canBlockBePlaced from ItemCheeseCake#onItemUse . Side note: It looks like you've copy-pasted the vanilla cake code. Why not just use/extend the existing classes?

Aren't those just String constants he's using to name the NBT fields? Not sure how that could cause any trouble... The attributes field is storing the attribute values, the attributeTags field is storing the tag names.