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
https://wiki.factorio.com/Tutorial:Circuit_network_cookbook#Latches
RS-latches can be easily made with a few combinators, for automatic on/off controls, based on whatever trigger conditions you set. (I use these a lot for all sorts of jobs around my factories.)
You can setup many different power grids, connected together via circuit-controlled power switches. This is good for making "priority" power areas in your factory, so some parts can be disabled automagically to keep more-essential systems online & help prevent brownouts (or worse).
This sounds quite straightforward to setup ingame. Only 2-3 trigger conditions to monitor, and 3 "states" to set the switches, so it shouldn't take many combis.
+ if main grid > laser grid : open switch so the laser bank can charge up.
+ if main grid < laser grid : close switch to prevent back-flow from laser grid.
+ if main grid = zero : open switch to enable emergency supply from the laser grid (until main grid
> laser grid {or} > preset amount ~ whichever preferred).
(I could probably whip up an example BP later as a "proof of concept", if you would like one.)
If-else means that if that condition is true then follow the "if" line, and when it's false then follow the "else" line. An additional "if" down that line means that both conditions have to be met (first if = false , second if = true) to continue. So they would never be true at the same time. The only thing that would happen would be that if the second condition isn't met, then the output would remain false, which is what we want for an on-off switch
Secondly:
I've seen latches but they kinda take too much time to set up. Like i said in my post, "more time than it's worth". For this to be worthwhile it would have to take up to 2 logical buildings (3 if we count the electric gate). I'm guessing it can't happen with this number of buildings though
For me, the time is certainly worth the results ~ a few mins to set up an automated circuit once vs doing repeated manual adjustments.
That laser reserved power control system was a bit easier to build than I expected: only 3x combis & 2x switches, though it can also be done with 4x combis and 1x power switch instead.
Works as I listed previously, & the emergency back-feed stays on until the main grid is back above 50%. (This seemed like an interesting use-case, & worth prototyping for later.)
Pic ~ https://i.imgur.com/aawFTVs.png?1
& example blueprint:
I have no idea what will happen if the turrets start firing all at once. If A drops to 0 suddenly then, again, the whole system might fail to operate since it will have no electricity before it can turn on the secondary power switch. So maybe A<5?
Still, my problem is that this is supposed to be the simplest form of an on/off switch and it's already too complicated (3x combi + 2 power switches = 5 buildings (not counting the 2 accum you would need just to get the data)). If you want to make it more complicated (like taking into account additional conditions), then you would need even more of a complex setup. But even in its simplest form, 5 buildings for a simple on/off switch is too much imho.
My point was, initially, if you can make flying robots, then you can surely make an on/off switch, with separate conditions (on when x, off when y).
I mean, flying robots, from the get-go, have an on-off switch in the form of when they will go back to recharge. (recharge when A=0 until A=100 then keep on flying until A=0 again). So our character has invented the on/off switch already inside the flying robot, but needs 5 buildings to recreate it outside it? Sounds a bit unrealistic to me.
Logical gates are great, surely, and it's an awesome addition to the game. But aren't they a tiny bit too primitive for a person who has invented flying robots, automated trains, nuclear missiles (must i go on)? It would all be enormously simpler if we just had If-else buildings. I mean, you could just add it on the research list after logical circuits! The problem would also be solved by storing variables (which is what latches do, right?) using a single "variable storing" building.
So my point is, why go into so much trouble using logical gates, when you already have the technology (in-game) to create switches, and if-else statements (let alone variable storing).
You could probably answer along the lines of "it keeps its current state", but doesn't that mean it would contradict its conditions in the first place, even an "else" condition would not be enough since when both conditions are met it would use the first condition and stop there (which might be fine in some scenarios and not in others).
As you continue to dig that problem, you end up with the need to make that "comparator" that would function as a fully programable gate that would completely negate the need for most comparators.
It would be similar to asking for a crafting machine that takes plates and spits out finished products directly, completely negating the needs for any intermediate crafting.
It would definitely save time, space and even UPS, but it would also no longer be factorio.
The whole point of the game is to use basic tools and combine it into a working whole that does what you want.
For circuit logic, those basic tools are the 3 types of comparators and the red and green wires (added to the fact that a lot of things have built-in circuits that allow them to interract with wires with a set of very specific instructions).
It's the same with train networks, the basic tools are not that big in number (rails, train stops, 2 types of signals, locomotives and 3 types of wagons), but when you use everything properly you can make some seriously impressive train networks that are capable of transporting and dispatching things where and when needed (you can even make a complex "request" type network similar to logictics robots if you combine it with circuit logic, even without using mods but with a lot of work involved).
However, an assembled machine out of basic parts is exactly what i want to make. For example, what do you need to make a 1-bit storage? I think it's 4 gates and 4 cables? Anyway, i might be off some cables but i'm close enough. So the "1-bit storage" building would be assembled from those ingredients.
Similarly Killcreek2 designed a kind of an on-off switch using 5 buildings and x cables (i don't remember how many). This means that the assembled electric on-off thing would need those to be assembled.
I'm basically following the exact path that factorio itself is following. And allow me to exaggerate too when i compare an assembled on-off switch to an assembled nuclear silo.
I wanted to address this first because, if factorio followed that logic is when it would no longer be factorio. You would basically have to design the entire process that x gets glued to y and becomes z. No, i'm talking about assembling, in the manner that everything else is assembled in the game.
And always remember, i'm not talking about something magical here. I'm talking about something that the character must have already designed in order for other things to function. Like i said in my example with flying robots.
Now, concerning the first thing you asked. You can construct such a thing with the logical circuits. Take a power switch, set it on when F=1. Then have two constant combinators sending a signal, one sending "F=1" the other sending "F=0". What happens to the switch then? That's exactly what would happen to the on/off switch when both conditions are true - although you would have to do that on purpose. HOWEVER, if you made if-else statements, then you would never run to this problem, since if the first condition is met, the second one wouldn't be checked at all.
An on-off switch basically starts off, just like a power switch starts off. From then on, it would just need two conditions. It doesn't change anything if any of those conditions aren't met (so it wouldn't change anything even if both of them were false). So if condition 1 is true, it changes to "on", and if condition 2 is true it changes to "off". If it receives false by any of the conditions it just doesn't do anything, it's as if it didn't receive a signal.
Concerning the if-else statements. If you had an if else statement, followed by a second if in its else branch, then you would basically have what i'm talking about.
IF x=true then turn on
ELSE (=if x=false)
IF y=true then turn off
(an "ELSE (if y=false)don't do anything" is implied by not putting an ELSE branch to the second IF)
So this would tell our switch to FIRST check whether condition x is met. If it's met then it would send the signal 1 (or true). If it isn't met it would follow the ELSE branch and from there it would follow the second IF. So if condition x isn't met, then it would check condition y. If that's met then it would send the signal 0 or "false" thus turning it off. If it's not met it wouldn't do anything.
This would be ran for any signal that goes through it. So any signal that passes through it, is being checked by those statements, and the machine outputs the correct signal.
But what i'm mostly interested in is why the idea of an on-off switch with different conditions meets so much opposition, when our character has already fitted one in every single flying robot (let alone all the other machines that would need one - we even have conditions for having a train leave a station, so it's not an "entirely" new thing).
Now, i wrote a lot, i'm not going to go back and proofread it, but you get my point anyway.
It is a of a bit rough prototype, so has a few minor flaws, but was just to show you how easy it can be to make these things work ingame. Some stuff is simpler than others, but it really depends on the ingame use & desired result.
Here is a simple controller I use to automagically toggle on/off my steam power generators, so that my factory first drains from the (solar powered) accumulators instead. ~ https://i.imgur.com/NssHj6a.png?1 ~ it tucks neatly around a big power pole, & even features a CC so that I can override it manually if/when needed. (The circuit does not actually even need the RS latch, it is just used to avoid rapid on/off flickering.)
As for a simple "if then else" sort of design, the circuitry ingame can do that already. (Very basic circuit use is 1x combi per condition you want to check, looking for "yes/no" or "1/0" signals only, aka "analogue" circuitry ~ what you seem to be describing in your examples).
You often can skip combis entirely, in some circumstances, as the machines / inserters / belts / etc can be programmed with the final check condition directly. More advanced circuits involve processing multiple signals in parallel through the same combis, and can use all sorts of encoding / data compression tricks to further reduce the number of combis needed.
A 1-bit storage cell can be made with one cross-linked combinator. (The single-combi RS latch is a 1-bit storage cell.)
However! ~ A single combinator can actually store a VAST amount of data: +2.1 billion to -2.1 billion per signal, multiplied by the number of different signal channels ingame. (This is because the signals ingame are "32-bit signed integers", not "single 1/0" data bits)
Here is the memory cell I use ~ https://i.imgur.com/uRlX658.png?1
(the CC optional & is just to show where the reset signal should be input).
It stores single-pulse (digital) signals for as long as you need it to; reserves one channel for a "full reset" trigger, but all the other 120+ can be used for data; and if you send in a single-tick positive / negative signal, it will add / subtract from the stored value of the matching signal channel. These stored values can be output as constants for use elsewhere (but unlike using a CC, they are dynamic & not hard-coded).
You seem to be asking for some sort of "programmable omni-combi" so that you don't have to build circuits the way the devs designed (using multiple combinators), and can just plonk down a single entity to do it all-in-one.
Or am I misunderstanding your suggestion?
Everything you have used as an example so far can already be built (rather easily), so adding a new programmable-entity would: A- add nothing new to the game; & B- make existing combinators obsolete, thus reducing the challenge of the game.
(This is why I personally don't support the idea for vanilla, & I assume it is likely similar reasons for the other veterans.)
Might already be a mod that does this, for those who do want it.
Well, it's true it would make combinators kinda obsolete unless you want to do something else with them (i can't come up with anything right now).
I would definitely not want to lower the challenge, in fact, in other posts of mine i suggest raising the enemy capabilities, since the survival aspect of the game is kinda easy. So it's not about making the game easier. You could make assembling the programmable on/off switch really slow or really expensive.
I understand the challenge aspect completely. I'm just saying it's unrealistic. Like the character chooses to rely on those buildings when he/she has already found a solution around them (like i said in my example about flying robots). That's all i would want, really. To be able to program those logical buildings like my character programmed the robots.
Although it's true, it wouldn't add anything new to the game, since you can work around that already, it's just frustrating to do something in 3+ steps that my character has already achieved in 1. That's all i'm saying.
To be honest, there is one more thing that i found unrealistic. The fact that belts don't use electricity. But same goes here, i would also like belts to use electricity. Like, connect one side of the belt to electricity and power the entire belt (maybe also belts that are connected to it). Anyway. That's something completely different and it sure raises some problems. Also, many people love to have access to belts early in the game, instead of having to research electricity first, so it's understandable.
Anyway, to our previous subject, if on/off switches are out of the question, then how about NOT logical gates, in addition to AND,OR and XOR ? Or at least "output 0" as an extra to "output 1" and "output input count"?
EDIT: PS: While on "unrealistic" i also completely agree with those friday facts that said that the player shouldn't be able to have large buildings in their backpack, nor should the buildings just be placed immediately on the ground. That's just my opinion.
Remember how i said that logical buildings don't work without electricity? This means that cutting off power to them basically means that that branch won't work anymore. This could be a way to split outputs (if output =1 turn on switch 1, left branch is on, if output =0, turn on switch 2, right branch is on.). I'll test it now, thought it might just make things needlessly more complex :P
EDIT: It doesn't work. The combinators keep a little bet of energy as a reserve and continue doing their stuff for some odd reason. If they are connected once to electricity, it seems they don't stop working, even if electricity is 0.
EDIT2: So i managed to create an on-off switch. I think the main information that one would need to know is that a combinator can keep the data it USED to output by feeding back to itself, and it will stop keeping it by receiving an opposite signal. So Condition F>=1, feedback F1. Then send a F-1 signal to it to make it stop keeping its data. I tested it a thousand times and it never stops working.
The switch i made basically does the following things:
1. Charge the reserve. Stop the connection to power when it's fully charged.
2. If the power from the base drops to below 50%, stop the connection to the base and start the connection to the reserve.
3. If the power comes back on, wait until it's at 100 (to avoid using the reserve for the base's consumers if the power drops again), start the connection to the base and go back to 1.
I'll count how many buildings i needed for it to work.
6 deciders, 1 arithmetic, 2 power switches (1 to base, 1 to reserve) out of which the 3 deciders are used for the data coming from the base (start/stop connection to the base, decide if it's time to use the reserve) and the rest were used for the reserve to decide when it should be charged, stop being charged, etc.
I'll try and make it better, because right now it's extremely crude, and post a blueprint string so you guys can tell me your opinion.
So i tested your blueprint and, although it does turn on the reserve when things get rough, the reserve remains connected to the base. I tried creating something on my own to show you exactly what i mean. Here it is:
0eNrNWFtuozAU3UrlzxFU2AkEkPpRVeoC5nc0igjctpZ4yTZpoyoLmIXMxmYlc4EmpGBeaZX2J4pj+3DvPec+yCvZxAXkgqeK+K+Eh1kqif/rlUj+mAZx+Zva5UB8whUkxCBpkJSrIAyLpIgDlQmyNwhPI3ghPt0bozfz7BmEKZ+5Cp9OrrL9b4NAqrjiUFtQLXbrtEg2IBD7iBAHEhFUIQQoxM0ziZeytHwiAjnXtkF2xDftaxvhIy4grLed0roWKpuI6vaiMg3qYiIqtWYZuzzCyiSIYxNiPC14aOZZDBqba+jlXgNlH6E2/HEMyKQH9ymaqUFz9OxqgKwTIIOg2tLaYVmeuCusU+Z5VNn5jEGpvlulRO4K2j5D6ftDOgtXWuVqDGzbp0QWrzfwFGw5XsBTWaHyQq07Kt9yoQr8peGoOmHekn3XU1p+PAqAtOMMkhxyERZc1esTZ6q13d5HfzUOuxMpWYw6fHga7kXHmw9cyBlBuCM1uFRBWWhouUjyQFQs+OTmYzHC2rE3dOppK0MvHzYuH29iNCm7SDjvh8P578/f3oAKiDoBcDvhNHoCv2qr0ZvKBJvCxGKcCWpNy+R3JetLMplZw5nM6LRMpk3nSyDiRTJarpeV40wLxs7pIXqoxUy7qDMA1vS2CEIeYY6hpDc87anTh7K1bDVjPdNvkE3OyTOS7vZ90tmWJuuM2aJ6q4z5Do0rUrV+EFmy5iliEP8hiCXM0tyqyj/Wu++289eZqEF7Hj2HNmp/GT3UsjpNZj479xdlh676wu+cF/4LZkerw3+/4OuHhnPIaGbJg7+DbGgzwZljudO2fHgkbO97fY40M2IguHpKQGHtHnKF2tcD3nSE1aB+grYklBjrRmIm9sUsB1RYZQP5cZ7EPtTTT0SkGay8kWmJ9g9a3sS67M0qDEf+lpP4+5TCMGFWvWBp+Nj46w4nWnuiGysxfYnJrHmsrmZl5ffttp87C1FrrMK705KM0fPoWH4ZHd+w+46Soa14mInVv4f+yd+UBomDDaAL5CdIEFu4qt/Gr+AlSPLqxWMLQtYxd1eMudSzVvjW8R9drh/w
The left side is simply connected to your base. When you want to test it simply turn on the far left power switch to charge the whole thing.
The right side is the reserve and on the top are the consumers. It doesn't work with more than 3 lasers since it drains the power from the deciders and they end up keeping their last output rather than updating it. To use it for as many lasers as you want, you would also need another reserve for the deciders.
So this does the following:
When it's connected to the base it starts charging accumulator 1.
When accumulator 1 is at 50% it connects to the consumers.
When accumulator 1 is at 100% it starts charging the reserve.
When the reserve is at 100% it disconnects from accumulator 1.
If the power is cut the consumers use accumulator 1 until it reaches 49%
When accumulator 1 reaches 49% it disconnects from the consumers.
When accumulator 1 reaches 49% the reserve is connected to the consumers.
It surely can be made simpler, but that's what i ended up with.
The main problem is that the reserve must always be connected to at least 1 consumer (in this case it's connected to its deciders) so that if power is cut, it eventually falls to 99%. Otherwise - if it remains at 100% - it will never turn on its power switch. So i've used 7 combi and 2 power switches for this. Which is what i meant earlier by "more trouble than it's worth".
I mean, i'd better fill the map with solar panels and steam engines than do this for every outpost xD
iirc, powered belts were tested early in development & found to be more tedious than fun, so the idea was dropped. (Gameplay beats realism.) I just assume they have a hamster wheel with a captured biter somewhere to power them, hehe.
Binary NOT gates are already in the game: you can use a decider programmed for "input =/= 1, output 1" (=/= is "does not equal", or simply "not").
Alternatively, an arithmetic programmed for "input * -1, output value" does a similar inversion (most useful in digital circuits to invert the value of the signal, but can be helpful in analogue or binary circuits too).
Regarding combinators de-powering in general, due to lasers / brownouts / etc ~ that was one of the (minor, solvable) flaws of my rough design. Well spotted. :)
So I would recommend using a stand-alone power supply for those control combinators to prevent such issues: 1 solar panel plus an accumulator would be enough (42kw average per solar, including night-time, combis use very little). Just make sure this power supply only covers those combis & does not connect elsewhere (small power poles ftw).
Doing this is usually easier & simpler than other options I have tried in the past.
However, this "power priority" feature is one way to make an "enemy detector" ~ using a single laser turret fed through an accumulator bridge. When the laser fires, the power is drained from a nearby combinator, interrupting a circuit that controls a power switch, to power-up the main laser banks to each side of the guard turret automagically. Like this: https://i.imgur.com/yjEQRvh.png?1
That seems to be doing basically the same things as the one I designed earlier (just with differing trigger thresholds, & using more components).
Will have a proper look at your BP later this evening, & see if i can find any improvements to suggest (other than a stand-alone power supply for the combinator control circuit).
Personally I love the challenge posed by circuits. Once you get past simple binary / analogue, into digital & parallel processing (the "each" wildcard is awesome btw), then the possibilities expand massively (smart stackers, on-demand deliveries, clever train routing via rail signal controls, monitoring displays & readouts, etc etc).
I like seeing the layout of the circuit visually (all the combis & wires arranged neatly), as it helps me to follow how input signals will go through the circuit & be affected by the various conditions / operations.
When your base has failed past a certain point, so it's certain it's not going to survive on its own, then completely disconnect it from your defenses. Instead, power the defenses up using the reserve power, that is being kept ONLY for the defenses, and/or operations the defenses need (for example, in gun turrets, it would be inserters feeding them bullets.)
Then, the threat was eliminated. the reserve was depleted. Your base power came back on. Everything is powering up. The accumulator 1 works as a "tester" to see if the base's power is stable. It is, as it's being fully charged. Then connect the reserve and charge it, before the next massive attack.
Anyway you get my point. I got really into it as i was describing it xD
Instead, your BP releases the reserve but doesn't disconnect itself from the base. Which means the reserve is powering the base operations along with the defenses.
Mine still has one problem though. The fact that the reserve's accumulator needs to constantly consume 1% of its power and recharge it. Otherwise, it will get stuck to 100% and not do anything. I could probably fix it with a timer but i would need even more components. (a timer could probably work as a loop that constantly adds 1 to its signal, then checks if a threshold is reached, when it's reached it sends a true signal once and resets itself.)
A switch, like power switches, but instead of electricity it allows signals from logical circuits to pass through. Or it could allow just 1 signal to pass through, idc. I said "like power switches" to imply the are turned on/off just like power switches.
However, just to say something. You probably won't need logical circuits to finish the game in the first place. And, to use them, you will have to learn about binary, bitwise operations, etc. I recently found even XOR works with binary. I mean, this is not your typical gamer's soup, right?
So if, in order to do something simple (like on/off) you have to learn programming, doesn't that mean we're going away from gameplay?