Choonster

IModel is the model in its raw form, which can be baked into an IBakedModel. IBakedModel is the model in a form optimised for being uploaded to the GPU. ICustomModelLoader is responsible for loading the IModel.

The chunk will redraw any time the state saved to metadata changes, but not when the actual state changes (because the actual state could change at any time). You need to call World#notifyBlockUpdate to trigger a chunk redraw. Since there's no callback for blocks n positions above a block changing, you'll need to periodically check whether the block can see the sky and redraw the chunk if that changes. Since you need to store this somewhere and redraw the chunk when it changes, you may as well store in the metadata rather than setting it from the actual state. Depending on how frequently you want to check this, you can either use a TileEntity that implements ITickable or schedule block updates (override Block#updateTick to perform the check and call World#scheduleUpdate from Block#onBlockAdded and Block#updateTick).

Your repository should include the Gradle Wrapper (gradlew, gradlew.bat and the gradle directory) so people building your mod don't need to have Gradle installed locally. You're using an old version of Forge which stops loading recipes for a mod as soon as an exception is thrown, newer versions continue loading recipes and log every exception that's thrown. I ran your mod with its current version of Forge and this exception was logged: You need to specify the metadata using the data property for any Item that has subtypes. I tried updating to a newer version of Forge, but you're still using GameRegistry.register, which is private in newer versions. You need to use the registry events instead.

Vanilla methods/fields have more than one name: there's the Notch name (Mojang's obfuscated names that change each version), the SRG name (MCP's auto-generated names that remain stable between versions) and the MCP name (MCP's community-assigned deobfuscated names). Forge deobfuscates from Notch to SRG names at runtime, so you never need to worry about Notch names. For normal code, ForgeGradle reobfuscates from MCP to SRG names at build time, so you don't need to worry about the names. For reflection, you need to check both the SRG and the MCP names for vanilla fields and methods yourself. The easiest way to do this is by using Forge's ReflectionHelper.findMethod/findField methods. These don't throw any checked exceptions, so you can use them directly in the field initialiser of the Method/Field field. You can use MCPBot to find the SRG name of a method/field.

To overlay things on your model, you'll need to create your own IModel/IBakedModel/ICustomModelLoader implementations. Forge has several examples of these. The SimpleModelFontRenderer class added to Forge in 1.11.2 allows you to render text on models. If there are a fixed number of variations, you can register them all with ModelBakery.registerItemVariants and then register an ItemMeshDefinition that selects the model based on some aspect of the ItemStack (e.g. metadata, NBT, capabilities). If the variants are dynamically-generated, you'll need your own model implementation. I can't really help you with the specifics of your model implementation, you'll need to look for examples in Forge or open-source mods.

Are you definitely registering an instance of this class? Post your registration code and the class that calls it. Also post the code where you create your creative tabs.

You can add your own conditions by implementing IConditionFactory and specifying the class in your _factories.json file. You can then use these conditions to enable/disable JSON recipes at load time.

You need to call CapabilityManager#register in a method called in preInit, you can't call it in a field initialiser because it returns void. The Class object you pass as the first argument of CapabilityManager#register (IShave.class) is the same Class object you need to pass to the @CapabilityInject annotation to inject the Capability instance into a field. You need to attach a provider for your capability to the entity using AttachCapabilitiesEvent<Entity>. I have several examples of capabilities in my mod. You can see the APIs here and the implementations here.

Do you get any errors in the logs?

You can use DedicatedServer#getStringProperty to get a property from the server.properties file, even if it's never used by Minecraft.

As far as I can tell, the server-name property is never used by Minecraft 1.12. The wiki says here that the server-name property was only ever used by Minecraft Classic.

What name are you talking about? Where is this name shown?

You can probably achieve this using RenderLivingEvent.Pre/Post or by adding a LayerRenderer to the Render. Botania renders its baubles and other items with this LayerRenderer. As an example, the cosmetic baubles are rendered by this method.

What's your overall goal? Tell me what you want to do (in terms of what the player will see/do), not how you want to do it.

This isn't possible. What are you trying to achieve? There's almost certainly a way to do it without needing to replace a whole class.

Delete it from the mods directory.

You have a 1.7.10 coremod installed, which won't work on 1.11.2. You should give each version its own game directory, you can configure this in the launcher. In future, please post the FML log (logs/fml-client-latest.log in the game directory) using Gist or Pastebin. This contains more information than the launcher's game output window and uploading it to Gist/Pastebin makes it easier to read.

Your blockstates file has two properties (game and facing), but the ModelResourceLocation you return from the ItemMeshDefinition only includes one of them. It needs to include both, in alphabetical order. You should also call ModelBakery.registerItemVariants with every possible ModelResourceLocation that can be returned by the ItemMeshDefinition to ensure that they're loaded by Minecraft.

No, you don't need to register JSON recipes yourself; Forge automatically loads and registers them. Is the recipe in the correct directory? It should be in assets/<modid>/recipes. Are there any errors in the log?

This is in the Support & Bug Reports section, which is for mod users rather than mod developers. Issues with a specific mod are best reported directly to the author, though.

The Forge installer you downloaded is for Minecraft 1.8. You need to download one for 1.12, e.g. 1.12-14.21.1.2387 (the current Recommended version).

You need to run Vanilla 1.8 at least once from the launcher before Forge for 1.8 can be installed. 1.8 is very outdated and won't be supported here much longer, you should update to 1.12. If you must use 1.8.x, use 1.8.9.

If the block is adjacent to the door, make it emit a redstone signal. If it's not, you'll probably need to toggle the door periodically if it's not open. If you want more help with this, create a new thread.

Did you find the exception being thrown as I explained in my previous post? When posting code, either include it in your post in a code block (the <> icon) or upload it to a site like Gist/Pastebin and link it here.

Don't use <mc_version>-latest as the Forge version (the minecraft.version property), specify a concrete version (e.g. 1.12-14.21.1.2426) so your mod can always be built without being affected by changes in newer versions of Forge. 14.21.1.2426 is a Forge version, not an MCP mappings version. The MCPBot website has a list of mappings versions here. Get rid of the sourceCompatibility/targetCompatibility lines, ForgeGradle 2.3 automatically targets Java 8 now that Minecraft 1.12 targets it. Don't post code in screenshots, either include it in your post in a code block (the <> icon) or upload it to a site like Gist/Pastebin and link it here.