Posts by SpeedDaemon

    interesting layout. I use teleport pipes and diamond pipe to create something similar. The center of my system is a backbone looking construct of pipes: teleport in -> gold -> diamond -> 2x stone -> diamond ->2x stone -> diamond -> 2x stone - diamond -> teleport out to mass storage/default chest. Off of each diamond pipe can be up to 4 teleport pipes going to different machine rooms. Machine rooms have 2 sets of pipes. The input teleport->gold->N x insertion -> teleport to mass storage for overflow. Then there is a output line that redirects back to the start of the backbone. Since everything goes through that main backbone line it makes a good way to monitor how mining is doing.

    I think I need to do some screen shots.

    I only like to use the TP pipes for long distance stuff (where you HAVE to use them due to the way the game works). Feels too much like cheating (IMO) otherwise. :)

    The main limitation that I see with doing it the way you are is that a certain item is always handled the same way, whereas with the sorting machines, you can handle the same item differently depending on where it's coming from. In my case, cobble overflowing from storage gets sent to a factory, and cobble coming out of there goes to be macerated (through the same tubes). Plus with the manual input you can send the same item to more than one place - for example, cobble needs to be able to end up in a macerator or a furnace.

    Granted, none of this is possible to implement until IC is updated to MC1.0, so what you've got is probably the best you can do right now :)

    Going through a Nether portal causes the quantum suit to go into some kind of hyper-mode. Sprint+jump will catapult you at ludicrous speed, and hitting anything in that sate will send you into the stratosphere (causing disconnection for hacking or flying). Even without sprinting, jumping while moving seems to be very twitchy. Just sprinting, or just jumping (without holding a movement key) seem to be ok.

    Disconnecting/reconnecting will fix it. It appears to be the act of using the portal that messes things up, not simply being in the Nether, as the problem exists in either world, and is solved in either world by relogging.

    Possibly separate issue(s):
    In the nether, q-boots will jump high, but don't work to prevent fall damage.
    In the nether with the q-helmet, my hunger bar drops to about 40%, then fills back up every few seconds while sprinting.

    I've only tested this in SMP so far, and has persisted from 1.23-1.337b...

    I've reworked my item handling plans in light of the new Redpower sorting machines in pr4. I think it really shows the power of the pr4 tubes (would have taken like 5x as much BC piping to do this).

    The main new feature is the "item bus." The only way into that section of tubing is via sorting machines, and the only way out is through colored tubes. That means basically that you only need one main tube to connect everything together. Instead of having one chest, and a dedicated pipe to send stuff to the macerators (and another for each additional set of machinery), you can just configure the sorting machine to tag the item with the macerator's color, and send it off. The product can even return over the same tube! Even better the stuff coming out of the machines can be sent to multiple destinations without having to build more dedicated piping.

    The callouts on the sorting machines show what color it's using to tag what.

    Ah i see. AFAIK making Energynet aware of the source of the power sent is not possible without a major rework. What if you could place 2 RE batteries, 3 glass panes, 2 coal dust and 1 redstone dust together with a solar panel in the crafting grid to make an "Advanced internal battery solar panel" that, during night time, will switch to battery power. During the day that solar panel will emit 0.5 EU/t and send another 0.75 EU/t into it's internal battery to allow it to have a constant 0.5 EU/t during day/night.
    A night is 12,000 ticks long so that means the internal storage only needs 6,000 EU but we give it 18,000 EU storage so the internal battery can be used to survive a full day of rain and another night. It will take 4 sunny days to completely fill the internal battery. Thus, if it rains 1 out of 5 days then you are fine.

    How about keep the recipe the same, but reduce the internal storage to just enough to solve the flicker. Then add an interface that lets you throw an RE battery in it if you want more storage. Would not only give you the choice about storage, but also allow for quickly fully charging one manually. Plus bonus RE battery chargers :P

    I also have capacity available on my server (16GB i5, symmetric 25Mbit)

    Will be mostly unavailable until after Christmas, though. :(

    Heck, I'd be willing to play the wind gen part, just 'cause it sounds like fun. lol

    The missing EU's are possibly stored in the other storage units. They have to reach their output level before they send power. So if you where using MFSU's then up to 512 EU would be "lost" in each and every one of them (simply sitting there on hold)

    As for cable length. If two machines are equally close and the incoming EU is an odd number then one of the two machines will get the extra EU based on which order they are checked. (F.E Up/down/north/west/south/east)

    I was using batboxes, and the six on the splits did have 0-32 EU in them, but that doesn't explain the other 4k that were missing... I arrived at the 20% loss figure by adding up the leftovers in all of the batboxen. I can post a pic of the setup if you want to peer review my experiment. :)

    It also seems to adjust split ratio for cable length even when the EU packet size is evenly divisible by the number of junction output paths. I just haven't figured out how it calculates that.

    This doesn't seem to be working quite as you say. I did some testing, and cable length seems to affect the split ratio (it's not just packet size / num outputs). It also seems to lose a lot of power somewhere.

    First was two MFSU through glass cable to two others. Didn't do much actual testing, just noticed that unless the path to both destinations was exactly the same length, they got uneven amounts of power. Don't have the numbers, but I still haven't managed to come up with math that gets anywhere close.

    Second was a line of batbox splits, same as you're using in your video (but without any transformers, which is why your min EU/t was 4).
    If the splits were even, it should take 5 splits to get from 32 to 1 EU/t., instead:

    Output of the "input" batbox (the one the splitters feed back to): 27 (not 32?? No idea how that's even possible. I don't have a spam macro, but was able to click fast enough to get an "avg over 1 tick" and it was still a solid 27.)
    after 1st split: 22
    2: 17
    3: 12
    4: 8
    5: 5
    6: 2

    Furthermore, out of 20kEU put into the input batbox, only 16kEU was left 5 minutes later after I'd written those numbers down, so the system has 20% loss (using glass cables). I notice that if you take the 5EU missing from the first output, plus one for each odd EU/t split, you get about 20% of 32EU/t...

    For breeders, replace the eff letter with cells burned/cells charged:
    BWXN-5/40 50 (water + suc neutral, uses 5 cells to charge 40, 50EU/t - although the EU rating can probably be assumed to be 10x cells burned for breeders)

    And if it comes across lava, it doesn't stop providing you have a pump.

    Not only that... I added two geo generators to my mining rig (4x diamond drill/OV/pump), and am able to get 20-40% of the power for it from the lava it pumps up. :)

    Well, if you're going to use luminators, you should have a pretty constant flow of EU out of your storage. If you hook up storage in series, you can place a detector cable between two of them near the output end. That cable will shut off its signal when storage upstream of it is empty, which you can use to trigger fuel dispatch. You'll already know exactly how much to send, since it's just storage size/4000 coal (plus a little extra to account for energy used during generation time if you want). Leave enough storage downstream of the detector to handle any delay required to get the generators started. Any solar/wind or other constant EU income will have to be input downstream of the detection point.

    EDIT: this setup will trigger a "not empty" signal right as the generators start, and there's no "full" signal - you'd have to have a system that sends a predetermined amount of fuel without further input...


    For example; In my last world I had a butt-ton of batboxes INSTEAD of MFSUs so that I could check the input/output of each one and display the results on an at-a-glance RP2 light display. Each batbox would trigger the output of the previous one only when it was empty, for cases where my power supply failed or was shut down, and would fill sequentially as well. This gave me a way to have something similar to the meter on the MFSU, except externalized into the world. I was still working the system out when my -supposedly- stable bucket reactor went critical... My fault entirely. I had forgotten something simple that I won't mention here...... ;( The most recent backup doesn't include that setup, unfortunately, and I have moved on to a new world anyway.

    P.S. The OreVeins is turning out to be quite entertaining! I would love to have the resources to set up a server with 'Extreme' mode. Talk about some real industrial commerce that could develop! Must say; it's made the ore scanners MUCH more valuable! I have (as a side note) 'reprogrammed' my scanners so they can be used to discover which ores I'm detecting. By setting the top 3 desired ores (coal/iron/diamond) each to some factor of 10, it's MUCH easier to understand what's beneath your feet. (Coal = 100, Iron = 1,000, Diamond = 10,000.)

    What I'm aiming for is sort of a 3-stage storage. 4 parallel series of MFSUs. The first set of 4 where the input comes in will essentially be kept redstoned all the time, giving me a 40MEU reserve in case I accidentally leave something running that drains everything. The last set will have the setup I described above, letting me know when the middle ones (up to 56, depending on resources) are empty and I can do another 400MEU reactor run. :) The mass fab(s) will tap in between the output MFSUs and the "middle" ones, so it can't touch the reserve, or run in a "low power" situation.

    You can feedback the storage here so you don't need downstream draw. FYI. Suggest having THAT test on a branch of the output, rather than on the primary output.

    True... You could actually put another splitter on that branch connected to the inverted output of both levers, so you're not needlessly feeding back except during the test.

    You could also put the tests on timers, with latches connected to indicators, but I tend to dislike timers running 24/7...

    Being more specific with the use cases would help, too, since you can take advantage of other circumstances in that case to make things easier.

    After some more thought, I still can't think of any way to have an ongoing indication of full/empty state.

    The simplest I can come up with is:
    Connect one lever to a splitter cable on the input wire.
    Connect a second lever to the storage unit itself.
    Connect a detector cable to the output.

    Check if empty:
    Turn on lever one - if detector cable is off, it's empty.

    Check if full:
    Turn on lever two - if detector cable remains on, it's full.

    Something downstream has to actually be accepting power during the tests.

    Technically the fastest way is by gravity into a pool of water. From that height it'll need to be 2 deep and probably 3x3 so you won't miss it.

    Or just have quantum boots... I've had the q-suit nether portal glitch send me way up above the top of the map, and still easily survive the fall :P (if I don't get kicked for "hacking"...)

    Storage full I don't think is that hard, although it still takes extra wiring. Just use a wind or water mill (constant EU flow) with a detector on the cable connecting it to your storage. If it's full, no power flows from the power source. Not sure how this would work with <1EU/t, though, and requires that there be no power draw.

    Another option for testing fullness would be to redstone the storage and check for leakage. This could be on a timer, or manual trigger. Since everything has some internal storage, blocking output for a few ticks shouldn't hurt anything.

    If you have several storage units in series, you can detect whether upstream ones are empty, but only if you don't have constant power input. Put detector cables before and after the last storage unit in the series. If there's power flowing through the downstream detector, and not the upstream one, it means all storage upstream of the detector is empty. I plan to use this setup as a low power warning for my power storage room, so I know when it's time to do another reactor burn. If you do have constant input, I guess you could use a splitter cable to interrupt it for a few ticks while this test is performed...

    It's as you say. You cannot split 1 EU packets.
    Add the bat box after the MFSU using a MV and LV transformer.

    Well, now that begs a question I haven't seen answered anywhere... Do cable junctions split packets, evenly distribute whole packets, base it on cable length...?

    Question for the OP: You say they're right next to each other... Is the output face of the batbox touching the mfsu? (you'd probably actually see the power in the batbox jumping around between 0-32 EU if this was the case)

    f9 only shows outlines of chunks that are covered by the chunkloader blocks. not all chunk outlines.

    It's also currently bugged (off by one) in some situations, so if you're placing something within one block of the edge, do your own calculations to verify. :)

    Also, don't forget to force-load your energy storage, or you'll just be powering the Void!

    I'm working on a system of block breaker/deployer loops that will let me place and remove those loader blocks quickly throughout my base.