[1.11.2] [SOLVED] Some Questions Regarding Minecraft::getMinecraft

[Draconwolver]

As I've not modded for a while, I'd like to begin again on the right foot. I apologize in advance if there's some misunderstanding of Java on my part.

 

1. Is it safe to save the value from Minecraft::getMinecraft in a static variable? The return type is static so I'd assume so, but then wouldn't this be the same across all instances of Minecraft that are run? If a player decides to log into two different accounts on two different instances of Minecraft, how would Minecraft::getMinecraft::player return due to Minecraft::getMinecraft being static?

 

2. I'm confident that Minecraft::getMinecraft can be used safely as soon as the mod is loaded, but when is Minecraft::getMinecraft::player not null? Does the player have to load a world first? Is there an event I can listen to to set a non-null Minecraft::getMinecraft::player to a variable then not have to worry about it?

 

3. Likewise, when in the process of loading up a world does Minecraft::getMinecraft::world gain a value? Is there, again, an event that would let me know when this becomes non-null?

 

Thanks, and please pardon my noobiness.

Edited June 5, 2017 by Draconwolver

[tripl3dogdare]

10 minutes ago, Draconwolver said:

1. Is it safe to save the value from Minecraft#getMinecraft() in a static variable? The return type is static so I'd assume so, but then wouldn't this be the same across all instances of Minecraft that are run? If a player decides to log into two different accounts on two different instances of Minecraft, how would Minecraft#getMinecraft()#player return due to Minecraft#getMinecraft() being static?

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.

10 minutes ago, Draconwolver said:

2. I'm confident that Minecraft#getMinecraft() can be used safely as soon as the mod is loaded, but when is Minecraft#getMinecraft()#player not null? Does the player have to load a world first? Is there an event I can listen to to set a non-null Minecraft#getMinecraft()#player to a variable then not have to worry about it?

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.

12 minutes ago, Draconwolver said:

3. Likewise, when in the process of loading up a world does Minecraft#getMinecraft()#world gain a value? Is there, again, an event that would let me know when this becomes non-null?

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!

[larsgerrits]

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.

[Draconwolver]

@tripl3dogdare @larsgerrits Thank you, this is very informational. I should've mentioned that I'm aware that all of this is client-side only, but thank you for the heads ups. Much of what I'm trying to do involves sending messages to the user, so it's hard to come by an event that provides a reference to the player returned by Minecraft::getMinecraft::player.

Edited June 5, 2017 by Draconwolver

[tripl3dogdare]

Glad I could help! That is one of the most common uses of it that's actually legitimately needed, yes. Just be careful to check 

world.isRemote

to make sure you're on the client side before you try to use Minecraft#getMinecraft, and you should be fine =)

[tripl3dogdare]

17 minutes ago, diesieben07 said:

Ehm... no, not really. You must encapsulate references to client-only classes in your own client-only classes, such as your ClientProxy and common code must not reference those classes directly.

My bad, I guess I'm just a bit too used to Scala where I can just

if(world.isRemote) {
  import net.minecraft.client.Minecraft
  // do stuff
}

Please disregard my previous comments as to how to use Minecraft#getMinecraft safely, it appears I am either an idiot or really rusty when it comes to Java.

[jeffryfisher]

20 hours ago, Draconwolver said:

what I'm trying to do involves sending messages to the user

Ah then, that might be a horse of a different color (or class). The server has a notion of "accesses". Look at how the server processes sound -- sound can be initiated on the server and then (a few layers down in its processing) the server loops through the world accesses to send packets to all users. You might also look at how one player's achievement causes messages to all other players.

 

So, if you're trying to make a mod where something happens on the authority (server) and is then told to some or all players, you should be able to imitate one of these processes. On the other hand, if you're trying to write yourself a client-side mod that will tell you where the nearest diamonds are, then we can't (won't) help you.