Jump to content

moronwmachinegun

Members
  • Posts

    4
  • Joined

  • Last visited

moronwmachinegun's Achievements

Tree Puncher

Tree Puncher (2/8)

1

Reputation

  1. 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.
  2. Well, I decided i didn't want to have to re-implement half of Minecraft just so I could set a XYZ value, so I just make my fake "chunk" be an array of ints. I have placed my "fake" oregen command-line simulation code up on my Github at https://github.com/richardhendricks/GT-standalone-oregen if it is of interest to anyone. performancetest.java has the basic skeleton of what I needed. There are a couple of sample tests in there, one using a non-chunkified worldgen to generate ores, one using a chunkified worldgen that remembers generated oreveins in a hashtable, and a chunkifed GT stone boulder generator that has random XYZ dimensions skewed towards making skinny pipes instead of bland round balls. The printout is very primitive, just a text printout of the chunks.
  3. Hello, I am looking at orevein generation performance in GT5U. Currently I am seeing numbers around 100-300ms to fill an orevein. I have pulled the logic into a standalone test harness, and it seems to run fairly fast, about 600uS to fill a vein (without any minecraft-related function calls, just randomization and loop control). I have optimized that a little, shaving off about 60uS, but that's clearly not where the major culprit is located. I was wondering if anyone has done any performance comparisons on how to step through a chunk. Based on my read of https://minecraft.gamepedia.com/Chunk_format it seems like doing a full Y layer at a time is the most CPU cache-friendly since you wouldn't jump up and down between sections. Also, it would be ideal to order XZ so that the memory accesses are linear and won't cause cache collisions (TMI: http://www.aristeia.com/TalkNotes/ACCU2011_CPUCaches.pdf). The current code does looping as for X for Z for Y so there might be some benefit to swapping Y to the outermost loop. And possibly a benefit to swapping order of X and Z. It might all be re-arranging deck chairs on the Titanic though. My suspicion is that the major time-sink is turning the victim block into a tile entity. I'm going to try adding some measurement code to see how much of the overall time is spent doing that. If that's the case, there isn't much to really do except lower the number of blocks converted by making veins smaller, reducing their density, or optimizing World.setBlock(). Also, if anyone has a more fleshed-out command line test harness for worldgen, that would be great (a fake chunk would be awesome). The variance when testing in-game is so high it's hard to tease out if improvements actually matter. If not, can someone point me to the Chunk class file so I can make a better simulation? Thanks for any help!
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.