This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
Backplague's profile picture

[Lua] 'if' not working?

Started by Backplague, 13 November 2012 - 08:48 AM
Backplague #1
Posted 13 November 2012 - 09:48 AM
I do see this question has been asked multiple times but none of them seemed to have helped me in my problem.
So i have this code (just a part of a larger code):

a1 = -1
if a1 == 1 then
write("[X]")
elseif a1 == -1 then
write("[_]")
else
write("[O]")
end
write(" 0 " .. a1)
As you see, this code should write "[_]". Note; "should" write, since it actually writes "[O]" a1 being -1 or 1. But the last line still writes " 0 -1". I have no idea why this is happening, i am kind of suspecting a Lua bug?
Fiery Arcanine #2
Posted 13 November 2012 - 09:59 AM
If you please can be more detailed.
What is the error?
And just a part of a code is probably not enough
Doyle3694 #3
Posted 13 November 2012 - 10:00 AM
post the whole code.
PixelToast #4
Posted 13 November 2012 - 10:01 AM
i dont get what you are trying to do
it writes " 0 -1" because it is out of the if statement
so it will do that regardless of what a1 is
remiX #5
Posted 13 November 2012 - 10:33 AM
Well your minecraft is bugged then, lol
Lyqyd #6
Posted 13 November 2012 - 11:05 AM
If works perfectly well. As Doyle said, we will need to see the whole code.
Backplague #7
Posted 15 November 2012 - 01:48 AM
Entire code in its entirety.


rednet.open("left")
local mainframeID = 0
a1 = -1
a2 = -1
a3 = -1
function parseString(str)
output = {}
for match in string.gmatch(str, "[^ t]+") do
  table.insert(output, match)
end
return output
end
function drawInterface()
term.clear()
term.setCursorPos(1, 3)
if a1 == 1 then
  write("[X]")
elseif a1 == -1 then
  write("[_]")
else
  write("[O]")
end
write(" 0 " .. a1)

term.setCursorPos(1, 4)
if a2 == 1 then
  write("[X]")
elseif a2 == -1 then
  write("[_]")
else
  write("[O]")
end
write(" 1 " .. a2)

term.setCursorPos(1, 5)
if a3 == 1 then
  write("[X]")
elseif a3 == -1 then
  write("[_]")
else
  write("[O]")
end
write(" 2 " .. a3)
end
function handleInput()
while true do
  event, p1, p2, p3 = os.pullEvent()
  if event == "mouse_click" then
   if p2 == 2 then
    if p3 == 3 then
	 rednet.send(mainframeID, "setState 0 " .. (a1 * -1))
    elseif p3 == 4 then
	 rednet.send(mainframeID, "setState 1 " .. (a2 * -1))
    elseif p3 == 5 then
	 rednet.send(mainframeID, "setState 2 " .. (a3 * -1))
    end
   end
  elseif event == "rednet_message" then
   if p1 == mainframeID then
    msgArgs = parseString(p2)
    if msgArgs[1] == "sendState" then
	 if msgArgs[2] == "0" then
	  a1 = msgArgs[3]
	 elseif msgArgs[2] == "1" then
	  a2 = msgArgs[3]
	 elseif msgArgs[2] == "2" then
	  a3 = msgArgs[3]
	 end
    end
   end
  end
 
  drawInterface()
end
end
drawInterface()
handleInput()
Orwell #8
Posted 15 November 2012 - 08:34 AM
You reassign a1 in this line at the bottom of the script:

a1 = msgArgs[3]

But msgArgs is a table of strings (the result from parseString(p2)), so a1 is a string now. And the if statement says:

if a1 == 1 then ...
But a1 is now "1", not 1 (a string instead of a number). To fix this, you should change the earlier mentioned line at the bottom to:

a1 = tonumber( msgArgs[3] )
You should also do this for the other lines that reassign a2 and a3.
CoderJohn #9
Posted 15 November 2012 - 03:25 PM
Actually to avoid error you should change it to:


a1 = tonumber( msgArgs[3] ) or -1;

-1 can be any number, it's just if you use tonumber on a string that isn't a number(ie "abc" or "123ab")
it will return nil. And assuming you want to keep a1 a number at all times you should add an "or some_number" so that it is a number even if tonumber returned nil
Orwell #10
Posted 15 November 2012 - 08:27 PM
Calling rednet.send with a negative number also raises an error, so -1 is no option. Also, it's a better practice to raise an error than to silently proceed and sending everything to the wrong id. Of course it's an even better practice to handle the nil value and to let the user correct this during runtime. If the id isn't read from user input, but rather derrived by the program itself, assertions are even better, so you can spot programming errors.

Anyway, good call to mention the exceptions, I was only trying to make it not too complicated yet so the OP could understand the issue. But handling exceptions is really a must actually.