V0idWa1k3r

No you didn't

ModelRegistryEvent is fired before init. Either populate this field at clinit(public static final Item wring = new WoodenRing(...)) and register the item at pre-init, do everything at pre-init or use forge's registry events and ObjectHolders

Well something(ModItems.wring) on that line is null. When and how are you setting that field/registering your item?

If you are using Then the methods that are annotated with SubscribeEvent must be static

Well, Lex says differently. As far as I am aware the registry events have been moved to directly after pre-init but before init. Maybe the docs are not updated yet? I am subscribing my handlers for registries during pre-init and it works fine.

Minecraft inverts the V axis for whatever reason afaik. Flip the UV map vertically and it should work.

a final static void?... Why?.. You might want to finish your code here. In any class an instance of you subscribe to forge's event bus during pre-init/automatically. Proxies are for distinguishing between physical sides. There should not be a common proxy to begin with, only a server one and a client one. Any common code can go in any common class, including your mod class for example. Assuming latest forge for 1.12: Not necessary. Registry events are fired after pre-init so you can subscribe your handler to a bus in pre-init and be done. It will especially not work as the methods are not static - EventBusSubscriber(or subscribing a class to a bus) will only process static fields.

ItemModelMesher is outdated and buggy. Use ModelLoader. Your models must be registered in a ModelRegistryEvent. Or during pre-init if you do not want to use the new registry events and are not using latest versions of forge. Unlocalized names have nothing to do with registry/modelresourcelocation names, use Item::getRegistryName(). What is that substring for?

Actually if you want to do something like that a custom GUI should suffice. You can use your custom GUI to add buttons and handle recipes/transactions/etc. and just send it to the server which validates that the client is not trying to lie with the transaction/do the logic/etc. You can get all recipes at IMerchant::getRecipes, that returns you a MerchantRecipeList that is an implementation of ArrayList<MerchantRecipe> so you should be able to get all recipes this way. The MerchantRecipe contains MerchantRecipe::getItemToBuy(first requested item), MerchantRecipe::getSecondItemToBuy(second requested item) and getItemToSell(the result). All those are ItemStacks so you should not have issues with those. I do not know how you would implement your transaction logic, that is up to you. Just do not forget that all logic must be ran or at least checked on the server so a malicious client can't lie to the server and you should be fine. Additionally there are other useful methods in MerchantRecipe that you may or may not need, like MerchantRecipe::isRecipeDisabled(checks if the player traded maximum amount of times for the recipe), MerchantRecipe::getToolUses(the amount of time the recipe was traded), MerchantRecipe::getMaxTradeUses(pretty self-descriptive ) and others. If you want the "press button -> send packet -> check trade -> spawn items & take currency" you should be able to bypass the container entirely as if it never existed.

Well, the items in the inventory would be null at the time the GUI opens. Those are the items in the slots that the player physically puts in. By the time the GUI is open those are null as the player couldn't have placed anything in the container. You can use MerchantInventory::getCurrentRecipe to get the currently selected recipe.

Well, I've tested it and it seems that triangulated faces load and render just fine for items so that seems to not be an issue. Can you please provide new fixed obj and mtl files?

I am not sure, I'll try it out later. L #230 : usemtl None You need to provide an actual material for the object in your model editor. Also should there not be an object definition(o name) at the beggining of the file right after the material file definition? It seems that you've made your model incorrectly in your model editor.

Caused by: java.lang.RuntimeException: OBJLoader.Parser: Exception parsing line #232: `f 66/1/1 67/2/1 65/3/1` Your model's face definition is invalid. Caused by: java.lang.NullPointerException at net.minecraftforge.client.model.obj.OBJModel$Material.access$100(OBJModel.java:595) ~[OBJModel$Material.class:?] Looks like something went wrong with the material, it might be null. Post your obj file somewhere so I can check if it is correct.

From the docs of the GuiOpenEvent: This event is called before any Gui will open. If you want to override this Gui, simply set the gui variable to your own Gui. There is a setGui method in the event. This will also not work as you expect it to as you are only replacing the GUI, but the server still has the villager's original container open. You need to handle that too. Apart from that - how do you know that merchantInventory is null? From what I can tell it should not be null and that is also what my debugger tells me. In any case you can have anything you want as the merchant's inventory in your container. See how ContainerMerchant initializes the inventory. Nothing stops you from doing the same.

Caused by: java.io.FileNotFoundException: progressiveg:models/item/ak_47_0.mtl Yeah, fix the wrong material and post the new log. Remember that the obj file must also be named the same as the mtl file.

Show the log file, it usually contains descriptive errors. Also make sure that your material(not the file) is actually called Material.

Either this is a part of an if statement or you have one too many closing parentheses. Why are you asking? Your IDE should tell you if your syntax is correct or not.

Wrong subforum. Wrong import. Wrong version(aka 1.7.10 is no longer supported on this forum)

Well your miners_portal field you are accessing is defined as a Block. and Block indeed has no trySpawnPortal method defined. Either define your fiield as a BlockMinersPortal or cast miners_portal to BlockMinersPortal before accessing it's methods.

Why are you passing a class as a second argument? You need to pass an implementation of IRenderFactory, not a class. You have quoted the javadocs for the method you are currently using(the one that takes a class and Render as arguments). As you've quoted it is marked as deprecated and is TODO-ed to be removed.

Additionaly some potential issues which are not directly related to your problem but are still worth fixing: ItemModelMesher is outdated and buggy. Use ModelLoader. And register your models in your client proxy during pre-init or in a ModelRegistryEvent(prefered) ?

You are already using a proxy, so you must be aware of how to use it correctly and do not need someone else to write code for you here. IRenderFactory is a functional interface you can either use a lambda/method reference for or you can create your implementation of it. Can you show your RenderDogOne class? Every Render child class needs a RenderManager as a parameter and yours does not have one so I would like to see what you are passing as RenderManager in your RenderDogOne constructor's super call. This is one of the reasons to use IRenderFactory - it has RenderManager passed to it as an argument.

Rendering for your entities must be registered during pre-init. Not init and not post-init. The way you are registering your renderer is deprecated and outdated. Use RenderingRegistry::registerEntityRenderingHandler(Class, IRenderFactory) instead of RenderingRegistry::registerEntityRenderingHandler(Class, Render) You can't have client-side only code in your common class like that or you will crash the server. Move it to your client proxy.

Almost. This is correct for the most part but there is one small, illusive and obscure issue. The BufferBuilder::color method has 2 overloads - 1 that uses 4 floats of [0 - 1] ranges and 1 that uses 4 integers of [0 - 255] ranges. As integer is the default number in java when you pass in a number without specifying it's type(like you are doing everywhere with color(1, 0, 0, 1)) it is assumed to be an integer. So the method with integers as params gets invoked instead of the one with floats and... well, you are passing 1 as alpha which considering an integer range of that method is practicaly invisible. You need to specify at least one number as a float so the correct method is chosen. In my original example I use color(1, 0, 0, 1F) Note the 1F at the end. By passing that number as a float I force the correct method to be chosen.