MJ Transporter Turtle

Edit: I've completly rewrote the program to include enderchests.

Edit2: Setup is much easier now with version 3. I believe turtle.dig() didn't used to auto pick up REC, which was fixed recently. I think I tried to use dig when I first wrote this, and it didn't work, but I might be wrong. Too lazy to check… If this doesn't work for you with and old TE, use version 2, or upgrade TE.

code:
http://pastebin.com/pkB1fNh7

or:

Spoiler

function TryPlace()
if not turtle.suckUp() then
  return false
end
if not turtle.place() then
  turtle.dropUp()
  return false
end
return true
end
function TryBreak()
if not turtle.dig() then
  return false
end
if not turtle.dropDown() then
  return false
end
return true
end

args = {...}
if #args < 1 then
print("Usage: RECCharger in or RECCharger out")
return
end
s = tostring(args[1])
sleep(10)
while true do
if  peripheral.call("right", "get")["Full Energy"] == nil then
  TryPlace()
else  
		 if (s == "in" and peripheral.call("right", "get")["Full Energy"] == true) or (s == "out" and peripheral.call("right", "get")["No Energy"] == true) then
   TryBreak()
  end
end
sleep(5)
end

This is a program I wrote to transport MJ over long distances/dimensions, using Redstone Energy Cells (REC), Gate Reader Engineering Turtles and two pairs of enderchests.

Mod requirements:
- Misc Peripherals
- Thermal Expansion
- Enderchest

The program involves at least 2 Gate Reader Engineering Turtles and 2 pairs of enderchests. You'll probably want at least 2 Redstone Energy Cells, but the system works with only 1. You start the program with a parameter (either "in" or "out"), which tells the turtle if it's working at a REC charging or discharging station respectively. At the charging station, the turtle dismantles any full REC in front of it, and places the REC into an (ender)chest under itself. At the discharging side it does the same with the empty cells. If there is no cell in front of it for any reason (the player can also manually remove cells, it shouldn't break the program), it tries to suck one down from an (ender)chest above, and place it in front.

The setup is really easy. You can make Gate Reader Engineering Turtles by crafting a normal turtle with a Gate Reader, to get a Gate Reader Turtle, then combine that with a Crescent Hammer.

I.) (Ender)Chest above the turtle, containing only REC. The turtles pull from here, so ideally you want empty cells at the recharging side, and full cells at the discharging side, but the program should be able to handle anything as long as there are only REC in those chests. An empty chest is also OK.
II.) (Ender)Chest bellow the turtle, containing only REC. You'll want to place the same colored enderchest here as the one above the turtle on the opposite side.
III.) REC always in front of the turtle. More than one REC next to the turtle may interfere

The turtle doesn't move, so no fuel is necessary.

Protips:
1: Make the turtles run this program on startup. The program shouldn't be able to break…
2: You can manually put in or take out your REC from the enderchests.
3: You can create multiple charging and recharging stations. The only reason I can think of which would cause problems is if an enderchest would get completly filled with RECs, so as long as you watch out for the total number of REC in the whole system, you can expand it as much as you want.


Why is my way better than…

…using only 1 set of enderchest?
The turtle has no good way of telling from a REC in item form if it's full or empty. So if you want to use only a single colored enderchest, you'll either have to do some sorting or at least introducing some constraints into your system. For me this makes things needlessly more complicated just to save on 8 blazerods and 2 enderpearls.

…using a single turtle with a turtle teleporter? (Direwolf20: Season 5 - Episode 24)
No fuel cost on any distance. Simultaneous charging and recharging. Program doesn't break if you quit at the wrong time. Program doesn't break in non-chunkloaded areas (it won't run obviously, unless you're there).

…using Thermal Expansions Tesseract?
Turtles have a 0% energy loss. Tesseracts have 25% by default.


Old version:

Spoiler

code:
http://pastebin.com/mjFcUaR6

or:

Spoiler

