Draco18s

Oh? Since what version?

Watch out for SideOnly(CLIENT), I believe getSubItems is client side only (as it is only used for the creative inventory). Instead use: BlockStateContainer bsc = block.getBlockState(); ImmutableList<IBlockState> values = bsc.getValidStates(); That will result in a list of IBlockStates that you can then ask for a pickBlock item.

IInventory is only for vanilla containers. That won't work with mods.

Remove tile entity does not do what you want, in any way, shape, or form. You want to remove an item from a tile entity's inventory? Use getCapability() to get its inventory and remove the item from the IItemStackHandler instance.

if(ladderState.GetValue(FACING) == EnumFacing.NORTH) { // do stuff } if(cropState.GetValue(AGE) > 5) { // do stuff } repeaterState = repeaterState.WithProperty(DELAY, 2);

Yes, the original poster had that function overridden and returning the proper value already.

It does. It's just that that array gets tossed and a new one is created by toArray()

Nope: https://www.tutorialspoint.com/java/util/arraylist_toarray.htm

Alot is better than you at everything

@Override public boolean isOpaqueCube(IBlockState state) { return false; } @Override public boolean isFullCube(IBlockState state) { return false; }

Add an exclude entry for it. *Shrug*

Change the path here to point at your file: https://github.com/Draco18s/ReasonableRealism/blob/master/build.gradle#L99

Nope, only blocks and items.

Mobs are still "Java" format. That hasn't changed yet.

One of the files is locked and can't be edited. Its in use (or incorrectly locked). As for your files, you need to tell the build task where to take the files from and where to put them. It's not automagic.

You could. But you'd have to put them in subfolders, because otherwise you would have multiple files with the same name in the same directory. gradlew build fullBuild or gradlew build terrakonCraftJar or gradlew build eCoreJar

Define "doesn't work."

In addition to what D7 said, if you're interacting with other parts of another mod... You need to do 2 things: 1) Put all of the "I need to reference that other mod" code in a separate class 2) Only load that class inside an if(Loader.isModLoaded("id_of_mod")) check. eg: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/FarmingBase.java#L154-L156 (and the code it references: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/integration/IndustryIntegration.java ) If you're dealing with items and blocks, you can use @ObjectHolder annotations to get those items/blocks from the registries (just check that they're not-null before using them, additionally an if(Loader.isModLoaded("id_of_mod")) check could be useful). see: http://mcforge.readthedocs.io/en/latest/concepts/registries/#injecting-registry-values-into-fields For conditionally hiding your items: you control the getSubItems method. Use an if(Loader.isModLoaded("id_of_mod")) check to either add your item(s) to the creative tab, or not. You can also use conditional recipes to control whether your items can be crafted.

I created a folder (called etc/) that I then created subfolders for and used those...let me grab how that works... https://github.com/Draco18s/ReasonableRealism/blob/master/build.gradle#L99-L102 I never included the etc/ folder on my repo, but you should be able to work that part out yourself:

Not use a static initializer? Seriously, control the order your code gets executed in. You HAVE to insure that your blocks get created before your items. The only way to do this is to explicitly invoke the initializers yourself.

Because your blocks and items are created in static initializer blocks, your item is being created before your block, so ModBlocks.CROPCORN is null at this point.

This looks fine, let me go see where this item is created... Uh...

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.