Leaderboard

Because it's very old version of Minecraft released almost 3 years ago. And with almost every Minecraft version changing a lot of stuff, it is very hard for the forum team to keep up. support for 5 different versions. They usually offer support for the latest 2 major versions, which right now are 1.10.2 and 1.11.2, and sometimes 1.8.9/1.9.4 (practically the same codebase) with a message they should update.

I cloned your repository to debug this locally, but I encountered an issue: You're manually adding the Tesla and JEI JARs in the libs directory as dependencies, but your repository doesn't include these files. You should prefer using Maven/Ivy dependencies as these will be automatically downloaded by Gradle when setting up the workspace. JEI's Developer Wiki explains how to add it as a Maven dependency here, Tesla's readme explains how to do this here. After fixing this, I narrowed down the source of your problem. The issue is that you're calling ModelLoader.setCustomStateMapper for your fluid Blocks before they've been registered, which ModelLoader doesn't support. You need to call it after they've been registered. In general, it's not entirely safe to pass around a Block or any other IForgeRegistryEntry before it's been registered. The technical explanation is that ModelLoader stores the registered IStateMappers in a HashMap<RegistryDelegate<Block>, IStateMapper>. HashMap uses Object#hashCode and Object#equals to determine if two keys are equal and RegistryDelegate.Delegate implements these using its name field, which is only set when an IForgeRegistryEntry.Impl instance (e.g. a Block) is registered. Before registration, all RegistryDelegates are equal to each other. When you call ModelLoader.setCustomStateMapper with a Block that hasn't been registered, the IStateMapper is stored in the HashMap with a null-named RegistryDelegate as the key. When you call it again with another unregistered Block, the HashMap considers the two null-named RegistryDelegates to be the same key, so it replaces the old IStateMapper value with the new one. When you call ModelLoader.setCustomStateMapper with a Block that has been registered, its RegistryDelegate will have a unique name (the Block's registry name) and be considered a distinct key in the HashMap from any other Block's RegistryDelegate.

No. You give the game folder a logical name, e.g.: "1.11.2 modded", which will contain a mods folder for your mods.

You could use the Forge reflection helper. I use it in my mod right here to access fields. There are methods in ReflectionHelper to grab hold of methods as well.

Google is your friend: (https://www.google.com/search?q=how+to+use+reflection+in+java+to+access+private+method&ie=utf-8&oe=utf-8) http://stackoverflow.com/questions/11483647/how-do-i-access-private-methods-and-private-data-members-via-reflection

One question: Is this for your own ores, or for vanilla/other modded ores? If the latter: If you want to influence other's ores, look at the GenerateMinable event. It passes the WorldGenerator, which you can cast to WorldGenMinable, and get the state, number and predicate from.

Did you Google minecraft forge ore generation?

It's very difficult to read the log you posted, please upload the full log (logs/fml-client-latest.log) to Gist or Pastebin and then link it here.

You could make different profiles with a different game folder, which has its own mods folder. If you use a different game folder for each profile, you won't get conflicts about mods for different versions.