Posts by Talonius

    Yes, the Integrated Heat Disperser. That updated design still has the same problem because some of the cooling cell do not have a neighbouring IHD. Ideally you need to make a design where each cooling cell has a neighbouring IHD but using as few IHDs as possible.

    Those cooling cells have no IHDs to help cool them down, thus they have to do so all by themselves.. this takes a long time to do.


    That design is incapable of taking advantage of external cooling because there are no components that interact with the hull.

    Rick: If you make a design with a full stack of ice but no supply, then it'll use only one stack and then keep going as if there was no ice. If you want to know how long the design will last without the ice, then remove the ice from the design?


    sam3d: That seems correct, recharing in IC2 is based on chance:
    0 to 2999 hull heat: 1 in 8 chance of a uranium pulse charging up the isotope.
    3000 to 5999 hull heat: 1 in 4 chance
    6000 to 8999 hull heat: 1 in 2 chance
    9000+ hull heat: All pulses are sucessful.


    An isotope requires 5000 sucessful recharge pulses to be completely charged.


    The planner disguards the randomness and replaces it with averages, thus any charging done in a design with less than 9000 hull heat will vary in-game.


    The new planner keeps closer tabs on the heat / charge levels in the reactor design and I'd guess that the 40% is more accurate and the tests you performed in-game were above the average.


    Edit: If any other breeder user out there have also experienced constantly higher then expected charge levels, let me know.

    I guess I should disable Effective EU and cycles for SUC designs without an accompanying supply


    Edit: Done, Effective EU and Max. cycles are hidden for (non-CA) SUC designs, due to their manual nature.

    Yes, they're both heating/cooling per second. The water outside as well as the reactor's chambers can only remove 33 heat every "reactor tick" (which is also 1 second). That meager amount of cooling can do nothing against the tremendous amount of heat that all those radioactive cells are making.


    This did remind of a change I was meant to do earlier, the generation time now highlights in red if running the reactor for that long would be risky.

    Bah, blasted IHD -> Plating -> Cooling Cell combo ... The IHD endlessly pumps heat into the plating because it can't see the status of the cooling cell, thus it melts during the cooling phase.


    I have tried to make the reactor preempt this event and stop the generation phase earily, but I guess it wasn't enough. For now, it'll warn you of a melted component during cooldown and you'll have to manually scale down the genration time (to about 79% in this design's case) to get an effective EU/t rating.

    - Fully overclocked (1 tick of process time per item) machines, peticularly in an auto sorting and processing system
    - A BC laser assembly table and power hub for BC machines (via a IC to BC power mod/addon and teleport pipes)
    - A cluster of mass fabricators for usable UU Matter stock.
    - An array of terraformers


    There's probably a few more, hehe

    Eep, a bug in the SUC supply code, distributing ice differently to how it'd happen ingame... crazy CASUC (ice) users beware, this bug was hiding the need for a reactor to have enough ice in it before the cycles begins!


    Also added a warning if there are blank slots before any ice/water on the grid.


    bdew: Thanks for reporting that bug, it was kinda bad for CASUC users ;)

    I altered SUC data tracking and how the planner calculates excess heat, hopfully no more minus Mark IIs.


    As for the reason you get slightly different results depending where you place the ice, it's to do with the order in which the reactor interacts with the the items in the grid.


    ---


    On another note, the new timing slider changes have now been moved from the testing url into the 'live' url.

    Fuel that has been augmented by enough dust that it's damage value it's higher than 16384 will not be excepted by generators.


    I took a peek in the code and found out why, in TileentityIronFurnace.getFuelValueFor:


    Code
    if (i == Ic2Items.filledFuelCan.itemID)
    {
        return (short)(itemstack.getItemDamage() * 2);
    }


    If the damage value is higher than 16384 then "itemstack.getItemDamage() * 2" will result in a number higher than a short can handle.

    Okay, the planner should now simulate the full effect of using the Timing Scale slider


    - The timing slider can move from 1 second to the maximum generation time for the current design.
    - The timing slider will reset if the design changes (It was either this, or simulating the reactor twice after every change)
    - The timing slider is saved along with the rest of the options.
    - Arrow keys can be used to fine tune the timing slider.
    - The info displayed while moving the timing slider are estimations, the true calculation will begin once the mouse is no longer dragging it.


    Effective EU/t is calculated in a slightly different way, it shouldn't effect Mark Is and IIs and only be a minor effect for others.


    New info, "Unused Generation Time": This shows how much of the last generation period was left when the uranium depletes. This is used in combonation with the timing slider to work out good generation/cooldown timings for whatever reactor control system you use.


    As the underworkings of the planner have gone through a fairly big change, it's going to sit on the alternate url here for a while, just to be safe.

    I thought so also, but when i hit CTRL+F5 (requests a brand new page a.k.a Hard Refresh) it does nothing.


    EDIT: Just to make sure i just cleared out my cache and no change.


    Hmm, I've looked through "reactorplanner.html" and "launch.jnlp" and there isn't a single reference to "IC2ReactorPlanner.jar", everything points to "ICReactorPlannerV2.jar".


    Generation time is the lesser of three events: Uranium depleted (Full cycle), reactor at 85% max hull heat or a component melts.


    As for the request, I'll look into a way of doing that without resorting to rough estimations.