Leaderboard

In the new 1.12.2 version you need to use the new way of registering with the new RegistryEvent<T> Try and read the documentation on at mcforge.readthedocs.io/en/latest/concepts/registries/ If you arent known with events check out this https://mcforge.readthedocs.io/en/latest/events/intro/ I could advice you to check out this repo from Harry'sTechreviews: a youtuber, you can also check out his video on it https://github.com/HarryTechRevs/MinecraftModding/tree/HarryTechRevs-1.12.2-Tutorials/main/java/harry/mod

Actually, its the items that are 16 pixels. An actual slot graphic is 18x18. The 1 pixel border that gives the slot some "depth" extends beyond the 16x16 bounds. But otherwise you're correct.

With boxes do you mean slots? when you add a slot to your container like such: for (int i = 0; i < 3; i++) { for (int j = 0; j < 9; j++) { addSlotToContainer(new Slot(playerInv, j + i * 9 + 9, 8 + j * 18, 84 + i * 18)); } } you're doing the following: You add 3 rows with each 9 slots. Every time i increases it goes 18 pixels down (slots are 18 big, 2 pixels around the 16 width item.) and every time j increases it goes 18 pixels to the right for the same reasons. The second value is the index, this is increased by 1 for every new slot basically. So every i adds 9, every j adds 1. addSlotToContainer(new Slot(inventoryToUse, slotIndex, xCoordinate, yCoordinate)); basically the slotindex is the index of the slot within the inventory. Vanilla inventory uses 0-35 for the items with 0-8 being the hotbar. slots 35-38 are armour. the xCoordinate is the spot within your GUI where you want to put your slot. The y Coordinate is the height from the top where your slot is. When you draw your Container the point '0' in x and y are the top left corner. in the GuiContainer (client side) you want to make your own 0 point, since 0 is the top left corner of the screen, not the gui. You have already declared the two variables for x and y in your gui using the following code however : int x = (width - xSize) / 2; int y = (height - ySize) / 2; so if you want something in the GuiContainer to be 15 pixels to the right and 10 pixels down(From the top left corner of your gui) you want to use drawTexturedModalRect(x+15, y+10, startOfTextureX, startOfTextureY, rectWidth, rectHeight); obviously if you want something to be in the corner of the screen you can just use 0 instead of x+number To clarify. the Container is your class extending container. the GuiContainer is the class extending GuiContainer. You probably know this. I'm just clarifying.

An inventory or GUI consists out of two things. The main Client side GuiContainer and the server side container. These are bound together with a guiHandler With the handler you're basically connecting the two. The way to add 'slots' to your GUI is to add slots to the container. You're using SlotItemHandler for your custom inventory .Which is the proper way to do it. Your problem might be that you haven't implemented an IGuiHandler. At least I can't find it in your GitHub. I might be blind. Anyway, to draw the bar you'll want to pass a variable with the percentage done to the client side guiContainer. Then use a drawTexturedModalRect(xPosition, yPosition, xStart, yStart, x, y); to draw the arrow. The way you do this is to set the 'start' of the draw texture to the left top corner of your texture. Then make the x the 'percentage' of your arrow. If the arrow is 50 pixels long and your machine is 50% done you set the x to 50*percentage where the double percentage is equal to 0.5 I'm writing from my phone. But I think that should be enough to get you going. Edit: When you pass a variable as '50' instead of a value with decimals and divide it by 100 to get a multiplier. Make sure you're using a double and casting one of the numbers to double so you actually GET a double. I know you probably already know this since it's basic. But I made the mistake once and when you do, you only get 1 or 0, don't be a dummy.

If you're coming from a professional coding environment, yes both Minecraft code itself and Forge's API are pretty "crazy". This is because Minecraft wasn't originally developed by professional programmers and furthermore was developed incrementally so there is a lot of inconsistency and a lot of stuff that would be frowned upon by software or engineering organizations. For example, the scope of fields and methods is really inconsistent with no proper encapsulation -- so you can reach into the code and change key values without any validation or synchronization. There are also often two methods which might do the same things. There is also abandoned code, code which does the same thing in multiple places (especially since without encapsulation the data validation is sprinkled throughout the code) and such. Forge is done by good quality programmers, but it has been an incremental effort with lots of different contributors. It is also limited in that it tries to minimize the patching of vanilla Minecraft. Because it is incremental, every now and then the API gets entirely overhauled (for example the move to JSON format to control a number of features, the new registry event system, and so forth). Because there are lots of different contributors there are inconsistencies in style, for example the use of functional programming is creeping into the code but isn't consistently used throughout. And because they're trying to minimize the patching it is really constraining -- for example I'm trying to submit my first contribution related to custom fluids acting more like water but because Material.WATER is hard-coded throughout the vanilla code it is somewhat dubious to try to take this on as it creates a lot of patches. I do find it wearing that the APIs change constantly -- keeping old mods up to date is a full time job and the modding community is getting fractured (you'll see on Minecraft Forum that majority of modders have stayed with 1.7.10 or 1.8.9). However, it is also the interesting part of the modding hobby and frankly has made me a much better coder by trying to keep up as it teaches a lot about the benefits of different approaches. Sorry for the long essay, but I understand the surprise you might feel when you hear an API is constantly changing...

Forge doesn't even maintain the Javadoc, that's all on the MCPBot side. This would be more accurate: http://files.minecraftforge.net/ The last build was 05:37 AM this morning (with a new recommended build that has no changes, 10 minutes later), and the previous build was on the 9th. MCP exports? Those happen daily.