Choonster

The root of your repository should be the root directory of your mod, i.e. where build.gradle is. The repository should include the buildscript (build.gradle and gradle.properties [if you have it]), the Gradle Wrapper (gradlew, gradlew.bat and the gradle directory) and your source code/resources (the src directory). Look at my mod and its .gitignore file for an example of the repository structure to use and which files to include.

The log should tell you why the recipe is incorrect. I suspect it's the same issue as this thread, you haven't specified the metadata for an Item with subtypes (minecraft:sand, which is an instance of ItemMultiTexture). You need to specify the metadata with the data property.

I'm not seeing any obvious issues that would stop the particles from working. Create a Git repository for your mod, push it to a site like GitHub (if you haven't already) and link it here; I'll need to debug this locally to locate the issue. I did notice that you have model registration code in a common class, which has the potential to crash the dedicated server. Model registration should be done in a dedicated client-only class. I also recommend moving your Block/Item registration to the corresponding registry events and your model registration to ModelRegistryEvent. This will make it easier to update to 1.12+, where GameRegistry.register is private.

You can do that, but it's much more reliable to give each version its own game directory. This way each version will have its own config files, saves and any other mod-related files.

Any Item that has subtypes (i.e. Item#getHasSubtypes returns true) requires the metadata to be specified with the data property when used in JSON recipes. I explained this here. ItemMeshDefinitions are registered with ModelLoader.setCustomMeshDefinition, just as before.

Have you checked for errors in the log? Side note: I previously said that newer versions of Forge continue loading recipes for a mod after encountering an error, but this is incorrect. I thought that this issue had already been fixed, but it hasn't.

Try deleting and recreating your IDE project. I initially had the same issue where assets weren't being copied to the IDE's output directory, but deleting and recreating the project fixed it. Item (and other IForgeRegistryEntry) instances should either be created in field initialisers or in the corresponding registry event, not in preInit. Models should be registered in ModelRegistryEvent. If your event handlers aren't being called, make sure you've registered them (either manually or with @Mod.EventBusSubscriber). If you've made these changes and are still having issues, update your repository and describe the issues.

I'm not sure what would cause that. Have you set up your IDE project by following these instructions? Update your code on GitHub and I'll try to reproduce and debug it locally.

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.