Leaderboard

... You don't have a texture... Textures are linked in the .mtl file, under a "map_Kd" key. Likely caused by an unsuccessful UV-mapping. It was never actually "added". Here's an example of a .mtl file with mapped textures. Oh, and for the future, please paste the contents of files like this to pastebin/github gist. Downloading (possibly malevolent) files from strangers can be off putting.

the JSON system is considered the proper modern way to do it. One advantage is that it will be able to be replaced in resource packs rather than "hard coded" into your mod. Unless you're doing something very unusual with recipes (in which case you might implement your own IRecipe class) you should use the JSON along with the registry event system.

The ObjLoader does support UV-mapping. If you mean the "key x is not supported, skipping", you don't actally need those in the .mtl. You should be able to remove them without any effects on your nodel.

Override FluidHandlerItemStackSimple#fill and FluidHandlerItemStackSimple#drain to call the super methods and then damage FluidHandlerItemStackSimple#container if the super method returned something other than 0/null and the doFill/doDrain parameter is true.

instead of the populate chunk event you might have better luck with the chunk load event. I was looking at this recently (and will probably file an issue about it) but there really isn't a great event for replacing the results of generation. There are events where you can fully replace the entire chunk provider, or biome and such, but if you want to let the normal generation happen and then replace selective blocks the populate chunk happens too early (also seems you can run into issue with concurrent modifications) and the other events tend not to pass the chunk primer. But I found that chunk load actually happens almost exactly where you need it to. So try that instead.

Would this not be possible (but ugly) with an IWorldEventListener & overriding IWorldEventListener::notifyBlockUpdate? Would require some guess-work to make sure it was indeed placed by BlockLiquid::checkForMixing, but should be viable.