[1.14.4] GUI Without Container?

[JayZX535 2]

Hey all,

 

I'm working on implementing a lore book to my mod.  It works similarly to vanilla books, except the text is all predefined.  As such, I'm trying to figure out how to create and access a GUI for it.  My question is, I'm not sure if I need to use a container for it, or if it even needs serverside access at all.  I'm planning on using info that's drawn from the mod's lang file and a player capability (which I've already coded to sync to the client), and it shouldn't need to send any info back to the server (nothing the player can edit except the currently viewed page, which I can easily handle via the client) so if I'm understanding everything right, it doesn't actually need to pull any data from the server.  As such, I'm not sure if I need to use a container at all, or if I should just make it a screen.  However, I want to ensure that I'm doing this properly.

 

I see that ClientPlayerEntity uses the following method... (which is called from the book items)

public void openBook(ItemStack stack, Hand hand) {
      Item item = stack.getItem();
      if (item == Items.WRITABLE_BOOK) {
         this.mc.displayGuiScreen(new EditBookScreen(this, stack, hand));
      }
   }

 

So I'm guessing I may need to do something like that.  Is this.mc.displayGUIScreen() the right method to use for modded GUIs?  Do I need to register the GUI anywhere, or if it's not linked to a container can I just open it like this?  I assume I need a client safe method to call to open this, so I'm guessing I should run that method through my proxy for safety?  Is there anything I should be aware of when it comes to using a client-only screen, and is there any reason I might still want to opt to use a container in this case?  If the method is clientside only, is there anything special I need to do to block movement (or anything else noteworthy)?

 

Thanks, and have a great day.

[diesieben07 7219]

If you just want a client-side GUI all you need to do is extend the Screen class and call displayGuiScreen. Just make sure to use DistExecutor (and possibly World#isRemote) to run it on the client only.

[JayZX535 2]

1 hour ago, diesieben07 said:

If you just want a client-side GUI all you need to do is extend the Screen class and call displayGuiScreen. Just make sure to use DistExecutor (and possibly World#isRemote) to run it on the client only.

Thanks for the confirmation!  Works like a charm on both server and client.  Ended up using both checks just to be extra certain and it all seems just fine.

[diesieben07 7219]

4 minutes ago, JayZX535 said:

Thanks for the confirmation!  Works like a charm on both server and client.  Ended up using both checks just to be extra certain and it all seems just fine.

Nothing to do with "extra certain". They do different things, you should learn what these things do.

[JayZX535 2]

1 hour ago, diesieben07 said:

Nothing to do with "extra certain". They do different things, you should learn what these things do.

I'm aware they do different things and I'm aware of what they do.  I'm being "extra certain" by covering both possibilities.

[diesieben07 7219]

14 hours ago, JayZX535 said:

I'm being "extra certain" by covering both possibilities.

This shows that you do not understand what they do.

[hiotewdew 3]

DistExecutor is used for physical side, whether you are using a minecraft client or dedicated server (in this case, this is the relevant information as only physical clients do rendering)

 

isRemote references the logical side, where true is the logical client. Logical client just means if it's not running the gameserver instance on that thread, so isRemote could return false on clients on the server thread. Also, isRemote checks do not properly avoid classloading, unlike DistExecutor which avoids them by utilizing the double supplier trick.

[diesieben07 7219]

2 minutes ago, hiotewdew said:

unlike DistExecutor which avoids them by utilizing the double supplier trick.

Just as a note, it doesn't actually do this properly.

[hiotewdew 3]

Just now, diesieben07 said:

Just as a note, it doesn't actually do this properly.

Does it not? I've used the double supplier trick in a lot of code and it's all worked just fine on dedicated servers.

[diesieben07 7219]

Just now, hiotewdew said:

Does it not? I've used the double supplier trick in a lot of code and it's all worked just fine on dedicated servers.

It works, most of the time. To understand when it does not work, you have to know a lot about how lambdas are implemented and how the JVM loads class files.

If you write a lambda, that code becomes a static method in the same class. If you write two lambdas (even if they are nested within each other), the code is still present in the containing class file, as two static methods. The JDK will then at runtime use whatever means it sees fit (currently it just creates new class files using ASM) to turn those static methods into actual instances of the interface.

Now, when the JVM loads your class file it has to verify it, so that there are no unsound type operations in the bytecode, for example.

So, if you e.g. do:

ClientWorld world = Minecraft.getMinecraft().world 

The JVM has to check that the type of Minecraft#world (ClientWorld) is actually assignable to ClientWorld. In this case this is trivial, because obviously ClientWorld is-a ClientWorld.

 

In this case the JVM can verify this code without loading any classes (i.e. it doesn't need to load ClientWorld). Your class (containing the two static methods for the lambdas) loads fine, even on the server.

 

Now, let's do a very subtle change:

World world = Minecraft.getMinecraft().world

Suddenly, your code will crash on the server. Why? Because the JVM has to now load World and ClientWorld to see if ClientWorld is assignable to World. It will fail to find ClientWorld and boom, your code crashes with a NoClassDefFoundError on a server.

 

This is why I really do not like this approach, because it is brittle and requires deep understanding of many mechanics that you normally never need to worry about in Java development to use correctly.

Yes, it's argueably a lot more convenient than @SidedProxy, but @SidedProxy made it very clear that we are dealing with classes that are potentially absent here, thus reflection must be used, it is the only truly safe way to interact with classes that are potentially absent.

It is also still unclear if this optimization the JVM does (not loading the classes at all if they are equal) is actually specified in the JVM specification, or if this whole approach relies on an implementation detail that HotSpot (OpenJDK's main JVM) does.

[diesieben07 7219]

Oh, and while I am already ranting...

Apparently CPW introduced some changes to the API to help with this problem. Except it was done in the most roundabout way possible, relying on more compilation internals and introducing even more confusing concepts.

[DavidM 173]

1 hour ago, diesieben07 said:

So, if you e.g. do:

ClientWorld world = Minecraft.getMinecraft().world 

The JVM has to check that the type of Minecraft#world (ClientWorld) is actually assignable to ClientWorld. In this case this is trivial, because obviously ClientWorld is-a ClientWorld.

 

In this case the JVM can verify this code without loading any classes (i.e. it doesn't need to load ClientWorld). Your class (containing the two static methods for the lambdas) loads fine, even on the server.

Out of curiosity, wouldn't this trigger the class loading of Minecraft since a method of Minecraft is being invoked?

[diesieben07 7219]

50 minutes ago, DavidM said:

Out of curiosity, wouldn't this trigger the class loading of Minecraft since a method of Minecraft is being invoked?

No, because that code is never executed.