Leaderboard

By default, mod TileEntities are replaced any time the block state changes. To change this, override TileEntity#shouldRefresh to return true when the Blocks of the old and the new IBlockStates are different.

Yes, but it looks like you haven't called the init method or the register method, you only called the registerRenderers method.

Oh, that's why. You have to register the armor items before you can register the renderers.

NullPointers are easy to diagnose. It means you tried to reference something when it is null. Can you show where you called the register methods?

Lhykos: that says whether or not this block renders sides, not adjacent blocks. This is what's missing: @Override public boolean isOpaqueCube(IBlockState state) { return false; } Also, make sure you annotate all override methods with @Override

You have to register your WorldGenerator on the Server Side, in the "CommonProxy". Not on the Client side.

Did you miss yet another "tut" versus "tutorial" change? I thought we solved all of those in one of your many other threads. If I can recognize a repeat problem, then you should too. Please learn from these exchanges so you can read your own crash reports and at least TRY to see what your problem is before instantly posting here.

I meant EntityCamera, yes. It's actually the EntityHanging#facingDirection field that's null rather than EntityHanging#hangingPosition as I initially suspected; this is because the EntityCamera(World, BlockPos, EnumFacing) constructor doesn't call EntityHanging#updateFacingWithBoundingBox.

Post your json files again. Did we just post at the same time again??

So, IItemPropertyGetter gives you the following (client side) method: public float apply(ItemStack stack, @Nullable World world, @Nullable EntityLivingBase entityIn) Which includes the ItemStack, and presumably its NBT tags. It must return a single floating point number, which is tied to a single "property name" (e.g. "Time" which is what the clock uses). The Item's json file then must have these states in sequential order because minecraft goes "Ok, I need 12.9845" and starts at the top and looks for the first value that's larger than the IItemPropertyGetter's returned value and uses that "variant." I discovered this by accident when trying to do something weird. You can see an example implementation of my own here (using world information, not NBT): https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/item/ItemThermometer.java#L53 https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/resources/assets/harderfarming/models/item/thermometer.json Where each one of those specified models is a normal, standard, item model file (which can point to a block, just like any other block item model file). https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/resources/assets/harderfarming/models/item/temp_05.json