function TryPlace()
if not turtle.suckDown() then
  return false
end
if not turtle.place() then
  turtle.dropDown()
  return false
end
return true
end

function TryBreak()
  if not turtle.attack() then
  return false
end
redstone.setOutput("left", true)
sleep(0.3)
redstone.setOutput("left", false)
return true
end

args = {...}
if #args < 1 then
print("Usage: RECCharger in or RECCharger out")
return
end
s = tostring(args[1])
sleep(10)
while true do
if  peripheral.call("right", "get")["Full Energy"] == nil then
  TryPlace()
else
		 if s == "in" and peripheral.call("right", "get")["Full Energy"] == true then
   TryBreak()
  elseif s == "out" and peripheral.call("right", "get")["No Energy"] == true then
   TryBreak()
  end
end
sleep(5)
end

This is a program I wrote to transport MJ over long distances/dimensions, using Redstone Energy Cells (REC), Gate Reader Engineering Turtles and two pairs of enderchests.

There is a slight difficulty doing this, since the turtle can't automaticly pick up REC. Possibly a bug…

Mod requirements:
- Misc Peripherals
- Thermal Expansion
- Enderchest
- Redpower 2 is recommended

The new version is called RECCharger. It involves at least 2 Gate Reader Engineering Turtles, 2 pairs of enderchests and at least 2 Redstone Energy Cells. You start the program with a parameter (either "in" or "out"), which tells the turtle if he's working at the REC charging station, or the discharging station respectively. At the charging station, the turtle always tries to dismantle a full REC in front of him. At the discharging side he does the same with the empty cells. If there is no cell in front of him for any reason (the player can also manually remove cells, it shouldn't break the program), he tries to suck one up from a (ender)chest bellow him, and place it. If there is a cell that is neither full, nor empty (or empty at a charge station, or full at discharge station), the turtle waits for 5 seconds, then checks again.

The setup is really easy. You can make Gate Reader Engineering Turtles by crafting a normal turtle with a Gate Reader, to get a Gate Reader Turtle, then combine that with a Crescent Hammer.

I.) (Ender)Chest under the turtle, containing only REC. Ideally you want only empty cells at the recharging side, and full cells at the discharging side, but the program should be able to handle anything as long as there are only REC in those chests. An empty chest is also OK.
II.) REC always in front of the turtle. More than one REC next to the turtle may interfere
III.) The player is responsible for the (automatic) transportation of the dismantled REC from one location, to the chest under the turtle at the other location. The turtle help the player doing this by emitting a short redstone pulse from his left side, when he dismantles a REC.

Here is a very simple Charging and Recharging station:





There is a Redpower2 Transposer right under the REC, and jacketed wire connecting to it from the left side of the turtle. The redstone pulse activates the transposer right as the REC drops as an item. This makes the transposer collect the REC item 100% of the time, and puts it right into an enderchest under it. This enderchest is connected to the enderchest under the turtle at the other station.


The turtle doesn't move, so no fuel is necessary.


Protips:
1: Make the turtles run this program on startup. There is a 10 second delay after starting the program to avoid item (REC) loss in case the turtle dismantles a REC while your game still loading.
2: You can manually put in or take out your REC from the enderchests.
3: You can create multiple charging and recharging stations. The only reason I can think of which would cause problems is if an enderchest would get completly filled with RECs, so as long as you watch out for the total number of REC in the whole system, you can expand it as much as you want.

Old old version:

Spoiler

http://pastebin.com/kYzwB3T5

Spoiler

function SwitchREC()
if not turtle.attack() then
print "Couldn't dismantle the Redstone Energy Cell"
return false
end
sleep(1)
if not turtle.place() then
print "Couldn't place a Redstone Energy Cell"
return false
end
tries = 0
while not turtle.suckDown() do
sleep(1)
tries = tries + 1
if tries>10 then
print "Couldn't get the Redstone Energy Cell from the inventory under me"
return false
end
end
return true
end

