Choonster

Use EntityList.getTranslationName to get the unlocalised name of an entity type (rather than an individual entity), you can then translate "entity." + unlocalisedName + ".name". See Entity#getName and ItemMonsterPlacer#getItemStackDisplayName for examples of this.

The MCP Mappings version is completely independent of the Forge MDK version; you can set the mappings property in the minecraft block of build.gradle to change the Mappings version. There's a snapshot version of the MCP Mappings released automatically every day, but Forge rarely updates to new Mappings versions.

You can use CraftingHelper.findFiles to iterate through files in a specific path for a mod and process each one in some way. Forge uses it to load recipes in CraftingHelper.loadRecipes(ModContainer) and advancements in ForgeHooks.loadAdvancements(Map<ResourceLocation, Advancement.Builder>, ModContainer).

If you use the WorldGenMinable(IBlockState, int) constructor, your ore will only generate in the "natural" variants of Blocks.STONE (i.e. Stone, Granite, Diorite or Andesite; but not the Smooth variants). These don't normally generate in the Nether, so your ore won't generate either. To generate your ore in other blocks, you need to use the WorldGenMinable(IBlockState, int, Predicate<IBlockState>) constructor and supply a Predicate that returns true for the block(s) your ore can generate in. Vanilla provides several Predicate<IBlockState> implementations in the net.minecraft.block.state.pattern package, you can also specify your own using a lambda or method reference.

As I discovered in this topic, you need to set Block#useNeighborBrightness to true. For some reason, Vanilla does this in Block.registerBlocks instead of in the constructors of the appropriate Block classes.

I've encountered a similar issue again while testing a PR. When attempting to run the Minecraft client from the Forge development environment with either JEI or TestMod3 in the mods directory, the game crashes with a ClassNotFoundException for a class that definitely exists in the corresponding mod JAR. This doesn't happen outside of the Forge development environment (neither in my TestMod3 development environment nor when launching Minecraft from the Mojang launcher). This was tested using Forge 1.12.2-14.23.2.2619 (commit 49be9b2) with JEI 1.12.2-4.8.5.147 and TestMod3 1.12.2-5.1-2ce586d (in separate runs). You can view the FML logs from these runs here. Does anyone have any idea why this would happen or how to fix it?

Use the eye icon in the post editor. Delete the FML log and then run the server again, making sure to use Java 8. If it still crashes, post the new FML log.

The sub-events of PlayerInteractEvent are fired when the player interacts with the world in various ways; you should be able to subscribe to the individual sub-events and cancel them when this mode is active.

That wasn't in a spoiler or on Gist. There's no error in that log, because you're running the server with Java 8. Your original crash was caused by running the server with Java 9.

You're using Java 9, which isn't supported by Forge. You need to use Java 8 instead. In future, post the FML log (fml-server-latest.log in the server directory) in a spoiler or on Gist.

There are many versions of Forge for each version of Minecraft, you need to use a version that your mods support. You should generally use the Latest or Recommended Forge version for the Minecraft version you're using.

You'll want to use the Capability system for this. If the levels are a property of the player, attach the capability to the player. If they're a property of the tool, attach the capability to the item.

That tells us almost nothing. What purpose does this data serve? What is it associated with? Where is it read/modified from?

Use Random#nextInt(int) to generate a random integer between 0 (inclusive) and the argument (exclusive) instead of the multiplication, subtraction and rounding you're doing now.

It adds the items to the list that you pass as an argument.

If an event exists, it can be subscribed to. Those three methods are only called when a player is actively using an item (e.g. drawing a bow, eating food, blocking with a shield) and only for the item that they're using.

The sub-events of PlayerInteractEvent are fired when the player left or right clicks in various ways.

Mojang obfuscates the Minecraft code as part of the build process, so everything has a name like a or cc. These names change with each Minecraft version. The MCP team is responsible for mapping these so-called Notch names to SRG names like func_0001_a or field_0002_b that remain stable between Minecraft versions. The MCP team and the community then map these SRG names to deobfuscated MCP names like doFoo or bar. It can be very difficult to understand what code is doing when nothing has a proper name and functionality can change between versions, so sometimes methods, fields and parameters end up with misleading names. If you have a better name for a method, field or parameter, you can open an issue on the MCPBot issue tracker.

You're running 1.12.2, but you have a bunch of 1.7.10 mods installed; which won't work. Mods (especially coremods) only work for the Minecraft version they were built for. You should use a separate game directory for each Minecraft version so each version has its own mods, config files, etc.

Minecraft uses StateMapperBase#getPropertyString to build the property strings uses as variants in blockstates files, but this is client-only. You can take a look at NBTUtil.readBlockState and NBTUtil.writeBlockState to see how Minecraft reads blockstates from and writes them to NBT; you could apply similar logic to generate/parse a state string in a config file. Edit: There's also CommandBase.convertArgToBlockState, used by commands to parse blockstates from strings. This is probably exactly what you want.

You do need to set the values at some point. Probably when the multiblock has been formed.

Because your Block extends BlockFlower and overrides BlockFlower#getBlockType to return BlockFlower.EnumFlowerColor.YELLOW, it has a single property called type with a single value called dandelion. Your blockstates file doesn't specify the type=dandelion variant, so the block renders as the missing model. The normal variant is only used for blocks with no properties. You could specify the type=dandelion variant to fix this, but I think it would be better not to extend BlockFlower at all since it's only designed to work with the Vanilla BlockFlower.EnumFlowerType values.

If you use three separate properties for the coordinates, you'll need to use fully-specified variants in the blockstates file; like in the standard Vanilla format (e.g. "x=0,y=0,z=0": { ... }). If you use a single property, you can use Forge-style variants (e.g."position": { "0": { ... }, "1": { ... }, ... }). Each { ... } represents a single variant, where you can set the model, texture, rotation, etc. I don't know what you mean by this. Block#getActualState just has to read the values from the TileEntity and return an IBlockState with the appropriate property values set, it shouldn't be storing anything in the TileEntity.

The PR has been merged, so this should be fixed in Forge 1.12.2-14.23.2.2618.

The installer doesn't download libraries if they're already present or not required on the client/server (depending on which one you're installing). There are no errors in that log, everything appears to have worked correctly. If Forge is crashing, post the FML log (logs/fml-client-latest.log in the game directory) in a spoiler (the eye icon in the post editor).