Chemistry Automation

From GT New Horizons
Jump to navigation Jump to search


Constant craft with fluid AE

When automating recipes with fluids, you might run into some issues. You can't quite use a fluid in an AE pattern, fluid movement can feel more difficult than items, and trying to run more than a few recipes in the same LCR can seem impossible. This page is dedicated to solving all of those issues, and possibly even more. While only three options are shown here, it's entirely up to you how you set any of this up. Once you understand the basics of automating Multiblocks, fluid logistic options, and cycling recipes, you will be able to freely explore the world of multiblock logistics.

First off, there will be a more simplistic method for automation. Simpler to setup and understand, yet lacking in many areas. Afterwards is a more complex method, that will give better results when it's bonuses start becoming more apparent.

Automation Challenge

Applied Energistics has fluid support through the Extra Cells addon. This includes import, export and storage busses and interfaces, but there are no processing patterns that can be used for autocrafting fluids. Here we want to build the next best thing: A setup that stockpiles a configurable amount of all the sweet chemicals we need.

Since we want to use Large Chemical Reactors for our setup, we have to deal with the problem, that GT multiblocks void output, if there is no available space in the output hatches. This can be achieved through redstone covers on the controller or, what we will do here, regulation of the input amount.

Components of the setup

The GT Large Chemical Reactor is our main machine, the rest is only logistics and regulation.

