Leaderboard

Personally I use custom packets more because I find it easier to understand what's going on when I've created it from scratch, rather than adapting vanilla things.

The first thing to note is that the Minecraft class is @SIdeOnly(Side.CLIENT). This means, you can access the class with a client or a remote server, but not on a dedicated server. Trying to load it in a dedicated server will cause Minecraft to crash with a ClassNotFoundException. So be careful to use this for client-side things only, like rendering. 1) 2 separate instance will have 2 seperate Minecraft classes, and they don't know about each other. So the first instance won't return the Minecraft as the other instance. 2) The Minecraft#player variable is initialized when the world is loaded. I don't think there's an event for that. 3) The Minecraft#world variable is initialized in the same method as the player, so they'll be accessible at the same time. Again, there's no event to catch that.

Each instance of Minecraft initializes the mod separately, so they won't overlap ever. I can't answer to whether saving it statically is safe, but I'd assume so. However, you should only ever use Minecraft#getMinecraft() if you absolutely have to - there are almost always better and safer ways to get the information you want. The player can only be gotten from a Minecraft instance on the client side, not on the server, so be very careful where you do this. If you can avoid using Minecraft#player at all, do. The relevant player will usually be passed along with events and method calls. I can't answer to this for sure, but again, Minecraft#getMinecraft() is usually unnecessary and the same effects can be achieved in a different and safer way. Hope that helps!

Because it is old and not needed.

As far as I am aware you do not need packets if you only want to see things changing in the gui. See how it is done in vanilla's classes, for example in ContainerFurnace (the methods that interest you are addListener, detectAndSendChanges and updateProgressBar). Vanilla uses get/setField that you should not have unless you are implementing IInventory which you should not do, but they are only a level of abstration, you can still send/recieve any numeric data you want with IContainerListener::sendProgressBarUpdate and Container::updateProgressBar. The only thing that changes is that you can't use IContainerListener::sendAllWindowProperties... but you can still send everything using sendProgressBarUpdate. Although custom packets will obviously work too, they are just a bit more complicated

If you want something to behave similar to vanilla, look at the vanilla implementation and either re-use or extend it as appropriate. In this case, use or extend RenderSnowball to render an entity as an item model.