Posts by SpeedDaemon

Quote from Altaree

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

Quote from Cadde

The code is in mod_ic2.java and the function is updateWind() at line 1381.

Is there a repo somewhere that can be checked out, or do we have to set up the whole environment to decompile it?

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.

Quote from Cadde

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

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 more batboxen I added to the chain, the more the output of the "input" batbox went down... So with two, it might have been fine - I'll have to play with it some more.

Quote from Cadde

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.

Quote from Cadde

Yes, cable junction splits packets. They don't merge them but they do split them.
Say you wanted to only supply 1 EU/t to a machine (like Power Crystals BC<->IC2 conversion mod's energy link) you can place a bat box, 2 cables from the output side and then 4 bat boxes on the outside of this cable feeding the split power back to the first bat box. Place one extra cable after the splitter and then the machine.

First split: 32 / 5 = 6 EU
Second split: 6 / 5 = 1 EU

The remaining "missing" EU's (32 / 5 = 6.4 and 6 / 5 = 1.2) will go into ONE of the splitting bat boxes. The reason it does this is because machines CLOSER to the split that happens get the extra EU. Hence why you add one extra cable after the splitter to make the target machine be the farthest from the second split.

Obviously you don't have to use bat boxes. You can probably use LV transformers (I haven't tested those though) or any other power hungry machines. Just remember that the Larger packet after a split gets sent to the CLOSEST receiver.
You can also build a straight line. It's easier to see what is going on by doing so.

Here is a demonstration video: http://www.youtube.com/watch?v=dkHIHtHnPjk

Display More

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...

Quote from HeadHunter67

But if you do that, output will suffer significantly, won't it? Or has that changed as well?

Yeah... seems to me all the extra wind gens you'd have to build to make up the output could just be made later (and rarely) on demand to replace broken ones.

Quote from MJEvans

The number you are proposing conflicts with the existing namespace.

Currently: MK(eff based number)-(Consecutive cycles, rounded down (except 0 means infinite))-random letters.

I suggest instead just rattling off a list of tags in a pre-defined order:

E = Efficiency
P = Power
B = Burst power (assumed to be power if not listed)
R = Ratio (percent redstone can be off if gated)
W = Water buckets per second
C = Ice cubes per second
S = Shutdown time required between runs if running constantly

In that order; with R, W, C and S being optional and assumed to be 1, 0, 0, 0 respectively if not defined.

For example, a hypothetical redstone gated reactor:
E3.833,P28.75,B460,R0.63

Alternately a tighter revision of the 'MK' system could be devised.

RA = Reactor Air-Cooled
RW = Reactor Water-Cooled
RX = Reactor 'externally' cooled (RP2/BC2/other)
R*C = Reactor Controlled/Clocked (Externally limited by a clock)
Breeders would also be possible but would have designations like BAN BAB and BAP (Negative, Balanced, Positive thermal co-efficient)

Then a - and a letter representing uranium efficiency class: A 4.2+, B 4+, C 3.75+, D 3.25+, E 2.5+, F 2+; else Y.

The above reactor would thus be RWC-C

Display More

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)

Quote from HeadHunter67

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.

Quote from Cadde

Sorry for taking so long to reply but i was reading the source on Wind Generators and checked a lot of other threads that had replies to them before this one.

What i intend to do with an Empty/Full detector is:

• When empty, Trigger a bunch of feeders to my generators to fill them with charcoal.
• When full, trigger a bunch of unloaders to unload my generators.

And anything in between OFC. Like an automated system to feed just as much resources to my generators as my energy storage can handle.
I also have plans on making my base lit by a bunch of luminators. I want the luminators to stop receiving power when my energy storage reaches low levels so that (roughly) the luminators will turn off at the same time as the energy storage is depleted or at least stop consuming power for all light systems (only leaving emergency lights on) when power level is low.

Obviously, the suggested consumption meter is a neat extra!
Thanks for the feedback/advice, it helped me get a better understanding of what i need to do.

Display More

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...

Quote from Corbald

Indeed!

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.

Quote from Corbald

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.

Quote from FnordMan

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 (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...

Quote from Cadde

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)

Quote from FnordMan

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.