Short range Rednet. (not modem)

Upcoming 1.5 version rednet support only Modems. And even Modems are insecure in it.
There are cases, when Turtle need to have other Peripherals, so rednet is unusable.

So I suggest Rednet to be able to open connectons between side-by-side computers.
All types of computers and turtles of course.

Basically I want computers to have peripheral method "send" to emit corresponding event with message as a parameter.

What?

Cloudy, on 10 February 2013 - 08:44 PM said:

What?

He wishes that 2 computers or turtles or a combination of both have the ability to send messages between each other without needing a modem… for a more 'secure' rednet method. although i don't know where it would ever be useful or used.

It seems I have trouble to explain in english again.

Security is not the main reason here but a valid reason too.
If Turtle has any tool and an upgrade, it has no place for Modem. So it unable to communicate at all. Write on a diskette is the only option without a side mods. Rednet is unusable for it.
Also if you have two Computers side-by-side, it's quite logical to be able to send messages directly. Computers are able to exchange information with any peripheral except themselves.

I understand a wish to make long range connection unreliable, but short range reliable should exist.

Soooo like NFC in phones?

What this person means is, that two computers side-by-side should be connected, being able to give eachother messages. Think of it as a LAN cable, just built-in and invisible.

This would be pretty useful.

I would think that it would work much like the bundled cable rednet DID, but only if two computers are right next to each other. In this sense, it would be possible to make a massive, 'super processing' computer amalgomation… sounds scary………. :(/>

I think this would be useful, and would best be done by adding a new peripheral call to computers, maybe peripheral.call("back",send,"Hello")

Yes, peripheral.call(…) to make a message event on another computer. Can we have true id here?

Thanks for all your responses here. :)/>

Uh PC<->Disk Drive<->PC maybe?

Sebra, on 12 February 2013 - 07:20 AM said:

Yes, peripheral.call(…) to make a message event on another computer. Can we have true id here?

Thanks for all your responses here. :)/>

true id is for lazy people :D/>

I like this. You get my vote.

Direct comp to comp IO sounds great. + 1

Sounds nice, but, not necessary, you could just check the ID of the computer sending the message, and use rednet.send() to only send to one computer. Nobody can intercept your message, and nobody can send fake messages. But I would like a file transfer from computer to computer, that would be amazing, but a giant computer cube sounds amazing!

Is it just me, or does it also sound considerably less capable than a single computer?

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

Is it just me, or does it also sound considerably less capable than a single computer?

A massive supercomputer amalgamation? Yes, that's pretty pointless. But there are other uses for this, mostly with turtles - have you ever been annoyed about needing to use up a peripheral slot for a modem to send messages to a computer/turtle one block away? Maybe your turtle already has two peripherals, or a tool and a peripheral.

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.

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.

I don't think it is super computers that this would be best but more peripheral attachment points would be nice specifically for hight band width devices like monitor redirection would be better from a fixed connection instead of broadcast.

mailmanq, on 12 February 2013 - 04:34 PM said:

Sounds nice, but, not necessary, you could just check the ID of the computer sending the message, and use rednet.send() to only send to one computer. Nobody can intercept your message, and nobody can send fake messages. But I would like a file transfer from computer to computer, that would be amazing, but a giant computer cube sounds amazing!

Not anymore, 1.5 rednet uses channels, not ids. The rednet API still seems to give you the sender ID but it actually doesn't the rednet API just defaults to send the PC ID as reply channel. Anyone else could send you a message on your ID channel with someone elses ID as reply channel though. Anyone can listen to channels.

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

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.

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.

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.

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.

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?

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.

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.

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.

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)

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)

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.

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*

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.

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.

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".

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.

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

just thought i might post this from IRC here

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.

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

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

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

just thought i might post this from IRC here

I should really be on IRC more often….

Hm, VERY interesting picture.
As it connected to Monitor it is definitely peripheral cable. But is also connects two Computers.
Is it means it can work as a LAN cable too?
Is it mean LAN connection identical to Peripheral?
Is it mean LAN messaging share interface with Peripherals?
It seems it is more than I ask for.

Sebra, on 16 February 2013 - 05:07 AM said:

