Choonster

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).

The installer doesn't download libraries if they're already present. There are no errors in that log, everything appears to have worked correctly. What's your actual issue?

You can have 27 (or more) states in a single Block if you store them somewhere other than the metadata, just override Block#getActualState to return the state based on information stored in a TileEntity or derived from the world (e.g. how many blocks are adjacent to this one and where they are in relation to it). You can tell each element of a model which part of a texture to render with the "uv" property (see the wiki for more details), but this would require making 27 individual models with different UV coordinates. If all the blocks are the same shape (or some of them are), you can make a single model and specify a different texture file for each state using Forge's blockstates format. You could probably mess around with dynamically-generated models or textures, but I think this is the simplest way to do it.

This PR from bs2609 should fix the issue if it's merged.

Forge doesn't support Java 9, you need to use Java 8.

ItemStackHandler#onContentsChanged is called when the contents of an ItemStackHandler change, you can extend ItemStackHandler (possibly in an anonymous class inside your TileEntity) and override this to do you what you need.

Since this commit for 1.12. It was then done by Vanilla in 1.12.1.

You need to tell Forge to only load and register the class on a specific side by passing a Side argument to the @EventBusSubscriber annotation. You can see an example of this here.

Gradle ran out of memory, you need to give it more.

Your post is unreadable on the dark theme, you should use the Tx button to remove the formatting from it. You need to tell ForgeGradle to reobfuscate the shadow JAR, you can see how I do this here.

Does this happen without OptiFine?