Factorio

Factorio

View Stats:
MAKAIROSI Aug 30, 2019 @ 8:47am
I still would love an on-off switch
A condition for it to be "on" and a condition for it to be "off". Right now it's "if-else", with no way to add another "if" (so as to make an on-off switch (if x true on, else if y true off )). At least last time i played there wasn't.

For example, you have lasers connected to capacitors, your base charges those, then disconnects from them. If your base has a deficit, it won't drain those capacitors. If your capacitors are emptied, then they are connected to the base.

This is extremely simple to do like "if capacitor=empty then connect else if capacitor = full then disconnect". But all you can do is "if capacitor=empty then connect else disconnect" which will just disconnect the capacitor as soon as it gets the slightest energy.

You could, in theory, create a bunch of logical gates to work like an on-off switch, but that would take more effort than it would worth. I haven't put much thought into it but having anything more than 1-2 gates for a simple "on when x, off when y" switch is just too much trouble.

You could end up with amazing things with on-off switches though! That's why i don't understand why they haven't implemented them yet (if they ever will).
Last edited by MAKAIROSI; Sep 3, 2019 @ 8:24am
< >
Showing 1-15 of 31 comments
The_Mell Aug 30, 2019 @ 9:10am 
Then please tell me how it should behave if both conditions to trigger on and off are true.
Killcreek2 Aug 30, 2019 @ 9:45am 
You can use a power switch manually (even from the map screen if you have radar coverage), or circuit wire it to a constant combinator which you turn on/off to control it instead. There is also a "pushbutton" mod, that does similar when stepped on (bit easier than opening the CC to toggle it on/off).

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).


Originally posted by MAKAIROSI:
For example, you have lasers connected to capacitors, your base charges those, then disconnects from them. If your base has a deficit, it won't drain those capacitors. If your capacitors are emptied, then they are connected to the base.
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.)
MAKAIROSI Aug 30, 2019 @ 9:31pm 
First of:

Originally posted by The_Mell:
Then please tell me how it should behave if both conditions to trigger on and off are true.

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
Killcreek2 Aug 30, 2019 @ 11:46pm 
Originally posted by MAKAIROSI:
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
Standard latch is 1x combi, plus up to 2x more combis to set the high/low thresholds. Can be built in less than a minute from scratch (with some practise), & even quicker if you make a BP of it.
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:
0eNrFl9uOmzAQhl+l8jWsMASSILVSNy/Q+ypCBpxdS2CQD8lGEe/eMezmhEmgStobxMHz2TP/eMYcUFpoWgvGFYoPiGUVlyj+fUCSvXFSmHdqX1MUI6ZoiRzESWme6mpHhSt3TGXvqHEQ4zn9QLHfOHdNc5qxHIyzqkwZJ6oSZ4CgWTuIcsUUo91C2od9wnWZUoFifOSQLNOlLlqAAwuSYFNxMy1w3PlL6KA93MxeQsCDX0pURZLSd7JlYAHDKq1qrZLecrdMKA1vjjN1I9yfqOlInGZmKmlssLm8CUr5+WpZbmKxbhoTjysPfHsQ+y54913ImMg0Uwl8y4+2GybkNLccJKlBjDd6Re2KypqIVoAY/ZgWHXwWmfYZhP3ypvu+BtxKe9eGEJMdE7S990y2rDS+HhNdjrGpEIzLo+jxafQ6MVB+PzA2h2aneXQqFWmd6CcVPmZVAB5ZOOGJU5KicGkByxQsc+uqoBbgF83GiqaxZjdQ81HuLe84tzhRqoIItyacFtYotRjPxliOZMyHEQY/sQbg59cAU/sVMY3AG723Bc17CRtcJqz/5J2M8a3WMpRkXTxzYGfdx5k9up/IU3Tl48P7HQz+ohkZSr2HlWmuko2oyoRxYKB4QwpJJ/Yq527RcZA/pLh/rbhzMyOGShj2JykZ/n8lw/5OmS7l6qFS9hvppRjBbSlxf/NapQomSeV/ljF8qVT0bKWmHmtWlmPNP9yb4wRxBoS31t1Bob3RoMHtejpyFERCBigtBFXDXdmzN2UcTuvK1vMBjia1ZWCA++2PSXz2C+SAJymYxeiX6cvflCBcbuCGfpCybs8sWypki5sHHl7Mo+XMWzTNH0TKfjg=
MAKAIROSI Sep 1, 2019 @ 7:16am 
@Killcreek2 I used what you posted and it does work. Some minor details: Logic gates in the game need electricity to operate. So when A=0 then the whole system doesn't work anymore (it won't turn on your secondary power switch). I found it needs to be at least 1% when the turrets are not firing, so A<2.

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).
Fel Sep 1, 2019 @ 7:41am 
Well a switch is that it has exactly 2 states, ON/OFF (or 1/0, or true/false, they all mean the exact same thing), how would it handle cases like both conditions being met or neither?
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).
MAKAIROSI Sep 1, 2019 @ 3:21pm 
First of all, i have to address what you said about the crafting machine. I understand you exaggerated in your example but in no way am i talking about making factorio something else.

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.
Killcreek2 Sep 2, 2019 @ 7:03am 
Well, the thing I built for you was actually two switching controllers in one combined package: first very simple (1x power switch) to make one-way electricity flow; and a second more-complex (1x ps, 3x combi) for the emergency back-feed.
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).


Originally posted by MAKAIROSI:
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).
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.
MAKAIROSI Sep 2, 2019 @ 9:01pm 
@Killcreek2

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.
Last edited by MAKAIROSI; Sep 2, 2019 @ 9:03pm
MAKAIROSI Sep 2, 2019 @ 9:25pm 
Actually i just came up with an idea, but i'm gonna test it first.

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.
Last edited by MAKAIROSI; Sep 2, 2019 @ 11:40pm
MAKAIROSI Sep 3, 2019 @ 7:53am 
@Killcreek2

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
Last edited by MAKAIROSI; Sep 3, 2019 @ 7:57am
Killcreek2 Sep 3, 2019 @ 2:05pm 
Originally posted by MAKAIROSI:
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.
It is a bit unrealistic, yeah.
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.

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"?
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).


Originally posted by MAKAIROSI:
Actually i just came up with an idea, but i'm gonna test it first.
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.
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


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.
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.
MAKAIROSI Sep 3, 2019 @ 10:37pm 
Yes, your idea was excellent but it didn't do what i wanted it to. I wanted the reserve to be disconnected from the base. This way, when the base starts failing and everything starts crumbling down, your reserve remains untouched and isn't drained along with the base.

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.)
MAKAIROSI Sep 3, 2019 @ 10:48pm 
So if we're going away from conditional on/off switches (though going away from that idea still seems like wasted potential to me), i have one more idea. Judging from the opposition the first one received, these ones will definitely get more.

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?
< >
Showing 1-15 of 31 comments
Per page: 1530 50

Date Posted: Aug 30, 2019 @ 8:47am
Posts: 31