Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
Same the other way around, if you connect a selector to the logistic network you could filter the quality signals or even generate them.
Not bad, but not enough. To make things clear, I need to explain what I want to achieve. Example: My factory produces bots in an assembler with quality modules. I want to request all qualities to be inserted into a roboport when the number of unused bots falls below a threshold. Yes, I can explicitly specify each type, it's not that much work. It just leaves the feeling that it's not perfect...
A second, similar, but I think even trickier problem: I am fascinated by the possibility of controlling a factory via signals. I want to make a assembler produce (let's say) red vials, in a quality of rare if there is enough material, otherwise uncommon. I generate the appropriate signals, connect the assembler and check the “set recipe” box. But now I also have to tell the requester chest that it has to get the right material. So I also have the assembler read out the ingredients of the recipe to send it to the chest. The only problem is that I now have both signals on the assembler's input - and suddenly it starts producing gears... I can't either separate the signals or determine the components of the recipe from another source.
I tried to generate the signals for the required ingredients by hand depending on the input signal of the assembler by using different decision combinators - but the result is hideous and doesn't even work reliably.
The two problems have in common, that i cant generate the signal of quality and the signal of item seperately to combine them accordingly. At least i think so?
or
https://factoriobin.com/post/r4jsi30dlaca-EXPIRES
XD
2nd:
something like that:
https://factoriobin.com/post/w8booe3x9fe1-EXPIRES
[...]
omg. if i did not know, what its supposed to do, i could not even figure out that. ok. A new enigma to solve. But at least I know there's a solution :) And I know why I didn't think of it myself.
a bit expanded and tweaked
sry im not that good with minimizing ;D questions? XD
"sry im not that good with minimizing" - thats actually good for me; my chances to understand would be even worse. circuits in general do you handle professional, though. I am ready to testify this.
I cant understand what you are doing there. Lets begin with the roboport: It reads the inventory of the logistic network and fedds it into the red wire. That goes straight to 4 comparison combinators - who ignore it. Instead they take the signal from the green wire as input and map it to the red output. the green input comes from the selector combinators to the left, Their input comes from the blue chest - huh?? Another set of quality setters is to the right. their output feeds one input of the calculators to their left (red). those compare the green input (C) with a X - wherever this may coming from...
No, i give up on this. I stand in front of it like an elementary school student in front of his school's electrical cabinet. No chance, not in ten years. I have saved your blueprints, though. Maybe, if i try to copy it piece for piece, i see the reasoning behind it.
Thanks anyway. You've put a lot of work into your answer, and although I don't really understand it, I can see what can be done with the circuits - and what the various switches on the new combinator do. This was not clear to me from the labels, or rather I had misunderstood them. I will probably have to curb my enthusiasm for the new possibilities until I understand them. But I will understand them eventually, I swear ;)
just let us start with this one for bots
if you click the roboport, you see that "read robot statistics" is selected, resulting in the access of the values "x" "y" "z" "t" "r"
now if you follow the green wire, you get to a combinator, that combinator reads the "y" value, that one counts the total logistic bots, that value is divided by 10 so i get 10% count of the total logistic bot amount
that new value (signal icon "logistic bot") now is provided via the green wire to 1 inserter and the matching requester chest, the chest is set to request, so it will order these 10% value of the total logistic bots, the matching inserter also has a red wire from the roboport as i need the "robot statistics" there too
the inserter itself is set to enable/disable, i want my logistic network to always have at least 10% free bots, so i check the "available logistic bots" against my 10% value of the total logistic bot amount, if there are less "free" bots than my set 10% total, it will add more bots to the network
(why i use that? as it works well with the quality version)
the easiest way for the quality version would be, just remove the "set request" from the requester chests, and add 50 of each quality to the requests
but if we look at my first option:
we have a constant combinator that sets the signal "logistic bot", that signal is fed via green wire into 4 selectors that transfer the quality to the set one, and at the end, fed it via red wire into the decider combinator, so we have every quality at the input of the decider (as a note, we also just could set all raritys at the constant combinator and save the 4 selectors, i just added them to show it)
the decider also get a green wire from the roboport, the roboport is also set to read the robot statistics, as we want the "x" value from it, the decider then checks if that "x" value, aka "free" logistic bots is lower than 500, so if there are less then 500 available bots, this becomes "true", so if there are less then 500, everything at the red input wire is passed on (set to "everything" with "input count" from "R")
these values now get into the next decider, that one takes "each" signal from the red input that is >0 (just a check if it exist) but outputs the value the same signal has at the green wire, the green wire from the roboport has your whole logistics network listed, so if there is any amount of the bot qualitys it will output it
so now you have all logistic bots listed in every quality your chests contain, you could now send that signal to a requester chest set to "set request" and just request all there, or like i did, use the signal inside a selector to only select the highest rarity bot signal and pass that to the requester chest (so if you drop low on logistics bot, it would always try to feed the highest rarity first and just use lower qualitys if you really drain the network
now to the assembler mess :D ( i use the 2nd one with the 4 rows of combinators)
starting from the constant combinator with the signal of the item you want to craft, that item signal is passed to a selector that trys to use the highest rarity of the item signal, as for now it cant get any other raritys so it passes it to the next selector, that one is just a "clock", every 1800 ticks = 30 seconds it picks one signal and keeps sending it for the next 30s, as it just gets one signal it cant rly do random stuff but it provides the signal to the assembler (we dont want the assembler to "flicker" with recipes, so we hold it constant for 30s)
the assembler is set to "set recipe" and "read ingredients", so the red wire from the selector sets the recipe to your choosen item, the green wire now collects the ingredients list and moves it to the next combinator, that one is just there to be able to increase the number of possible crafts to check, i want to be able to craft at least 2 items from the materials available, that combinator sends these values now to a requester chest, (set to "set request" (and optional "trash unrequested" if you want to keep it clean) also to a line of selectors, these selectors transfer the quality of the input to the set quality, at the same time one of them is set to "count inputs" so we know how many different materials we need (signal "C")
from each of the quality transfer selectors we move the signal on into a decider, like we did before with the logistic robots, we read the input from the selectors at the "g" green wire if they are >0 (existence check) but output the values from the same signals from the "r" red wire that is connected to a roboport (aka logistic network) as a result we now get the amount of items we have at the network available for crafting
these "available" items do get passed on the red wire, while we also drag the green wire from the first selectors to the next combinator
that combinator reads "each" signal from the red wire, (the stuff we have available) and subtracts the amount we need, (signal at the green wire) to craft 2 items (as we set it to x2 earlier) and outputs the result to the next combinator (so the signal will get negative if we dont have the needed amount)
the next combinator just checks if the values of each signal >0, if they are, they get passed on into a selector that counts the input signals and maybe you remember that we already counted the signals at the beginning, so we submit the new count "X" to the next combinator on red wire, this one also gets the old count "C" at the green wire, if there are enough materials to craft our items "X" should have the same amount of signals as "C", if we miss something at "X", the >0 check eleminated some signals because of the lack of materials at the storage
but to have something to pass on with the x=c check, we need another signal, we need the matching rarity for the materials we have, so we take the signal from our item at the constant combinator with a green wire and feed it into selectors with quality transfer, these submit the new quality item signal to your "X" = "C" check, so if that check is passed, the quality item signal is passed back to the first selector, that one with only the basic item signal, that one now maybe has more signals then the basic one and because of the sorting it selects the highest rarity we can craft, that signal then moves into the "clock" and the assembler will craft the new quality
if the materials for the new quality are consumed, it will move a step back until it drops to the basic craft
i currently use that setup to craft quality moduls, the setup crafts basic moduls and feeds em into a recycler, after a while there are enough materials to craft higher quality, it switches, crafts the available materials into items and drops back to start the cycle again
you can add more assemblers to the setup, just use a green wire from the "clock" to another assembler (set to "set recipe) as the red wire that is already connected to the main assembler would also loop the "read ingredients" and mess up
for the so also added requester chests you can use the green wire from the main assembler, as that contains the "read ingredients" signals
to have all assemblers working, just set the multiplier that checks for the amount to craft (currently *2) to the total amount of assemblers, so it checks if you have enough materials to support all
...sry for the wall of text
The third: now it gets tense. The first question concerns the function of the random selector: it does not randomly select any signal, but one from the input signals. Is that correct? And it helps against the flickering of the signals - another lesson learned. This will also be useful elsewhere. Now comes a point where I got stuck: The green cable on the assembler now holds the ingredients of the blueprint, but the red one not only holds the blueprint, but also the ingredients! The assembler therefore switched to producing the ingredients at some point. - In my case anyway, the structure was of course completely different, much more primitive. The clock was also missing. The rest of the setup is now clear - thanks to your “wall of text” - the last sentence is the icing on the cake. After a fantastic explanation and a lot of work, you apologize.
I really hope this example will make it into an official tutorial at some point. I've learned more about circuits this evening than I have in years.
selector (random): yes, a random signal from the input, and that signal is hold for the duration set in ticks
to the green and red wire at the assembler, the red wire has the blueprint from the random selector and you are right, also the ingredients, but as the wire ONLY connects the output of the random selector and the assembler, the "input" aka ingredients are not used anywhere, thats the reason we use a green wire to use the ingredients signal to the combinater input, so we dont "mix" the blueprint input on to combinater
thats also why i wrote, if you want to add more assemblers, dont use the red wire that "normaly" holds the blueprint, as that signal gets mixed with the ingredients, thats why you use a green "clean" wire from the random selector to set the blueprint at the other assemblers (important, you dont need to read "ingredients" at the extra assemblers, just set the recipe)
Edit:
if i didnt mess something up, thats my final for that kind:
https://factoriobin.com/post/idmz0zvaawtx-EXPIRES
i totaly forgot that we can do multiple conditions inside a decider so i could cut a row down by 2 combinators...and used the free space to add another
so now you can set your item you want to craft, and you can set "E" and "I", E = endproduct, I = intermediate, so like i saved it for modules, i just want 10 of each, at the saved blueprint the endproduct aka the legendary item isnt needed as it is "just" tier 2 modules, at the tier 3 module production E is set to 50 :)
the whole thing also shuts down complete if you have enough of the basic item, if you dont want that, just disable "enable/disable" at the facilitys or remove the red "x" signal
the only thing i couldnt exclude is the amount check (currently set to 4 as there are 4 facilitys)
and you can rotate the blueprint 2 times and fit it onto the roboport...to get that to work i had to split the red wire, as otherwise the E and I signal would run into the other "side"
well i think, someone else could cut that down further, as you could also just cycle the quality signal and save the result to circuit...but i never done that
https://factoriobin.com/post/befy1wdnpm08-EXPIRES
combinator config:
"X" = x times the crafting material request
"N" = amount of items you want
"Q" = variable for quality (set it to the quality you want, but keep the value at 1k or at least higher than "N")
at the combinator where you find "N" and "Q" you can add the items you want as a signal with value 1
the only issue i have, i would love to use "Q" to also set quality filters at the inserters, but that doesnt work, thats why there is a version with "pure" legendary and a version that shows how to config the filters at the inserters for other quality (like rare)
what does it do? it crafts each of the set items up to the set quality and set quantity, if it is done, it sends a global alert
if you combine it with the other one, you could use the scaling and recipe switching with the queue
I will test the rules according to which the selector sorts. If I'm sure of any findings, I'll let you know.
The thing with the signals on the assembler is a bit puzzling for me. I remember that the wiring in my experiments was the same as yours: red was the input that sets the recipe (although in my case it came from a decider, not a selector), and green was the output to the requester chest. The most likely explanation is that I somehow built a loop that fed the ingredient signal back in at red.
The fact that this works in your example probably also means that the assembler (or another device?) can distinguish between the signals that it feeds into a network itself and those that come from outside - otherwise the assembler would have to react to the ingredient signals on the red cable in the same way as to the signal from the selector. And this is also the case with other assemblers that you want to control in this setup - you clearly state that you must not use the aforementioned red network for the connection, but need a clean green one from the selector. This conclusion comes as quite a surprise to me; I hadn't expected it in the slightest.
I'll have to test your two other blueprints another time - I don't have the necessary concentration right now. As I said... but " I'll be back ".
for starters it can help to add arithmetic as "one way" signal blockers if you run into issues with mixed signals or if you would need 3 colours to not mess up :) , just let it calculate each*1 or each+0 and be safe that the signal just can go in one direction