Hm, VERY interesting picture.
As it connected to Monitor it is definitely peripheral cable. But is also connects two Computers.
Is it means it can work as a LAN cable too?
Is it mean LAN connection identical to Peripheral?
Is it mean LAN messaging share interface with Peripherals?
It seems it is more than I ask for.

Computers can also be wrapped as peripherals.

Cloudy, on 16 February 2013 - 02:29 AM said:

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

I think you were trying to be funny. You may have succeeded. But just to clarify, it's not about having all peripherals at once in one computer, it's about being able to have moving computers sharing their peripheral capabilities over a wireless network, or forget about sharing, in general just being able to connect to a wireless network. From there on people can build swarms of turtles that effectively has several peripherals at use (in different turtles), but IMO, the means (e.g. the programming needed for such a thing) would justify the end result ('ALL THE PERIPHERALS AT ONCE', one per turtle in a swarm). That is, there won't be a need for more than modem+peripheral, because that would allow already to network several peripherals.

Dlcruz129, on 16 February 2013 - 06:56 AM said:

Spoiler

Sebra, on 16 February 2013 - 05:07 AM said:

Hm, VERY interesting picture.
As it connected to Monitor it is definitely peripheral cable. But is also connects two Computers.
Is it means it can work as a LAN cable too?
Is it mean LAN connection identical to Peripheral?
Is it mean LAN messaging share interface with Peripherals?
It seems it is more than I ask for.

Computers can also be wrapped as peripherals.

But they cannot send messages between themselves yet.

Have those red outlines told you something?

Sebra, on 16 February 2013 - 08:13 AM said:

Dlcruz129, on 16 February 2013 - 06:56 AM said:

Spoiler

Sebra, on 16 February 2013 - 05:07 AM said:

Hm, VERY interesting picture.
As it connected to Monitor it is definitely peripheral cable. But is also connects two Computers.
Is it means it can work as a LAN cable too?
Is it mean LAN connection identical to Peripheral?
Is it mean LAN messaging share interface with Peripherals?
It seems it is more than I ask for.

Computers can also be wrapped as peripherals.

But they cannot send messages between themselves yet.

Have those red outlines told you something?

Wired modems, also peripheral cable functionality

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.

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.

Turtle movement does eat rednet, but you're not going to be communicating with an adjacent computer while moving, are you?

Direct comp to comp IO already exists.

Just use the rednet suite of commands on the side the other computer is on.

zekesonxx, on 16 February 2013 - 12:41 PM said:

Direct comp to comp IO already exists.

Just use the rednet suite of commands on the side the other computer is on.

Could you explain how to do that ??

zekesonxx, on 16 February 2013 - 12:41 PM said:

Direct comp to comp IO already exists.

Just use the rednet suite of commands on the side the other computer is on.

We removed bundled cable rednet.

Cloudy, on 16 February 2013 - 12:50 PM said:

zekesonxx, on 16 February 2013 - 12:41 PM said:

Direct comp to comp IO already exists.

Just use the rednet suite of commands on the side the other computer is on.

We removed bundled cable rednet.

Oh. Well then you can't do that.

Cloudy, on 16 February 2013 - 02:29 AM said:

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

I don't want to have all the peripherals at once on one computer, just a way to have one peripheral on a turtle and still send messages from it.
Edit: Coolis already said something similar.

zekesonxx, on 16 February 2013 - 12:59 PM said:

Cloudy, on 16 February 2013 - 12:50 PM said:

zekesonxx, on 16 February 2013 - 12:41 PM said:

Direct comp to comp IO already exists.

Just use the rednet suite of commands on the side the other computer is on.

We removed bundled cable rednet.

Oh. Well then you can't do that.

You could copy rednet from 1.481, or make your own system. It's slow though. Although 16x as fast as WRCBE.

if you want a wireless X turtle where X is some turtle peripheral add-on, talk to the addon author. OCS has wireless sensor turtles; If OCS can make the sensor peripheral left-side-mountable, then other peripherals can too.

it's better to have "left-side-mountable" Modem than all other peripherals.

A way to talk side-by-side still needed.

GopherAtl, on 16 February 2013 - 04:39 PM said:

if you want a wireless X turtle where X is some turtle peripheral add-on, talk to the addon author. OCS has wireless sensor turtles; If OCS can make the sensor peripheral left-side-mountable, then other peripherals can too.

