Keep receiving, even after receiving a message

Hello,

I've got a program for my turtles, and at different phases of the program, they broadcast their progress, fuel, etc using rednet.broadcast()

I wanted to know if there was a way to use the rednet.receive() on my wireless pocket computer so that it keeps receiving, or until I press a key like enter or something.

Thank you!

You shouldn't really use broadcast. There is a rednet.send() function to send a message directly to a certain computer.

On the pocket computer create a while loop and within that add rednet.receive(). After a message has been received print the info you want to, then the pocket computer will wait for the turtle to broadcast again and repeat.

The_Cat, on 17 November 2016 - 07:44 PM said:

You shouldn't really use broadcast. There is a rednet.send() function to send a message directly to a certain computer.

I disagree. All computers receive the message either way.

KingofGamesYami, on 17 November 2016 - 11:46 PM said:

The_Cat, on 17 November 2016 - 07:44 PM said:

You shouldn't really use broadcast. There is a rednet.send() function to send a message directly to a certain computer.

I disagree. All computers receive the message either way.

Depends on his setup. I was just thinking that if he had multi setups the broadcast would interfere with each of the recieveing computers. But then again I guess you could sort it through the rednet.recieve sender id.

The_Cat, on 19 November 2016 - 10:57 AM said:

Depends on his setup.

No it doesn't. Messages sent through a modem always arrive at all computers with a modem. A rednet send simply has a little flag on it telling rednet.run() to not convert it into a rednet_message event if it's ID doesn't match that of the computer it is running on.

OutrideGaming, on 17 November 2016 - 11:52 AM said:

I wanted to know if there was a way to use the rednet.receive() on my wireless pocket computer so that it keeps receiving, or until I press a key like enter or something.

rednet.receive() indeed simply sits and waits for as long as it takes for a message to arrive. If you want to wait for multiple messages, use a while loop.

If you want to break that loop on a key press, avoid rednet.receive() and instead manually pull the rednet_message events it fetches for you. Eg:

while true do  -- A loop that repeats indefinitely.
	local event, par1, par2 = os.pullEvent()  -- Wait for an event to occur
	
	if event == "rednet_message" then
		-- Do something with the message. par1 is the sender ID, par2 is the message.
		
	elseif event == "key" and par1 == keys.enter then
		break  -- Exit the loop.
	
	end
end

KingofGamesYami, on 19 November 2016 - 01:31 PM said:

Messages sent through a modem always arrive at all computers with a modem.

No, messages sent through rednet are always received by all systems with rednet open (and then only as of CC 1.6). This may not be true for modem messages that are not sent through rednet, or for systems that are set to receive messages without using rednet.

Assuming rednet is in use by multiple systems in the area, using a broadcast does indeed tend to lead to more events being generated than are necessary. It's indeed better to avoid it if it isn't required.

The most accurate description is this:

When a computer transmits a modem message, that message will be received (a modem_message event will be generated) on all computers that are both within range and have the channel it was sent on open. Rednet sends out modem messages on specific channels, either the ID of the desired target computer, or 65535 for broadcasts. Computers with rednet open will create rednet_message events when they receive modem_message events that have a payload matching the format of a rednet message, and that were sent on the channel of that computer's ID or channel 65535.

So, it is indeed better to use rednet.send.

Lyqyd, on 20 November 2016 - 03:02 AM said:

Rednet sends out modem messages on specific channels, either the ID of the desired target computer, or 65535 for broadcasts.

As of CC 1.6, channel 65533 is additionally used either way (enabling the "repeat" script to do its thing) - this is what Yami's on about.

I was mistaken in thinking that all systems with rednet open receive these additional transmissions, though - regular systems don't listen on that channel unless they're specifically running a script that opens it.