Draco18s

That's why I have this class: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/internal/CommonContainer.java I solved it once, never need to mess with it ever again.

It means that the field or method isn't static.

You can use ==, but yes. Use the constants in Items class.

All of them except your seed, which unless you add it to those lists in the constructor (terrible idea). No. Probably because its using the default crop inspector, which is mature if the metadata value >= 7. You'll have to write your own inspector is my guess.

By the way: if(false && !world.isRemote) // Forge: NOP all this. Why do you still have that block it does nothing? Its also a terrible idea to use +10 as your UPPER/LOWER value. Metadata is limited by 16 states, meaning you're limiting your max age to 6, whereas if you used a single bit (+8) you could have max ages up to 8. It also means you can use bitwise logic instead (int age = meta & 7; int halfAsInt = meta & 8). this.seed = new CoreSeedFood(name, 3, this); You can't do this. You are not allowed to create items at this point in the startup process. How do you even register this item? The return value from setBlock is not useful in any capacity that I've ever seen. And after a lot of testing, I've determined the issue. This function is run when you use bonemeal: @Override public void onBlockAdded(World world, BlockPos pos, IBlockState state) { if(getHalf(state) == EnumCropHalf.LOWER) world.setBlockState(pos.up(), getDefaultState().withProperty(HALF, EnumCropHalf.UPPER), 2); } It does not run when the block updates.

With 1.13 just around the corner, it is no longer advised to use variants like this.

Yes, and what I'm saying is, your two-block crop isn't using one block to store its age. Its using two. That method can't deal with that.

This is not functionally useful. If the chunk the crop is in is not loaded, then the crop won't update. The blocks above the crop are always in the same chunk as the crop itself. if(!world.isAreaLoaded(pos, 1)) return; // Forge: prevent loading unloaded chunks when checking neighbor's light Nice to see you including the crop grow events if(ForgeHooks.onCropsGrowPre(world, pos, state, rand.nextInt((int) (25.0F / f) + 1) == 0)) Dollars to doughnuts this line isn't doing what you want: int i = getAge(state);

Its a common interface so that event handler methods don't need to be called with Reflection (which is slow).

Be aware that Forge for 1.13 isn't stable yet.

Singleton is the name of a pattern whereby there is only one object and it is referenced everywhere as needed. "Per block" is the "everywhere" If a TE won't work for you, you need a custom data studies that holds that information by coordinate. You will need to manage it yourself. It will be hard. You have no other options.

If you want a central mod around which all your other mods are linked, call it "Lib" or "Library" instead of core. (I did this, even as much as it pained me not to call my API bundle for my "hard stuff" collection "HardCore")

Sounds like you're storing the data in a field of your block class. This will never work (as you've seen) because blocks are singletons. You must use a separate data structure, such as a Tile Entity.

You haven't correctly set up your block to have states. You need to override createBlockState.

https://github.com/BigBadE/AdvancedEnchantments/blob/master/src/main/java/bigbade/advancedenchantments/AdvancedEnchantments.java#L40 Why are you not using the ModelRegistryEvent?

This is why I have this class: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/internal/CommonContainer.java

It is the integer representation of a 255-255-255 color. 0 is black, 16777215 is white. Or if you prefer, 0xFFFFFF

Inside the registry event.

You might also want to look into the Looking Glass mod. I don't know if it has been updated recently (XCompWiz has been pretty busy), but you might be able to examine it to see how it works. The whole point of Looking Glass was to provide a mod-friendly way of being able to render views of any location in Minecraft, including other dimensions.

You don't want to set anything here, what you have to do is query the side. Check if world#isRemote is false.

Either: 4 or fewer enum values Separate blocks

1. The server. Because the server has authority over the world. 2. You don't have to do anything.

You need a custom subclass of ItemBlock.

Blockstates aren't magic. They're just a more developer-friendly way of expressing the same information that has always been there: metadata. Metadata is still limited to 16 possible unique states, so with your current code you have a FACING value that has 4 distinct states. This means that your TIER value can only have 4 distinct states that fit within metadata. That said, you shouldn't be using metadata to store "different" blocks at this point. Once you update your mod for 1.13, you'll have to flatten those metadata values back into separate block instances, so you may as well just do that now.

Is that IHasModel? Stop using it. It does nothing except make you retype the same lines over and over. All items need models, yes, ALL ITEMS which means that the interface is not special. Now if the interface is because the item has a custom mesh definition, that's fine (that's special). This means that the model you want isn't being registered and baked. This is common for custom mesh definition models. This is the chunk I use: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L184-L195 (and a mesh definition: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/industry/item/ItemCastingMold.java#L89 ) It looks like the code you posted should perform similar operations on the right data.