Getting Started (Applied Energistics 2) - AE2 Channel Surfing

From Feed The Beast Wiki
Jump to: navigation, search
This guide was originally created by ShneekeyTheLost. Formatting was added by Xbony2.
I hereby give blanket permission to the Official FTB Wiki Team to reproduce, in whole or in part, any mod guide which I post on the FTB website, so long as the works are credited.
I also give permission to the Official FTB Wiki Team to edit the posts to comply with Wiki page formatting guidelines and practices.

AE2 Channel Surfing for Newbies (A Reference Guide for the Rest Of Us!)​[edit | edit source]

By request, I've taken it upon myself to tackle this tricky subject: how to manage your channels for an AE2 ME Network. Hold on to your hard hats, there's gonna be one heck of a text wall under construction.

Definitions and conceptual implications​[edit | edit source]

So, let's make sure we're all on the same page here. Let's define some terminology so there is no miscommunication.

A Data Channel, generally referred to as just a Channel, is the smallest unit of data throughput you have to worry about. Typically, most things that store, detect, retrieve, or otherwise interact with the items in your network will take up one channel.

Signal Bleed is when you have channels from one network 'bleeding over' onto another network, likely shutting both of them down because the number of channels exceeds throughput.

The Power Channel is something I might refer to which just refers to a method of transmitting ME Power but not data. Typically, this break involves using Quartz Fiber and is used to ensure that sub-networks don't get their data crossed.

A Power Crossover is a use of this power channel concept, used to transmit power but not channels to different networks when certain devices are used. In addition to whatever facing might be there (P2P to channel subnetwork, storage bus + interface facing each other, etc...) there is a Fluix Cable 'crossover' which goes around it with a Quartz Fiber break in it at some point to prevent signal bleed.

A Fluix Cable contains eight data channels and the power channel.

A Dense Cable contains 32 data channels and the power channel.

An ad-hoc network is specifically a network which does not have an ME Controller connected to it. Useful for small sub-networks and introductory systems.

A Network is defined as a set of data channels and everything immediately attached to them, but explicitly ends when the data does. So if there is no data flow, it is the end of that discrete network. Multiple networks may be found in one setup.

A sub-network is defined as a network which is subordinate to the primary network. If the data channels do not connect directly, but is still able to be interacted with, that is a sub-network.

Steve's First Network​[edit | edit source]

From my previous guides, I showed you the mechanics of the system, and how to get started with a basic network that includes an ME Drive and a Crafting Interface. Now we're going to be taking a deeper look into this to understand some fundamental mechanics regarding channels.

This is an ad-hoc network because it doesn't have an ME Controller. At this point, it doesn't really need one. It has precisely two channels used, one each for the drive and the interface. This is similar in concept to a series of chests which are storing things and a crafting table that can 'see' those chests and craft using the contents. Which in and of itself is pretty darn spiffy when you think about it. You can have up to ten disks in there, and each 1k disk is able to store roughly the same amount as one diamond chest. Bigger disks store proportionately more quantity of the items, although it does not increase the number of different items permitted in the system.

To increase the ability to automate, we need an ME Interface, which takes up a third channel on the ad-hoc network. This will permit us to pipe stuff into our network. Frequently, I'll end up with this right at the end of my ore production line because my first use for an ME Network is to get my ore refining more fully automated and stored.

Now, I really don't want to store things like Cobblestone 'on disk', I typically like to have a Barrel set up for it and use a Storage Bus on the barrel to 'see' it. That's another channel.

Pretty soon, we get to the point where we start running out of channels. Then, it's time to make our ME Controller.

Controlling the Network​[edit | edit source]

Now, a Controller also changes how channels work, which can be observed with smart cable. In an ad-hoc network, channels are universal. Adding a device anywhere along the line increases the number of channels used everywhere along the line. However, a Controller is going to be the central 'hub' of channels, so a channel will only go as far as the device it is servicing. This is primarily useful for a reduction in energy costs, since the amount of energy an ME Network consumes is based on the number of channels in any given section of cable, but can also be used to help troubleshoot when you exceed your channels.

You can only have one single controller multiblock per network, and really that's all anyone should rightfully need. Processes can be done on sub-networks, storage can be done on sub-networks, only crafting really has to be done on the primary network. The only time you'd worry about channels on your main network is when you have so many sub-networks that the number of sub-networks starts to eat up your channels. Then you probably want to start consolidating some of them, or maybe consider upgrading to a multi-Cray network to handle the enormous size of your world.