GT Super Tanks are used as fluid storage, since they offer good capacity in a compact block format. They are also cheaper and less prone to random failures when updating the modpack. They can take GT covers. (Basically don't use extra cells storage drives)

GT Fluid Detector covers can be slapped onto GT tanks and give out a redstone signal, that is strongest when the tank is empty and weakest when the tank is full. This can be inverted to get a redstone signal proportional to the amount of stored fluid. Note that the latter mode is called inverted and the former is the standard mode.

Dense Redcrystals from Automagy are redstone contraptions, that output a signal only if the input signal is equal or stronger to a configurable threshold. This threshold can be adjusted by rightclicking the center crystal with a Thaumcraft wand. You can also use the wand to configure, with which sides the crystal can interact by toggling the smaller crystals on the sides on and off.

Extra Cells Fluid Export Busses just do what the name suggest, they output fluids from the network to the tank they are connected to. The fluid to export can be set by clicking with a portable fluid container (for example IC2 cells or universal cells) onto the center square in the GUI. They can also take expansion cards.

The Redstone Card from AE can be used to allow our export busses to be controlled by a redstone signal. They go into the slots on the right in the GUI. Then a button on the left appears, that allows us to specify in what way the bus is supposed to react to a redstone signal.

Extra Cells Fluid Storage Busses can be used on GT tanks and allow the network to see and use the fluid in the tank. It is recommended to use the whitelist feature by clicking a fluid container onto one of the squares in the GUI. This prevents the network from inserting any unwanted fluid into the tank in the case that it is empty.

Setup

Top view of an LCR showing the the input regulation using a Fluid Cover, Dense Redcrystal and ME Fluid Export Bus

Start by building a LCR with only one output hatch. This goes on the front into the top row. We will need 1 LCR for every 3 recipes we want to automate. If you want more speed, you can share walls, but you can only support 2 recipes per LCR. It is recommended to put the cupronickel coils towards the sides to have more space for hatches on the back. If you need a circuit for the recipe, that will go into the controller. All recipes you want to automate with one LCR will use the same configuration circuit.

For every recipe, we need to identify a unique input resource, that is not needed by the other recipes in the same LCR. This will get input through an Input Hatch on the back of the top layer, 2 blocks behind the appropriate Output Hatch. It is recommended to use a fluid as the trigger resource, as the internal sizes of fluid hatches is much smaller than that of item busses. It is also recommended to use LV hatches for the same reason. Larger hatches will lead to a delayed shutoff of the processing, since the ingredients already input will still be processed.

Also set up a Fluid Export Bus on this Input Hatch, insert your shiny Redstone Card and turn the Redstone mode to Active with signal.

For all other ingredients we set up Input Hatches or Busses somewhere on the back side of the LCR, but not in the top row. These can be kept filled constantly using AE (Fluid) Export Busses.

If you have set this up for one recipe, activate the LCR for one recipe and then lock the output hatch to the product by shift rightclicking it with a screwdriver. You will probably input the trigger resource manually for this one run.

Now you can place a Super Tank on top of the Output Hatch. You can also directly connect a Fluid Storage Bus to the top of the tank. Don't forget to whitelist the appropriate fluid in the bus to prevent AE from inserting other fluids. Lucky you already got that one cell of product, eh?

Onto the back of the Super Tank goes a Fluid Detector Cover in normal mode, so no need to screwdrive it or anything. Between the cover and our Export Bus with Redstone Card goes the magic Dense Redcrystal. Deactivate the 2 connections to the sides, so it is only connected to the cover and the AE Export Bus. Then set the the signal threshold on the Redcrystal. A threshold of 15 will mean, that the system will stop production if there is any of the fluid in storage. The lower the number, the more will be kept in stock. Don't set the number too low though, we need some head space in the tank, since the LCR will still process ingredients already in the Input Hatch after the shut off.

Now rejoice, for you are done. At least with the first recipe that is. Have fun expanding this to a full line of LCRs.

Conclusion

While this method excels in simplicity, you will notice you start to need many many reactors. Oil alone will put you at more than a handful, adding PBI/circuits/Pt proc increases the count by a lot. Extra cells also has its downsides when using import/export/storage busses, which can also be avoided.

Pros:

very simple to setup

Avoids <2tick recipes better than single LCRs

If needed, LCRs will run 24/7

Cons:

LCR counts can get very high with this method

Your overall machine on% will be very low for most recipes

Relies on fluid AE


SFM based recipe consolidation

One alternative to the constant fill method, is to use Steve's factory manager. Through it's precise movement system, you're able to move whole increments of recipes. The upsides of this method, are that they let you condense essentially infinite recipes into a single LCR. The circuit integration will have to be the same on them, but that will still save you many LCRs. On top of this, as all recipes run in the same LCR, if you do it right, it'll be able to run 100% of the time. In single machines per couple processes, with some taking different times, unless you void outputs, many machines will be off, waiting on the slowest part of the chain to run.

I will explain each step in detail, however here is a visual representation of what you want to do: https://youtu.be/WhrYZsUyEw4

Basics of SFM LCRing

For the most part, sfm based LCRs are very simple. They rely on the same idea of crafting when buffers are low, however they used this as a method of triggering a 'craft' command. This command is a set of conditions, inputs and outputs. The basic structure follows as such

>LCR check

>Output(s) check

>Input(s) check

>Pull inputs

>Push inputs

>Pull/push outputs (optional)

I'm going to skip explaining the LCR check step until last, simply do to the complexity. However in order, this is what those commands are meant to do.

Input/Output check

These are the first two commands after the LCR is deemed fit to craft. The output check is a fluid condition that checks for your desired buffered amount of fluid. On true, do nothing, on false, continue onto the next condition. This will then activate when your buffer is low, starting the crafting. Input check is preformed on the same set of tanks, but will check if you have everything you need to run the recipe. This time, a true value will proceed, while a false will end the chain. Check for all fluids/items, at the right quantities. I find it easy to set all fluid storages to a variable, so checking them is easier.

Push/pulls

This is simply one input/output for fluids, and one for items, depending on what the recipe will do. Pull from your storage area, and push into the LCR hatches. Simply chain these together to end the crafting steps.

outputs

How you handle your outputs is up to you. I personally find that eio conduits on the output hatches, that feed many drums/tanks works well. You can use whatever you want here, it's not just limited to sfm. However, if you wish, you could add commands to your sfm to always pull fluids from outputs and push into certain tanks. The issue is you will need to define the specific tanks each output. I find using eio filtering is less bulky with larger setups.

LCR checker

This is by far the most complex part of sfm automation on LCRs. The idea is that you never want to be crafting 2 recipes at the same time, as fluids can mix between them. To accomplish this goal, you have many options. You are essentially just trying to turn the concept of "Is it safe to put items into this LCR" into a true/false redstone condition. You can certainly use OC here, however if you're using OC, you're probably better off completely avoiding sfm.

One method is the hatch fill method. As long as a hatch is filled, there is still fluids in it, but the second they all empty, you're safe to put whatever you want inside. This seems to be the fastest method, as it relies on the initial event that itself allows more items to enter the LCR. Sadly there is no sfm command to check if a tank has any fluid, so we need to work around that. Putting fluid detectors on hatches, and item detectors on busses, can give fill level as a redstone signal. Through splitting the signal between on/off when the hatches/busses gain even 1 item or 1L of fluid, you can use this as somewhat of a "ready to craft" mechanic. When they all signal empty, you're all good to input another recipe, however when they signal full, you will want to disable additional recipes being added.

If you use the fluid detector method, you can simply link that redstone output to sfm. With a receiver, you can use true/false to enable and disable all crafts. Depending on what your high/low signals mean, youll end up with one value signaling a clear LCR, and the other signaling a full one.

There is another option for sfm fluid detection, however it's somewhat painful. You can use a fluid condition that lists *every* fluid that is input into that LCR. If you require it to have none, this can be used as a fill detector. The downside here is that if you have a lot of recipes, this can easily get tedious to do. For that reason alone, I recommend using another fluid detector method.

Conclusion

SFM is a decent option for combining recipes in a single LCR. It works very well with fewer recipes, however it can be forced to work on larger recipe counts. One tip I will give, it's easy to setup a base group that you can copy when you need new recipes. Simply changing the values on some fluids is much easier than making all the commands over again. Also, setting your hatches/busses to variables can be useful when adding new recipes. No need to go digging through the 16+ hatches for the 4 you need every time.

Pros:

Fairly straight forward

Easy to add new recipes

Fairly fast recipe switching

Able to combine all recipes of a similar circuit integration into a single LCR

Can avoid fluid AE if flasks are used for AE in/out

Cons:

Recipe swapping can take >1s

Sometimes recipes will get stuck from SFM not completing a full command before the redstone disables it (could just be that I did it poorly, but I've experienced this with sfm in a few ways)

SFM alone can only specify fluids up to 999000L, meaning super tanks and such need extra infra

Can be laggy if done weirdly, or simply many 500+ command managers exist


Flask based recipe consolidation

Without venturing into OC, this is the best method for LCR automation I have found. The idea is to use AE and volumetric flasks together, to turn recipes with fluids into recipes that are AE compatible. While this doesn't seem to have any drastic benefits, it's quite useful. This combined with the speed of the item transfer, and the seemingly flawless functionality, makes flask based LCR automation a top tier option. You will be using flasks, items and empty flasks to accomplish the same goal as SFM. While it might try to function similarly, it's far superior.

Intro to flask chem

Much like SFM, you will be preforming actions based on similar criteria. Some of these actions will be done for you by AE, but some you will need to externalize into the game world. The same basic idea holds. You will check if your LCR is empty, if you have the inputs they will be pushed from AE, it will craft your recipe, and then once empty will restart with another recipe. Some of the ways the steps are done is different, some the same, but you will see many similarities. This is primarily because the flask method was made to build upon the sfm method, while fixing many of its glaring issues. It will use volumetric flasks to quantify fluids into discrete chunks with known values. Then will use AE for item input, and some GT for filtering. While currently this is fairly powerful, with flasks that hold >1000L this becomes even better.

Once again, if you wish to read about, I will explain it in detail. However, I have also made a tutorial video showing what to do: https://youtu.be/CGPWCnDKxZU

Challenge

There's a handful of obstacles we need to find ways around. Without sfm's specific fluid movement, we're forced to quantize recipes another way. Volumetric flasks will be our method of choice, for a few reasons. They provide not only a 1000L quantization, but let us move discrete values of fluids ranging from 1-1000L (possible higher values in the future). With these being treated as items rather than fluids, AE is able to input all the needed ingredients like any normal recipe.

Once again knowing when the LCR is empty will be an issue, however it's tackled the exact same way as with SFM. Using fluid/item detectors we can turn the state of the LCR into a redstone output.

Sometimes recipes can have outputs that need different cells, or need certain stacks in certain hatches. This is accomplished through GT pipes, that will push similar stacks into drawers, and sort stacks based on position in AE patterns. Allowing us to set destination hatches based on that unique fluids placement in the pattern relative to other fluids.

AE doesn't by default have the same mechanic of stock keeping that SFM/LCR spam will have. It's based on demand based crafting, as opposed to continuous production. However, we are able to use crafting cards and interfaces to equate the same principle with any fluid/item.

Not all recipes output in the same quantities, so we either need all of their batch outputs to reach a common flask volume, or need a way to include the flasks with the recipe. Here I've chosen to place them in the recipes. With the larger pattern terminal, you're more limited on outputs than inputs, so sacrificing some slots to output cells isn't the worst thing.

First steps

Much like with SFM, our initial step is going to be defining when the LCR is ready for an input. Similarly, I've found the best method to be the item/fluid(inverted) detectors, as they clearly define when inputs can and cannot mix. While we aren't using sfm, we'll have to employ some redstone mechanics to translate this idea to the rest of the item handling. Setting up redstone on the input detectors, then running it through a not gate feeding a pulse former is a good start. This will give a singular pulse every time the machine is cleared of inputs. We can use this in conjunction with detecting when the machine gets inputs to toggle all the behaviors.

AE Input Chest

The next thing you'll need to do is setup an input chest from AE. This will receive all your flasks and items, and be the start of the crafting process. I recommend using a GT chest buffer simply due to their ability to have shutters attached. There's periods in which you will not want item input, and the shutter module is a very useful tool. Attaching the shutter to the face that touches your AE interface, and setting it to "open when work is disabled" allows for a redstone signal to close off this inventory. Attaching a conveyor to another side of this inventory will allow it to push into a GT pipe. Set this conveyor to enable with a redstone signal as well. Put an item detector somewhere you will be able to pull the signal from. You will also need a machine controller to enable redstone control on the block. This allows for a chest that will receive one stack of items, and to move them needs to disable input of more items. To fully achieve this you will also need to set your inventory to blocking mode.

GT Piping

From that pipe leaving your AE input, you will need to branch off two paths. Set an item filter on one output, and a restrictive pipe on the other. Setting the filter item to empty volumetric flasks with nbt enabled will allow for pulling empty flasks from the AE chest. Any item that is not an empty flask, which would be your fluid and item inputs, will continue through the restrictive pipe. Attach the output of the item filter to drawers next to output hatches. Pull items from the drawer to the hatch, and setup a way to pull items from the hatch into AE. The point of the drawers is for when you have more than 16 flasks worth of output in a recipe, you will need all those flasks to go into the same hatch. Hatches only buffer 1 stack, so additional buffering is needed. The drawers also act as a way of filtering different sized/named flasks from a recipe. This would be useful for when you have 2 outputs that don't have a large common denominator, as well as ensuring the right amount of flasks end up in each hatch. GT will push all it can to the first inventory, so if all the flasks are they same, you will only be capturing one output. With that out of the way, you now have your system for capturing outputs and bringing them back to AE. For the output bus you can simply feed this directly into AE.

The alternative route that fails the item check for empty flasks will need to be once again connected to an item filter, and a restrictive pipe as 2 possible output directions. This time the item filter will check for flasks with nbt disabled. Once again connect the output of the filter in a series to multiple drawers that get pulled into input hatches. You will also need to pull the empty cells from the input hatches and push them into AE. Exact same idea as the output fluids, but this side simply handles the input fluids.

The restrictive pipe after the last item filter will need to connect to your input bus. This will capture any input that is not a flask of any kind, which will just leave your input items.

Small tip, the amount of items in the item filter will determine how many can pass through the filter at once. If you have a recipe with 4 input flasks needed, and only filter 2 in the item filter, it will mess up and send the other 2 into the input bus instead.

Redstone logic

Now that almost everything is setup, you will need to attach the final redstone logic to the build. This will simply be to enable/disable the AE input chest based upon a few things. First off, connect your item detector signal to the input of an RS latch that you sneak/screwdriver'd twice. Attach the pulse former from the hatch detection to the other input of this latch. Set the side that enables with the item detector to connect to the machine controller on the chest. You can leave the 4th side unconnected, it's useless for this. This will create a system that will enable your movement signal when items are present, which disables additional inputs. Once the machine gives a cleared signal, it will toggle the signal to open up the AE chest, and allow more inputs. Essentially this is one big blocking mode that extends to all your hatches/busses.

Creating Patterns

As this relies on AE, we will need to create AE recipe patterns for this. For the most part you will simply put your input fluid flasks, input items, and output empty flasks into the pattern, and tell it that this will craft filled output flasks. The few things to keep in mind, the ordering of your items will relate to the order of the hatches they end up in. While not crucial for inputs, for outputs this is necessary to put the right flasks in the right spots. The GT Pipe logic is simply that the closest inventory will be filled first, however you will need to use this in combination with learning the order your output hatches will fill when crafting. This way you can consistently put the right flasks in the right place.

Stock Keeping

Unlike the other methods, this doesn't have a native stock keeping aspect to it. While many will know how to do this with AE, I figured I'd explain it at the bottom just in case. To buffer many items, set them in an interface, and put a crafting card in it. From there, pull them into a tank or drawer or whatever. You can store fluids as fluids or as items. Both have their pros and cons.

Conclusion

While superior in function to alternative methods, it's not always the best option to use. The setup can be a little complex, and it will struggle with some recipes due to reaching the lowest tick limit. The speed is relatively good, but some recipes will still cause your higher tier LCRs to shut down between item swaps.

Pros: Fast item movement, under a second, possibly under 10 ticks if you setup it up for this

Easy to add new recipes simply using AE patterns

Many many recipes in the same LCR

Meshes well with flask based fluid xfer with AE for other uses

Cons: Somewhat bulky to setup for a few reactors

SFM can be faster at times to transfer fluids, depending on setup

SFM can add new recipes faster

Looses to sfm in batch size limits (999B for each fluids in sfm vs. AE flasks which will always have less than 999B for all fluids combined)

Fast recipes will still have the LCR turn off between recipes. I haven't been able to transfer fluids withing the 2tick recipe limit