I didn't know that all turtle upgrades got their own wireless version (that's what I seemed to be told on IRC). If that's the case, the whole swarm thing is doable.

So looking at the new Wired Modem in beta I see it will not help here. New modems can help to make short or long range between Computers.
Turtle cannot use Networking Cable. Modem breaks if block it attached is broken.
And it is still not logical to be able to send info to any peripheral except two smartest: Computers and Turtles.
Easiest way would be to add "send" peripheral method to queue message event in connected Computer/Turtle.

Not happening.

Understood. :(/>

We've not counted out Turtles interacting with modems yet, though.

I understand you want computers to be dumb/mute/inarticulate without modems.
Just quote the way Wired Modem can be usable with Turtles.

Spoiler

immibis, on 31 August 2012 - 02:52 PM said:

This peripheral is the interface between a network and a computer. It must be placed on the side of a block, but will stay even if that block is removed - this allows it to be used with turtles.

why doesn't someone just make a peripheral that you can call peripheral.call("front","send","hi") and it will queue a message event on all linked computers/turtles? then a turtle can arrive, place a link and use it to commune with another turtle or you can have static link points. I would do it myself but I don't know java

Such peripheral can help. But it cannot be so convenient as direct connection could be.
For Turtle to Turtle messaging on a field you need to place it in the world. Two Turtles talking do not touch each other so unable to send items without moving. Possible but not so convenient.

Cloudy, on 25 February 2013 - 11:30 PM said:

Not happening.

well it seems your best option at this point :D/>

Sebra, on 28 February 2013 - 06:49 AM said:

Such peripheral can help. But it cannot be so convenient as direct connection could be.
For Turtle to Turtle messaging on a field you need to place it in the world. Two Turtles talking do not touch each other so unable to send items without moving. Possible but not so convenient.

know what would be the most convenient of all? the ability to arbitrarily send whatever you want to any computer anywhere in the world. It could be part of the magic api,
magic.sendWithoutRednet(target,msg)

Fits in well with the other functions in the magic api
magic.getBlockID(x,y,z)
magic.reproduce(numChildren)
magic.fetchDiamonds(howMany)

my point being, convenience is in no way a major critera for whether features will be added. Plausibility, consistency, and sure, usefulness - but usefulness and convenience aren't the same thing. If anything, there is an effort deliberately made no to make things too easy.

My suggestion here simple, logical, convenient and useful.
Your magic interface not logical. It is extremely overpowered. It may be useful for some things and even simple as possible. But it breaks significant part of game.
I know about ability to communicate with any computer on any distance in any dimension of most worlds. It is called "internet".
My suggestion here is not overpowered. Only short distance, only direct contact. Like com-com, lpt-lpt, usb-usb cables.
My suggestion here is logical. Now computers are dumbest peripheral of all. They are unable to receive information directly, only simple on/off.
Imagine two people on a field, unable to speak without phones(modems), notebook/pencil(diskette) or other "hardware".

Actually Sebra. Now that you mention it. Our computers are connected by, the internet is, cables. (Hinting at the new 1.6 cables.) So we'll have the ability to lay out the internet, block by block. Unlimited range, modems will be obsolete for long range data transfer.

But still, two computers next to each other should be able to do something…

EDIT: Wait, the suggestion is literally being able to send rednet messages (that the other computer can receive and choose what to do with) to computers if they're right next to each other. Not directly calling anything, right? I'm saying that because if you could directly call anything then with the cables you could potentially bypass rednet and wrap the computer on the other side of the length of cable and call whatever you want for whatever purpose you want. Without the other computer having a choice. Then my idea of rednet internet but using the cables is ruined.

This suggestion would certainly get my vote - although the cables that will be added in 1.6 will effectively mimic the behaviour of these connections, they will still require at least one block of space to be inserted. For a server cabinet (as an example) space is money, so directly connected computers would be awesome.

Just messaging of course. Nothing more.
And what are you mean by 1.6 cable? Current beta is 1.51.

I just assumed it was 1.6, haha.

mailmanq, on 12 February 2013 - 04:34 PM said:

Sounds nice, but, not necessary, you could just check the ID of the computer sending the message, and use rednet.send() to only send to one computer. Nobody can intercept your message, and nobody can send fake messages. But I would like a file transfer from computer to computer, that would be amazing, but a giant computer cube sounds amazing!

Uhhh, Little Lua Hax0rs can intercept it right?

Direct messaging between computers are possible by using the rs api. Send messages as bits. This is a bit slow, but for short commands this works perfectly. :)/>