The other advantage of a Controller is the number of channels it can provide. An ad-hoc network only has 8 channels available before the whole thing shuts off. A Controller can provide up to 32 channels per facing if dense cable is used. To avoid channel bleed, consider painting the adjacent cables coming directly from your Controller. That means for a single Controller block, you have a potential of 32*6 = 192 channels. With a single block.

Subordination: Respect My AuthoriTAY​[edit | edit source]

So, you've probably heard about the "Super Soaryn Drive" or seen stuff on various youtube channels and wondering how the heck does it work anyway. Allow me to 'splain.

Say you have your primary network. It's a pretty decent network, you've got some crafting going on, and you've gotten to the point where you have this whole wall of barrels you want to set up with storage buses... but each barrel is its own bus, and you've got a LOT of Barrels. How do you keep it all stored and accessable without eating up your entire network? The answer is to create a sub-network.

On the main network, you have a Storage Bus. The subordinate network or sub-network, has an interface. They face each other. This lets the main network 'read' the sub-network. However, there's some restrictions and limitations which may apply, void where prohibited.

The main network can retrieve items from and store items to the subordinate network. However, you won't be able to access any 'on demand' crafting. So if your sub-network has its own crafting CPU and an Interface with an MA attached, you won't be able to see its recipes from the main network. Having said that, if you have some sort of auto-crafting set up that is triggered by adding or removing items, it will still trigger. So, for example, if you have a setup which creates charcoal blocks with a level emitter to turn it off when it hits 1k blocks, and you take some out of the sub-network via the main network so that the amount is less than 1k, the automatic system should kick itself on and craft them. However, you won't be able to access that crafting recipe directly from the main network.

The subordinate system can NOT retrieve items from or 'see' the main network unless you use a 'two-way' where each network eats up a pair of channels with a storage bus and interface going each direction. It can be done, it just requires a network connection going each way.

You're also going to need a Power Crossover to keep the sub-network powered. Just don't forget the quartz fiber to make sure the power flows but the data does not.

Some examples of sub-networks and their use​[edit | edit source]

  • Ore Refinery. This really shouldn't take up many channels, so there's generally not much point in a dedicated sub-network for it. Ores go in, Ingots come out. Might be a bit more complex if you also have setups to do things like Pulverize Redstone Ore. It can be done as its own discreet sub-network if the number of refining tasks warrants it.
  • Kitchen. Particularly if you use things like Pam's HarvestCraft, there can be a lot of sub-combines in making a meal. Your whole kitchen can be set up on its own sub-network, as long as it is set up to provide a certain amount of food. So, for example, you want your kitchen to keep in storage at all times a stack of Delighted Meals. You take out half a stack, and it starts refilling that stack automatically.
  • Thaumcraftorium. If you want crystallization on demand, and wanting to automate it with AE, you're going to want this to be a sub-network with its own ME Controller and probably a two-way connection to your main network.
  • Super Soaryn Drive. Basically, a bunch of ME Drives and/or barrels on its own sub-network which can be stored to and retrieved from via your main network. Depending on the size, it may need its own Controller.

Yes, you can do sub-sub networks and nested networks, but I wouldn't advise it. Not only is it generally not necessary, but it is pretty tricky to set up and difficult to troubleshoot.

P2P MLG Pro​[edit | edit source]

So, you've heard about P2P and wanting to know what all the fuss is about? Sure, we can go over that.

Basically, Peer to Peer (P2P) is used to transmit stuff from one point to another without actually hitting the main system. So, for example, you can pipe water into one side of a P2P connection, and have it go out the other side of the connection without needing to store any of that water on the network or otherwise access the water from the network. But the important thing, for our purposes here, is that you can transmit Data Channels, which means you can run a ton of channels much less expensively.

So, you've got the one P2P Tunnel connection hooked up to, say, a dense cable. 32 channels of data goodness. Now you do a Power Crossover and run basic fluix cable down to the other side of where you want those 32 channels. Do another P2P Tunnel, with a dense cable on the other side, and another power crossover.

Congratulations, you've moved 32 channels a long way at a quarter of the cost if you had run dense cable all the way! And only for two channels on the intermediary ad-hoc subnetwork. Which means you can move four SETS of 32 channels each to their various destinations. And that's just if you want to keep it ad-hoc. If you add a controller, you can have a whole passel of channels being moved across. Which is where it gets a bit confusing, because they're all on the same sub-network. So you may want to paint the end-destinations as you link them to make sure you've got everyone straight.

In Conclusion​[edit | edit source]

When AE2 came out, everyone saw channels as 'one big huge nerf', and that was polite compared to some of the things that were said about it. However, with sub-networks and controllers, you've got plenty enough channels to do whatever you want to do, and have a bit of fun actually putting some thought into laying out the cable instead of just running lines every which-way.