function CheckRefuel()
if turtle.getFuelLevel() < 1000 then
print "Refueling"
turtle.select(2)
if not turtle.suckUp() then
print "Couldn't find any (fuel)items in the inventory above me"
return false
end
if not turtle.refuel() then
print "Couldn't use the items I got from the inventory above me to refuel"
return false
end
turtle.select(1)
end
return true
end

function Tele()
if not peripheral.call("back", "teleport") then
print "Teleporting failed"
return false
end
sleep(1)
return true
end

function WaitUntilFull()
print "Waiting for a full Redstone Energy Cell"
while not peripheral.call("right", "get")["Full Energy"] do
sleep(5)
end
end

function WaitUntilEmpty()
print "Waiting for an empty Redstone Energy Cell"
while not peripheral.call("right", "get")["No Energy"] do
sleep(5)
end
end

while true do
WaitUntilFull()
if not SwitchREC() then
break
end
if not CheckRefuel() then
break
end
if not Tele() then
break
end
WaitUntilEmpty()
if not SwitchREC() then
break
end
if not Tele() then
break
end
end

This is a program I wrote to transport MJ over long distances/dimensions, using Redstone Energy Cells (REC), a Gate Reader Engineering Turtle and a pair of Turtle Teleporters.

There is a slight difficulty doing this, since the turtle can't automaticly pick up REC. Possibly a bug…


Mod requirements:
- Misc Peripherals
- Thermal Expansion
- Redpower 2 is recommended

Turtle needs to be a Gate Reader Engineering Turtle. You can make those by crafting a normal turtle with a Gate Reader, to get a Gate Reader Turtle, then combine that with a Crescent Hammer.

Setup in both location needs to be the following:
1: Turtle teleporters behind the turtle, facing the turtle. Don't forget to link the teleporters both way with a redstone repeater in hand.
2: Redstone Energy Cells on the opposite side of the turte. Turtle is always facing the REC.
3: Empty Chests under the turtle.
4: The player is responsible for making the dropped REC get into this chest within 10 seconds. The easiest way of doing this is to have a Redpower Transposer directly under the REC, facing upwards. Then connect the undersides of the Transposer and the Chest with Pneumatic Tube. Provided that you enclose the whole system, the dropped REC item can't bounce anywhere except onto the Transposer, so you don't need to provide a redstone pulse.

5: Only at the charging side, there needs to be a Chest above the turtle containing only fuel.
6: Turtle starts at the charging side, having an empty REC in its inventory slot 1.


Details:
The turtle waits for a Redstone Energy Cell (REC) to charge fully at location A, while also having an empty one in its inventry (slot 1). When the REC is full, it breaks it, and places an empty one in its place. Then it waits for max 10 seconds for the dropped REC to appear in a chest bellow. It sucks it up, then teleports to location B. At location B, it waits until the 3rd REC (that's already placed) runs empty, then it replaces it with the one from its inventory and teleports back. And the loop starts over again.

This method minimizes the number of teleport uses by always waiting for a cell to completly fill/empty. Of course you need to have a 3rd REC to do this.

Refueling:
Only at the location A (where the REC is charging), from a chest above it. Only have fuel in that chest. It refuels with a whole stack once it gets bellow 5000 fuel. The turtle uses twice the distance between the teleporters as fuel. Depending on how long the distance is, this can be a LOT. 1000 block distance would mean 4000 fuel usage on one round (transporting 600.000 MJ). 4000 fuel is 50 coal, which would be 80.000 MJ in a sterling engine (if I calculate correctly), so decide it yourself if this is worth it or not. I'm planning to make a second edition of this, transporting multiple REC in one go, thus increasing efficiency.


Edit:
I just realised that you don't actually need to teleport the turtle! You could have 2 turtles, 1 in each end, just for dismantling and placing the Energy Cells. Then you could use an enderchest to transport them… Why don't I ever think of the cheap and easy way first???

Edit:
I just realised that you don't actually need to teleport the turtle! You could have 2 turtles, 1 in each end, just for dismantling and placing the Energy Cells. Then you could use an enderchest to transport them… Why don't I ever think of the cheap and easy way first???

HAHAH :P/>

Well, this is pretty nice man. Usefull, I suggest you also post the 1 in each end turtle script :)/>

