Draco18s

You forgot about the can_harvest_with_fist_if_Material_allows_it property public static final Material WOOD = (new Material(MapColor.WOOD)).setBurning(); //does not need tool public static final Material ROCK = (new Material(MapColor.STONE)).setRequiresTool(); //requires tool

*Squints at* Oh, you're right. My mistake. Anyway, I can't see the problem then.

There are two water blocks, WATER and FLOWING_WATER. Also, you can use ==

Don't use the Model Mesher, use ModelLoader.setCustomModelResourceLocation instead. And during preInit

Yes, but no, but yes. Yes: you don't need to do anything with your texture file No: you'll have to fiddle with the output (or blockstate file) to correct the reference to your texture (McCrayfishs's to doesn't know your modid) Yes: it'll work just fine except for that

Then save the block (or the material) and reference it twice. Also, if you're looking top to bottom, the sheer fact that the generator is still running means the block above is air and you don't need that check.

He means the effect that makes players visible behind walls. From spectral arrows.

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/FarmingEventHandler.java#L282

Json models are super easy to work with. Recreating your models in them isn't too bad, though Ido recommend using an external program for the models, blockstates are simple enough to do by hand. McCrayfish's program is good.

Why do you get the block at the position twice, once to check if it's material is air and again to check is the material is water? If it is water, it CAN'T be air.

Jesus christ, why do you have two threads on this problem?

"co.coolbeyblades7.minecraft_mod.proxy.ClientProxy;" Remove the semicolon. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/OresBase.java#L90 public void postInit(FMLPreInitializationEvent event) Double check the event object you have here. I'll give you one hint:

Oh. I found your problem. ingotCopper = register(new ItemBase("ingot_copper").setCreativeTab(CreativeTabs.MATERIALS)); cornSeed = register(new ItemCornSeed()); corn = register(new ItemBase("corn").setCreativeTab(CreativeTabs.FOOD)); Note what class you instantiate here. You're creating two ItemBase objects and completely bypass your ItemCornSeed class. That said: new ModelResourceLocation(Variables.MOD_ID + ":" + id You should use item.getRegistryName() here instead. Similarly with TestMod.proxy.registerItemRenderer(item, 0, "corn_seed") you only need to pass the item and metadata (and you don't need to override this method at all!). Additionally, the use of "corn_seed" here instead of "corn" means that you're telling the game to look in one place, when it should be looking in another (another reason to use getRegistryName()). public ItemBase(String name) { this.name = name; setUnlocalizedName(name); setRegistryName(name); } You should use setUnlocalizedName(getRegistryName()) instead, to avoid name conflicts with other mods (lang files are not mod unique). Nitpick: ItemModelProvider You should name the interface IItemModelProvider. The initial "I" indicates that it is an interface, rather than a class and make for cleaner, more readable code. Awesome sauce the power of generics time: private static <T extends Item> T register(T item) If you change this signature to <T extends Item & IItemModelProvider> you won't need the instanceof check. Presumably all your items would implement it, wouldn't they?

I want to redo my ultraflexible registration system to use the new events, but it's going to be tough.

Show the part of the code that has the @SidedProxy annotation. And show your client proxy class, including package and imports.

The error lies within your registerItemRenderer method of your client proxy (probably), which you did not include.

Bounding boxes, collision boxes, and so on should be limited to 1x1x1 blocks. No more, ever. Trying to make it larger will lead to weird side effects, like mobs trying to jump over it, but unable to because it's too tall, but pathfinding says that there's only a 1x1x1 block there, so it's fine. (You remember mobs trying to jump over fences? Yeah. That).

ModelLoader.setCustomModelResourceLocation(..., new ModelResourceLocation(...,"inventory")) You have told Minecraft to look for an "inventory" variant. { "variants": { "normal": { "model": "examplemod:exampleblock" } } } You have specified a "normal" variant. You have not specified a default model.

You shouldn't be using IDs or metadata directly. That gives you an IBakedModel object which is a series of quads. I believe that the texture will be bound for you when you go to render it.

Registry name -> Blockstate(s) Blockstate -> Model(s) Model -> Texture(s) These are the only valid assumptions you can make. You can't jump from the registry name to a texture. You have to use the registry name (in combination with a StateMapper) to get the blockstate variants from the blockstate file(s). From there you can retrieve a model. Then you need to parse the model for a list of textures

I did not misunderstand you at all. 1) You are using the face of the block hit as the direction to dig in. This is flawed, but "good enough" (if you are looking at a corner of the block you can pick any of the three faces just by twitching your mouse a handful of pixels) 2) You treat East and West as the same direction (ditto up/down and north/south) 3) You then loop from behind this point to in font of this point X blocks. To whit I say: What did you expect to happen?

Likely that would be new ResourceLocation(Block#getRegistryName()) But then you'd have to load the block's blockstate and model files yourself to try and find textures. Any given block can have as many textures as it wants for as many blockstates as it wants. Alternatively, you can get it's baked quads like so: https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe04_block_dynamic_block_model1/CamouflageBakedModel.java#L63-L67

Have you tried using player.getLookVec()?

The LivingEntity#tasks list is public. Just modify it.

You don't need a TESR for this. GreyGhost created an example mod of how to use the baked model system to render as another block. https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe04_block_dynamic_block_model1 I've even taken this code myself and adapted it to fiddle around with an idea.