Factorio 2.0 Circuit Network Tutorial ❇️ : Basics to Intermediate - Automate Your Factory!

[@tjlambaes]

I’m so glad you didn’t tell us what the wires do and blah blah blah about the basics. I’m not sure if anyone else is like me, but I really want to learn more about using combinators as memory cells and the different uses for advanced circuit networks kind of like the s latch you showed.

[@hb-man]

Yes. There's basic info about wires that's valid since before 1.0, that hasn't changed in 2.0 AFAIK. In essence, a cable carries all signals put into it anywhere, and adds numbers of the same signal. So if you connect multiple chests to green cable, it knows the contents of all chests as a sum. And the reason two colours exist is because you need to keep some signals separate.

[@Xterminator]

@@tjlambaes For sure! I figured showing some more useful things and intermediate uses would be more helpful.

[@EmilyGamerGirl]

The big thing about lamps is, if you just want them to be colored, you don't need to use ANY signals- you can just use the dropper button on the lamp and enter R,G,B values yourself! The signals are useful if you want the color to change based on a circumstance- for instance, you could have it be green when full, yellow when medium, and red when low.

[@mnm8818]

Too add, even with a signal you don't need any combinator, just tell it what colour the light bulb is with what you stated above (dropper symbol)

[@alessandrosantarini9880]

For the output of the assembler you need to filter or it will output ingredients as well. That is why it is filled with gears and plates :D On the train example will actually cause problems. You will request 333 motors but you will start FILLING the train, this will ask for MORE motors. You have two options: 1) trash unrequested, when the train will leave robot will pick up trash, but you need to also set filters for the inserters or if a new train comes it will start mixing. 2) use another math combinator to reduce the amount of the request on how much the train is filled (not 100% sure is working in this way). 2-bis) you can probably use a latch to store and disable request chest when you reach the amount Overall yes, you can do very powerful stuff. Another use is to use a stack combinator BEFORE having the request input in the assembler. So it will ask for a stack of that item. This is quite handy because of some recipe that have like 1 iron plane (damn pipes!!), and it will be veeeeery slow to operate because it will request just 1 at the time. There is another use case of the request reading assembler ingredients where you can blueprint the amount based on the variable of the recipe!

[@cmdrblahdee]

For the selector combinator, the thing I immediately started using it on is the asteroid collectors. If you have it sort the list of rocks you have from least to most, then set the filters based on that output, you're always grabbing what you're low on. Use a constant combinator to make sure nothing is "forgotten"

[@kenoomish9173]

For the crafter As someone suggested already, you can just say EACH if less then certain amount, then output EACH. But that will stop working if all of one item gets taken out or it will start producing new item if something else gets put in by accident, it is better to use a constant on a second wire as a setter of what should be produced, you can also make it to compare EACH coming from the storage and check if it is less then the EACH from the constant combinator, this will allow you to also specify what amount of a certain item you want when setting the desired items in the constant. Note tho that this will still cause issues if the input is the same as output and one of the item is used in creation of another (like the belts in video), this will cause the machine to produce desired amount of first item, then switch to making the second one, taking first item out of storage causing there to be less of that item in storage and switching the recipe back to the first one, taking the item out and putting it back, realizing then now there is enough of that item so no new one needs to be crafted and switching back to the second recipe causing it to flipflop between those two recipes. I figure it could be fixed by including an SR latch but it would lose the ability to set specific amounts for certain items... If anyone is curious, that would require you to set values for the items you want to produce in the constant combinator to one then you connect it to the decider, lets say with red wire, connect storage with green wire to input, then you connect red wire from the output to input. Now for the decider combinator, the setting signal is EACH from green is less then, say 50 AND EACH on red is more than zero. The output should be EACH at count one. Now we set the resetting signal, for that we make new block in the decider by using the OR and inside that we are checking that EACH signal on red wire (in this example) is equal to two AND the EACH signal on green is less then, lets say 200 (make sure to give it some larger margin since assemblers will take some stock inside). With this you take green wire from the output (the one not connected to input) and connect it to the assembler.

