Bundled Cable Problems!

Hi there. So i've just written a program for my light system in a factory I built. I know it is pointless using computercraft for this job as I could do it without very easily but I wanted to see if I could run the system through a computer. The aim of the program is to react to a redstone current and switch all lights on. For some reason when I turn the left input on the lights turn on, yet when I turn it off it they don't turn off. Please can somebody tell me why. Here is my program.


term.clear()
term.setCursorPos(1,1)
print("Waiting for a signal")
for i = 1, 50000 do
sleep(3)
if redstone.getInput("left", true) then
all = colors.combine(all,colors.lime,colors.magenta)
redstone.setBundledOutput("front",all)
elseif redstone.getInput("left", false) then
all = colors.subtract(all,colors.lime,colors.magenta)
redstone.setBundledOutput("front",all)
end
end


i'm new to computercraft so please don't moan at me for getting stuff wrong!
Thank :)/>

firstly don't use a for loop or it will eventually stop working, also why are you using the 'all' var? it is not necessary

while true do --an endless loop
  os.pullEvent() --this will pause your code until an event occurs (redstone changing is an event)
  if rs.getInput('left')==true then --corrected syntax
    rs.setBundledOutput('left',colors.combine(colors.lime,colors.magenta)) --much simpler
  elseif rs.getInput('left')==false then --you can just use 'else' here but just to show correct syntax again
    rs.setBundledOutput('left',0) -- 0 means no output
  end
end

you could actually just say if rs.getInput('left') then without the ==true, that would work too. for the second one you could also say if not rs.getInput('left') then to invert it. give it a whirl

fpfireharden, on 29 November 2012 - 09:52 AM said:

i'm new to computercraft so please don't moan at me for getting stuff wrong!
Thank :)/>

KaoS, on 29 November 2012 - 09:59 AM said:

firstly don't use a for loop or it will eventually stop working, also why are you using the 'all' var? it is not necessary

while true do --an endless loop
  os.pullEvent() --this will pause your code until an event occurs (redstone changing is an event)
  if rs.getInput('left')==true then --corrected syntax
	rs.setBundledOutput('left',colors.combine(colors.lime,colors.magenta)) --much simpler
  elseif rs.getInput('left')==false then --you can just use 'else' here but just to show correct syntax again
	rs.setBundledOutput('left',0) -- 0 means no output
  end
end

you could actually just say if rs.getInput('left') then without the ==true, that would work too. for the second one you could also say if not rs.getInput('left') then to invert it. give it a whirl

No moaning at him!
Actually, though, fpfireharden, you kind of want people to moan at you. KaoS is especially constructive with his moaning. I am not.
Blaaaaargh.

lol I'm not moaning, I'm correcting… but thanks for the compliment

Thanks a lot KaoS this helps! As I said i'm new so I don't really understand much :P/>

One question though, the "while true do" part .. Do you have to set something as true .. or just write while true do?

while true do simply means that it will do something while "true is true". Since true is always true, that will run forever.
It's short for "while true == true do"

Cranium I am not sure how understandable that is to someone who is entirely new to coding. No offence meant of course, I got it fine. I'm sure you will not mind me taking a crack at it

while true do is like an if statement except it is a loop. have you ever tried saying

if true then print('yep') end

it will of course print 'yep' basically as long as the condition between 'while' and 'do' is true it will run so you can say

local num=0
while num~=5 do
  print(num)
  num=num+1
end

that will output

0
1
2
3
4

because as long as num~=5 then it runs, when num==5 then it stops. true is just a way of skipping that. technically 'while 1==1 do' is the same thing

No, technically it is not the same thing. In "while 1 == 1 do", you ask the computer to evaluate whether the numeric value 1 is equal to the numeric value 1, returning the boolean value true if they are equal and returning the boolean value false otherwise. With "while true do" you are simply supplying the boolean value true. The ultimate effect is approximately the same, but one is clearly better and simpler than the other, from a technical perspective.

Logically, we might say that "1 == 1" is materially equivalent to "true". But from the technical perspective of lua coding they are clearly different.

For similar performance reasons, it is better to define a static value like your color combo of magenta and lime up top, like "local colorsML = colors.combine(colors.lime,colors.magenta)". You can also define all to an initial value (if it isn't initially zero) by saying "local all = rs.getBundledOutput("left")", so that you can have this operation work without disturbing any other bundled output on the left side (if all would be zero anyway, then this is just a waste of time). The very best performance option would be to directly use the numeric value of "colors.combine(colors.lime,colors.magenta)" (which should be 36) everywhere in your code (an optimized language would do this automatically), but this would hurt maintainability of your code.

Because lua is not generally heavily optimized during interpretation, these decisions by the programmer make a real difference (if generally a relatively small one, given the performance of modern computers). If you don't intend to ever change your scheme of using lime and magenta as the affected colors to turn on/off, I would recommend using the numeric value 36 instead. But if you think you ever might change it, then initialize their value once in a variable scoped to the program, as the best for maintenance and performance. Using "colors.combine(colors.lime,colors.magenta)" every time you want that value is a poor second for performance and also not the most maintenance friendly option.

Does all this really matter? Isn't "materially equivalent" close enough for all intents and purposes? Technically, yes it matters and there are intents and purposes for which "materially equivalent" isn't close enough. But really, usually it doesn't matter enough to make a noticeable difference and material equivalence is as close to identical as you need.