Updated. The new version is much better… and simpler. I guess this is what the enderchests do with everything.

what you could do is to save on enderchests is put a relay under the transposer with the output towards the enderchest under the turtle, and use a tube to connect the output of the relay to the chest.
also I saw Direwolf20 once code a program like this, I think it was in episode 74 or 75 on his 3rd SMP season, maybe you can check his code and see if that works or also buggs

Yusunoha, on 26 January 2013 - 01:47 AM said:

what you could do is to save on enderchests is put a relay under the transposer with the output towards the enderchest under the turtle, and use a tube to connect the output of the relay to the chest.
also I saw Direwolf20 once code a program like this, I think it was in episode 74 or 75 on his 3rd SMP season, maybe you can check his code and see if that works or also buggs

I thought about using only 1 pair of enderchests, but I personally like 2 pairs better. The program should work either way, as long as there is an inventory under the turtle with the proper cells. The setup on the pictures is only one option. The reason I like it is because its small and compact. Even if you only have the required mods installed, once you have killed the enderdragon, and have a blaze spawner setup, the enderchest recepies are not that expensive. And if you have mods like soul shards, they are outright cheap.

Actually what you're saying might not work. If you want only 1 pair of enderchests, the enderchests themselves can't be under the turtles. That's because the turtles can't determine about a cell in item form if it's full or empty. So if both locations dump the cells into the same enderchest, the turtles will need help in sorting out the full and the empty cells. You can do it with tier1 redpower2 machines, but it won't be as compact as the setup in my pictures.

I recently set up something similar in my world, but much simplfied – I had one enderchest on either side of the turtle and the cell in front. It's been working fairly reliably for me, and the turtle hasn't had any issues picking up the cells.

The main trick to get it working reliably was to use this code for the pickup:

turtle.attack()
if not turtle.suck() then
  sleep(1)
  if not turtle.suck() then
    print("HELP ME!  I've lost the cell!")
    error()
  end
end

I've yet to see the error case happen. (It did occasionally fail when I only had the single suck in there though.) Not sure if you actually need two sucks or if it's just the delay that makes it work properly, but I'm sticking with this for now.

I actually tried sucking dropped items, but decided not to do that because it didn't seemed like it worked 100%. It looks like it works for you with the proper setup, but I have my concerns. What if the first suck doesn't work, and during that second of delay the item bounces away on a conduit or something?

Also… if you have your enderchests on the left and right that means that your turtle needs to turn, right? I guess that's not a huge problem in SMP with chunkloading, but in SSP what if you log out just as the turtle turns? An easy fix would be putting the chests above/below the turtle.

I use a slightly different setup, which only requires 1 set of enderchests. On the side of the 'master' turtle (i.e. the charging station) I have a filter connected to the enderchest. This has an empty REC in it which means it will pull out any REC which is not charged 100%. It dumps these into the master turtle for placement.

Since I didn't want to have an extra REC always in my slave turtle to use for comparison, I have it sit idle for a little bit longer than my timer runs on the filter, to make sure there are no empty RECs in the chest anymore when it goes to suck() the next full one, since otherwise it would likely pick up the one again that it just dropped in there. With only one slave this is fine, but with multiple slaves you would run the risk of it picking up an empty one that one of the other ones dropped in. This is not a huge deal as it'll just detect that it's empty and go swap it again. Also setting the timer to pulse more often or the slaves to pause for a bit longer would cut down on this risk considerably.

I don't mind the slightly bigger setup for the charging station, what with all the engines and everything there, another block or two won't matter, but it means that moving the quarry involves breaking one less enderchest. Of course if you want to be more compact, you could use the turtle to send the redstone timer signal to the filter.

