I noticed recently while I’m holding any GregTech 6 tool (specifically tested with a Thorium Pickaxe, Shovel, Axe, Saw, and Tartarite Mining Drill (HV)) and hold down the right mouse button I get an immediate FPS drop (to about 3-10 frames per second) that lasts until I release the right mouse button. I first noticed this when using a Saw to debark logs, but further testing reveals this happens regardless of the type of block you’re aiming the tool at, and even occurs while aiming at nothing.
I also tested and determined this only happens with GT6 tools - other items (from vanilla Minecraft, GT6, and other mods) don’t have this problem.
I tested and observed this problem both in the overworld (where my FPS is always somewhat low) and in Random Things’ Spectre Dimension (where my FPS is always very high, due to the lack of mobs, tile entities, and blocks that need to be rendered).
I don’t have any further insights as to why this might be happening, unfortunately. I’m not sure if this is something that only occurs with my particular assortment of mods, or if it’s strictly a GregTech-related issue.
Edit:
I did some more testing and noticed it doesn’t occur when I use my Thorium Shovel on a Burning Box (Solid, Invar). This makes me think the FPS drop occurs when the mod tries but fails to find a special use for the tool.
Alright, I got in finally and gave that snapshot (GregTech 6.14.11-42-gcd777392 according to the Mod Info screen) a test . Unfortunately, it looks like the problem is still occurring. I tested with a Thorium Wire Cutter and a Thorium Axe.
Holding right-click when using either of those tools when aiming at nothing but air causes the FPS to drop.
Using the Thorium Axe on most blocks also causes the FPS to drop.
Using the Thorium Wire Cutter on most blocks, however, causes the tool to be swung and does not produce an FPS drop.
Sorry for the delays. I finally got some time to test the snapshot (GregTech 6.14.11-43-g8aa1903f).
There’s still an FPS drop when holding down the right mouse button, although it may have improved slightly.
From my tests in the Spectre Dimension, it reduces to about 6 to 17 frames per second (from an average of about 100), which is a small increase from the previous 3-10.
I might try attaching JVisualVM to my Minecraft instance later to see if the sampler can identify where in the code the JVM is spending all of its time.
Okay, I have some sampler results, although I don’t know how helpful they’ll be. In typical fashion, while I was sampling, the FPS drop was less severe than usual (by about 15 FPS) for some reason.
I took two sets of sampler results - one where I just let the game run normally without doing anything for several seconds, and another where I held down the right mouse button for several seconds while holding a Thorium Wire Cutter.
I noticed a couple of functions not found in in the first set of results make their way towards the top when this happens, namely: net.minecraftforge.oredict.ShapedOreRecipe.checkMatch buildcraft.BuildCraftMod$PacketSender.run
Another thing I realized later might be a factor is the JVM I’m using. On the recommendation of some users over at Reddit I’ve been using OpenJ9 8.0.282.8 from AdoptOpenJDK (as opposed to Oracle’s JVM) along with some new JVM options this playthrough to improve the game’s performance.
Here are the JVM options I use: -XX:+UseG1GC -XX:ParallelGCThreads=8 -Dsun.rmi.dgc.server.gcInterval=2147483646 -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=32M -Xmx8G -Xms8G -Xmn128M -Duser.language=en -Duser.country=US -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
If you think it’s relevant, I can test if the issue occurs with Oracle’s JVM as well if you want.
Edit:
In case you were wondering, the reason the “jmxremote” arguments are on there is because I could only get JVisualVM to connect to OpenJ9 via JMX.
You did not sample anything i have to say. You need to actually look into the tree and open the functions until you get to a function that has rightclick in its name, the Screenshot of nothing opened does not say anything for me at all. Also please tell me if Buildcraft is actually the reason for your Lag, because I do not have Buildcraft installed at all.
Alright, I re-sampled the FPS drop and took a snapshot this time. I couldn’t find any function with “right” in its name in the results, but what I did find is that the Client Thread is receiving and processing a “S30PacketWindowItems” (presumably every tick), which ultimately winds up calling net.minecraftforge.oredict.ShapedOreRecipe.checkMatch which seems to be what is generating the client thread lag:
I don’t have any kind of GUI open while I’m doing this. It’s really strange that the game is trying to update a crafting matrix I can’t even see. I tried looking up “activate” in the results as well and wasn’t getting any matches there either (I’m using the tool by holding the right mouse button while not pointing at a block, which may be why).
I think the snapshot has demystified the issue pretty considerably, though. What I think might be happening here, serverside each tick while holding one of the aforementioned affected GT6 tools with the RMB down, the code tries to find a use for it (e.g. blocking, debarking a log, emptying a burning box, changing the connectivity of a wire/pipe, etc), and then failing that it goes down a path that marks the tool as being updated (e.g. something setting an NBT value? I’m not entirely sure, I don’t have a whole lot of Minecraft modding experience.) which causes the server to send a packet to the client telling it that the inventory has been updated. Then, for whatever stupid reason, the client wrongly concludes that the crafting grid has changed and tries to find a recipe matching its new contents, and finds nothing because it’s empty (and because it’s empty and will therefore match nothing, it maximizes the amount of time it takes to scan for a matching recipe).
Edit:
Sorry about that!
Didn’t mean to keep you or anything. I’m just a little indecisive when it comes to my writing, so I sometimes wind up rewriting things I write several times if I’m not satisfied with how it sounds the first few times around.
Oh great so it sends a lag packet to the client whenever rightclick is held… I wonder why it actually lags for you though, it does not seem to do that for me.
And I am someone who likes to reply ASAP, so that I dont waste peoples time, and I didnt want to waste your time. XD
@OvermindDL1 so we should ASM this into the Mojang Code:
net.minecraft.item.crafting.CraftingManager
At Line 307:
if (i == 0) return null;
That way if the Grid is empty (which it obviously would be for the Player Inventory) it will never iterate over the entire fucking Crafting Recipe List. This should also fix some other Lag Sources while it is at it.
public ItemStack findMatchingRecipe(InventoryCrafting p_82787_1_, World p_82787_2_)
{
int i = 0;
ItemStack itemstack = null;
ItemStack itemstack1 = null;
int j;
for (j = 0; j < p_82787_1_.getSizeInventory(); ++j)
{
ItemStack itemstack2 = p_82787_1_.getStackInSlot(j);
if (itemstack2 != null)
{
if (i == 0)
{
itemstack = itemstack2;
}
if (i == 1)
{
itemstack1 = itemstack2;
}
++i;
}
}
if (i == 0) return null; // This is the place to inject this Line
if (i == 2 && itemstack.getItem() == itemstack1.getItem() && itemstack.stackSize == 1 && itemstack1.stackSize == 1 && itemstack.getItem().isRepairable())
{
Item item = itemstack.getItem();
int j1 = item.getMaxDamage() - itemstack.getItemDamageForDisplay();
int k = item.getMaxDamage() - itemstack1.getItemDamageForDisplay();
int l = j1 + k + item.getMaxDamage() * 5 / 100;
int i1 = item.getMaxDamage() - l;
if (i1 < 0)
{
i1 = 0;
}
return new ItemStack(itemstack.getItem(), 1, i1);
}
else
{
for (j = 0; j < this.recipes.size(); ++j)
{
IRecipe irecipe = (IRecipe)this.recipes.get(j);
if (irecipe.matches(p_82787_1_, p_82787_2_))
{
return irecipe.getCraftingResult(p_82787_1_);
}
}
return null;
}
}