Leaderboard

Then yes, you would sync those values in a packet, except you're not changing the config variables. You're storing the result in wherever you are using the HUD. Basically, when turning on the hud, send a packet to the client from the server side containing the variables stored in the config. Then, store those values inside the HUD to be rendered. This way you are getting the variables from the server rather than the client. That's how I see it anyways.

I used an assortment of guessing, looking at vanilla usage, and looking at the code in the obfuscated method (I didn't realize the MCP names were in place in the latest version at that time). AFAIK the only thing that changes across minor versions is the build.gradle file. To update, simply download the newest mdk, replace your build.gradle with the new one, and edit it to fit your need (add mod id, dependencies, etc). Make sure to re-import the workspace after that.

For Eclipse: Make a github accout. Create an empty repository on github for your mod. It will give you the address to use as the remote. In Eclipse, right-click on your project, select Team, choose Share Project. on the Share Project screen, check Use or create repository in parent folder of project Click Create Repository Click Finish Right click your project again, choose Team, then Commit. It will open the Git Staging window at the bottom. add all the files with the green ++ button, which moves them to the bottom window. Click Commit and Push. In this screen, fill in the URI with the address for your repo from github. You can either fill in the username/pw info and save it, or make it prompt you every time, up to you. After this, you should see your project on github. When you edit/change files, use the git staging window to Commit your changes, and Push when you want to send it to github (you don't have to push every time you change, just when you want to publish it). Do some reading up on git, it's really useful. Branches are great.

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.