84 replies to this topic

[BigSHinyToys]

 Cloudy, on 13 February 2013 - 01:16 AM, said:

A solution to this problem will come eventually (valve time).

Conspiracy Theory:
Peripheral cables will be able to have more than one peripheral connected to them per side. Allowing computers to activate more than six.

[immibis]

 ChunLing, on 12 February 2013 - 10:48 PM, said:

Well, as mentioned above, you can use a disk drive to communicate...it is suboptimal for certain purposes, but there's not much you really can't do with a shared drive, communication wise.

I'm not opposed to adding in some kind of networking cable that would allow wired rednet and peripheral methods in the core mod, though. I just thought the idea of a big cube of computers sounded counterproductive.

The suggestion wasn't for cables... just for adjacent computers to be able to communicate.

Using a disk drive requires constant polling.

[ChunLing]

So does rednet. Really, rednet requires more constant polling, since the rednet_message events tend to be lost if they aren't checked constantly, while a file in a shared drive will stay there until it is altered or deleted by one of the computers. You can also do a good bit more with a shared drive...it just means that you're messing about with writing files.

As for cables or not...as mentioned, a cabled peripheral connection allows you to actually do things you couldn't accomplish with a single computer. An expansion of peripheral methods to allow two adjacent computers to communicate doesn't really seem to offer much functional improvement. Perhaps my thinking on the subject is too limited, but the only idea it would seem to enable would be the aforementioned giant cube of computers, which didn't seem functionally an improvement over a single computer.

[immibis]

 ChunLing, on 13 February 2013 - 09:13 PM, said:

So does rednet. Really, rednet requires more constant polling, since the rednet_message events tend to be lost if they aren't checked constantly, while a file in a shared drive will stay there until it is altered or deleted by one of the computers. You can also do a good bit more with a shared drive...it just means that you're messing about with writing files.

Uh, no?
Polling means "repeatedly checking if something has happened, instead of waiting for it to happen."

-- this is polling
while true do
  if stuffHasHappenedYet() then
	respondToStuff()
  end
  sleep(1)
end

while true do
  if fs.exists("disk/sharedDataFile") then
	processRequest()
  end
  sleep(1)
end

-- this is not polling
while true do
  waitForStuffToHappen()
  processStuff()
end

while true do
  local sender, message = rednet.receive()
  processMessage(sender, message)
end

Polling uses more CPU and has higher latency, for obvious reasons.

Quote

As for cables or not...as mentioned, a cabled peripheral connection allows you to actually do things you couldn't accomplish with a single computer. An expansion of peripheral methods to allow two adjacent computers to communicate doesn't really seem to offer much functional improvement. Perhaps my thinking on the subject is too limited, but the only idea it would seem to enable would be the aforementioned giant cube of computers, which didn't seem functionally an improvement over a single computer.

You've never had a computer that controlled one or more nearby turtles?

[ChunLing]

Usually over rednet, but of course I've had computers that controlled turtles by means of a drive (and drives that didn't really need a computer because the contents were static).

Taking your distinction about polling, it is of course true that the file writing system is slower than rednet. But it also doesn't require constant checking, as rednet does. This makes it superior to a non-wireless rednet connection for control of turtles, since they can come by and pick up information written on the disk rather than having to be present (and primed to receive) when the message is sent.

I still may be missing something, but I really don't see how the suggestion as it stands offers any functional improvement at all over using a disk drive for the suggested task.

[immibis]

 ChunLing, on 14 February 2013 - 12:32 AM, said:

Usually over rednet, but of course I've had computers that controlled turtles by means of a drive (and drives that didn't really need a computer because the contents were static).