[@FMPthEmAd]

With one combinator and one constant emitter : - in constant emitter : 1 yellow belt ; 1 red belt ; 1 blue belt - in combinator : If "each" < 51 then "each" at 1. - in factory : use recipe. At the beginning of the loop, every belt signal is at 1 because there's no belt in chest. So each signal is at 1, and factory take the first one avalaible : yellow. So it makes 50 yellow belts. Now Yellow belt signal is at 51, so 0 after the combinator. Factory takes fisrt recipe avalaible, that is now the red signal. And makes 50 red belt. And at last 50 blue belts. When there's 50 belts of each in chest, each signal is at 0 after combinator. And factory stop.

[@cmdrblahdee]

I cant remember which is the right "each", but there's a few different colors that handle how that info is passed through, so if anyone is reading this but having issues, it might be that. Or wired wrong.

[@StickerWyck]

Packed RGB means all the 0-255 components are combined in the same channel. It's the most complicated option but it's also the most powerful as it allows you to assign multiple colours to multiple lights without wiring them independently (which can be an absolute mess of wires). It works by adding up the RGB components together in 3 powers of base-256. To put it a better way: [Packed value] = (blue value) + (green * 256) + (red * 65,536). You can even blueprint a little circuit to convert RGB to Packed to do all that math for you at the cost of slight latency to the circuit.

[@MacManChomp]

You can use a single decider to change assembler recipes in your design by using a constant combinator with your limits. Send the destination contents to the decider on a green wire and constant on red and compare green < red, but if using a logistics network, items will sometimes go below zero. That will cause errant signals unless you filter them out, which can be done with the same decider using AND Red > 0. Wire colors don't actually matter here, but signal separation does, so you can swap the colors without issues.

[@ivo215]

For the assembler recipe, you can put the items and amounts you want into a constant combinator, and use a red wire into a combinator. Then you can use a green wire from your output chest into that same combinator. Then you can use the decider combinator to forward each signal where the combinator has the larger number. This is what you need to have made. You feed that signal into a selector combinator. You can set that to select one of the input signals. And you use that to set the recipe in the assembler. Then you use the assembler to output the ingredients of it's recipe to a requester chest. The requester chest will request the ingredients. The assembler will craft and output that item until the required amount is met or until the selector combinator selects a different item to craft.

[@sir9129]

for the changing assembler recipes you can use each and check for an amount then output each. this checks all the signals and lets through the signals that passes the condition and it only uses 1 combinator

[@jackofsometrades6727]

I use the "set recipe" feature for modules. If any of the module counts go below X, the whole block of assemblers will start producing that module. I wanted to focus on something else instead of setting up three blocks.

[@theMGKPL]

you bring to me a concept of sushi train, one train that brings them all!! if done right you could make fully automated city blocks where you set product and the auto city block makes all magic for you as well as universal trains that just reed what city block need and get straight to station that have this basically you can make like a handful of universal blueprints to rule them all

[@KrimsonStorm]

I think my favorite thing to do with the new circuit network is for belting in ingredients up to space. Instead of using bots to fill rockets, read requests from the space platform, do some logic with deciders, and tell which arms to activate to throw into the silos. For example, on volcanus I'm shipping out tungsten, calcite, foundries, miners, and then both military and metallurgy science. Divvy up which silos launch what items, and then the order it should fulfill requests. Boom, no bots needed for most deliveries. Works great for belt and train heavy playstyles, like mine. Now excuse me I got to figure out how to belt only gleba. I still wish we could scan the spoilage percentage of an item.

[@Xterminator]

@@KrimsonStorm That's an awesome usage! I should definitely try that as well. I also wish you could read spoilage percents too though.

[@MrTomyCJ]

7:50 I having tried, but maybe you could have a constant combinator with the amount of each item you want, outputting a red signal, and a decider combinator that outputs any green signal (coming from the chest) that is lower than the red signal. For similar setups you often need to also read the item that inserters are holding, otherwise things tends to flicker.

