phazeonphoenix

Oh, my mistake. When I wrote that code snippit I failed to add event to the beginning of the os.pullevent line. Try this: event, id, message = os.pullEvent("rednet_message")

mon.clear() mon.setCursorPos(5,5) mon.write("ID: " .. id)

I THINK in the case of rednet Ids it's not the computer's ID but the "channel" you're speaking on / listening to for communication. Try this. Change your on monitor output to display the value of id so you can see what value is being sent there.

try if id == 21 then (the same as you're using to send the messages)

the line event, senderId, message, distance = os.pullEvent("rednet_message") is assigning the 5 possible return values from os.pullEvent to that list of variables. Event is always the first value returned but we don't have to actually do anything with it. Event would be filled with what type of event has fired in this case it would always hold "rednet_message" since with os.pullEvent("rednet_message") you're limiting to only rednet_message events. If you were doing things like monitor touch screen or keyboard input the event value would be different and you'd want to check what event holds. In this case as long as you have it in the line above, a value gets assigned to it that you don't have to do anything further with.

Not bad for pulling code out of my rear huh? Perhaps if you change "engine_state = false" to "local engine_state = false." The local keyword effects variable scope which may be the problem here. The other issue is that the computer sending the message should send the same messages that the computer receiving is looking for. I used somewhat generic messages in my code. It should match what your sending. The event is needed since that's always the first one returned (I missed that in my code.) Distance is last and it is safe to omit it.

engine_state = false mon = peripheral.wrap("back") do while true id, message = os.pullEvent("rednet_message") if id == 21 then if message == "engines on" then engine_state = true elseif message == "engines off" then engine_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 end There that may or may not work as is, but that should illustrate what you'll have to do. os.pullEvent will wait for a rednet_message, react if it's a message it's looking for and updates it's display afterward.

Since he's adding the second computer over rednet to the mix it's already not simple. os.pullEvent isn't evil you just have to be careful with it. Sleep() is your friend. I guess the first question to ask is why did you opt to use two computers instead of just one?

Doing this with CC sadly isn't very straight forward. The direction you're going to want to go is os.pullEvent and it gets pretty dicey from there on out. Just theorizing you'd want to set up a loop with an if conditional for rednet events (if one exists I don't have time to do a full researched answer ), have it keep track of state (engines are on or off, hot tub is on or off, etc) and display it's state on screen.

machines take power from most sides and multiple connections per machine aren't needed. conduits do not have a limit of how much MJ it can output per tick, liquiducts do 100mb/t.

Yes I agree it seems more "wholesome" somehow to do it that way. What I was pointing at with my comment was in the end we're simply deluding ourselves into thinking that one way to attain the wood is better than the other when in the end they both achieve the same result, we have wood!

Yes but the limit is high upwords of 2000 MJ/t. Best I can explain that is that the conduit network works both as a conductor sending X MJ/t down the line but also storing an amount of MJ if your power generation is greater than your power utilization. I use the figure as an excess of energy production indicator. It's the average power utilization by that connection over X ticks. Can be seen as a direct indicator of how much power you're utilizing per tick. Sum all your averages together for your total. I believe it means you're power input to conduit C is greater than your output from conduit C. Each cell by default wants to output 50MJ/t times eight that is a potential input of 400MJ/t connected to the potential output of (lets assume) two fully running quarries. This goes back to each conduit line being able to store as well as transmit energy. MJ acts more like a liquid than anything else. The energy in the line would behave similarly to how items running through BC transport pipes. When they reach a branch/fork/intersection they randomly pick a new direction to go in and go. Depending on pipe design that might favor certain destinations more than another. This is the behavior I've seen. If there's a power input surplus, eg high saturation, the devices attempting to input power every tick try to push power into the pipe. Seeing that the pipe is full(ly saturated) no power is used/exchanged. Then a relatively small amount is pulled out of the pipe by a powered device. Next tick one input gets to output a bit of power to top off the pipe but every other input is denied since it's full again. How do they determine which is first? No idea it seems random. If there's a power input deficiency, eg low saturation, the inverse happens. Power output connections are checking the pipe every tick for power and finding none does nothing. Insufficient power input occurs and one output gets a partial amount of energy chosen randomly. Actually most of what I said above applies to them. You get much more information about their capacity and throughput with the multimeter than you do with the redstone energy conduits.

I hadn't realized that. I was trying to make a funny comment about choosing to cut trees and use the saw mill over using a MFR setup that didn't take client performance into account lol

Some method of fooling yourself into thinking you're doing it more "naturally" by having to harvest trees yourself than the MFR machines just simply generating gobs of wood.