As an example, imagine you want to control a turtle which moves in a limited range via WRCBE (and you don't have MiscPeripherals). You could place a computer nearby with a modem and a WRCBE receiver, and have the computer translate WRCBE signals into rednet messages. This applies to any other device or peripheral that needs constant attention, not just WRCBE receivers.

 ChunLing, on 14 February 2013 - 12:32 AM, said:

Taking your distinction about polling, it is of course true that the file writing system is slower than rednet. But it also doesn't require constant checking, as rednet does. This makes it superior to a non-wireless rednet connection for control of turtles, since they can come by and pick up information written on the disk rather than having to be present (and primed to receive) when the message is sent.

It's not about the proportion of time spent checking/waiting, it's about having to do it over and over, or just once per message.
On a real computer, waiting for an event (with os.pullEvent, rednet.receive, sleep, etc) would put the CPU into low-power mode until the event occurred. With polling the CPU would keep waking up to check the disk drive, wasting power. Except instead of wasting power it's wasting the Minecraft server's CPU time, and any unnecessary lag is bad, mkay?

Edit: Also, in the filesystem example, the delay is from the sleep(1) which could mean messages are noticed up to a second after they're sent. The actual reading and writing takes negligible time. You could decrease the delay down to 0.05s, one tick, and then you'd be using 20 times the CPU with 1/20 of the maximum delay.

 ChunLing, on 14 February 2013 - 12:32 AM, said:

I still may be missing something, but I really don't see how the suggestion as it stands offers any functional improvement at all over using a disk drive for the suggested task.

Mostly in that it avoids polling.

[ChunLing]

Your example suggested using this to communicate with turtles. Turtles movement functions eat events, and if you use the turtle.native functions, there are significant performance issues since they do not yield. This means that you really can't feasibly just put a rednet_message event in place and have the turtle come get it. The turtle has to be in the right place when the message is sent, so you need to poll for the turtle being there.

Yes, this can probably still be quicker than disk access, taken in absolute terms. But the difference is less than a game tick, which is the threshhold of negligibility for CC.

That's why I was interested in non-turtle (or non-moving turtle) cases in which this would be useful.

In real life, one cannot be cast into a survival situation with no tools or supplies, and build a working computer in less than a day. I'm not saying that CC shouldn't have more expensive recipes, but as long as you can build computers (and particularly turtles) in survival mode, we aren't really talking about realism as it pertains to real life, only as it pertains to a MineCraft world setting.

Constant polling is a strawman, the suggested uses of this contact communication system do not as yet include any constant communication, so the polling would be occasional. And occasional polling is entirely acceptable within the context of measurable time in a MineCraft world.

Of course, it is not up to me to decide whether you've made a case for the utility of this proposed mod. It is simply my opinion that the developers have refused requests that would be more useful than this.

[GopherAtl]

yes, turtle movement eats rednet, but you can always use a coroutine to listen for rednet.

--hold recieved rednet for main thread to process at liesure
local rednetQueue={}

local function rednetListener()
  while true do
	local message = {rednet.receive()}
	rednetQueue[#rednetQueue+1]=message
  end
end

local function mainRoutine()
  while true do
	--do turtle stuff
	--just an example to demonstrate, this coroutine won't get rednet messages during the turn
    turtle.turnLeft()

	--check for rednet messages
	while #rednetQueue>0 do
	  local nextMessage=table.remove(rednetQueue,1)
	  --handle the message
	end
  end
end

parallel.waitForAny(rednetListener, mainRoutine)

[OmegaVest]

Hmm. So, the question has come down to whether or not this would help with turtles. . . After much consideration, and a thorough reading of immibis and ChunLing's arguments, I find that, surprisingly (to me at least), I agree with ChunLing. You don't actually have to keep polling the drive if you use some creative redstone (Hell, why are computers in Minecraft to begin with?). And what I mean by this is: No matter what, the computers (or computer and turtle) would have to be touching for this suggestions implementation to even be relevant to the conversation.

So, we know they will not be moving. If they were, then that case is outside the scope of this suggestion. We also know that turtles and computers can activate redstone. And we know that disk contents are, in fact, static until something changes them. So, basically, if you have it where a simple redstone event would update either the turtle or the computer to check for a single file to be affected. ie. have a file that says "Updated" or "Nothing". Even just "0" or "1".

So, as I see it, this suggestion is about adding a step to take away one step. It's a sidegrade. And not much of one, really, if you have to use it as a peripheral. And, yes, I realize this was nothing more than a rehash of the previous page or so, but maybe we'll all remember that we are talking about the validity of a specific suggestion. And, personally, I don't think it is necessary (and this coming from someone who wanted turtle.dropSelf) if it was only going to be base contact usefulness. A small radius, maybe, but that would be stepping on a few toes, and kinda make modems near-superfluous to the advanced and wasteful coder. (ie. Me)

[CoolisTheName007]

I think the ability to have at least wireless communication and a separate peripheral on a turtle is the only way people will make use of several peripherals over some distance and linked to several mobile computers. Having to maintain physical contact / put a disk on the middle / using redstone it's just too complicated for mobile turtle squads.
Having wireless turtles back / an extra peripheral slot for wireless turtles would be a way to go about it. Otherwise, turtle's as explorer's equipped with peripheral's would have to be coming back to base to report.

[immibis]

 OmegaVest, on 14 February 2013 - 02:17 PM, said:

Hmm. So, the question has come down to whether or not this would help with turtles. . . After much consideration, and a thorough reading of immibis and ChunLing's arguments, I find that, surprisingly (to me at least), I agree with ChunLing. You don't actually have to keep polling the drive if you use some creative redstone

Just tested it, and redstone signals do not pass through disk drives in any way. That means you need two redstone wires, and makes things much bigger, even much bigger than a pair of modems - at least 3x2x3. Why would it be harder to communicate with a 1-block max range than with a 64-block max range?

 OmegaVest, on 14 February 2013 - 02:17 PM, said:

So, as I see it, this suggestion is about adding a step to take away one step. It's a sidegrade. And not much of one, really, if you have to use it as a peripheral.

The suggestion isn't for a new peripheral. You can already use computers and turtles as peripherals themselves, so eg a computer can reboot another computer it's touching. The suggestion is to add a new peripheral method to that which queues a "contact_message" event.

 OmegaVest, on 14 February 2013 - 02:17 PM, said:

And, personally, I don't think it is necessary (and this coming from someone who wanted turtle.dropSelf) if it was only going to be base contact usefulness. A small radius, maybe, but that would be stepping on a few toes, and kinda make modems near-superfluous to the advanced and wasteful coder. (ie. Me)

You've never programmed a turtle do this?

• Wait for command while sitting at base location.
  
• Execute command, possibly moving away from base location.
  
• Return to base location.
  
• Repeat.

Combine that with any communications network not based on wireless modems - so that it can't move with the turtle - and you can see why you'd want a computer to receive messages and queue them for the next time the turtle is idle.

 OmegaVest, on 14 February 2013 - 02:17 PM, said:

(Hell, why are computers in Minecraft to begin with?).

They're not... they're in ComputerCraft, a Minecraft mod. Unless you meant redstone computers.

 CoolisTheName007, on 14 February 2013 - 02:55 PM, said:

Having wireless turtles back / an extra peripheral slot for wireless turtles would be a way to go about it. Otherwise, turtle's as explorer's equipped with peripheral's would have to be coming back to base to report.

If you want wireless communication, you need a peripheral slot. If you don't want wireless communication, you don't need a peripheral slot.
Also if modems had their own peripheral slot there'd be no reason not to put one on every turtle.

 ChunLing, on 14 February 2013 - 12:59 PM, said:

Your example suggested using this to communicate with turtles. Turtles movement functions eat events, and if you use the turtle.native functions, there are significant performance issues since they do not yield. This means that you really can't feasibly just put a rednet_message event in place and have the turtle come get it. The turtle has to be in the right place when the message is sent, so you need to poll for the turtle being there.

You get a peripheral event when the turtle moves next to the computer and a peripheral_detach event when it moves away. Alternatively, you could program the turtle to send a message to the computer every time it finishes a task and is ready for another.
You won't be using any turtle functions while receiving contact messages, because then the turtle would be moving so it wouldn't be touching the computer. It doesn't matter if the turtle moves while you're not trying to send it messages, of course, as long as it comes back eventually.
I don't see the relevance of turtle.native here.

 ChunLing, on 14 February 2013 - 12:59 PM, said:

Yes, this can probably still be quicker than disk access, taken in absolute terms. But the difference is less than a game tick, which is the threshhold of negligibility for CC.

I'm not sure if you're talking about latency (time between the message being sent and being received) or server CPU time here.
The latency can be anything up to the polling interval (how often you're checking for messages). Eg: If I send you an email, and you check your email every 24 hours, then it could be up to just under 24 hours before you see it.
The CPU time used for one check is small, much less than a game tick, but it adds up when many turtles are doing it every tick. Probably wouldn't be enough to cause noticeable lag, though.

 ChunLing, on 14 February 2013 - 12:59 PM, said:

Constant polling is a strawman, the suggested uses of this contact communication system do not as yet include any constant communication, so the polling would be occasional.

When communication does occur, how would you notice it without polling? You could poll say every 5 minutes, but then it's up to 5 minutes before the computer notices.
*types command for sorter to put 64 cobblestone in the furnace*
*5 minutes later, sorter turtle notices command and puts 64 cobblestone in the furnace*
*5 minutes later, UI computer notices response and tells me the command was successful*

[ChunLing]

The polling is occasional. If you want the turtle to sit on the drive and wait for a signal that there are new instructions on the drive, you can use redstone. Your dismissal of this possibility is not well supported.

Also, if the turtle is really going to be right there next to the computer, then you can just access the turtle instead of the computer. The system would only be of use for queuing orders while the turtle was otherwise engaged, meaning it only checks when it gets back. Relaying orders through the computer when the turtle is right there is "giant block of computers" territory again, a suggestion which simply has no utility.

I do not like the tone of this conversation, it seems needlessly adversarial. But you are not making a convincing argument that there is any significant utility to the proposed change. Therefore, I will state at this time that, until I state otherwise, I remain unconvinced of the need for the suggested alteration.

[CoolisTheName007]

 immibis, on 14 February 2013 - 05:41 PM, said:

If you want wireless communication, you need a peripheral slot. If you don't want wireless communication, you don't need a peripheral slot.
Also if modems had their own peripheral slot there'd be no reason not to put one on every turtle.

I want more than just communication: I want to be able to use several peripherals attached to moving turtles in a coordinated way (for instance, turtle swarms that use peripherals). That implies communication between the peripheral controller's (the turtles), and rednet was, until now, a way to do it. So, it's not just wireless communication, it's wireless communication + another peripheral.
My point of view is that it would be cool and non-op to have two peripheral slots for turtles, or just a built-in modem in turtles, whichever is easier to implement.
The alternative is (peripheral in turtle)<->(computer/turtle) needing physical contact with a common physical structure (turtle next to turtle, redstone, disk drives, ect) for communication.
Right now:
(turtle with modem)
<-physical structure (disk drive, redstone, ect, i.e. a cumbersome structure to move)
OR queuing events on contact(as it has been proposed here)
->(other computer/turtle with a modem)
does not seem simple enough. Having to keep two turtles moving as one, one with a modem, one with a peripheral, just to communicate results from the peripheral in real-time just seems too sluggish, slow and complicated for CC.

[Sebra]

Thank you, Immibis for understanding of this idea. I would be unable to express it better.

 CoolisTheName007, on 15 February 2013 - 04:26 AM, said:

I want more than just communication: I want to be able to use several peripherals attached to moving turtles in a coordinated way (for instance, turtle swarms that use peripherals). That implies communication between the peripheral controller's (the turtles), and rednet was, until now, a way to do it. So, it's not just wireless communication, it's wireless communication + another peripheral.

You can do swarm now. You can do it with Modem on each Turtle. You just need another Turtle for each tool/peripheral you want to use.

About "supercluster" of several Computers:
There are tasks whch would demand multi-computer system. Unlike real life it will not improve "calculation speed". But quite often you need another Computer to control yet another Monitor, yet another sensor, yet another Peripheral. Also you may want your "main server" to communicate with your "test laboratory".

[CoolisTheName007]

 Sebra, on 15 February 2013 - 04:59 AM, said:

You can do swarm now. You can do it with Modem on each Turtle. You just need another Turtle for each tool/peripheral you want to use.

A turtle with a peripheral that is not a modem is unable to be part of the swarm because it can't communicate with the rest of the swarm via wireless rednet. IMO, that's a shame.

[Sebra]

Oh yes, sorry. I thought Modem is able to be on left side. But it seems Crafting Table is the only exception.

[Pinkishu]

just thought i might post this from IRC here

[CoolisTheName007]

 Pinkishu, on 15 February 2013 - 11:50 PM, said:

just thought i might post this from IRC here
-snip-

Still, it's not what the OP refers to, which was turtles being able to have a peripheral other than a modem and still being able to communicate with computers wirelessly. Peripheral cables require physical contact, just pointing out.

[Pinkishu]

In theory turtles could lay cables behind them or you'd have a " cable-line"

[Cloudy]

People are just so greedy. HAVE ALL THE PERIPHERALS AT ONCE.