Draco18s

First: http://shouldiblamecaching.com/ Second: Go to the Eclipse marketplace and download the JSON Editor plugin. Edit your JSON files inside Eclipse, then Eclipse will know that they've changed.

Looks correct.

The problem is that the client doesn't know what the contents of a chest are until the player opens it.

Blockstates are just a more developer friendly way of expressing metadata and other types of information (such as a fence's connectedness) The underlying data structure is still Block + Metadata, but you as a developer will only ever interact with it in order to translate between blockstate and metadata (and back) for your own blocks. The result is you can have LADDER:FACING=NORTH instead of LADDER:0 or REPEATER:FACING=WEST,DELAY=2 instead of REPEATER:11 (11? 11!? What is this magic number?)

Sure, do everything wrong. Just disregard our advice and do it your way. You're probably right afterall. Its not like you came here asking for help.

startSideB is already the distance from the player on the Y axis. Why would you arc-cosine the ratio of side A over the hypotenuse, then cosine the result (resulting in the ratio of side A over the hypotenuse again...)? Christ man, use the ratios of similar triangles. You want the enemy to be 3 units away. You know how far away the enemy is. Divide and multiply.

This is why lighting is fucked up. Do not do this. Lighting will not be your only issue.

The problem is that you apply a flat value to the entity's motion, rather than a value computed from the angle of attack (Math.sin and Math.cos). "Oh, the entity is 0.1 not far enough away on the X axis! Shove him 3 units away!" Also, drop the Math.pow(startSideA,2) nonsense. That's more expensive than startSideA*startSideA.

1.7.10 is no longer supported. Update.

Probably. Rather than trying to override that inventory, I would just use super calls in the necessary functions. I haven't messed with custom dispensers since 1.7.10, but maybe that'll help. You may also be interested in this.

Is it an overridden method? That might be why. If so, mark it with @Override

Your custom TE class does nothing at all remotely useful. It has its own inventory (separate and different than the base class's inventory!) but the overridden methods...do nothing with this new inventory. Your block has several methods that are unused too: getBehavior() - this method is protected and not referenced by your class dispense() - this method is protected and not referenced by your class dropBehavior - this field is private and only referenced by getBehavior() and dispense().

No you didn't. I want to see your entire Block and entire TileEntity classes. Possibly also other things, I can't be sure.

Don't do this. Use multiple blocks.

The JSON format does not permit comments.

Keybinds are not a Forge registry, just register one like you always have in the past.

Yes it is. Show your code.

Show your entire log. The underlying error may be hidden by the missing variant exception.

Because you don't synchronize your TE from server to client. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L160-L175

I don't see anything obviously wrong, but feel free to check out my code where I do something similar: (Note that my block has multiple states that changes the #overlay texture) https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/resources/assets/harderores/models/block/hardore.json https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/resources/assets/harderores/blockstates/ore_hardgold.json https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/block/ore/BlockHardOreBase.java

setBlockState doesn't exist because you're using an older version of Minecraft. You should probably update.

Ok so, this bit here (redacted for simplicity): from zipTree(jar.outputs.getFiles().getSingleFile()).matching { exclude 'com/draco18s/ores/**', 'com/draco18s/industry/**' } This removes my "actual mod" from being included in a compiled jar file. In this case, it excludes the folder com/draco18s/ores and com/draco18s/industry, as we only want the library in this jar. Then this bit here: from zipTree(jar.outputs.getFiles().getSingleFile()).matching { include 'com/draco18s/ores/**', 'assets/harderores/**', 'cog_config/**' exclude '**.xcf' } Makes sure to only include com/draco18s/ores, and its associated assets. The exclude line makes sure not to include large, layered, GIMP image files that aren't actually used by the mod (it's a template for the icons actually used). Your gradle file will already have one task that builds everything. You can rename it and modify the include/exclude as appropriate, then duplicate and modify again, using a new task name. At the bottom, these bits: oresJar.dependsOn('reobfJar') set up to make sure that gradle does all of the appropriate compilation tasks in the proper order. Lastly, this is a task that does a full compile (builds all the jars, redacted slightly for simplicity): task releaseJars(type: Copy) { from coreJarNoCog from oresJar rename '-(.*)jar', '.jar' rename '-(.*)zip', '.zip' into '.' } This task will already exist in your gradle file, you just need to add the from lines so that a full build builds all of your other jar tasks.

It will match only the forest biome, yes. As for generating flowers, world.setBlockState(...) does amazing things. If you're asking how to spawn flowers the way vanilla spawns flowers, I suggest looking for the code vanilla uses to spawn flowers.

Which of the three issues that I said you are doing wrong do you not know the alternative for?

If the code you posted is your modified version, you're still doing everything wrong. Problematic Code Issues #1, #2, and #6