Yep Are you saying you have an empty gap between the layer of tesserects and the first layer of liquid managers? Or that you have a layer of normal blocks between them?

Well hey they say the human mind has to hear something seven times before it remembers something permanently. I must have missed it.

I'll leave this here. Check out this and this too. Only thing I'll add is to reinforce the bring a linking book rule!

I guess I'll still be the one standing up for AS and fusion generators. With the system of capturing steam that my power plant uses power is steady and constant as my fusion reactor turns itself back on before all the steam is exhausted from the system. I will be writing up some info on it in the near future for those who are curious. Oh one more little tidbit that helped me immensely with the fuel loading design, AE Export buses CAN export into a Buildcraft transport pipe. One gold transport pipe feeding directly into the top of the fusion reactor block with an AE Export bus pointing at the other end of it. It gives you much more freedom to place the mechanics of sending fuel down the pipe.

Not that this will make any difference to Tekkit in the foreseeable future but talk on the AS forums seems to be pointing to a liquid deuterium source instead of cells.

No but you get 16 empty cells when you craft the recipe. It's not as bad as it sounds. Fusion reactors are capable of producing enormous amounts of energy if designed and implemented correctly. It's all about your needs both now and in the future. Charlie's setup generates MASSIVE amounts of energy and (probably) runs continually producing steam and utilizing it without storing it. If you use that much power then his setup would work for you. I don't have that massive of power requirements (yet). My setup captures steam and powers turbines from the storage tanks. My reactor is only active for brief periods every ~ 20 minutes to fill the tanks and the turbines produce enough energy for my current power requirements. Need more power? Add more turbines until I no longer can keep my tanks filled then expand with another reactor chamber. This is one of those situations that any one design will not be effective for everyone.

How about you go overboard? Set up DSUs for the common output of your quarries and see if you can max them all out!

I'd have to say that the "files" being stored aka the digital representation of that block would be very complex and non-compressable like a video file. The storage math used in AE is loosely based on the actual file storage techniques. There is a logic to it but it has been "fudged" here and there.

So are we defining two types of fusion reactor setups? Flood type reactors: Where steam is generated and sent directly to turbines via liquiducts in an open flow setup. Fuel injection is on either a timer or uses a gate to detect empty pipes. Capture type reactors: Steam is generated and fed into large parallel tanks which are drawn from via liquiducts and fed to turbines. Fuel injection uses a gate to detect empty tanks. At first I thought that steam wasn't being treated like a regular MC liquid. Further observations have proven to me it is but unlike any other liquid in minecraft it's used EXTREMELY quickly. So quickly that the pipes don't get a chance to fill before they are drained. Here's some observations I've found about Liquiducts: Each segment of pipe seems to act as both a pipe and a tank: holding more than it can put through in a single tick. There can be more liquid in a network of pipes than can be outputted via a single output connection. Each connection can only move 100 mb of a liquid per tick in either direction. Connections to a tank/tesserect/liquidmanager can be multiplied to fill/drain it faster. See This image? Flow goes from right to left. Steam (or any liquid really) comes in and flows into the large tank via 4 connections. I then draw from two connections on the tank leading to two connections on a liquid manager. I then draw from one connection on the liquid manager. That whole arrangement is multiplied 4 times in parallel and feeding turbines not pictured. The key is parallel connections to a single storage tank. Because I have more input connections than output connections on the tanks/managers they will retain an amount of liquid as long as there is a source feed. Interestingly enough it doesn't seem to matter if the multiple connections to a single tank are themselves separate pipes or not. The four connections in a row fed by a single pipe on the right of the tank feed it just as effectively as the two completely separate pipe lines feeding the liquid managers. This whole setup moves a huge amount of liquid around that just vaporizes the moment it reaches it's destination. No other use of a minecraft liquid will draw this much liquid at a time. You have to design your pipes accordingly.

I wanted to post my now operating Fusion reactor. I adapted Kiwi's steam storage idea. This system is able to keep it's steam buffer filled and there is no interruption in power generation. I used an AE export bus configured in redstone pulse mode injecting a single deuterium cell when the large tanks are empty. It does so once every 20 ~ 30 minutes. I have no idea how much power I generate with this setup. It seems that Atomic Science is a very complex mod with many facets that need tweaking, tuning and balancing. But when you get it right the power is just ungodly.

I use redstone energy conduits. Just be sure to use a wrench and give 'em a whack so they draw power from the turbines (the end will turn orange). I've also seen Redstone Energy Cells hooked directly to the turbine and conduits drawing from it instead. I don't know do BC wooden conductive pipes work too? [edit *$@&#! grammar police]