38 replies to this topic

[Hexicube]

I've been working on a simple utility that manages a nuclear reactor for you. I am currently trying it out on my private tekkit server running 3.0.4, but it looks to be working OK.
Software works as intended for me, you should have it set to startup just in case the server restarts or something and you find a lovely crater where your reactor used to be...
The second version is currently untested...


Right now it takes two redstone inputs to work out the reactor temperature state (cold, warm, or hot), and gives two outputs (one toggles the reactor, another is a bundled wire output for whatever you want).
It now also accepts an optional input from an MFE/MFSU(should be the first of a chain of storage units with the redstone output set to emit if partially filled) to work out if the reactor ran out of cells or the storage is full.
The second version uses a single bundled cable for all input/output, if you do not want to use an optional in/out then set it to 0 (the reactor will think it is empty if you disable the storage state signal, but this has no adverse effects).
Protip: You can set the storage state input to be a lever, which will basically act as a manual override shutoff switch. You could also do this with an OR gate, so the reactor continues to monitor the EU storage.


The input and output sides are freely change-able from the top of the code, as well as the three colours it uses within bundled cables for the outputs. The two temperature inputs are hooked up by using Thermal Monitors on the reactor, preferably with the cold heat level being lower than the hot.
The second version only has one side for all wiring, but the side is still configurable.

Here's the code:

Spoiler

os.pullEvent = os.pullEventRaw

local coolDownSide = "left"
local heatUpSide = "right"
local controlSide = "front"
local displaySide = "top"
local storageStateSide = "bottom"

local onCol = colors.white
local offCol = colors.black
local emptyCol = colors.blue
local storageFullCol = colors.red

local reactorEnabled = true
local reactorEmpty = false

local storageFull = false

local timeSinceActive = 0
local timeSinceFull = 0
local timeSinceNotFull = 0

local width, height = term.getSize()
local companyName = "HexCorp Industries"

