Choonster

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?

I'm not going to write the code for you. Was there a specific part you didn't understand?

Check if the event's IChunkGenerator is an instance of ChunkGeneratorOverworld, then use reflection to access the ChunkGeneratorOverworld#settings field.

Since all of these fields are final, you'll probably need to use the registry override system to replace the Vanilla biomes with your own. Create an instance of the appropriate Biome class (e.g. BiomePlains) with a BiomeProperties that has the desired properties, set its registry name to the same as the Vanilla one (e.g. minecraft:plains) and then register it with IForgeRegistry#register. Since there's already a Biome registered for that name, your instance will override the Vanilla one. Do this in RegistryEvent.Register<Biome>.

The debug info overlay is rendered by GuiOverlayDebug and GuiIngameForge.GuiOverlayDebugForge.

Then you can look for the MCP mapping CSV files in the Gradle cache (~/.gradle or %USERPROFILE%\.gradle); these map SRG names to MCP names. I don't have the full path with me, but look for de/oceanlabs/mcp.

Those are SRG (obfuscated) names. You can use MCPBot to find the corresponding MCP (deobfuscated) names.

Which version of Minecraft are you using? EnumFacing.getDirectionFromEntityLiving was added in 1.11; in 1.10.2 and earlier the equivalent method was BlockPistonBase.getFacingFromEntity. When you want to implement a feature (e.g. set a block's facing based on the placer), you should look for places in the Vanilla or Forge code where similar features are implemented (e.g. pistons).