I do have them turning at the moment just because I didn't want to rebuild my charging station and hadn't thought about what would happen if they are turning when I log off. I mean it's pretty unlikely to happen since I run my quarry only at 20mj/tick so it only swaps about once every 25 minutes, but still. I guess you could write the current state to a file and run a check off of that, so it remembers if it was mid-turn. But yeah putting the chest above or below would be a better (if less challenging ;)/> ) option.

I'd like to improve on the whole thing by using inventory turtles and sharing an enderchest in that way (i.e. first 5 slots for full ones, last 5 slots for empty ones) but the inventory module is too buggy for that right now

Just saw Direwolf20's new video, in which he builds a similar system to my first version (with the teleporters). My way is generally better, but I learned that you can now use turtle.dig() properly on engi turtles, so I updated my version.

ok im a noob to CC how do i run this program? ive got an engineer turtle and ive put the Program into my programs folder and i called it Celltrans

this is how far i got

>Celltrans
Usage: RECCharger in or RECCharger out

after this my face melted

Can someone help?

plz keep simple.. im retarded xD

Damoklesz, on 28 January 2013 - 05:03 PM said:

I actually tried sucking dropped items, but decided not to do that because it didn't seemed like it worked 100%. It looks like it works for you with the proper setup, but I have my concerns. What if the first suck doesn't work, and during that second of delay the item bounces away on a conduit or something?

It's a fair concern, but I haven't seen it happen yet. I do have the charging conduit on the side, and all other sides (except the top and the turtle) are solid blocks. Possibly that helps. It might be even better to have the charging conduit on top but the layout of the other stuff in that room prevented me from trying that.

Damoklesz, on 28 January 2013 - 05:03 PM said:

Also… if you have your enderchests on the left and right that means that your turtle needs to turn, right? I guess that's not a huge problem in SMP with chunkloading, but in SSP what if you log out just as the turtle turns? An easy fix would be putting the chests above/below the turtle.

Yes, it has to turn, but it's really fast. I have it set to wait 20-30 seconds between "polls" of the chest to reduce lag and I've never yet managed to catch it in the wrong spot. But you're right, it's technically possible. I'm not too worried about that as I'm usually nearby the charging station so I can see if something goes wrong, or if items stop coming in from my quarry (which is the only thing discharging at the moment). Putting the chests above and below probably would have been a better design though, but wouldn't have looked as good :)/>

Bobnick171, on 05 February 2013 - 10:10 AM said:

ok im a noob to CC how do i run this program? ive got an engineer turtle and ive put the Program into my programs folder and i called it Celltrans

this is how far i got

>Celltrans
Usage: RECCharger in or RECCharger out

after this my face melted

Can someone help?

plz keep simple.. im retarded xD

First of all, you'll need a Gate Reader Engineering Turtles, not just a normal Engineering Turtles. Check out the MiscPeripherals page for the details.

If you choose Celltrans as a filename, then you start the program by typing either "Celltrans in" (without quotes) if you want the turtle to remove the full redstone energy cells (the turte is at the charging station).
The same way you start the program by typing "Celltrans out" if you want the turtle to remove the empty energy sells (at you quarry, or wherever you use up the energy).

uecasm, on 05 February 2013 - 08:35 PM said:

Damoklesz, on 28 January 2013 - 05:03 PM said:

I actually tried sucking dropped items, but decided not to do that because it didn't seemed like it worked 100%. It looks like it works for you with the proper setup, but I have my concerns. What if the first suck doesn't work, and during that second of delay the item bounces away on a conduit or something?

It's a fair concern, but I haven't seen it happen yet. I do have the charging conduit on the side, and all other sides (except the top and the turtle) are solid blocks. Possibly that helps. It might be even better to have the charging conduit on top but the layout of the other stuff in that room prevented me from trying that.

