well, it's still all pretty cool. if folks took the time, trying to invent something like this can be very educational. If you want to understand how a bunch of computers can all be hooked up to the same hub and Computer A can talk to Computer C, while Computer's B and D ignore the conversation, this is where it starts.
The mental exercise of how to make that happen in redstone gives one insight into how it really was done. Conversely, this is why Nosejob is able to make it work in MC, he understands how it works in the real world, so can work out an analog solution in MC.
It's funny that he mentions telegraph, because in my first post, I was thinking of mentioning that this an advanced form of that.
For the people who "don't understand", I think it's a good thing to try to wrap your head around this. Not the nuts and bolts of exactly what block does what and where in the design. Just work through the principal involved.
Let's say you and I are 500 blocks apart. We can't see each other, but would like to pass a message from one to the other. We're in creative mode, let's say (or duping. whatever).
The simplest thing for me is a telegraph. It's just me pressing a button in a dot and dash pattern that means something, which puts signal on a wire and gives a click or buzz or lights up a light on your end. In MC, we could simulate that with a lever on my end (because I can leave it in the ON position longer for the dashes) a redstone trail from my lever to a piston on your end. imagine we put the repeaters in place to keep the signal up over distance. Repeaters aren't important to the concept, except as a mechanical requirement in the game.
to send a signal of SOS (because monsters are coming), in Morse code that would be ...---... as 3 dots, 3 dashes, 3 dots. A dot is a quick on/off on the lever, a dash is where I turn it on, wait 2 seconds, turn it off.
at this point, you have to watch the piston, and when it starts moving, write down (with paper) the exact order of how long it was in the up position. You'd see the piston pop up and down three times quick, that's the first S. Then you'd see it pop up and stay up for 2 seconds before it pops down three times. That's the O. Then it's do the quick triple pop-up again for the other S.
That's pretty primitive, and requires you to be watching the piston to know I'm trying to tell you something. If you wanted to tell me something back, we'd need a second redstone line for you to send to me and I receive on it. Or, we'd have to break and rewire the line to my piston and your lever, so you could respond. That requires me know you want to reply.
this is where the advanced ideas come in. How can you record the message I send so it'll be waiting for you when you come to look, rather than having to watch the piston?
How can we use the same redstone line instead of running a second line? Traditionally, for 2 stations, it's been acceptable for there to be a pair of lines. One to send, the other to recieve on.
But once you get to 3 or more systems, you don't want to have to run 2 lines per stations to each. That would just get messy. You want to re-use the same 2 lines so that my station listens to its reciever line and figures out what station is talking and what he's saying. The sending station wants to send out on his sending line, but also make sure he only talks when nobody else is talking. Otherwise, it'll just get messy.
this is where networking comes into play.
The idea of an engineering exercise is to figure out how to create a simple version of the real thing, to better improve your understanding of the real thing. You don't have to "create the internet" to complete the exercise. But figuring out how to do it in MC will give you a better understanding of how it was done in the real world, because you'll be solving some of the same problems.
Keep in mind, the original internet and EtherNet had origions on AlohaNet, which was multiple stations on different islands sharing the same radio frequency in hawaii. The goal was to make it so one station could check to see if anybody else was transmitting, if not, then it would broadcast. The other stations listened, and if the actual target heard the message, it recorded it. The other stations ignored it. This is the same engineering problem.
I was actually inspired by something like a telegraph. On YouTube I saw a word processor, (that alone is no simple feat) but it didn't use buttons or pressure pads that are encoded to binary, then decoded to whatever format is necessary for the display. Instead, characters were designated with a single lever, using Morse code. It was sort of a telegraph/typewriter hybrid and, needless to say, I was amazed and still not 100% sure how it even works. This system is a lot simpler, there are no dots and dashes, just one 4-tick pulse size. It would technically be faster to just transmit packets of data in a binary format, but who wants to stretch all of those lines across 500+ meters? Not me, I would much rather use one line that would take a fraction of the time to build, as well as being less of an eyesore.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffI was actually inspired by something like a telegraph. On YouTube I saw a word processor, (that alone is no simple feat) but it didn't use buttons or pressure pads that are encoded to binary, then decoded to whatever format is necessary for the display. Instead, characters were designated with a single lever, using Morse code. It was sort of a telegraph/typewriter hybrid and, needless to say, I was amazed and still not 100% sure how it even works. This system is a lot simpler, there are no dots and dashes, just one 4-tick pulse size. It would technically be faster to just transmit packets of data in a binary format, but who wants to stretch all of those lines across 500+ meters? Not me, I would much rather use one line that would take a fraction of the time to build, as well as being less of an eyesore.