Importing & Exporting from one side

Riuga

New Member
Jul 29, 2019
684
0
0
(Not sure if this has already been posted, but a quick google returned a negative yield)

DW20's S5 SMP Ep 39 (/watch?v=0QGXtVr36cA).

Instead of import from top and make it look messy with facades (I honestly felt like punching the screen when I saw that :/)
, he should have done this:

npr6Y2Q.png


It's cheaper too!

Export bus: [Empty Syringe] Stack Mode
Import bus: [Slime Emb. Syringe] Stack Mode

Storage buses left blank.

I currently use this design as a way of wireless EU.

Hope this helps you guys (and maybe Dire :D)
 

Saice

New Member
Jul 29, 2019
4,020
0
1
Yeah not many people think outside the one huge AE network box. Isolated controllers can make some fairly tight setups. The genartic storage bus is really over looked way to much.
 

ShneekeyTheLost

Too Much Free Time
Dec 8, 2012
3,728
3,004
333
Lost as always
Storage buses have some problems with doing that.

First off, you would have a problem getting the filled syringes from the enderchest to the vets this way. Because of how AE handles storage, it would continue to consider the EnderChest a valid place to put them, so it wouldn't pull them out.

A *MUCH* better way of doing it would be those newfangled Translocators.

Enderchest behind and between the two vets. Translocators in the middle block are configured to output from both vets and into the Enderchest, accepting only empty syringes. Translocators on the outer corners (directly behind both vets and on either side of the enderchest) refill them. Alternately, if that causes a problem with one or the other vet being filled first, reverse the polarity, since Translocators automatically have round-robin sorting.

Problem solved without needing AE.
 
  • Like
Reactions: Saice

Riuga

New Member
Jul 29, 2019
684
0
0
Storage buses have some problems with doing that.

First off, you would have a problem getting the filled syringes from the enderchest to the vets this way. Because of how AE handles storage, it would continue to consider the EnderChest a valid place to put them, so it wouldn't pull them out.

A *MUCH* better way of doing it would be those newfangled Translocators.

Enderchest behind and between the two vets. Translocators in the middle block are configured to output from both vets and into the Enderchest, accepting only empty syringes. Translocators on the outer corners (directly behind both vets and on either side of the enderchest) refill them. Alternately, if that causes a problem with one or the other vet being filled first, reverse the polarity, since Translocators automatically have round-robin sorting.

Problem solved without needing AE.

