Posts by Root Infinity

  • Bug : Wind eventually becomes fixed forever at a high or low value

    Quote from Cadde

    Yes, but MCP is easier for those who don't have JD-gui etc. It decompiles everything and it makes it easier to follow the source in eclipse since the eclipse workspace that comes with MCP is set up and ready to go.
    Plus, if you fix the decompile errors you can make changes and test them easily. Can't say the same about manually decompiling everything.
    Hence why i suggested MCP.

    EDIT: Oh and MCP de-obfuscates for you. So the few vanilla MC calls made from IC have readable names instead of aa.bb.xyz()

    That is the one annoying thing about JD-GUI.... It is generally fairly easy to figure out what they are though.

  • Help me make a list of all cobblestone derivatives

    Here it is!

    Attachment has specifics, but here is the list (pulled from craftguide in-game, so I hope it is accurate :/ )

    Display Spoiler

    Cobblestone Transport Pipe
    Stone Transport Pipe
    Glass Pane
    Stone Wafer
    Cobblestone
    Cobblestone Slab
    Stone Slab
    Sand
    Smoothstone
    Glass
    Stone Stairs
    Button
    Stone Pressure Plate
    Sandstone
    Sandstone Slab
    Stone Brick Slab
    Stone Brick Stairs
    Stone Bricks
    Furnace
    Tank
    Detector (furnace)
    Detector (player)
    Detector (any)
    Detector (empty)

  • Suggestion: Worm-Hole Integrated Personal Safe

    Quote from Lasergut

    So a personal safe useable by all, but linked to the player so everyone who opens it sees only their own inventory, with many access points? I could see many many uses for that on SMP and SSP. Especially when it comes to trading. If you have everyone who can have an inventory they can all access from 1 block it makes it easy to trade without the need to worry about carrying a mountain of rare materials half way across the world.

    What about this?

    Two separate blocks - a storage block and an access block.
    Set it up so that the access block can access linked storage blocks (perhaps with pages/tabs?), and the storage block can access anything with inventories beside it, including the personal chests of (only) the person accessing it.

    It would use a certain amount of EU per stack to move items (although I do not know if that should be at the storage block's end or the access block's end...)

  • Grandiose Base Plans - comments/ideas welcome :)

    Quote from kkabcd

    Would you preffer to use Redpwer Pipes or Buildcraft Pipes


    Personally I prefer buildcraft pipes for long distance runs (Buildcraft pipes can be made from cobble, whereas redpower requires brass.)
    The autorouting for redpower pipes is useful though! (Although just wait - this looks very promising!)

    As for my 2:Industrial Credit:s worth:

    • Neat design.
    • I personally would put the manual input before the ore branch.
    • For scrap - don't forget about scaffolding and/or glass panes!

  • Nether Power Generation

    Does anyone have any suggestions on how to make a long-term (20M EU minimum) unattended power source in the nether capable of outputting at least 50EU/t?
    Solar panels are not possible, as are water mills. Generators are also not really feasible (1000 charcoal?). This leaves windmills, geothermal generators, or nuclear reactors. I am using redpower2 and buildcraft3. So does anyone have any ideas on designs? (I am beside a giant lava pool, in case that gives you any ideas).

    (Note that nuclear reactors in the nether cannot use water!)

  • Was...was it worth it?

    So it is this design (Mark I-O EC), give or take?

    It is a nice design, isn't it... (I've seen it before.)

    (If you need more EU/t with 0 chambers you could go to this one (Mark II-4 ED), but as its efficiency is abysmal, I don't recommend it - it is probably best to save up for more reactor chambers.)

  • Magnetizer idea

    Currently magnetizers draw a flat 2EU/"s" no matter where you are on the pole. I have an idea that would make it a little more realistic:

    • Make magnetizers draw anywhere from 1-32 eu/"s", capped both ways.
    • Make them give the player a boost of a certain amount of acceleration per inverse meter from the magnetizer per EU/"s".
    • Have this include gravity - so if the boost is small you will slide up albeit slowly.
    • Have this be per player/(NPC later?) - so if you have two players you either consume twice the current (if possible) or (more likely) have both players go up more slowly.
    • Have magnetizers be able to magnetize fences beside them (already suggested I believe)
    • Have the accelerations stack for multiple magnetizers (again possibly capped) - but each one must still be powered separately!
    • Have acceleration possibly be capped for sanity reasons.
    • This could mean that if you don't have enough power or you have too many players on the pole you may stop or even start slowly descending!

    This would avoid the arbitrary limit of 20 blocks while still making it expensive to create very high elevators...

  • Reactor Calculator App Questions

    Two questions and two suggestions:

    Can you build in support for command-line arguments? Specifically it would be nice to be able to call "Java -jar Sim.jar -info somereactor.sav" or somesuch and have it not start up the GUI at all, but just print out the info and exit...

    The other thing is: what is the format of your save files?

    Also, for the reactor info, you could build a "fast" switch in. Basicially it would run the sim for one step, and the extrapolate from there. It would work only if the reactor doesn't have water, lava, or ice (as those are the only things where their temperature contribution is temperature-dependent), and doesn't break components during operation. Basically you'd take the maximum increase in heat of any component (including the reactor itself), and extrapolate from there.

    Finally, could you color-code the background of a) the cells and b) the reactor area, toggable from more red == higher heat to red = heat excess and blue = heat deficit? That would be useful for optimising reactors...

    I'm considering building a reactor brute-forcer/random reactor generator (with some simple optimisations) - I have the logic flow planned but not the actual program written, but I won't be able to unless this happens (and the sim comes out:P)

  • Theoretical Reactor Design(s)

    Quote from Alblaka

    Afaik the maximum would be 4? Diagonal adjacent doesn't count.

    Yes - but I added the heat speed-up factor and forgot to explicitly state it... Normally it takes (~)40k pulses to replenish uranium - 3000+ heat it takes ~20k, 6000+ heat it takes ~10k, and 9000+ it takes ~5k. The maximum is one with four neighbours at 9000+ heat, or 4 neighbours * (10k ticks in a cell / 5k ticks to replenish a cell) - 1 original cell = 4*2 - 1 = 7

    Quote from Viktor_Berg

    Just a hint:

    Insert 8 plates into the Reactor, bam, it can tolerate 18000 heat.

    You can run it hotter than 9000, it just won't speed up the process of making more uranium currently, so there is no point. That's been clarified in my original post.

  • Theoretical Reactor Design(s)

    I like working on theoretically "optimum" designs. This is the one that I have taken the time to design so far (warning: untested!).

    Mark 1-O EE BEA* Perfect-Breeder "Sirus"


    I was looking at the optimum way to breed Uranium with as little Uranium as possible for input. This was the result. Using only one (1!) Uranium, it breeds four Uranium from it. It can be tweaked to cool one more per cycle (negative breeder - add an extra cooler in the blank spot) or down as far as you'd like (positive breeder - just randomly remove coolers). It must be heated to at least 3000 heat to break even, 6000 heat is optimum however as it cycles through all four in a cycle - if you want to micromanage run it at 9000+ and change them halfway through. Unfortunately it has the worst possible efficiency rating, so it is not really useful in the real world.


    To start, put an additional uranium call in the blank space, and/or remove one or more of the dispensers. It must be submerged fully in water to operate however!


    Quote from Calculations


    All heat gain goes directly to the reactor hull, so that's all good - no overloading components here! Every heat dispenser is connected to at max four cooling cells, and every cell is connected to at least one dispenser, so it can distribute heat properly. This means that it is a simple heat gain/heat loss equation.

    heat loss = Reactor Loss + Chamber Loss * # Chambers + # Water Blocks + # Cooling Cells = 1 + 2*6 + 20 + 21 = 54
    heat gain = Uranium Gain * # Pulses + Depleted Gain = 10*5 + 4 = 54

    Can someone double-check my calculations on this?

    I additionally propose a new classification: Breeder efficiency - how many NET uranium (out - in) a reactor produces on average from one piece input at 9000+ degrees. Note that the values as they stand currently correspond to <1, >=1, >=2, >=3, and 4 adjacent isotopes per uranium, respectively. Unfortunately the code does not increase chances beyond 9000 heat currently, so there is no point in making uber-hot reactors.

    BEE: <1
    BED: 1 - <3
    BEC: 3 - <5
    BEB: 5 - <7
    BEA: 7 (thoeretical maximum: Uranium surrounded by 4 depleted Uranium: 1 in / cycle -> (4 neighbors) * (2 out / neighbor/ cycle) = 8 - 1 uranium / cycle = 7 uranium / cycle)