local function clearScreen()
  term.clear()
  term.setCursorPos(1, 1)
  term.write("Nuclear Reactor Control Unit")
  term.setCursorPos(width-#companyName+1, height)
  term.write(companyName)
end

local function doTick()
  timeSinceActive = timeSinceActive + 1
  local hot = rs.getInput(heatUpSide)
  local cold = rs.getInput(coolDownSide)
  local full = rs.getInput(storageStateSide)
  if full then
	timeSinceFull = timeSinceFull + 1
	timeSinceNotFull = 0
  else
	timeSinceNotFull = timeSinceNotFull + 1
	timeSinceFull = 0
	storageFull = false
  end
  if timeSinceFull >= 20 then
	hot = true
	timeSinceFull = 20
	storageFull = true
  else storageFull = false end
  if timeSinceNotFull >= 20 then
	timeSinceNotFull = 20
	reactorEmpty = true
  else reactorEmpty = false end
  if reactorEnabled then
	if hot then
	  reactorEnabled = false
	  reactorEmpty = false
	end
  else
	reactorEmpty = false
	if not cold then
	  reactorEnabled = true
	  timeSinceActive = 0
	end
  end
  clearScreen()
  term.setCursorPos(1, 3)
  term.write("Current status: ")
  if reactorEmpty then
	term.write("Cells Depleted")
	rs.setOutput(controlSide, false)
	rs.setBundledOutput(displaySide, emptyCol + onCol)
  elseif storageFull then
	term.write("Energy Storage Full")
	rs.setOutput(controlSide, true)
	rs.setBundledOutput(displaySide, storageFullCol + offCol)
  elseif reactorEnabled then
	term.write("Active")
	rs.setOutput(controlSide, false)
	rs.setBundledOutput(displaySide, onCol)
  else
	term.write("Inactive")
	rs.setOutput(controlSide, true)
	rs.setBundledOutput(displaySide, offCol)
  end
  sleep(0.25)
end

while true do doTick() end

Here's some better commented code that only uses one bundled cable (untested):

Spoiler

--[[START OF CONFIG]]--

--[[POSSIBLE CABLE COLOURS]]--
--white		 orange		  magneta		 lightBlue
--yellow		lime			pink			gray
--lightGray	 cyan			purple		  blue
--brown		 green		   red			 black

--[[BUNDLED CABLE SIDE]]--
local cableSide = "back" --side of computer the bundled cable is on

--[[REQUIRED CABLES]]--
local coolDownCol = colors.white --input from heat sensor (temp should be lower than heatUp one)
local heatUpCol = colors.red --input from heat sensor (temp should be higher than coolDown one)
local controlCol = colors.black --output to control the reactor

--[[OPTIONAL CABLES]]--
local storageStateCol = colors.green --input from EU storage set to "Emit if partially full"
local onCol = colors.pink --output to show the reactor is online
local offCol = colors.purple --output to show the reactor is offline
local emptyCol = colors.lime --output to show the reactor needs uranium [requires storageStateCol]
local storageFullCol = colors.orange --output to show the EU storage is full [requires storageStateCol]

--[[OTHER SETTINGS]]--
local companyName = "HexCorp Industries" --name of your company

--[[END OF CONFIG]]--


os.pullEvent = os.pullEventRaw --Prevent Ctrl+T from closing the program

--Initialise reactor state variables
local reactorEnabled = true
local reactorEmpty = false
local storageFull = false
local timeSinceActive = 0
local timeSinceFull = 0
local timeSinceNotFull = 0

local width, height = term.getSize() --Store the size of the screen

local function clearScreen()
  term.clear() --Clear the screen
  --Print the program and company names
  term.setCursorPos(1, 1)
  term.write("Nuclear Reactor Control Unit")
  term.setCursorPos(width-#companyName+1, height)
  term.write(companyName)
end

local function doTick()
  --Increment reactor active timer and check inputs
  timeSinceActive = timeSinceActive + 1
  local hot = rs.testBundledInput(cableSide, heatUpCol)
  local cold = rs.testBundledInput(cableSide, coolDownCol)
  local full = rs.testBundledInput(cableSide, storageStateCol)
  if full then --The EU storage is giving a signal, increment its variable
	timeSinceFull = timeSinceFull + 1
	timeSinceNotFull = 0
  else --The EU storage is not giving a signal, increment its other variable
	timeSinceNotFull = timeSinceNotFull + 1
	timeSinceFull = 0
	storageFull = false
  end
  if timeSinceFull >= 20 then --There has been an EU signal for 20 ticks, the EU storage may be full
	hot = true
	timeSinceFull = 20
	storageFull = true
  else storageFull = false end
  if timeSinceNotFull >= 20 then --There has not been an EU signal for 20 ticks, the reactor may be out of uranium
	timeSinceNotFull = 20
	reactorEmpty = true
  else reactorEmpty = false end
  if reactorEnabled then
	if hot then --Disable the reactor, because it is too hot
	  reactorEnabled = false
	  reactorEmpty = false
	end
  else
	reactorEmpty = false
	if not cold then --Enable the reactor, because it has cooled down
	  reactorEnabled = true
	  timeSinceActive = 0
	end
  end
  clearScreen()
  term.setCursorPos(1, 3)
  term.write("Current status: ")
  if reactorEmpty then
	term.write("Cells Depleted")
	rs.setBundledOutput(cableSide, emptyCol + onCol)
  elseif storageFull then
	term.write("Energy Storage Full")
	rs.setBundledOutput(cableSide, storageFullCol + offCol + controlCol)
  elseif reactorEnabled then
	term.write("Active")
	rs.setBundledOutput(cableSide, onCol)
  else
	term.write("Inactive")
	rs.setBundledOutput(cableSide, offCol + controlCol)
  end
  term.setCursorPos(1, 4)
  term.write("Temperature: ")
  if hot then term.write("|Cold |Warm >Hot")
  elseif cold then term.write("|Cold >Warm |Hot")
  else term.write(">Cold |Warm |Hot") end
  sleep(0.25) --Four ticks to the second
end

while true do doTick() end

Here's a couple of images showing my setup (they're a bit big, also only first software version):

Spoiler

Feel free to change it as you see fit or make suggestions as to improving it, but I suggest you use this as a startup file as computers tend to do a fresh reboot on a server restart (from what I've noticed). If you do use this in a project, mentioning me would be nice, thought I don't enforce it...just don't say you made it! />

Also, if you're a bit confused, here's a world I made (flatmap/creative) showing how to set up the reactor with the newer software version:
https://dl.dropbox.c...r%20Control.zip

[Hexicube]

Just noticed the "Cells Depleted" text wouldn't show, I've moved that little bit of code up to remidy this.

[yoskaz01]

just a small suggestion,

if you want to show the actual temperature and number of cells in the reactor, consider using ccSensors.
check the peripheral page.

[Hexicube]

I would, but I'm using tekkit, so I'd rather try and use what I have. I was fully aware of ccSensors before-hand. />

[Hexicube]

Just changed the program to include a redstone signal stating that the energy storage is full. You don't really need to hook up this input, but it forces the reactor to turn off when it has been on for 3 seconds.

[Hexicube]

Changed it to use the storage input to detect if the reactor ran out of cells, instead of the low temperature input. There's currently a quirk in energy storage units where if you set it to emit on partially full you get 1 tick of redstone current when the EU exceeds the packet size...as such, it's not advised to run a reactor which produces more EU/t than the storage unit is giving out.

Also, you should have a chain of MFEs/MFUs, as the first to be powered in the chain(and thus the last filled) can be set to emit when partially full to inform the manager if storage is getting full or not, rather than using the emit if full option and wasting a bit of EU.

[Paukinra]

Hey, been trying to get this to work but I keep getting this error when trying to run the program as startup:

bios:206: [string "startup" ] : 26 : '=' expected

Any ideas what mgith be wrong?


Also, I am a little confused as the which cables I need and where they go, whould it be possible to get a pretty picture? />

[Hexicube]

Paukinra, on 19 June 2012 - 08:25 AM, said:

Hey, been trying to get this to work but I keep getting this error when trying to run the program as startup:

bios:206: [string "startup" ] : 26 : '=' expected

Any ideas what mgith be wrong?


Also, I am a little confused as the which cables I need and where they go, whould it be possible to get a pretty picture? />

I'll make some nice pictures to help with setting it up. As for the problem, I'd double check you entered it right, it works perfectly fine for me with vanilla tekkit and no extra APIs.
[edit] Done, if you want I could make a fresh world and construct a setup using the default settings for download...

[WarBird]

The color coded lights are a good idea, but itd be nice to know what each mean, Im assuming that blue means either cold or no cells, and that red means its going to blow. I assume white means that its on, the last white from what I can see means storage full, and green means ?
I am also having trouble figuring out how you got the MFSU containers linked up to the computer. I am not sure if not having the containers linked is the problem, but, the system always reports the cells being depleted.

[elustran]

I like the basic idea of this, but I wanted to do a few things differently. I basically used some of your code and format as a base - mostly the tick loop and the outline of the screen clearing function (It's still a - and added my own control language. It's pretty messy - I probably should have written a couple of functions to call on instead of writing everything individually in a big if-elseif chain. At least I commented a fair bit. I'd love some ideas for cleaning it up. I've debugged it as much as possible and I think it works, mostly.

Basically, I wanted to run everything from a bundled cable so I could put the terminal wherever without extra cables sticking out of it, provide for power-on detection of thermal sensors and coolant, leave as much space as possible for water in the reactor chamber, and output to a monitor. The monitor output part I put in a startup routine with the startup routine on disk, but the program on the computer.

Startup routine:

This will check for a monitor next to the computer and use that for output if its available.

Spoiler

if peripheral.getType("right") == "monitor" then
	shell.run("monitor", "right", "/nuke3")
elseif peripheral.getType("left") == "monitor" then
	shell.run("monitor", "left", "/nuke3")
else
	shell.run("/nuke3")
end

Reactor code:

This checks the status of a low and high heat sensor, reactor activity, if the battery is full, if coolant has power, if thermometers have power (for remote thermometers), and cable breakage. It outputs signals indicating the computer is on, whether to activate coolant, whether to deactivate the reactor, and whether to activate an alarm. Input signal wires could easily lead to both the computer and a signal light.

This system is intended to have a redstone torch near the reactor chamber powering a wire in the cable to detect if the cable is intact (no signal means a cable breakage). There is a signal indicating that the computer is on, which could be used in conjunction with redstone/redwire gates for various external signal overriding purposes. The system is also intended to be attached to a buildcraft/industrialcraft ice cooler (or a ridiculously OP EE-based one if you're lazy). For the thermal sensors, you should use an AND gate from a power detector cable on both of them so if either loses power, you'll get a warning. There are also provisions for an override switch should something fail.

Spoiler

os.pullEvent = os.pullEventRaw

local cableside = "back" --side of computer for cable

--inputs

local therma = colors.red --input for overheat sensor
local batstate = colors.gray --input if battery is full
local coolant = colors.white --input if coolant active
local cablesignal = colors.black --detects bundledcable breakage if power on distant end is no longer received
local thermpow = colors.orange --detects if thermal sensors have power
local coolthresh = colors.cyan --detects if coolant threshold sensor is active
local reactorpow = colors.pink --detects if power cable from reactor is active
local override = colors.brown --detects if power off override is active

--outputs

local nukepower = colors.green --output turns off reactor
local klaxon = colors.yellow --outputs alarm signal
local coolpow = colors.blue --activates coolant system
local computeron = colors.magenta --indicates that computer controller is operational

--immediately signal acknowleging nuke OS is running

rs.setBundledOutput(cableside, computeron)
local cablestate = computeron

--ticker variables

local timeSinceActive = 0
local timeSinceFull = 12 --when set to under 12, reactor should be off, starts at 12 so reactor starts on
local timeSinceNotFull = 0
local heattimer = 20 --when set to under 20, heattimer should leave reactor off
local alarmtimer = 0

--function and variables to display on screen

local width, height = term.getSize()
local companyName = "HexCorp Industries"

local function clearScreen()
	term.clear()
	term.setCursorPos(1, 1)
	term.write("Nuclear Reactor Control Unit Mk.II")
	term.setCursorPos(width-#companyName+1, height)
	term.write(companyName)
end

--checks reactor state and applies outputs every tick
--there is an attempt to record cable state to enable some functions to add outputs to the cable state
--without rewriting over previous states

local function doTick()
	timeSinceActive = timeSinceActive + 0.25
	heattimer = heattimer + 1
	timeSinceFull = timeSinceFull + 1
	local batfull = rs.testBundledInput(cableside, batstate) --true if battery full
	local overheat = rs.testBundledInput(cableside, therma) --true if overheat temp reached
	local cableintact = rs.testBundledInput(cableside, cablesignal) --true if cable is intact
	local coolanton = rs.testBundledInput(cableside, coolant) --true if coolant is active
	local thermon = rs.testBundledInput(cableside, thermpow) --true if thermometers have power
	local cooldown = rs.testBundledInput(cableside, coolthresh) --true if coolant activation temp reached
	local reactoron = rs.testBundledInput(cableside, reactorpow) --true if reactor is on
	local overridden = rs.testBundledInput(cableside, override) --true if power kill switch is on
	
	--displays reactor status, cable status and coolant status
		
	clearScreen()
	term.setCursorPos(1, 2)
	term.write("Coolant status: ")
	
	if coolanton then  --displays coolant status
		term.write("On")
	elseif cooldown then
		term.write("CHECK COOLANT!")
	else 
		term.write("Off") 
	end
	term.setCursorPos(1, 4)
	term.write("Reactor status: ")
	
	--main output selection list
	
	if thermon == false and overridden == false then
	--if cable is intact, the override should reach the reactor, so thermal sensors may be in manual shuttdown
	--warning therefore not relevant in manual shutdown
		term.write("THERMOMETER OFF!")
		rs.setBundledOutput(cableside, nukepower + computeron)
		cablestate = nukepower + computeron
		alarmtimer = alarmtimer +1
		if alarmtimer >= 24 then --turns on alarm if times out for too long
			term.setCursorPos(8, 5)
			if alarmtimer % 2 == 0 then --modulo used to flash sign
				term.write("CHECK TEMPS!")
			end
			rs.setBundledOutput(cableside, klaxon + nukepower + computeron)
			cablestate = klaxon + nukepower + computeron
		elseif alarmtimer >= 6 and coolanton == false then
			term.setCursorPos(1, 5)
			if alarmtimer % 2 == 0 then --modulo used to flash sign
				term.write("CHECK TEMPS AND COOLANT!")
			end
			rs.setBundledOutput(cableside, klaxon + nukepower + computeron)
			cablestate = klaxon + nukepower + computeron
		end
		timeSinceActive = 0
	elseif overheat then
		rs.setBundledOutput(cableside, nukepower + computeron)
		cablestate = nukepower + computeron
		term.write("Overheated ")
		heattimer = 0
		timeSinceActive = 0
		alarmtimer = alarmtimer +1
		if alarmtimer >= 24 or coolanton == false then --turns on alarm if overheated for too long
			term.setCursorPos(8, 5)
			if alarmtimer % 2 == 0 then --modulo used to flash evacuation sign
				term.write("EVACUATE!")
			end
			rs.setBundledOutput(cableside, klaxon + nukepower + computeron)
			cablestate = klaxon + nukepower + computeron
		elseif alarmtimer >= 6 and coolanton == false then
			term.setCursorPos(1, 5)
			if alarmtimer % 2 == 0 then --modulo used to flash sign
				term.write("COOLANT OFF! EVACUATE!")
			end
			rs.setBundledOutput(cableside, klaxon + nukepower + computeron)
			cablestate = klaxon + nukepower + computeron
		end
	elseif batfull then
		rs.setBundledOutput(cableside, nukepower + computeron)
		cablestate = nukepower + computeron
		term.write("Battery Full")
		timeSinceActive = 0
		timeSinceFull = 0 --used to detect whether reactor should come on
		alarmtimer = 0
	elseif overridden then
		rs.setBundledOutput(cableside, nukepower)
		--computeron signal removed as added precaution and sign of override
		cablestate = nukepower
		term.write("Override Engaged")
		timeSinceActive = 0
	elseif reactoron == false and timeSinceActive >= 2 then
		--if the reactor is refueled, fixed, etc, reactoron should come on, skipping this
		rs.setBundledOutput(cableside, computeron)
		cablestate = computeron
		term.write("Reactor Off")
		timeSinceActive = 2 --this will display inaccurately, bit of a kludge
	elseif heattimer >= 20 and timeSinceFull >= 12 then --reactor on when cooldown/battery timer is complete
		--this should be the only option where the reactor is active
		rs.setBundledOutput(cableside, computeron)
		cablestate = computeron
		term.write("Reactor Active")
		term.setCursorPos(1, 5)
		term.write("Active Time: ")
		term.write(timeSinceActive)
		alarmtimer = 0
	else
		rs.setBundledOutput(cableside, nukepower + computeron)
		cablestate = nukepower + computeron
		term.write("Reactor Cooling")
		timeSinceActive = 0
	end
	
	if cableintact == false then
		term.setCursorPos(1, 3)
		term.write("BROKEN CABLE!")
		if alarmtimer >= 24 then --if cable is broken while in overheat, klaxon should sound, may not work
			rs.setBundledOutput(cableside, klaxon + computeron + nukepower)
			cablestate = klaxon + computeron + nukepower
		end
	end
	
	-- adds cooldown mode to last cable state, but doesn't reset cablestate
	
	if cooldown or thermon == false or cableintact == false then
		rs.setBundledOutput(cableside, cablestate + coolpow)
	end
	
	sleep(.25)
end

while true do doTick() end

[Hexicube]

elustran, on 28 June 2012 - 10:20 AM, said:

I like the basic idea of this, but I wanted to do a few things differently. I basically used some of your code and format as a base - mostly the tick loop and the outline of the screen clearing function (It's still a - and added my own control language. It's pretty messy - I probably should have written a couple of functions to call on instead of writing everything individually in a big if-elseif chain. At least I commented a fair bit. I'd love some ideas for cleaning it up. I've debugged it as much as possible and I think it works, mostly.

Basically, I wanted to run everything from a bundled cable so I could put the terminal wherever without extra cables sticking out of it, provide for power-on detection of thermal sensors and coolant, leave as much space as possible for water in the reactor chamber, and output to a monitor. The monitor output part I put in a startup routine with the startup routine on disk, but the program on the computer.

Startup routine:

This will check for a monitor next to the computer and use that for output if its available.

Spoiler

if peripheral.getType("right") == "monitor" then
	shell.run("monitor", "right", "/nuke3")
elseif peripheral.getType("left") == "monitor" then
	shell.run("monitor", "left", "/nuke3")
else
	shell.run("/nuke3")
end

Reactor code:

This checks the status of a low and high heat sensor, reactor activity, if the battery is full, if coolant has power, if thermometers have power (for remote thermometers), and cable breakage. It outputs signals indicating the computer is on, whether to activate coolant, whether to deactivate the reactor, and whether to activate an alarm. Input signal wires could easily lead to both the computer and a signal light.

This system is intended to have a redstone torch near the reactor chamber powering a wire in the cable to detect if the cable is intact (no signal means a cable breakage). There is a signal indicating that the computer is on, which could be used in conjunction with redstone/redwire gates for various external signal overriding purposes. The system is also intended to be attached to a buildcraft/industrialcraft ice cooler (or a ridiculously OP EE-based one if you're lazy). For the thermal sensors, you should use an AND gate from a power detector cable on both of them so if either loses power, you'll get a warning. There are also provisions for an override switch should something fail.

Spoiler

os.pullEvent = os.pullEventRaw

local cableside = "back" --side of computer for cable

--inputs

local therma = colors.red --input for overheat sensor
local batstate = colors.gray --input if battery is full
local coolant = colors.white --input if coolant active
local cablesignal = colors.black --detects bundledcable breakage if power on distant end is no longer received
local thermpow = colors.orange --detects if thermal sensors have power
local coolthresh = colors.cyan --detects if coolant threshold sensor is active
local reactorpow = colors.pink --detects if power cable from reactor is active
local override = colors.brown --detects if power off override is active

--outputs

local nukepower = colors.green --output turns off reactor
local klaxon = colors.yellow --outputs alarm signal
local coolpow = colors.blue --activates coolant system
local computeron = colors.magenta --indicates that computer controller is operational

--immediately signal acknowleging nuke OS is running

rs.setBundledOutput(cableside, computeron)
local cablestate = computeron

--ticker variables

local timeSinceActive = 0
local timeSinceFull = 12 --when set to under 12, reactor should be off, starts at 12 so reactor starts on
local timeSinceNotFull = 0
local heattimer = 20 --when set to under 20, heattimer should leave reactor off
local alarmtimer = 0

--function and variables to display on screen

local width, height = term.getSize()
local companyName = "HexCorp Industries"

local function clearScreen()
	term.clear()
	term.setCursorPos(1, 1)
	term.write("Nuclear Reactor Control Unit Mk.II")
	term.setCursorPos(width-#companyName+1, height)
	term.write(companyName)
end

--checks reactor state and applies outputs every tick
--there is an attempt to record cable state to enable some functions to add outputs to the cable state
--without rewriting over previous states

local function doTick()
	timeSinceActive = timeSinceActive + 0.25
	heattimer = heattimer + 1
	timeSinceFull = timeSinceFull + 1
	local batfull = rs.testBundledInput(cableside, batstate) --true if battery full
	local overheat = rs.testBundledInput(cableside, therma) --true if overheat temp reached
	local cableintact = rs.testBundledInput(cableside, cablesignal) --true if cable is intact
	local coolanton = rs.testBundledInput(cableside, coolant) --true if coolant is active
	local thermon = rs.testBundledInput(cableside, thermpow) --true if thermometers have power
	local cooldown = rs.testBundledInput(cableside, coolthresh) --true if coolant activation temp reached
	local reactoron = rs.testBundledInput(cableside, reactorpow) --true if reactor is on
	local overridden = rs.testBundledInput(cableside, override) --true if power kill switch is on
	
	--displays reactor status, cable status and coolant status
		
	clearScreen()
	term.setCursorPos(1, 2)
	term.write("Coolant status: ")
	
	if coolanton then  --displays coolant status
		term.write("On")
	elseif cooldown then
		term.write("CHECK COOLANT!")
	else
		term.write("Off")
	end
	term.setCursorPos(1, 4)
	term.write("Reactor status: ")
	
	--main output selection list
	
	if thermon == false and overridden == false then
	--if cable is intact, the override should reach the reactor, so thermal sensors may be in manual shuttdown
	--warning therefore not relevant in manual shutdown
		term.write("THERMOMETER OFF!")
		rs.setBundledOutput(cableside, nukepower + computeron)
		cablestate = nukepower + computeron
		alarmtimer = alarmtimer +1
		if alarmtimer >= 24 then --turns on alarm if times out for too long
			term.setCursorPos(8, 5)
			if alarmtimer % 2 == 0 then --modulo used to flash sign
				term.write("CHECK TEMPS!")
			end
			rs.setBundledOutput(cableside, klaxon + nukepower + computeron)
			cablestate = klaxon + nukepower + computeron
		elseif alarmtimer >= 6 and coolanton == false then
			term.setCursorPos(1, 5)
			if alarmtimer % 2 == 0 then --modulo used to flash sign
				term.write("CHECK TEMPS AND COOLANT!")
			end
			rs.setBundledOutput(cableside, klaxon + nukepower + computeron)
			cablestate = klaxon + nukepower + computeron
		end
		timeSinceActive = 0
	elseif overheat then
		rs.setBundledOutput(cableside, nukepower + computeron)
		cablestate = nukepower + computeron
		term.write("Overheated ")
		heattimer = 0
		timeSinceActive = 0
		alarmtimer = alarmtimer +1
		if alarmtimer >= 24 or coolanton == false then --turns on alarm if overheated for too long
			term.setCursorPos(8, 5)
			if alarmtimer % 2 == 0 then --modulo used to flash evacuation sign
				term.write("EVACUATE!")
			end
			rs.setBundledOutput(cableside, klaxon + nukepower + computeron)
			cablestate = klaxon + nukepower + computeron
		elseif alarmtimer >= 6 and coolanton == false then
			term.setCursorPos(1, 5)
			if alarmtimer % 2 == 0 then --modulo used to flash sign
				term.write("COOLANT OFF! EVACUATE!")
			end
			rs.setBundledOutput(cableside, klaxon + nukepower + computeron)
			cablestate = klaxon + nukepower + computeron
		end
	elseif batfull then
		rs.setBundledOutput(cableside, nukepower + computeron)
		cablestate = nukepower + computeron
		term.write("Battery Full")
		timeSinceActive = 0
		timeSinceFull = 0 --used to detect whether reactor should come on
		alarmtimer = 0
	elseif overridden then
		rs.setBundledOutput(cableside, nukepower)
		--computeron signal removed as added precaution and sign of override
		cablestate = nukepower
		term.write("Override Engaged")
		timeSinceActive = 0
	elseif reactoron == false and timeSinceActive >= 2 then
		--if the reactor is refueled, fixed, etc, reactoron should come on, skipping this
		rs.setBundledOutput(cableside, computeron)
		cablestate = computeron
		term.write("Reactor Off")
		timeSinceActive = 2 --this will display inaccurately, bit of a kludge
	elseif heattimer >= 20 and timeSinceFull >= 12 then --reactor on when cooldown/battery timer is complete
		--this should be the only option where the reactor is active
		rs.setBundledOutput(cableside, computeron)
		cablestate = computeron
		term.write("Reactor Active")
		term.setCursorPos(1, 5)
		term.write("Active Time: ")
		term.write(timeSinceActive)
		alarmtimer = 0
	else
		rs.setBundledOutput(cableside, nukepower + computeron)
		cablestate = nukepower + computeron
		term.write("Reactor Cooling")
		timeSinceActive = 0
	end
	
	if cableintact == false then
		term.setCursorPos(1, 3)
		term.write("BROKEN CABLE!")
		if alarmtimer >= 24 then --if cable is broken while in overheat, klaxon should sound, may not work
			rs.setBundledOutput(cableside, klaxon + computeron + nukepower)
			cablestate = klaxon + computeron + nukepower
		end
	end
	
	-- adds cooldown mode to last cable state, but doesn't reset cablestate
	
	if cooldown or thermon == false or cableintact == false then
		rs.setBundledOutput(cableside, cablestate + coolpow)
	end
	
	sleep(.25)
end

while true do doTick() end

Well, your version is certainly interesing...the reason I didn't use bundled cables for input was because it was initially individual wires because I didn't understand the API and then couldn't be bothered to change my reactor layout.

I assume it works just as well as my original program does, so the ideas you gave within the code is nice, but I think all the functionality my current version provides should suffice...but I don't mind anyone using yours for the extra bits n pieces.

I haven't really looked over it in detail, but one instance where you can clean up the code a bit:

rs.setBundledOutput(cableside, klaxon + computeron + nukepower)
cablestate = klaxon + computeron + nukepower

Could be written as:

cablestate = klaxon + computeron + nukepower
rs.setBundledOutput(cableside, cablestate)

There are probably other instances of improving it, but right now I'll be improving my program to account for bundled cable output...once I deplete my cells so my reactor doesn't explode! />

WarBird, on 27 June 2012 - 07:08 PM, said:

The color coded lights are a good idea, but itd be nice to know what each mean, Im assuming that blue means either cold or no cells, and that red means its going to blow. I assume white means that its on, the last white from what I can see means storage full, and green means ?
I am also having trouble figuring out how you got the MFSU containers linked up to the computer. I am not sure if not having the containers linked is the problem, but, the system always reports the cells being depleted.

The colours of the output merely represent what colour wire it uses. These can be hooked up to any colour light you want.
White shows the reactor is active (I used a red lamp), black is inactive (green lamp), blue states the reactor may be out of uranium (blue lamp) and red states the MFSU storage is full (white lamps, makes reactor inactive).
You don't actually need to hook up any of these, the output cable is a completely optional cable to make it possible to see the status of the reactor without entering the computer next to it, which is useful for factories containing multiple reactors.

As for hooking up the MFSUs, I will upload another picture to help with preparing them.
Basically, the power from the reactor goes into the first MFSU, which has its redstone output set to "Emit if partially filled". This MFSU also sends its power to other MFSUs, which keeps it empty so the redstone signal quirk works as intended. Using MFSUs for this allows any amount of reactor power output from ~64EU to ~256EU, but any value that can be expressed as 2^n (1, 2, 4, 8, 16, 32, etc.) will not work due to the way the quirk works. Any value under 64 might cause the reactor to keep thinking the cells are empty for a moment or two. Any value over 256 might cause the reactor to think the energy storage is full for a moment or two. Any value over 512 is guaranteed to cause the reactor to think it's full and will cause the reactor to constantly flick between on and off until the cells run out or it actually fills the storage.
Note that MFEs and batboxes also work, but they have lower EU input/output so I would recommend just using MFSUs. Also, if your reactor doesn't blow up a baxbox from directly energy input, you really need to improve the design!

[elustran]

Hexicube, on 28 June 2012 - 02:47 PM, said:

Well, your version is certainly interesing...the reason I didn't use bundled cables for input was because it was initially individual wires because I didn't understand the API and then couldn't be bothered to change my reactor layout.

I assume it works just as well as my original program does, so the ideas you gave within the code is nice, but I think all the functionality my current version provides should suffice...but I don't mind anyone using yours for the extra bits n pieces.

I haven't really looked over it in detail, but one instance where you can clean up the code a bit:

rs.setBundledOutput(cableside, klaxon + computeron + nukepower)
cablestate = klaxon + computeron + nukepower

Could be written as:

cablestate = klaxon + computeron + nukepower
rs.setBundledOutput(cableside, cablestate)

There are probably other instances of improving it, but right now I'll be improving my program to account for bundled cable output...once I deplete my cells so my reactor doesn't explode! />

Ha, yeah, I thought about that change too, but I had already done it the other way before it occurred to me I'd need to save the cable state for later if I wanted to add a bit to it, which I did for the coolant monitor portion. If you look, the only time I ever used it was at the very end to power on cooling - at that point I was just "Meh. It works." Main thing I'm wondering is if I should have made separate functions to call on within the elseif chain or if it actually runs faster to just leave it like it is...

Quote

As for hooking up the MFSUs, I will upload another picture to help with preparing them.
Basically, the power from the reactor goes into the first MFSU, which has its redstone output set to "Emit if partially filled". This MFSU also sends its power to other MFSUs, which keeps it empty so the redstone signal quirk works as intended. Using MFSUs for this allows any amount of reactor power output from ~64EU to ~256EU, but any value that can be expressed as 2^n (1, 2, 4, 8, 16, 32, etc.) will not work due to the way the quirk works. Any value under 64 might cause the reactor to keep thinking the cells are empty for a moment or two. Any value over 256 might cause the reactor to think the energy storage is full for a moment or two. Any value over 512 is guaranteed to cause the reactor to think it's full and will cause the reactor to constantly flick between on and off until the cells run out or it actually fills the storage.
Note that MFEs and batboxes also work, but they have lower EU input/output so I would recommend just using MFSUs. Also, if your reactor doesn't blow up a baxbox from directly energy input, you really need to improve the design!

That was one part of your original code that I really didn't get (which is why I didn't wind up including it in mine), and after that explanation, it's starting to make more sense. But I'm wondering, is there a problem with simply pumping reactor output into a line of MFSUs and ANDing their output signals to indicate they're all full? Was there some sort of trick you were trying to exploit?

[Hexicube]

elustran, on 28 June 2012 - 09:51 PM, said:

Ha, yeah, I thought about that change too, but I had already done it the other way before it occurred to me I'd need to save the cable state for later if I wanted to add a bit to it, which I did for the coolant monitor portion. If you look, the only time I ever used it was at the very end to power on cooling - at that point I was just "Meh. It works." Main thing I'm wondering is if I should have made separate functions to call on within the elseif chain or if it actually runs faster to just leave it like it is...

That was one part of your original code that I really didn't get (which is why I didn't wind up including it in mine), and after that explanation, it's starting to make more sense. But I'm wondering, is there a problem with simply pumping reactor output into a line of MFSUs and ANDing their output signals to indicate they're all full? Was there some sort of trick you were trying to exploit?

I would expect having it right in there makes it a bit quicker, though with the sleep calls and the small amount of code the difference is insurmountable.

The MFSUs was a trick I discovered with the "Emit if partially filled" setting. Basically, the MFSU emits if it is holding over 512 EU (packet size) but is not full. The way the MFSU is coded causes it to emit 1 tick of redstone signal before sending out its EU that same tick, and my program picks it up to work out 3 possible states from 1 signal. No signal is considered an empty reactor, constant signal is full MFSU, and fluctuating signal is neither. The reason you have to chain the MFSUs is because the first one in the chain (which gives out the signal) needs somewhere to send that power, so it doesn't emit a constant signal.
I only discovered this because I thought it would only emit once it passed about half full. />
You could easily just have the 2nd one in the chain set to emit when full, but that would have the effect of causing the program to think the reactor is empty. However, this has no effect on the usual running of things, as a full reactor or an overheat overrides this and turns it off.


Also, if you didn't initially notice, I added a second version of my code that only uses a single bundled cable, to avoid all the mess. />

[elustran]

Hexicube, on 28 June 2012 - 10:39 PM, said:

elustran, on 28 June 2012 - 09:51 PM, said:

Ha, yeah, I thought about that change too, but I had already done it the other way before it occurred to me I'd need to save the cable state for later if I wanted to add a bit to it, which I did for the coolant monitor portion. If you look, the only time I ever used it was at the very end to power on cooling - at that point I was just "Meh. It works." Main thing I'm wondering is if I should have made separate functions to call on within the elseif chain or if it actually runs faster to just leave it like it is...

That was one part of your original code that I really didn't get (which is why I didn't wind up including it in mine), and after that explanation, it's starting to make more sense. But I'm wondering, is there a problem with simply pumping reactor output into a line of MFSUs and ANDing their output signals to indicate they're all full? Was there some sort of trick you were trying to exploit?

I would expect having it right in there makes it a bit quicker, though with the sleep calls and the small amount of code the difference is insurmountable.

The MFSUs was a trick I discovered with the "Emit if partially filled" setting. Basically, the MFSU emits if it is holding over 512 EU (packet size) but is not full. The way the MFSU is coded causes it to emit 1 tick of redstone signal before sending out its EU that same tick, and my program picks it up to work out 3 possible states from 1 signal. No signal is considered an empty reactor, constant signal is full MFSU, and fluctuating signal is neither. The reason you have to chain the MFSUs is because the first one in the chain (which gives out the signal) needs somewhere to send that power, so it doesn't emit a constant signal.
I only discovered this because I thought it would only emit once it passed about half full. />
You could easily just have the 2nd one in the chain set to emit when full, but that would have the effect of causing the program to think the reactor is empty. However, this has no effect on the usual running of things, as a full reactor or an overheat overrides this and turns it off.


Also, if you didn't initially notice, I added a second version of my code that only uses a single bundled cable, to avoid all the mess. />

Cool - it's very useful to see the commenting. I'm not sure if it will cause a problem for you or not, but since you mentioned the code was untested, I thought I'd mention this - I never used rs.getBundledInput in my code since I'm pretty sure it gets *all* the active bits on the cable and doesn't let you test for a single color. I wound up using rs.testBundledInput to get the boolean for only the bit I wanted to check for.

[Hexicube]

elustran, on 29 June 2012 - 06:16 AM, said:

Hexicube, on 28 June 2012 - 10:39 PM, said:

elustran, on 28 June 2012 - 09:51 PM, said:

Ha, yeah, I thought about that change too, but I had already done it the other way before it occurred to me I'd need to save the cable state for later if I wanted to add a bit to it, which I did for the coolant monitor portion. If you look, the only time I ever used it was at the very end to power on cooling - at that point I was just "Meh. It works." Main thing I'm wondering is if I should have made separate functions to call on within the elseif chain or if it actually runs faster to just leave it like it is...

That was one part of your original code that I really didn't get (which is why I didn't wind up including it in mine), and after that explanation, it's starting to make more sense. But I'm wondering, is there a problem with simply pumping reactor output into a line of MFSUs and ANDing their output signals to indicate they're all full? Was there some sort of trick you were trying to exploit?

I would expect having it right in there makes it a bit quicker, though with the sleep calls and the small amount of code the difference is insurmountable.

The MFSUs was a trick I discovered with the "Emit if partially filled" setting. Basically, the MFSU emits if it is holding over 512 EU (packet size) but is not full. The way the MFSU is coded causes it to emit 1 tick of redstone signal before sending out its EU that same tick, and my program picks it up to work out 3 possible states from 1 signal. No signal is considered an empty reactor, constant signal is full MFSU, and fluctuating signal is neither. The reason you have to chain the MFSUs is because the first one in the chain (which gives out the signal) needs somewhere to send that power, so it doesn't emit a constant signal.
I only discovered this because I thought it would only emit once it passed about half full. />
You could easily just have the 2nd one in the chain set to emit when full, but that would have the effect of causing the program to think the reactor is empty. However, this has no effect on the usual running of things, as a full reactor or an overheat overrides this and turns it off.


Also, if you didn't initially notice, I added a second version of my code that only uses a single bundled cable, to avoid all the mess. />

Cool - it's very useful to see the commenting. I'm not sure if it will cause a problem for you or not, but since you mentioned the code was untested, I thought I'd mention this - I never used rs.getBundledInput in my code since I'm pretty sure it gets *all* the active bits on the cable and doesn't let you test for a single color. I wound up using rs.testBundledInput to get the boolean for only the bit I wanted to check for.

Totally forgot about that...I will have to change it to testBundledInput! />

[Hexicube]

Changed second program to use testBundledInput instead of getBundledInput, and fixed a typo in the config section.

[HelenB]

Hexicube, on 23 June 2012 - 12:28 PM, said:

Paukinra, on 19 June 2012 - 08:25 AM, said:

Hey, been trying to get this to work but I keep getting this error when trying to run the program as startup:

bios:206: [string "startup" ] : 26 : '=' expected

Any ideas what mgith be wrong?


Also, I am a little confused as the which cables I need and where they go, whould it be possible to get a pretty picture? />

I'll make some nice pictures to help with setting it up. As for the problem, I'd double check you entered it right, it works perfectly fine for me with vanilla tekkit and no extra APIs.
[edit] Done, if you want I could make a fresh world and construct a setup using the default settings for download...

Please do because I can't get my head around any of this and ccSensors is buggy and wont let me do what I want it to do. I'd like to learn from a save because I'm a visual learner and I need to see things in action and discover them to get my head around things.

[Hexicube]

HelenB, on 06 July 2012 - 01:35 PM, said:

Hexicube, on 23 June 2012 - 12:28 PM, said:

Paukinra, on 19 June 2012 - 08:25 AM, said:

Hey, been trying to get this to work but I keep getting this error when trying to run the program as startup:

bios:206: [string "startup" ] : 26 : '=' expected

Any ideas what mgith be wrong?


Also, I am a little confused as the which cables I need and where they go, whould it be possible to get a pretty picture? />

I'll make some nice pictures to help with setting it up. As for the problem, I'd double check you entered it right, it works perfectly fine for me with vanilla tekkit and no extra APIs.
[edit] Done, if you want I could make a fresh world and construct a setup using the default settings for download...

Please do because I can't get my head around any of this and ccSensors is buggy and wont let me do what I want it to do. I'd like to learn from a save because I'm a visual learner and I need to see things in action and discover them to get my head around things.

I made a world showing the software and all of the option wiring hooked up (uses second version of software)...see first post...
Also, I fixed some bugs in the code for the second software, 5 misnamed variables...

[Hexicube]

Just realised I didn't hook up the reactor to the MFSUs in the example world, fixed it...

[HelenB]

Hexicube, on 06 July 2012 - 02:55 PM, said:

Just realised I didn't hook up the reactor to the MFSUs in the example world, fixed it...

Woah it's quite EPIC! I filled my reactor up to the brim with Uranium and the system controlled it! />

I can improve your setup. Use glass fibre cable from the reactor to the MFSUs instead of that green insulated cable.