This is pretty much a moot point now, since the dig() function now picks up the REC properly.

My goal with this program has always been to be universal, expandable, and to have the minimal setup required. So while I understand that your way of doing things works for you, I tried to explain why I wasn't doing that.

Damoklesz, on 05 February 2013 - 09:05 PM said:

uecasm, on 05 February 2013 - 08:35 PM said:

Damoklesz, on 28 January 2013 - 05:03 PM said:

I actually tried sucking dropped items, but decided not to do that because it didn't seemed like it worked 100%. It looks like it works for you with the proper setup, but I have my concerns. What if the first suck doesn't work, and during that second of delay the item bounces away on a conduit or something?

It's a fair concern, but I haven't seen it happen yet. I do have the charging conduit on the side, and all other sides (except the top and the turtle) are solid blocks. Possibly that helps. It might be even better to have the charging conduit on top but the layout of the other stuff in that room prevented me from trying that.

This is pretty much a moot point now, since the dig() function now picks up the REC properly.

My goal with this program has always been to be universal, expandable, and to have the minimal setup required. So while I understand that your way of doing things works for you, I tried to explain why I wasn't doing that.

More to the point, with the introduction of Tesseracts you could argue that the whole setup is kind of moot now since a 25% power loss would require less materials to overcome than building a setup with turtles swapping RECs. But it's more fun to build something that automates, of course.

Having said that, I think Dire's solution with the teleport pads (while cool in that it uses more different bits) is unusually inelegant (since he usually comes up with pretty smart solutions to problems). Because he only uses 1 REC, the quarry is basically switched off half the time while the engines recharge the REC. Not to mention the fact that it doesn't have any kind of session persistance so if he logs off at the wrong moment, the turtle gets lost.

Anyway I've switched mine over to use an energy tesseract now. Combined with an item tesseract it means that I only have to break a total of 5 blocks to move my quarry (the quarry, the two tesseracts and two energy conduits, which you wouldn't even technically need). Plus, the item tesseract means that I don't have problems with the sorting machine getting overworked anymore, since it can now sort in-line and can run at whatever speed the quarry poops out the items at. I actually use a filter to filter out the items for recycling in-line (since that's about 90% of the blocks) and then have the sorting machine pull the remainder from an enderchest so I can still manually drop items into that chest (directly or from other chests/bags) for auto-sorting. Only thing I want is an elegant system for switching off the power to the quarry when either the line gets blocked for some reason (I have that already) or the quarry is finished.

Gili710, on 06 February 2013 - 10:06 PM said:

Damoklesz, on 05 February 2013 - 09:05 PM said:

uecasm, on 05 February 2013 - 08:35 PM said:

Damoklesz, on 28 January 2013 - 05:03 PM said:

I actually tried sucking dropped items, but decided not to do that because it didn't seemed like it worked 100%. It looks like it works for you with the proper setup, but I have my concerns. What if the first suck doesn't work, and during that second of delay the item bounces away on a conduit or something?

It's a fair concern, but I haven't seen it happen yet. I do have the charging conduit on the side, and all other sides (except the top and the turtle) are solid blocks. Possibly that helps. It might be even better to have the charging conduit on top but the layout of the other stuff in that room prevented me from trying that.

This is pretty much a moot point now, since the dig() function now picks up the REC properly.

My goal with this program has always been to be universal, expandable, and to have the minimal setup required. So while I understand that your way of doing things works for you, I tried to explain why I wasn't doing that.

More to the point, with the introduction of Tesseracts you could argue that the whole setup is kind of moot now since a 25% power loss would require less materials to overcome than building a setup with turtles swapping RECs. But it's more fun to build something that automates, of course.

Having said that, I think Dire's solution with the teleport pads (while cool in that it uses more different bits) is unusually inelegant (since he usually comes up with pretty smart solutions to problems). Because he only uses 1 REC, the quarry is basically switched off half the time while the engines recharge the REC. Not to mention the fact that it doesn't have any kind of session persistance so if he logs off at the wrong moment, the turtle gets lost.

