Leaderboard

As anyone who's started porting to 1.14.2 is probably aware by now, container and GUI creation has changed... quite a bit. To summarise what I've gathered so far: Containers (more accurately: container types) are now registry objects and must be registered in a RegistryEvent.Register<ContainerType<?>> event handler. Container objects themselves must provide a constructor of the form MyContainer(int windowId, PlayerInventory inv, PacketBuffer extraData). This will be used to instantiate the client-side container. Your container's constructor must call the super Container constructor with your registered container type and the windowId parameter (this int parameter is not used in any other way - just pass it along to the superclass constructor and forget about it) You can use the extraData parameter to pass... extra data! to your container. This PacketBuffer parameter is built server-side when you call NetworkHooks.openGui(); see below. Typically, your container will have (at least) two constructors; the factory constructor described above which is used for client-side construction, and a constructor taking whatever parameters you need to pass to set up your server-side container object. Container-based GUI's are now associated with a container type with the ScreenManager.registerFactory() method, which takes a registered ContainerType and a ScreenManager.IFactory to construct your GUI object. Call that in your client-side init code. ExtensionPoint.GUIFACTORY is gone, no longer needed, as is the old IGuiHandler system. ScreenManager does all that work now. While there must be a one-to-one mapping from ContainerType to each GUI, also remember that you can happily re-use the same container class for multiple container types if you need to; just pass the container type as a parameter to your constructor and up along to the Container constructor. All container-based GUI's must provide a constructor taking(T, PlayerInventory, ITextComponent), where the generic T is the type of your container object. Container-based GUI objects are now generified (is that a word?) on the container's class, e.g. public class MyGui extends ContainerScreen<MyContainer> IInteractionObject is gone; instead your tile entity should implement INamedContainerProvider: the createMenu() method is where you create and return your server-side container object. (I believe getDisplayName() is only used to initialize the title field of your GUI object). To open a container-based GUI on the tile entity (server-side), call NetworkHooks.OpenGui(player, myTileEntity, pos) or player.openContainer(myTileEntity) That would typically be called from Block#onBlockActivated() If you want to create a container-based GUI for an item, create a class implementing INamedContainerProvider (a static inner class of the item makes sense, or perhaps an anonymous implementation), implementing createMenu() and getDisplayName() to create and return the container object as above. That would typically be called as something like NetworkHooks.OpenGui(player, new MyItemContainerProvider(stack), pos) or player.openContainer(new MyItemContainerProvider(stack)) from Item#onItemRightClick() or Item#onItemUse() player.openContainer() can be used if you have no need to pass any extra data to the client, e.g. your GUI is just displaying container slots, like a chest. But if your client GUI needs access to the client-side tile entity, use NetworkHooks.openGui() and pass at least the tile entity's blockpos so the client container can get the GUI object. Syncing any necessary TE data to the client-side TE needs to be done separately by whatever means you choose. Note that NetworkHooks.openGui() has a couple of variants to allow extra data to be passed to the client-side container object: a simple pos argument if you just need to pass the blockpos of your TE, or a more flexible Consumer<PacketBuffer> if you have more complex data to pass to the client. The simple pos variant just calls the full-blooded Consumer<PacketBuffer> variant in any case. It's this packet buffer that is received by the client-side container constructor.

Make sure you have the most up to date version of all your mods

In src\main\resources\META-INF there should be a file called mods.toml. Change all of the occurrences of [25,) to [26,) and [1.13.2] to [1.14.2]. If this doesn't work, please post the file. Hope this helps!

Your errorlog doesn't match your code at all. As for the code you've provided: Don't extend Gui on your event handler class, that makes no sense. The resourcelocation currently points to assets/minecraft/vezythieme/vezy.png. if (e.getType() != null) { if (e.getType() == ElementType.TEXT) The first check is redundant. If the type is TEXT it can't be null. RenderGameOverlayEvent is a parent class for Pre and Post events. Pick the one you need. However that doesn't matter since your error log indicates that the code you are using is completely different. Make sure the file is actually there. Check that it isn't test.png.png or something like that, check that eclipse isn't being a derp and is actually including your resources, etc. A screenshot of the file in your folder structure would also help.

I found it by searching for classes called “Blocks” or looking for instantiations of Block. These forums are specifically not for basic Java or how to use your IDE, they’re for help with the Forge API. Minecraft’s code is always changing, so thinking about what the class is used for, where it was previously used from is a great way to find the new equivalent.

net.minecraft.block.Blocks

here is a full list (I think) of all vanilla package name, class name, and class location changes from 1.13 to 1.14 https://gist.github.com/williewillus/2dfc945b7b7fdb69cc3ff830072d22fe

net.minecraft.block.blocks

@rtester do not hijack others threads

Of course it's alright to not get everything right the first time. I think the problem here is that you are misunderstanding Draco18s' tone. Draco is a fun and helpful person who spend a lot of his time on the forum answering others' question. His occasional sarcasm keeps the conversation in a light mood, but might sometimes appear to be unfriendly (which is definitely not his intention) to people who are not used to his way of speaking, in which case all I could say is "don't take it personally; he doesn't mean that; he is trying to help you". As for your problem, you should not directly use the meta of a blockstate to get the direction it is facing, as the meta of a blockstate might not directly convert to its corresponding EnumFacing (some blocks stores more than just an EnumFacing value in its meta). Instead, you should use the FACING property of the blockstate, which, if exists, always directly tells you the facing of the block. It is also faster and more readable.

https://github.com/ModCoderPack/MCPBot-Issues/issues/819 Stop asking for ETAs. I've clearly stated whats going on.