[1.14.4] GUI Without Container?

[JayZX535]

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.

[JayZX535]

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.

[JayZX535]

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.

[hiotewdew]

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.

[hiotewdew]

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.

[DavidM]

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?