Anyway I've switched mine over to use an energy tesseract now. Combined with an item tesseract it means that I only have to break a total of 5 blocks to move my quarry (the quarry, the two tesseracts and two energy conduits, which you wouldn't even technically need). Plus, the item tesseract means that I don't have problems with the sorting machine getting overworked anymore, since it can now sort in-line and can run at whatever speed the quarry poops out the items at. I actually use a filter to filter out the items for recycling in-line (since that's about 90% of the blocks) and then have the sorting machine pull the remainder from an enderchest so I can still manually drop items into that chest (directly or from other chests/bags) for auto-sorting. Only thing I want is an elegant system for switching off the power to the quarry when either the line gets blocked for some reason (I have that already) or the quarry is finished.

Since the turtle setup is now only 1 GRE Turtle, 2 enderchests and nothing else, the Tesseracts are not really cheaper. Unless you're in a situation where you can't get Blaze Rods, but you have plenty of Ender Pearls and diamonds. Also the 25% is substantial enough to at least consider turtles as an option. As far as Tesseracts go, imo the Liquid Tesseracts are a great addition, and the Item ones also have their uses (like you said).

Also the conduits loose 5% energy regardless of the distance (this was news to me too, 3 weeks ago). So you might actually loose ~30%, and should get rid of those conduits asap. Unless I'm wrong and the conduit loss is somehow ignored due to the Tesseract loss.

As far as I know if a quarry is finished it doesn't use any more energy, so what exactly do you want to turn off then?

Damoklesz, on 08 February 2013 - 12:20 AM said:

As far as I know if a quarry is finished it doesn't use any more energy, so what exactly do you want to turn off then?

The engines that are creating the power, since they won't stop simply because the quarry stops. Of course I could just use a buffer REC with a gate on it which switches off the engines when the REC is full. That makes sense since I have a bunch of RECs anyway.

Didn't know about conduits losing 5%, will have to test a bit with that with the new MJ meter.

On a side note regarding your 'no diamond cost' statement in your OP, the Energy Storage Frame for the REC still requires a diamond and you still need at least 2 RECs for this to work properly, so you're not saving any diamonds over using Tesseracts. I actually think that it's a little strange that the tesseract frame is basically cheaper than the Energy Storage Frame, I don't know why he didn't use the new Invar ingots for the recipe instead. That would make them feel like a bit more of a mid-game rather than early game item. Of course the enderpearls might be prohibitive, but if you have EE those are not hard to get.

I still think the energy transport system using turtles is cooler, but I just had to try out the new toys King Lemming gave us :)/>

Gili710, on 08 February 2013 - 01:13 AM said:

Damoklesz, on 08 February 2013 - 12:20 AM said:

As far as I know if a quarry is finished it doesn't use any more energy, so what exactly do you want to turn off then?

The engines that are creating the power, since they won't stop simply because the quarry stops. Of course I could just use a buffer REC with a gate on it which switches off the engines when the REC is full. That makes sense since I have a bunch of RECs anyway.

Didn't know about conduits losing 5%, will have to test a bit with that with the new MJ meter.

On a side note regarding your 'no diamond cost' statement in your OP, the Energy Storage Frame for the REC still requires a diamond and you still need at least 2 RECs for this to work properly, so you're not saving any diamonds over using Tesseracts. I actually think that it's a little strange that the tesseract frame is basically cheaper than the Energy Storage Frame, I don't know why he didn't use the new Invar ingots for the recipe instead. That would make them feel like a bit more of a mid-game rather than early game item. Of course the enderpearls might be prohibitive, but if you have EE those are not hard to get.

I still think the energy transport system using turtles is cooler, but I just had to try out the new toys King Lemming gave us :)/>

You're right about the diamonds. For some reason, I don't know why, I haven't though of the actual REC costs…