Leaderboard

If you read the javadocs of the LivingEntityUseItemEvent.Finish you will see the following lines: Fired after an item has fully finished being used. The item has been notified that it was used, and the item/result stacks reflect after that state. Note the item/result stacks reflect after that state. part. If you have used the potion the item is indeed an empty stack - as that is what happens to a potion as you drink it. You can make a workaround by subscribing to either Start or Tick subevents, storing the reference to the stack being used somewhere(presumably in a map, just make sure to not leak memory with your keys), removing that reference on the Stop subevent and using that reference as the item being used originally at your Finish subevent handling. Do not forget to clear that map when needed. That is not a perfect solution and if someone suggests a better one you should use theirs.

I encountered several issues with your code: You're registering two different IMessageHandlers (HireVillagerPacket and ChangeFollowPacket) for the same IMessage class (MessageSendEntityId), which doesn't work. Each IMessage class can only have a single IMessageHandler. These classes are poorly named. HireVillagerPacket and ChangeFollowPacket are packet handlers, not packets. MessageSendEntityId tells me what the packet sends, but it doesn't tell me the most important piece of information: why the packet is sent, i.e. what action does it perform? You use Packet in the handler names but you use Message in the packet name, pick one and stick with it. GuiHandler#getClientGuiElement incorrectly returns a Container instead of a GuiScreen for the Hauler ID. GuiIvVillagerHauler uses ContainerIvVillagerHireNitwit instead of ContainerIvVillagerHauler. ContainerIvVillagerHauler adds 15 Slots for the villager's inventory, but the IItemHandler created in IvVillager only has one slot. The Button_Hire and Button_Follow classes no longer serve a purpose, you can replace their usages with regular GuiButtons. When you have an if statement that does nothing but set the value of a boolean variable (like in GuiIvVillagerHireNitwit#actionPerformed), you can move the expression used as the condition of the if statement directly to the initialisation of the boolean variable and remove the if statement. When you have a boolean variable declared directly before and only used in the condition of the if statement, you can move the expression used to initialise it directly into the condition of the if statement and remove the boolean variable. If the condition of an if statement is particularly complex, it can be clearer to keep some parts of it as variables. I've fixed these issues and pushed the changes to GitHub. You can view and/or merge the changes here. You appear to be using GitHub's web UI to upload changes to your repository, I highly recommend using a proper local Git client instead. This will allow you to create more fine-grained commits with descriptive messages rather than lumping all your changes into a single commit with a message like "Add files via upload".

VisualVM is the default jvm profiling tool that is usually shipped with your JDK. It is pretty good and should suffice in most cases. I remember there being mods that did the same, opis and alike. I also remember seing something about alternatives for MC 1.10+. I'll look them up and edit this post with their names if I find any. Also this question is not related to modding directly, so I do not think that this is the right subforum for it? Edit: that alternative is called TickProfiler.

The announcement box at the top of this forum says: So to answer your question, no, there isn't currently a fix. Be patient, forge for 1.12 has only just come out, let them fix all the bugs first, it's probably already on the todo list.

The debuger can't 'not show anything'. Even if your breakpoint isn't triggered it is already showing something, isn't it? It is showing that your code isn't being executed. Then you take if from there and try to see why exactly is it not being executed. If your whole IWorldGenerator is not being triggered(that is a breakpoint at the start of the generate method isn't triggered) then you are not registering your generator correctly. If that breakpoint is triggered something later down the lines isn't correct and the breakpoints allow you to figure out precisely what. If you are using logging to debug - well, you shouldn't. Learn how to do breakpoints, it is literally 1 click of your left mouse button. Logs were ment to give information to the end-user, not to debug. Try again with breakpoints(or if you already are tell exactly what part of your code is not being executed) and post the answer in that other topic of yours.

BlockPos.getAllInBox(from, to)

We are still working on the backend and getting it all together. Sadly its a slow process as there arnt many people working on it. We're trying to bring on another person but ya, it's slow. The other side of this, is we don't really collect much data. So there isn't much to actually show. The only real important thing this has shown us so far is that J8 is by far the java version of choice. Which is what allowed us to decide to force J8 for 1.12+. Minecraft following suit is just bonus reason to do it If you can think of a metric that you'd like to see on the public front let us know and we can consider it, If we have the data.