[1.7.10] Shift-crafting lag

[moronwmachinegun]

Hello,

  I am working on https://github.com/GTNewHorizons/NewHorizons/issues/5163 for our GTNH modpack, and wanted to get opinions on my proposed solution. We have forked versions of TiCon and Forestry, so we can implement a custom fix for this problem. My level of minecraft code expertise is low, so I wanted to see if anyone has any thoughts.

 

Forge 1.7.10 on a shift-click does this bit of code in GuiContainer::mouseMovedUpOrDown

                    while (iterator.hasNext())
                    {
                        slot1 = (Slot)iterator.next();

                        if (slot1 != null && slot1.canTakeStack(this.mc.thePlayer) && slot1.getHasStack() && slot1.inventory == slot.inventory && Container.func_94527_a(slot1, this.field_146994_N, true))
                        {
                            this.handleMouseClick(slot1, slot1.slotNumber, p_146286_3_, 1);
                        }
                    }

 

My code analysis has shown that canTakeStack is called at least 4 times through various steps, depending on how the slot is implemented. canTakeStack does a traverse of the recipes each time, causing bad lag for us because our oredict and recipe map is ludicrously large.

I understand FastWorkBench implements a recipe cache so that it doesn't search each time, but that's beyond my ability to implement in 1.7.10.

Meanwhile, I am thinking of implementing a quick&dirty fix inside the mods canTakeStack. It won't be as elegant as FastWorkBench's recipe crafting cache, but should help.

 

- Check the current tick against the saved tick number, and if they are different, perform usual recipe scan behavior. Update saved tick number + save system time => this will detect if the slot is receiving a lot of requests in a single tick

- If the current tick is the same, compare current system time against saved system time, if the difference is greater than X (probably 1s?), return false to break out of loop => this will rate-limit the shift-crafting so it doesn't hardlock the server for more than the time allowed.

- Check if the slot has been modified, if it has, perform usual recipe scan behavior. Mark slot unmodified => this will detect if the slot has been changed, or if code is just asking that it could be changed.
- If the slot is modified/item successfully extracted, mark the slot modified. => Tells canTakeStack it has to rescan recipes.

 

Are there any gotcha's I am not seeing?  Thanks.