Posts by andy_t_roo

    most of the excess time in your startup is caused by saving configs - the issue i raised with forge about this mentions that you could save allot of startup time by no saving configs that don't change, and someone commented that
    "There's already a mechanism in place to help with this (which works perfectly and I'm currently using) via theproperty.wasRead() method of a Property that's returned via the cfg.get*() methods."…425#issuecomment-14022377

    see [url][/url]
    eg: 2.5 seconds in gregtechmod.common.GT_ModHandler.addPulverisationRecipe of which 2.2 is the save ; similarly about 90% of most of the other code paths end in the same un-needed save call.
    You could probably cut your startup time down to under 3 seconds just by eliminating those. (i would suggest further profiling of your code to see where else the bottlenecks are.)

    re:Lefty - be careful with matching the right version of gregtech with other mods - there's been several changes with quantum chests recently - eg: logistics pipes was over-stuffing digital chests, because they accepted items via the ISided interface, even when they were "full", and greg hadn't published his IDigitalChest interface.
    Also, the latest version of GT broke all machines interfacing with some versions of logistics pipes, because LP (for a few patches) assumed that anything with a quantum chest interface could be accessed in the same way as a quantum chest. (and now all machines implement the quantum chest interface.)
    Logistics pipes integrates with AE also, AE can even pull crafting requests from the logsitics networks

    greg, thanks for the update ; logistics pipes will be updating to use the new api soon, and do a correct "is there space for this item" check, using the api.
    Just wondering - how do classes end up using your ore dictionary, when they call the normal forge function; those callbacks look like they originate from your post-load...

    anyway, a good portion of the load time is spent saving configs - perhaps an "isConfigChanged" check before saving? (i have also raised this issue over at forge).

    and finally, i'm not sure how bc/lp manage to over-stuff your digital chests, because for insertion, the chest is just another ISided inventory, with no special cases (lp has a special handler for checking how many items are in there, using your API).
    edit: cut broken image formating

    GT_Mod.postload currently takes 18.4 seconds to startup. this was 30% of my 69 mod startup time.

    of that 11 seconds is OreDictHandler, which then calls addXRecipe (for many different sub-recipe types)

    the next closest mod startup time (with 2.5 seconds) is forestry, and that is because plugins-for-foristry, extra-bees, and some other things get rolled into there.

    Could you please optimise your startup time?

    that reactor has a total of 160 cooling (9*vent next to 1, 2*2, 3*3 , 4*4, total of 40, * 4 per component).

    the unbalanced cooling from my reactor is around 2.2k. does the "cheap" ness of that reactor include the hull cost?
    - 200 iron, 180 copper, 80 tin per reactor. i think i'd need 14 of them to cool enough.

    something like http://www.talonfiremage.pwp.b…s41wck2vu8ls6p9bh9ufbu6m8 has 480 cooling, and costs
    - 240 iron, 508 copper, 76 tin, and 144 gold

    3x your reactor (which also gives 480 cooling)
    - 600 iron, 540 copper, 240 tin. ; i guess it depends on if you are short on iron, gold, or tin. (360 iron + 164 tin+ 32 copper vs 144 gold) (not to mention 1/3 the floor space and control logic needed).

    my solution to this is to put an electrolyzer on the mfsu, and then detect the presense of a water cell - turn on at 25%, turn off when full or 75%.

    if you have a stack of cells, you can add a 5 min delay on the turn on/off.

    (buildcraft logic gates needed to detect specific inventory items)

    an rs nor latch remembers which side was last high (design can be found at…le:StandardLogicGates.png), and is only 2 torches, 2 blocks and a small amount of redstone.

    If you are prepared to spend a bit of gold, and automate swapping coolant every 3 mins, then you can get an effective eu/tick of about 1000 eu/tick (925/tick assuming it takes you 16 seconds to swap out the old coolant and put new coolant in, every 3 mins)

    The reactor, ignoring the coolant is full cycle (see http://www.talonfiremage.pwp.b…rgstrm3u94wtyrhdok4zsfaps )
    most of the advanced heat exchanges can not be swapped to golden because things will overheat (although with the downtime for swapping, i would guess that minor modifications could be made)

    This is a little different from the HAYO Corp in that it has over 450 cooling built in, while the best HAYO cooling reactor cools 336; so this reduces the need for secondary cooling reactors by 1.5 reactors. It is better to cool at the uranium, as the heat goes to the hull, while coolant cells require extra components to slowly move the heat out of them.

    Also, the HAYO c.s.s.r, while it is efficiency 6, uses neutron reflectors to achieve that. Finally, with only 8 coolant cells to be replaced, it should be able to be done with 1 rp retriever, once RP is updated, leading to a quicker coolant replacement, and less down-time.

    question: whats the best reactor for cooling coolant?

    i downloaded the latest version here (1.23b), and while everything seems to work, the fml log is getting spammed with "[IC2] WARNING: chb.mods.mffs.common.TileEntityExtractorAll@5586c94d didn't implement demandsEnergy() properly, no energy from injectEnergy accepted although demandsEnergy() returned true."

    this is with a mostly-full capacator, and the Extractor linked to several MFSU's

    i vote for keeping the Reactor Heat Control; because it makes a good emergency cooling system.
    Now that there isn't true Causac's the need for emergency cooling isn't as great (reactor components come into it allot more).

    thoughts : cooling with ice/water was too easy, creating a super-explody-causac, or a simple+stable reactor with little inbetween; the idea of just cooling cooling cells i think is a good one, because they are potentially consumable, so if thigns go wrong, they can still go badly wrong with a poor design.

    as for cooling with water vs lapis -- it depends on if you want to cool with a renewable resource or not. I would be in favor of not cooling with water, as that requires no effort to create. Ice,

    creating lapis from uumatter is about 76k eu per lapis (assuming scrap), and you get 40k cooling from it. Everything produces more heat than EU, so it is a net energy loss to cool a reactor with UU constructed lapis. the same is for redstone (10k cooling from 28k EU spent).

    twice compressed water->ice takes 1600 eu (standard compressor, worse with overclocking), or around 300 eu (advanced machines, fully spun up, and overclocked)

    asuming that you can get snow for free, and have fully spun up advanced machine, the cheapest EU cost ice is about 150, so getting 100 cooling from ice is a net EU loss, if you used any machines in its making. - you gain, if you you silk-touched the ice, but you spent XP, and time to do that ...

    An old causac could be cooled by 7 bocks/second to generate 2k eu/tick.

    I am not against keeping ice as a cooling agent, because high power reactors create allot more heat than EU (4 Adjacent quad cell = 140 eu/t, 448 heat/second).
    A new reactor with mostly double cells to generate 2k/tick generates over 5k heat/second - that would be 53 blocks a second. given that a fully spun up singularity compressor generates 2 blocks/second, the industrial requirements to actually do a full causac are very high.

    I vote for leaving water and ice in at their current cooling levels, because the new reactor structure makes it harder to cool via this mechanism.


    Mk 1, EA+220/tick, full cycle, 5.33 efficiency - link uses thick reflectors, for lasting a whole cycle.
    cost(thick):259i, 609c, 101t, 118g
    cost:259i, 513c,65t,118g

    or without the reflectors : 4.33 efficiency, 260/tick
    cost:227i, 468c, 74t, 118g

    Mistic on #Industrial-Craft extended the idea to his efficiency 7 reactor (140 eu/tick, using neutron reflectors) :
    Mk 1, EA*
    (Mistic's original: http://www.talonfiremage.pwp.b…cypeml7e1m2t0xu9ultndh3b4)
    mistic's revised 4 chambers:
    cost(thick): 213i, 523c, 109t, 96g
    cost: 213i, 395, 61t, 96g.
    (edit: yes, i know thick neutrons are more expensive - i chose to put them in because they are 1 replacement/cycle; i've added costs with thin reflectors.)