Leaderboard

No, it uses RESULT.DENY to prevent the growth. It's effectively canceled, but it does not use event.setCanceled(true).

Try using inheritance. Check for your item, if you want to render it, call super.doRender. If you want to not render it, just return.

A block model is not supposed to take more than 1 block. It creates issues of all kind. Even Mojang had to go through a lot of inconvinience to make fences working, and that is mostly workarounds. You could use a custom IBakedModel if you do not care about collision boxes. You should just have your block have multiple other blocks surrounding it that act as 'parts of the bigger model'. As for your first question - it is a bit difficult to understand what exactly you are trying to achieve but you can use a Block::getExtendedState to have as many states of a block as you want. You will need to store something that dictates the current to-be-chosen state somewhere, most likely in your tileentity.

No, you're still not scheduling a task. You can't just create a method that returns Runnable and return null from it, you need to actually create a new instance of an anonymous (or named) class that implements Runnable and overrides Runnable#run to perform the action. You're still retrieving the entity ID from the packet outside of what would be the scheduled task (even though you're not using it), which you shouldn't really do. I'm not sure what you're asking.

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.