So I’ve seen a lot of people asking about how channels work and what they should do to activate specific things, but haven’t been able to find a good guide that really explains the answer. So I decided to make one myself.
What channels do
Channels do the same thing wires do, just not visibly. Wires are easier if you’re less experienced with GKC, because they’re visible and you can see what’s going on all the time.
How to use channels
Channels can be set within a device’s settings, accessible by clicking on a device. When in there, you’ll see settings like these:
In those text boxes, you can enter the name of a channel. If it says “when _____, transmit on” then it’s like the beginning of a wire.
If it says “______ when receiving on” then it’s like the end of a wire.
If one button has “when button pressed, transmit on” set to “DeactivateButton” (that being an example of what you could name a channel), and another button had “deactivate button when receiving on” set to “DeactivateButton” (the same channel), then when you pressed the first button, the second one would be deactivated - just like if you wired the first one to the second one.
So, yeah. Channels work the same way as wires.
Channels carrying messages
Let me ask you a question.
Let’s say you’ve wired a button to a notification with the following settings:
button pressed > send notification
A player that presses the button will be sent the notification. That’s obvious.
But have you ever thought about… why?
Nowhere in the settings of the devices and wires is there anything that dictates who the notification sends to.
But it sends to the triggering player…
This shows us that wires carry a message greater than just “send the notification”.
Their message also contains the triggering player.
And it’s the same with channels.
Channels carry the action, and the triggering player.
And the reason this is especially good for channels brings us to the next chapter…
Why use channels?
So what have we learned now?
Channels work exactly the same as wires, except wires are visible and easier to use.
So why use channels?
Well, let’s make a list (i love lists).
Reason 1: There’s no limit.
There is a limit of 6 wires going in or out per device.
You can’t have more than 6 wires going out of a device or into a device.
However, this limit can be easily bypassed with chained wire repeaters.
Simply wire a device to 6 wire repeaters, and you can wire each of those wire repeaters to 6 other devices (whilst still carrying over all the data of the wire’s message), allowing you to essentially wire one device to 36 other devices.
So this isn’t really as important a reason.
However…
Reason 2: Memory
Wires use memory.
10 per wire, in fact.
This doesn’t sound like a lot, but wires and channels are one of the most vitally important parts of any GKC map. Wires can use hundreds, usually thousands of memory in one map.
Channels, on the other hand, require no memory, making them much better to use if you need a lot of them in your map.
Reason 3: Self-messages
Having a device send a message to itself can be a super useful thing to be able to do when building in GKC. For example, maybe you have a button that should deactivate when it’s pressed. However, if you’ve ever tried this with wires, you’ve probably noticed that you can’t wire a device to itself.
But as you may have guessed, this is easily possible with channels.
Now, sure, you could just use a wire repeater, but that takes up space and, counting the wires, uses a total of 25 memory. So why do it?
Reason 4: Blocks
This is arguably the most important reason on this list.
Aside from property changing, channels are the only way to make blocks do stuff. In a block, after you run all the code, to get the message outside of the block and into devices, you either need to update a property, or transmit on a channel. There’s no way to just take the output of your block code and just yeet it down a wire. You have to transmit on a channel.
Reason 5: Waypoints
This final reason is what actually prompted me to make this guide in the first place.
Waypoints.
Assuming you know how a waypoint works (if not, read this guide), you probably know that it can track either it’s own location, a flag’s location, or a player’s location. The first two of those are pretty easy to set up, but I’ve seen quite a lot of confusion over the final one.
If you’ve ever tried to have a waypoint track a player using wires, you’ll notice it’s not possible. The only wiring options are to activate and deactivate the device.
To have a waypoint track a player, you need to use channels. There’s a setting in the device, “start tracking player when receiving on”, which is how you do it.
As I talked about before, the player that is in the channel’s data (the triggering player) will be the one the player starts tracking. So if you want a waypoint to track a specific player, you’ll have to have that player trigger something that broadcasts on a channel. You could use blocks to pick a player by their name (let me know if you want an actual tutorial on that), or use a relay to pick a random player, or whatever you want, it’s up to you.
So that’s my list of reasons on why you should use channels rather than wires.
Conclusion
So in conclusion, what do I think you should take out of this?
Should you always use channels and never wires?
Well, not necessarily.
Wires are way easier if you are short on time and/or just want to connect two devices quickly, and they are visual, making it easier to see what’s going on in your map, especially if you aren’t as much of an organized person. However, channels incredibly versatile and are great for many special functions such as the ones I listed above. Also, too many wires can get a little cluttered and also take a bigger toll on your computer’s performance, so if you don’t have as good of a computer, I reccomend channels, especially if you need a lot of them.
I hope you learned something about channels from this guide! If you did, be sure to give it a 
!
If you already knew everything I talked about, then maybe reply with a suggestion on something I didn’t talk about that I should add!
Thank you for reading!