Modems have virtual antennas, so they are radio. My opinion is that a better approach for two turtles to communicate to each other very short range is to have some sort of api side controllable power for the modem. maybe being an additional parameter to transmit() or something. Meaning, if you know you're next to a turtle, you could reduce modem transmission power to like 1%. There are many reasons why this would benefit, and one of the biggest ones is "not to interfere or collide" with other in use channels at a reachable distance. One of my biggest problems I face is the fact that modems always run on maximum transmission power, which for rednet isn't a problem because they keep track of ID's, but for other implementations, I have to sit down sometimes and do some trig to figure out proportions of the signal with pencil and paper and implement my own collision prevention solution.

Direct messaging between computers are possible by using the rs api. Send messages as bits. This is a bit slow, but for short commands this works perfectly.

Haha, that's actually kind of awesome Jarle, if not a little insane :D/> ^^

sophiamaster, on 16 March 2013 - 04:14 AM said:

Modems have virtual antennas, so they are radio. My opinion is that a better approach for two turtles to communicate to each other very short range is to have some sort of api side controllable power for the modem. maybe being an additional parameter to transmit() or something. Meaning, if you know you're next to a turtle, you could reduce modem transmission power to like 1%. There are many reasons why this would benefit, and one of the biggest ones is "not to interfere or collide" with other in use channels at a reachable distance. One of my biggest problems I face is the fact that modems always run on maximum transmission power, which for rednet isn't a problem because they keep track of ID's, but for other implementations, I have to sit down sometimes and do some trig to figure out proportions of the signal with pencil and paper and implement my own collision prevention solution.

Direct messaging between computers are possible by using the rs api. Send messages as bits. This is a bit slow, but for short commands this works perfectly.

Haha, that's actually kind of awesome Jarle, if not a little insane :D/> ^^

A bit but it works. :P/>

Only problem with using redstone IO is that it would probably require a sync, as in just like ethernet frames, flashing 1's and 0's so that the other machine knows when to start, and how to pair up 1's and 0's. Something that isn't hard but I wouldn't want to write it for trivial purposes.

sophiamaster, on 16 March 2013 - 01:51 PM said:

Only problem with using redstone IO is that it would probably require a sync, as in just like ethernet frames, flashing 1's and 0's so that the other machine knows when to start, and how to pair up 1's and 0's. Something that isn't hard but I wouldn't want to write it for trivial purposes.

True

i love this idea. but maybe 3-10 block radius.

No. That would be like charging your phone from a cable that is 10 feet away XD

MudkipTheEpic, on 26 March 2013 - 04:16 AM said:

No. That would be like charging your phone from a cable that is 10 feet away XD

lol xD

MudkipTheEpic, on 26 March 2013 - 04:16 AM said:

No. That would be like charging your phone from a cable that is 10 feet away XD

or it could be "Redtooth".

I do think the point of the original post to have them next to each other however.

Only touching by sides. I think Peripheral connection is like USB (universal serial bus).
No magic wireless things. No device needed. No RS message driver launched.

sophiamaster, on 16 March 2013 - 01:51 PM said:

Only problem with using redstone IO is that it would probably require a sync, as in just like ethernet frames, flashing 1's and 0's so that the other machine knows when to start, and how to pair up 1's and 0's. Something that isn't hard but I wouldn't want to write it for trivial purposes.

I wonder how we could solve that problem, hmmmm....

I think i might try and write somthing up for fun tonight.

how about just putting a disk in a disk drive next to both computers and they both access the files

Disc Drive is inconvenient because of:
1. It need block and item which makes it not better than rednet.
2. It need periodic check which makes it worse than rednet.

Here is a topic I made that contains an API that can send messages with bundled cables if someone is intrested

http://www.computercraft.info/forums2/index.php?/topic/11657-laning-cable-communication-api/