Leaderboard

Step back from the "how do I make an api jar" and look at your mod. What is it that you've created that other people might want to use? Did you add a machine that has some sort of recipe? Did you add a machine that has some sort of recipe? Do you have some capability that could be exposed? Do you have some other mechanism that other mods might either want to know about, modify, supply data to, or get data from? Do you have block properties that aren't vanilla? First, create an API package separate form your mod. In there create interface that declares the action you want to expose. Second, implement that interface on the class that's already handling those actions. Third, store a reference to the instance in an API location (don't forget to instantiate it). Fourth, convert all existing references over to use the API instead. If you do things right, the game won't crash and your machine will still work. Congrats, you made an API. If you don't use your own API, you can't test it. And if you don't test it, you won't realize that something's wrong (it took Reika and I back and forth over 3 revisions of his API before I could add a recipe to the Rotary Craft Extractor). You can do the same thing for block properties, capabilities, and other things as well. However there's other things to keep in mind as well: Once you've declared the interface and released it, it's effectively permanent. You've signed an API contract that says that these methods exist and are guaranteed to exist. If you change the method signatures in the future, it won't be your mod that crashes, but the mod that tried to use your API. And users will complain to them even though it's your fault. Imagine how frustrated a player would be if that other mod author vanished from modding and you changed the API: users would be hammering a brick wall with no response, unable to use two of their favorite mods together. Instead, you should mark the methods in the interface as @deprecated (so that no one else starts using them) and in the implementation, make a best-guess conversion to the new method. If it can't be done at all, then just leave an empty method stub. The two mods won't integrate as they used to, but they'd still run. You can throw warnings and log messages and non-fatal errors all you'd like, but the JVM should never crash.

Don't know much on your situation, so excuse the perhaps insolent remarks. Most modders discriminate the API portions of their mod into a separate folder, where another can easily just take the code, and then copy into a separate portion of their development environment, to use. Thus, as long as the forge hooks for an API are there, then you are good to go. You could also separately compile the API, but I don't know how, no would I. As a side not, what I am referring to for the forge hooks for an API (in case you don't know) I am referring to the package-info.java files, containing @API(owner = [yourDiscriminatorName], apiVersion = [API version], provides = [your API, should probably be like the core API class name, like "MyModAPI"]) Beyond that, I don't know much more of what you are looking for beyond letting the world know you have a mod, and that it has an API, if other modders wish to make hook into it.

You need to call IThreadListener#scheduleTask with a Runnable implementation that performs the appropriate action in its run method (an anonymous class or lambda is usually used here). Currently you're immediately calling IvVillager#hire_Villager (on the network thread) and passing the result to IThreadListener#scheduleTask. The only thing you do on the network thread should be scheduling the task to run on the main thread. What do you mean by "ids"? If you mean the index argument of the Slot/SlotItemHandler constructors (assigned to Slot#slotIndex/SlotItemHandler#index), that's the slot index within the inventory (IItemHandler) that the Slot should read from/write to. If you have Slots for multiple inventories in a Container (which is often the case), you'll often have multiple Slots with the same index argument but different inventories (e.g. one for slot 0 of the villager's inventory and one for slot 0 of the player's inventory). Slot#slotNumber is the unique index of the Slot in the Container, this is automatically assigned when you call Container#addSlot. To protect against malicious clients sending the packet when the player isn't actually near the villager.

You can't compare ItemStacks using the == operator, it checks for object identity - so a newly created stack will never be == to an existing stack. Instead you need to check the item that's within the stack (using stack#getItem) and compare it to the block's ItemBlock (which you can obtain from Item.getItemFromBlock). Items can be compared using ==, because they are singletons (so there's only ever one gold ore item, for example).

You're telling it to remove a newly-created ItemStack object. That exact object won't be present in the list, because you've just made it. You're right in thinking you need to check if the drop would be the ore block. You'll need to iterate through the list of drops, and for each element, check whether its item (ItemStack#getItem) is the ItemBlock for the block in question (Item.getItemFromBlock(block)).