[GregTech-6][1.7.10] Moved to Website

  • Speaking of world gen glitches..

    I've sometimes seen gregtech generate (part of) its layers with chisel stone. Or atleast limestone layers..

    zdvPT9i.jpg


    That's chisel limestone on top, and gregtech limestone below it. Obviously all chisel worldgen was off before the world was even created.

    This was with with my own compile of chisel 2.9.5 (to make optifine multi-core chunk loading work again), but I doubt chisel is at fault.

  • That aint a glitch, thats GregTech generating decorative Rocks of Chisel.

  • That aint a glitch, thats GregTech generating decorative Rocks of Chisel.

    I see, thanks.


    Then here's a real bug (hopefully):

    If you shift-click items in an unset ore-dict prefix filter then the item will enter the filter slot and get voided instead of being picked up as the prefix to filter for.

    I haven't tested it on a minimal instance without InventoryTweaks and whatnot, so it might just be some other mod that's interfering.

  • Hm.. and the alkaline/nicd cells are made with either steel or hsla steel wires, but the cells and batteries list their content as iron and will smelt/shred back to iron according to NEI.

    Smelting/shredding individual steel wires will give back steel so I suspect that's a bug.

  • Hm.. and the alkaline/nicd cells are made with either steel or hsla steel wires, but the cells and batteries list their content as iron and will smelt/shred back to iron according to NEI.

    Smelting/shredding individual steel wires will give back steel so I suspect that's a bug.

    The BAtteries can be made using any Iron Wire. Steel counts as iron for that sake. Iron Wires just dont really exist.

  • Hello!

    I found a undocumented/unconfigurable ores - Uvarovite / Chromite / Grossular ore vien, after wiping Cave Dimension
    also minerals - like bauxite etc.
    Does it possible, to switch off their generation?

  • Hello!

    I found a undocumented/unconfigurable ores - Uvarovite / Chromite / Grossular ore vien, after wiping Cave Dimension
    also minerals - like bauxite etc.
    Does it possible, to switch off their generation?

    Do you use the Stone Layer Generator? That one is currently not configurable.


    But if that Cave Dimension works with the old Generator, thne its still configurable.

  • I have different Worldgeneration
    And minearls from Unfeground Biomes

    You do know that Rock Types from Underground Biomes are actually generated by GT6, right? And that the GT6 Generator crashes and lags way less.


    Also I am very sure that GT6 generates its Stone Layers ONLY on the Overworld, so why exactly would it pop up in the Cave Dimension?

  • I would link that Thaumcraft Patchers Page on my Site too, should you decide to do that. More convenient for everyone. ^^

    Yeah, this may be a better idea than me rebuilding TC4 .jar and redistributing Azanor's code... Not to mention I am stupid and cannot even get it to compile without modifications right now, so I doubt I can make much headway.


    Chocohead One of the problems as far as I understand is as follows:

    1. thaumcraft.client.renderers.item.ItemThaumometerRenderer has to render the Thaumometer every frame when it's a held item, so that we see the aspects of whatever we're scanning. It calls doScan() and figures out what the player is looking at. All of this is fine so far.
    2. Once a ScanResult is created, the renderer calls thaumcraft.common.lib.ScanManager.hasBeenScanned() to figure out if the player has scanned the item before, and if they did, it calls ScanManager.getScanAspects() to get the list of aspects associated with the scanned object via thaumcraft.common.lib.crafting.ThaumcraftCraftingManager.getObjectTags() and render them on the Thaumometer.

      LAG HAPPENS AT THIS PART!*
    3. getObjectTags() is supposed to be a O(1) lookup to ThaumcraftApi.objectTags(), but instead it does the following:

    *This is likely not the source of all the lag... even when item has not been scanned before, looking at Sand or trying to scan sand lags the game, and merely looking at an item that has not yet been scanned should not have called the getObjectTags() method. This means that part of lag is coming from somewhere else, somewhere that I have not successfully identified.


    I wish I could have provided profiling results to narrow down which method was lagging, but VisualVM just spits back some io.netty methods and says nothing about Thaumcraft. Maybe someone else who has done it before would be able to profile successfully?

  • I'll get back in a few hours to provide a more thorough evaluation, but the main cause is ScanManager being a disaster which iterates objectTags way too much for what it is storing. I expect generateItemHash is largely to blame for blowing up things being called multiple times whether an item has been scanned or not (which is probably what you're seeing from sand) . This is compounded on from Thaumcraft internally storing what you've scanned as a list which it must go through to check every frame, a set would've been a much better choice given it largely uses contains over anything else (for scanning at least, later I'll double check). Generally ScanManager re-evaluates things multiple times a method, which scales very badly when the methods start getting chained together from the Renderer.


    Comparatively ThaumcraftCraftingManager is much more likely just to produce spikes from iterating big lists, you'd expect to see some effect from that, but it might be washed out from ScanManager still being the bulk of call times. If fixing ScanManager still produces sharp drops on completing scans threading that would be the next course of action. It is very much more dependent on the number of crafting recipes it recognises how to scan for how long it takes, which would be noticeable on a non-GT modpack with lots of recipes but much fewer registered items with aspects.


    The patcher might be slightly incompatible with TC addons given objectTags and groupedObjectTags should not have keys of lists but rather identity keys to item instances, then submaps that can handle meta values. ScanManager heavily suffers from this from iterating the keys when unable to find a matching meta, a more logical structure could've lifted performance substantially alone. It is more likely you'll either get ClassCastExceptions or just nothing scanning from other addons if they are unhappy with them changing, they'll just have to get patched too as it will aid their performance. So long as they go through the register methods rather than direct field access they will be fine however as that can (and will need to be) be patched simply in Thaumcraft's API without worrying about the implementations calling it.

    ScanManager will need to get nearly completely rewritten but only getObjectTags in ThaumcraftCraftingManager is likely to need patching before performance picks up significantly. Testing is going to be a nuisance as it relies on having lots of items to take serious FPS hits, but I don't doubt there'll be people willing to help with that ;)

    145 Mods isn't too many. 9 types of copper and 8 types of tin aren't too many. 3 types of coffee though?

    I know that you believe that you understood what you think I said, but I am not sure you realise that what you read was not what I meant.


    ---- Minecraft Crash Report ----
    // I just don't know what went wrong :(


    I see this too much.

  • You do know that Rock Types from Underground Biomes are actually generated by GT6, right? And that the GT6 Generator crashes and lags way less.


    Also I am very sure that GT6 generates its Stone Layers ONLY on the Overworld, so why exactly would it pop up in the Cave Dimension?

    Caves Dimension comes From Enviromine

    My modpack is Created 1.5 Year ago

    And orespawn is strict

    Bauxite and titan are aviable in Cosmoss only
    Chrome and manganese are aviable in cossmos to
    or from Sluice