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

Need help with waiting for multiple events

Started by Gyronimo, 05 August 2013 - 06:57 PM
Gyronimo #1
Posted 05 August 2013 - 08:57 PM
Here's the gist…
I'm trying to make a security system with a forcefield. the outside uses a terminal that needs to be unlocked with a password, while on the inside, I use a touch screen I activate to send off a rednet message to the first machine.
I've tried using a method from this forum (http://www.computerc...ultiple-events/). However, it doesn't work on the first conditional statement, only the second (I've marked it in the code).

I hope you understand what I mean, and if you can help me with this, I'll be forever thankful.

- Gyro

edit: screwed up code


local access = {
  a = "Access Granted",
  b = "Access Denied",
  c = "Invalid"
}

function setText(color, x, y)
  term.setTextColor(color)
  term.setCursorPos(x, y)
end

local key2 = false

while key2 == false do
  sleep(2)
  rednet.open("left")
  term.clear()
  setText(colors.white, 1, 1)
  write("Press any key to continue")
	  
  local event, p1, p2, p3 = os.pullEvent()

  if event == "rednet_message" then  --#THIS IS THE LINE THAT DOES NOT FIRE
	local id = p1
	local msg = p2
	
	if msg == "1" and rs.getOutput("bottom") then
	  rs.setOutput("bottom", false)
	elseif msg == "1" and not rs.getOutput("bottom") then
	  rs.setOutput("bottom", true)
	end

  elseif event == "key" then
	term.clear()
	setText(colors.white, 1, 1)
	textutils.slowPrint("Welcome to ")
	setText(colors.lime, 12, 1)
	textutils.slowPrint("Gyro")
	setText(colors.red, 16, 1)
	textutils.slowPrint("Vault")
	setText(colors.white, 21, 1)
	print("!")
	print(" ")
	textutils.slowPrint("Please enter the admission code")
	write("=>")
	
	w, h = term.getSize()
	local key1 = false
	
	repeat
	  if read("*") == "ducky" then
		sleep(1)
		setText(colors.lime, (w-#access.a)/2, h/2)
		write(access.a)
		key1 = true
		sleep(2)
		term.clear()
	  else
		sleep(1)
		setText(colors.red, (w-#access.B)/>/2, h/2)
		write(access.B)/>/>/>
		sleep(2)
		term.clear()
		setText(colors.white, 1, 1)
		textutils.slowPrint("Please enter the admission code")
		write("=>")
	  end
	until key1 == true
	key2 = true
  end
end

while true do
  term.clear()
  setText(colors.lime, 1, 1)
  write("Gyro")
  setText(colors.red, 5, 1)
  write("Vault")
  setText(colors.white, 1, 3)
  if rs.getOutput("bottom") then
	print("[1]Disable field")
	print("[2]Lock")
	print("[3]Disable field (5 sec)")
  elseif not rs.getOutput("bottom") then
	print("[1]Enable Field")
	print("[2]Enable Field and Lock")
  end
  write("=>")

  rednet.open("left")
  local event, p1, p2, p3 = os.pullEvent()

  if event == "char" then
	local option = p1

	if option == "3" and rs.getOutput("bottom") then
	  rs.setOutput("bottom", false)
	  sleep(5)
	  rs.setOutput("bottom", true)
	elseif option == "1" and rs.getOutput("bottom") then
	  rs.setOutput("bottom", false)
	elseif option == "2" and rs.getOutput("bottom") then
	  shell.run("test")
	elseif option == "1" and not rs.getOutput("bottom") then
	  rs.setOutput("bottom", true)
	elseif option == "2" and not rs.getOutput("bottom") then
	  rs.setOutput("bottom", true)
	  shell.run("test")
	else
	  setText(colors.red, (w-#access.c)/2, h/2)
	  write(access.c)
	end

  elseif event == "rednet_message" then	  --#THIS LINE FIRES
	local id = p1
	local msg = p2
	
	if msg == "1" and rs.getOutput("bottom") then
	  rs.setOutput("bottom", false)
	elseif msg == "1" and not rs.getOutput("bottom") then
	  rs.setOutput("bottom", true)
	end
	shell.run("test")
  end
end
Lyqyd #2
Posted 05 August 2013 - 09:08 PM
Split into new topic.
Gyronimo #3
Posted 05 August 2013 - 09:53 PM
We're still running 1.4.7, as we are using the mindcrack pack from FTB. Also, the second event does fire, just not the first one :/
Lyqyd #4
Posted 05 August 2013 - 10:34 PM
So, when it is sitting at "press any key to continue", it fails to see any rednet messages come in? You've used debug prints to verify that it is receiving the events, but that the if statement isn't catching them? I'd suggest using some debug prints to verify exactly what's going on if you haven't already done so.
Gyronimo #5
Posted 05 August 2013 - 10:45 PM
This is what's so strange.. I did use a debug print on line 18(just below term.clear() ), and it showed up after I sent the message, but nothing happened to my forcefield.

I know the message I send is correct, because I sat up a second computer to print out the message it recieved after I broadcasted it (just in case), and it printed the correct message.

I also know that all the wiring is correct, because when I use the "char" event in the second loop, it turns the forcefield on and off.

edit: got the line wrong :P/>
Lyqyd #6
Posted 05 August 2013 - 10:48 PM
What did debug prints in the if statements turn up, as to whether it thinks it's turning the redstone on/off?
Gyronimo #7
Posted 05 August 2013 - 10:54 PM
It's as if it loops around without doing anything, untill it comes back around to "press any key to continue".

I'm going to try putting in some more of them.. maybe I'll come up with something
Gyronimo #8
Posted 05 August 2013 - 11:00 PM
wow….. I have no idea what happened, but I put in debug prints everywhere, and suddenly everything just worked :S I'm really confused now..
I suppose it might have something to do with lag or something with the server in some way, but I'm not sure.

Thanks for the reply guys!
Lyqyd #9
Posted 05 August 2013 - 11:50 PM
Please provide reliable reproduction instructions to create a scenario in which rednet_message events do not fire under conditions in which they should. If you can provide those, please post that in Bugs. If you cannot, you need to stop posting that rednet is deprecated, or that rednet_message events don't work correctly, or that it's buggy. All of that is incorrect information, which is unacceptable in answer posts in Ask a Pro.
GopherAtl #10
Posted 05 August 2013 - 11:55 PM
to help, here are the conditions on which rednet_message events fire:

* rednet.open() was called on the side the modem_message came from.
* the message came on the computer's id frequency or on the broadcast frequency.

… and that's the whole list.

opening those frequencies directly through the modem will not cause them to fire. I have seen no evidence of inconsistency in this behavior, so I am guessing you perceived inconsistency because you weren't aware of exactly what these conditions were.