[@Omnifarious0]

12:30 - Your belt example works almost by accident. It will select the "lowest" signal, by some metric. In this case, the lowest will be the yellow and the highest blue (I suspect). And so as long as yellow is present, it will be yellow. If you had a scenario where you pulled blue from the chest so it started making blue, it would swap over to yellow the second you pulled some yellow from the chest. This problem is a very tricky problem to solve, and I've been thinking about it for awhile. Especially in the context of getting the most out of productivity modules. You could use one of the new fancy selector combinators to always pick the belt color that had the lowest count. :-) That would take two combinators because you'd have to filter to just belts with one decider (using multiple conditions 'ored' together and then passing the count of all signals that met the condition), and then use the selector to select the first signal when sorting in ascending order.

[@arielmoonsoo9219]

I'd have to double check the docs, but I believe you can translate the separate R/G/B triplet into the combined color by performing the following operations and saving the result to the same signal R

[@petermuller3682]

You dont need a constant combinator to change the color of light. just click the pipette in top right corner to set it.

[@nguyendi92]

For SR Latch, You don't need different color wires. The S signal ( check signal) will not recount itself, It will constantly output 1 even if you loop it back. Unless your output wire also check another number down the line, thus add a new total. I don't see any reason to use a different wire. An If you want a Clock, You actually need to Input X

You can remove the concrete from the floor, put it again, remove, put, and so on. It will clear the grass and the video will look much cleaner.

[@RottedMushroom]

My go to setup for setting multiple amounts of items in a chest is one constant combinator with the list of items I want and the amounts and then an arithmetic combinator hooked to the chest multiplying each signal by -1. This way when desired amount is reached it cancels out the signal from the constant.

[@plantoloz3931]

i think they just change it so you can set a negative amount on the constant combinator. I mean the group multiplier

[@RottedMushroom]

@@plantoloz3931 Ah that is very cool actually. Now that I think about you could also just set the constants to negative and then you don't need the arithmetic one at all lol.

[@alexanderjanke1538]

25:28 no it's not new. You could read the train ID before space age too

[@matthiskalble3621]

For the sr latch use greather than or equal to is much more stable

[@jeffreyspinner5437]

Whoa, I asked the universe for up to date circuit tuts, and voila, it's been partially answered! Is your "basic" video this one from 6 years ago!? Factorio Circuit Network Tutorial: Basics for Beginners - Guide & Walkthrough kzbin.info/www/bejne/bYSkpWqQp9aqjpI I was told for trains, you can go as far back as 4 years, but that one you did with circuits 6 years ago still is helpful? On the upside, I do like that circuit mod you highlighted recently, that is good, imo.

[@Xterminator]

@@jeffreyspinner5437 Yeah that's the one! It goes over the most basic stuff like how wired works, hooking up things, etc, and all that is still valid today. :)

[@DesyncBro]

Good Video as usual, that said If you dont mind XTerm, i have a Tutorial how to use the Packed RGB option for Lights on my channel. Maybe some of your viewer are interested? Best regards

[@hayzersolar]

There's a mod called the crafting combinator. Now they have done away with it and this you can do it by yourself now

[@TChapman500Gaming]

Try this: out = (A AND (B OR C))

[@SpencerUnderwoods]

I think the reason your belt assembler didn't constantly change recipes is because your output went to a regular chest. When I've made similar set ups with logistics chests it constantly swaps recipes when a red belt eats a yellow belt, or a blue belt eats a red belt. I think it needs a latch to force the recipe to stay the same until crafting is done

[@MacManChomp]

This can be done with a memory circuit, where you hook the output of a decider to the input and output everything as long as some reset signal is 0. Then you can use the assemblers recipe finished signal to reset the memory circuit, dropping the recipe if it's no longer necessary. It's better though to separate dependent crafts in this situation, to prevent craft B from triggering a signal for craft A, causing the machine to craft one and swap over and over. I can't think of a way to stop this without using a large number of combinators.

[@Solo-ir8vx]

异星工厂大学习！