? I dont understand what you're trying to say. I've tested this, it pulls the empty out and puts the filled in (I think it's a bit slower, might be my imagination).
 

ShneekeyTheLost

Too Much Free Time
Dec 8, 2012
3,728
3,004
333
Lost as always
? I dont understand what you're trying to say. I've tested this, it pulls the empty out and puts the filled in (I think it's a bit slower, might be my imagination).
Well, first off, if a vet runs out of embiggening syringes (like a temporary lack of Lapis), then it no longer becomes a valid destination for them, meaning once a vet gets empty, it will NEVER again be filled, unless you do so manually. Second off, you're using too much computation power for what you are doing, because a third of the time, it is pulling a full syringe out, only to put it BACK in the EnderChest, since you are using a storage bus on it. Third, this is a job which is MUCH better handled by Translocators rather than AE.
 

Riuga

New Member
Jul 29, 2019
684
0
0
Connect to a dark cable with a timer using RedNet to reset?

EDIT:

They do fill in the the vet after the others are full so :/
 

namiasdf

New Member
Jul 29, 2019
2,183
0
0
Quartz is often expensive and outsourcing specific tasks to dedicated set(s) of machines is usually accomplished with BC pipes, etc. for a lot less.

I was looking into modulating a lot of my processes, but I then realized how much quartz I needed to refit my entire base with AE. >_>
 

ShneekeyTheLost

Too Much Free Time
Dec 8, 2012
3,728
3,004
333
Lost as always
Quartz is often expensive and outsourcing specific tasks to dedicated set(s) of machines is usually accomplished with BC pipes, etc. for a lot less.

I was looking into modulating a lot of my processes, but I then realized how much quartz I needed to refit my entire base with AE. >_>
Many people use a lot more AE than necessary to automate a process, and it can be significantly trimmed down.

For example, let's say you want to teach your AE network about making Pulverized Obsidian. Conventional wisdom says you need to have an ME Interface with the recipe obsidian -> pulverized obsidian attached to your Pulverizer, then have an Export Bus pull it out. Nonsense! Simple hook up a pipe from the output of your pulverizer back to the ME Interface! Remember, anything that hits that interface automatically goes back into your ME network, so you save yourself an Export Bus and some cabling!

Also, many things can be taken care of with the same network of systems, only peripherally connected to your ME Network. For example, you can set up all ores to a precise export bus which is the input for your ore refining process, whatever it might be. The output of your ore refining process can be an Import Bus if you want, but it would probably be a lot faster to just use an ME Interface, because anything thrown into the ME Interface just goes into the system like an Import Bus, but without the additional resources, and it ends up being a bit faster in the bargain. The only time you actually need to use an Import Bus is if something is an inventory and doesn't spit things out (IC2 and some Forestry machines). Heck, depending on how it works, you might even be able to use a vanilla Hopper connected to some piping and wrap it around to a nearby ME Interface, or just Hopper + ME Interface and done.

Export Buses as well can occasionally be replaced with ME Interfaces. You can use the inventory slots in an ME Interface to pass resources as long as it can draw from an adjacent inventory. In fact, I think it even tries to put that resource into the adjacent inventory for you. So you could have, say, a Fermenter with an ME Interface set to have at least one sapling and mulch. Well, it will then put that sapling and mulch into the fermenter, which will then start processing (given power). Then it will refill those slots, keeping the fermenter filled with saplings and mulch until your system runs out. No need for import buses or anything!

In short: A lot of people use a lot more complicated and expensive ways to do things with AE than they really need to. Some of it is a holdover from Logistics Pipes, and how they used to work, or following the behavior patterns of those who have this issue. Some of it is simply being unaware of how flexible and powerful ME Interfaces are. Some of it is simply using a brute-force approach to a simple problem. Generally, it doesn't take all that much for an ME Network to get hooked up with peripheral systems, but many people make it enormously more complicated than they have to.
 
  • Like
Reactions: TaintedHorizon

namiasdf

New Member
Jul 29, 2019
2,183
0
0
Well it's also the time that it takes for the item to come out as well.

I tend to outsource processes that I don't really care how quick they are, to logistics pipes.
 

gattsuru

Well-Known Member
May 25, 2013
364
103
68
There's also a lot of warnings on the AE-wiki that ME Interfaces will stop importing items into the network if the Interface's internal buffer fills up with exportable items. I've yet to see it happen in a practical case, but that's also made me a little cautious.
 

ShneekeyTheLost

Too Much Free Time
Dec 8, 2012
3,728
3,004
333
Lost as always
Well it's also the time that it takes for the item to come out as well.

I tend to outsource processes that I don't really care how quick they are, to logistics pipes.
I tend to not use LP since Krapht started working on LP2. But then I got AE, so hey, not a problem anymore!
There's also a lot of warnings on the AE-wiki that ME Interfaces will stop importing items into the network if the Interface's internal buffer fills up with exportable items. I've yet to see it happen in a practical case, but that's also made me a little cautious.
That's why you define exportable items a bit more clearly so the internal buffer doesn't fill up.
 

namiasdf

New Member
Jul 29, 2019
2,183
0
0
Also interfaces have an issue of compact-ability. Though, due to the design of my factory, (square with machines along the edges) I could place an interface in the middle and have all the contents pumped out via autarchic gates and BC pipes, into a central import bus.

Though, from an engineering stand point, that delay makes it hard to estimate (in some cases) the throughput of your processes, due to the delay. I don't sit in front of my access terminal and watch the numbers for very long, I tend to check, get a mental note, then come back after I've done some other work. In those cases it can make my estimates less precise.

Though the discussion is on how to save AE resources, creating a separate AE network for the purpose of outsourcing work from your main network costs, in addition to the usual AE resources, another controller and another chest/drive. Depending on how quickly you need to process those items is a matter of whether it's worth those extra resources. I have yet to find a situation where I'd need a separate AE network though, so I can't really say from experience at this point.

We'll wait and see where my intrigues bring me.