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.

Bit of follow up since I understand a bit more now.... To get extra data passed across to the client (like a TE blockpos, for example), Forge 26.0.16 adds an extra PacketBuffer parameter to the NetworkHooks.openGui() calls, and a corresponding parameter to the container factory constructor. Looks like NetworkHooks.openGui() remains the way to go for modded - I guess player.openContainer() is really for vanilla only? Update: player.openContainer() should be fine to use if you're just creating a GUI purely to display some container slots (and don't need direct access to the clientside tile entity), like a chest GUI for example. Typically, you'll have two or more constructors in your container objects - one "factory" constructor which is called by Minecraft client-side when a GUI is opened (and when the container type is registered during init), and one or more constructors of your choosing which create a container with any data you need to initialize them with. Those extra constructors would be called server-side from your INamedContainerProvider implementation, and client-side from your "factory" constructor, having extracted information from the extraData PacketBuffer.

Objectholders need to public static final and null.

No worries. One other thing, regarding my point about one-to-one container->GUI mappings... If you have one container object but you want several different GUIs (my use case: Modular Routers modules nearly all use the same container object - a 9-slot inventory for filtering - but several modules have extra GUI controls for configuring module-specific properties), then: A separate container type will need to be registered for each GUI type, but you can use the same subclass of Container each time, just with a different ContainerType parameter. Then you can associate each container type with its corresponding GUI using ScreenManager.registerFactory() as normal

1.13 flattened spawn eggs into a separate item for each entity type instead of being a single item with the entity type in the NBT. See the wiki for the new item registry names.

I still don't get why some people delete their post right after someone solves their problem...

i personally would go to 1.13.2 first to get used to it because it is a bit better to find information on the forge version and and -should- have less bugs

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

I've got some tutorial information as well as links to others here: http://jabelarminecraft.blogspot.com/p/minecraft-17x.html Note that part of the confusion is that there are actually four fairly different situations related to capabilities: Using existing capabilities (e.g. IItemHolder) in your custom classes Using custom capabilities in your custom classes Using existing capabilities on vanilla (or other mod's) classes Using custom capabilities on vanilla (or other mod's) classes I think people get confused because often a tutorial will be covering a case different than yours and so if you apply it you'll either be missing something needed or will duplicate something unnecessary.

Well in this thread you actually used the words: "please stop" "don't ask" "useless questions will not be answered" "not supported on the forum" "this thread should be locked period" "get out of here" You also questioned his motives related to PVP. You also insulted him by calling him "lazy" and "unoriginal". All the above might actually be true, but leave it to diesieben07 to respond. And no one needs to attack so aggressively -- I know it can be frustrating to see people come asking for help when they are indeed lazy or incapable of programming Java. But just ignore them instead of getting in an all caps flame war. I don't want to see you banned from the forum because you seem to legitimately care about modding and have a lot of passion and potential. So just stick to threads that don't frustrate you! Cheers!

@DifferentiationIt is good that you understand the rules of the forum, and also nice that you're actively particpating and interested in modding. However, the only people that should enforce the rules are official moderators. It is even okay to suggest someone should spend time learning more Java, but some of your posts are literally telling people to "go away" or "we're not going to support that". No one except official moderators should ever tell someone to go away or try to draw a line over support. Now I often see people who post and I can tell that they're likely going to need a LOT of help, or want to do something they probably shouldn't. In those cases I simply don't respond. Sometimes other people will, sometimes not, but it is up to them if they want to spend the time supporting someone. One other thing to note is you never really know who the person posting is. Perhaps it is a younger kid. Perhaps it is someone with some special needs. So it is best to always err on the side of compassion and tolerance even if they seem a bit misguided. Anyway, please leave the rules to the moderators -- our moderators do a good job. If someone posting annoys you then just don't respond to their thread.