phazeonphoenix

Ouch on that my friend. While it's not as fast as World Edit and friends, to clear large spaces you might want to look at the filler (As bass-ackwards as that sounds). You can set the filler to clear out large areas and is much cheaper to make and operate than a quarry. Some might say the effort needed to do it isn't worth the results but if you're trying to flatten a 7 x 7 chunk square like hell do I want to do that by hand! And now for my two cents. Tekkit has machinated ways to do many of the things that you might do with World Edit. You could program turtles to build structures if you where so industrious. That's part of the fun of playing Tekkit is to find the ways of doing things in a highly convoluted machinated way that's not just *point* be gone! *poof*

You should utilize the power you're generating. Machines like the pulverizer and the electric furnaces won't continually draw power unless they have work to do. They have a small buffer charge that once full all power usage stops. Pulverize then smelt your ores into ingots. Make some charcoal from stacks of wood. Throw some cobble in a pulverizer set to output into a furnace and make some glass. Or build some machines that will work continually. The fisher comes to mind. Outside of that, make your engines easy to turn off. Magmatic engines will stop when they receive a redstone signal. A very low tech way of dealing with it is to put a lever on every engine. A mid-range solution would be redstone wires or RedNet Cable connected to a lever. Automating the process involves Redstone Energy Cells and some logic gates. If you don't need to use the power continually there's no reason to generate it continually. When you start getting into the realm of automated farms, AE storage and crafting networks, force fields and laser drills you will need continual and large amounts of power. :D

No, but that answered the question why hasn't anyone filled in that bit of information. It's largely immaterial.

I have a question for those players that have used Mining Drills. According to the wiki you obtain certain ores by using certain colored Laser Foci. There is a table there that lists all of the vanilla ores and gems. But what about lead, copper, silver, certus quartz and "Shiney Metal" aka platinum? Have you been able to obtain those ores at all? Has anyone noticed a pattern?

Could you continue running tests but increase the "large turbine with one connection" count? I'm curious how the power will scale.

I think the problem might be the fact that every value but the name field starts counting at 0. Do you have a redstone_energy_cell_0 or do you have a redstone_energy_cell_70? It's easy to change the code to start counting at 1. local storageUnitCount = 70 -- change this local storageUnits = {} for i=1, storageUnitCount do -- change this storageUnits = { ["id"] = "redstone_energy_cell_" .. i, ["name"] = "Cell" .. i -- change this } end

I think this is what you're needing local storageUnitCount = 69 -- Total number of RECs minus 1 since the cell id starts with 0. local storageUnits = {} for i=0, storageUnitCount do storageUnits = { ["id"] = "redstone_energy_cell_" .. i, -- you concatenate with the .. operator ["name"] = "Cell" .. i+1 } end That will build the same table structure you've had to manually define before. I'm a bit confused how you're reading the individual RECs though. Sensors? Computers at each REC?

Although I don't think it precisely refers to this issue but there are several reports that the oxygen sealers might be bugged. I ran into issues myself which caused me to abandon my interstellar building plans.

1. I believe that statement is referring to a combustion engine running regular fuel. Biofuel only works in bio fuel generators. 2. What are you using to connect to your powered devices? If you use buildcraft conductive pipes you need to use a wooden pipe for the first segment touching the generator. Similarly if you use Redstone Engergy Conduit you need to right click the connection to your generator with a wrench so that it draws power from the generator. The connection will have a red arrow on it when it's correct.

If you use conductive pipe you need to use a wooden one first. Engine > wooden pipe > gold pipe > harvester.

It's not the first thing I think of in terms of solutions because up until the release of 1.1.8 Tekkit didn't have vanilla hoppers. They where added in MC 1.5.x and the previous recommended version of Tekkit ran with 1.4.x. *shrug*

it's the os.pullEvent line that's causing the trouble here, it waits for a redstone event before allowing the program to loop again. Remove it but be sure to put in a sleep() call.

After watching youtube videos on the mod, read this thread. Lots of discussion about how to make things work.

An ugly solution to this problem we used early game was to create a loop of BC transport pipes that lead from your source chest, to your intended destinations and then back to the chest. That way the items would turn around and go another direction instead of popping out when the pulverizer is full. I wouldn't suggest doing this for very large setups as this will cause increasing lag the more items that are moving around in the pipes. But at first it's not enough to hurt much anything. Just plan to upgrade later.

Oh Reece, I simply meant that since this topic mostly turned into a discussion between the two of us that technically could have taken place in PMs, could you post the basic code that finally worked with engine_state and buffer_state so that everyone could benefit. :)

The naming is confusing. rednet as Reece is using is strictly about inter-computer communication over (it seems) multiple transmission mediums, wired and wireless. It's not the same as using RedNet Cables with their 16 colors. Yes one could have implemented this with RedNet Cable and that would have been a bit more straight forward to figure the coding portion out since you're testing physical lines for on or off state. This is simply a different way to implement the same thing. It's more powerful than using RedNet cables because you could very easily code something that might have more than on or off states, eg auto, manual, off. Also you would not be limited to running physical lines between all of your outposts. It just requires more know-how to implement.

Could you post the solution that worked so we can say we contributed to the forum?

Glad to help. CC is one of those mods that people either love or stay away from like the plague. You have to at least be able to make yourself think like a programmer for a short period of time.

Remember that what a sender sends and what the monitor is testing for should be the same. Your buffer sender sends "buffer drain" and your monitor is looking for "Buffer: Drain". It's case sensitive. You could send anything really just as long as it matches the other side. Remove the 21, from your broadcast calls in the buffer sender's code.

Ok my mistake yet again. Contrary to what it may seem I'm not a CC programming expert. I hadn't done all my research on rednet. See This. You are correct that is the ID for the destined PC. There's two ways to fix this. event, id, message = os.pullEvent("rednet_message") if id == 17 then -- do things elseif id == 21 then -- do other things end or if you use rednet.broadcast instead of rednet.send in your sending computers that WILL send to all attached computers. If you go this route remove the if id == whatever then line and one of the ends so that you're no longer checking what id contains.

What's happening is that only the one computer is sending it's update messages on rednet id (aka channel) 17 and that's the only one the monitor computer is listening to. You could make it listen to multiple but that's not necessary here. Just have all of your sending pcs use the same rednet id and you'll be fine.

I think since there isn't a straight forward way to get the computer ID and that the computer ID can change if the computer is dismantled and replaced they opted for a different system of identifying the intended recipient. Rednet is a message bus meaning that it doesn't send to specific PCs it sends to any computer connected to the rednet network and each computer either reacts to it or doesn't depending on the code running on it.

in your sender's code: rednet.send(21,"engines on") That first argument is what id it's being sent by. Pick a number and just use it. The idea is one... implementation of rednet communication would use one rednet id, another (e.g. a completely separate and independent from this status monitor project) implementation would use another.

rednet.open("top") local engine_state = false local buffer_state = false mon = peripheral.wrap("back") while true do event, id, message = os.pullEvent("rednet_message") if id == 17 then if message == "engines on" then engine_state = true elseif message == "engines off" then engine_state = false elseif message == "Buffer: Drain" then buffer_state = true elseif message == "Buffer: Retain" then buffer_state = false end end mon.clear() mon.setCursorPos(5,5) if engine_state == true then mon.write("Engines: On") else mon.write("Engines: Off") end mon.setCursorPos(5,7) if buffer_state == true then mon.write("Buffer: Drain") else mon.write("Buffer: Retain") end end The issue with your example is that you created two endless loops and only one could be active at a time. All of your computers sending and receiving messages via rednet should use the same rednet id.