Combinator help

[herkalurk]

I'm trying to make a signal output that shows how many trains have passed a signal. I've never really used combinators and was reading the wiki and still haven't figured it out. Below is the current setup of the cominators. Please let me know where I have gone wrong.

light.PNG (834.93 KiB) Viewed 2358 times

arth.PNG (413.04 KiB) Viewed 2358 times

dec.PNG (271.74 KiB) Viewed 2358 times

[DaveMcW]

You picked a hard problem to learn with.

First you need to convert the long red signal into a single-tick pulse.
Then you need a memory cell to store the pulse.

Here is the solution, good luck figuring out why it works.

Blueprint

0eNq9VduumzAQ/JVqH1s44pKkRzz0I476VlXIwCZZydjImKhRxL93bVKSEE5zOVVfkIzX45lZj32AQnbYGFIWsgNQqVUL2Y8DtLRRQrp/dt8gZEAWawhAidqNpC51rS3tEPoASFX4C7K4D24uFIbstkZLZcgIBSlhtTnDSPqfAaCyZAkHJn6wz1VXF2h4kxGqxoq6OkSJpTWM12iJvFGjW16slaPAgNHLMoA9ZGH6suRtWKDievI6DxC7j8HqfCfi0YIryZQdWT9kVn3v1E3IJDd0XbEJRzrxQMYaLfMCt2JHXM9FJ6Ccpysaqa7JtDa/sndHxnb8Z2QyVIROFG/RokNxUK0VrskhG6gbNGJgBZ95pe5s0z2K3d/vZnrpZsxuBpC44o1BVHeUz5mfjrQqLKlC81fnbxp/BPknrp/sjtygboTxrDL49oTdbwNks2dunbL52ug6J8UYkK2FbPGBViRTb4OL6aWL32xTkutEHHv4fHwWj8Yn/l/peZvNTnQZnS/P9bL/0DV0t+nT1qZTrMvp91K2HBUYQTI8Cn03XpG/ZSsyg7rh3Mw06g+VUuoWR/v8aT7xNCiqcc6aDj905cypW536Y1nfZmtDJ3NGn1eXTLS5tPj3LTt7RwOQokBmDN8ZS33yoUV3mndoWr9w9fo1iV/TVZQu+v43EK6UMA==

[CageStooge]

The entire system is the most overly complicated, poorly documented, system I have seen.

It is even more complicated than programming a VCR clock in 1989 with a manual written in hieroglyphics 27 buttons on the VCR and none of them labeled.

I did not check this blue print, so this is not directed at the person who replied to you, but almost everything I have come across is someone showing a youtube how you can do something, but not actually showing you step by step what to hook up, but rather than "here I made this do x, isn't that neat" and so i mean I can see it is working but not a clue how.

Or, someone posts a blue print, I plop it in and I see lots of numbers flying by but yet it doesn't actually achieve what the stated intention was.

Seriously, I can code in shell scrips, Powershell, c#, java, and can usually work my way through understanding what virtually any programming language is doing, so it's not like the concept of foreach, do while, do until, nested loops, nested if then (else), etc.

I'm beyond irritated with it, and quite honestly have given up. It is LITERALLY easier for me to just run around and do whatever a circuit would be expected to do then waste HOURS trying to figure out how to have a simple clock work; and still haven't gotten it to do so. I've been through the wiki and here's a suggestion, how about someone plop a blueprint into the wiki rather than trying to explain it in terms of stereo instructions.

Yes, as you can probably work out, I'm rather irritated with the entire system. It's fundamentally just poorly implemented at best. I went from telling people "Factorio is awesome" to "Factorio is awesome, unless you try to use the circuit system".

/rant

tl;dr Circuts are overly complicated, poorly implemented, documented even worse than stereo instructions from the 80s, and should have been left out of the game without a better implementation system.

[herkalurk]

The entire system is the most overly complicated, poorly documented, system I have seen.

It is even more complicated than programming a VCR clock in 1989 with a manual written in hieroglyphics 27 buttons on the VCR and none of them labeled.

I did not check this blue print, so this is not directed at the person who replied to you, but almost everything I have come across is someone showing a youtube how you can do something, but not actually showing you step by step what to hook up, but rather than "here I made this do x, isn't that neat" and so i mean I can see it is working but not a clue how.

Or, someone posts a blue print, I plop it in and I see lots of numbers flying by but yet it doesn't actually achieve what the stated intention was.

Seriously, I can code in shell scrips, Powershell, c#, java, and can usually work my way through understanding what virtually any programming language is doing, so it's not like the concept of foreach, do while, do until, nested loops, nested if then (else), etc.

I'm beyond irritated with it, and quite honestly have given up. It is LITERALLY easier for me to just run around and do whatever a circuit would be expected to do then waste HOURS trying to figure out how to have a simple clock work; and still haven't gotten it to do so. I've been through the wiki and here's a suggestion, how about someone plop a blueprint into the wiki rather than trying to explain it in terms of stereo instructions.

Yes, as you can probably work out, I'm rather irritated with the entire system. It's fundamentally just poorly implemented at best. I went from telling people "Factorio is awesome" to "Factorio is awesome, unless you try to use the circuit system".

/rant

tl;dr Circuts are overly complicated, poorly implemented, documented even worse than stereo instructions from the 80s, and should have been left out of the game without a better implementation system.

It's not about knowing scripting languages, it's know base machine code. I work in IT, can script in bash, powershell, javascript, and php. This isn't any of those languages. There isnt XOR in most languages today, but it's in the base code.

[CageStooge]

Actually PLCs do have a type of programming language, but regardless the entire system in the game is overly complicated. The mod MicroController is a better implementation, but even that could be improved if it were handled by the developers.

Why not just do this:

Put a sensor on a pipe. Have it monitor the flow, or the pressure, or any other variable.
Have another system that acts as a controller
Have us name the sensors either with a "name" or an integer "id"
Give us a gui that let's us drag or type in the sensor / switches / monitors / whatever

So, put a sensor on a tank name it tank1_sensor
Put a sensor on another tank name it tank2_sensor
Put a power switch on a pump (pump_switch1)

Give us a an HMI / GUI where you drop in tank1_sensor, tank2_sensor, and pump_switch1.

if tank1_sensor & tank2_sensor > 5000 then pump_switch1 = on

or

if tank1_sensor + tank2_sensor > 3000 then pump_switch1 = on

or

if tank1_sensor or tank2_sensor < 3000 then pump_switch1 = off


No need to string wires all over the place. No need to figure out red input, output, loop wire, this green network touches this red network, but don't let it accidentley touch this red wire to this power pole, because it will then integrate with another red network and blow both of them up. In fact, literally no need for power at all.

Nothing else in this game is anywhere remotely close to the complicated nature of the method in which they implemented factory automation. This game is intuitive in every way, except this one. Now, a new user may not know how to create an optimized system of processing oil to begin with, but they can figure out "oil pump here, pipe to chemical plant, set plant to make x, pipe that to this other thing, and eventually spit out a product.

Then, if you give us a method to actual write some type of simple BASIC code system, people can scale up the complexity to whatever level they want. We would see some seriously cool automation that the current system is unable to provide despite the fact that it is incredibly overly complicated to implement. The return on investment (ROI) is virtually non-existent, and is honestly probably a negative ROI. It's also too fragile, and incredibly complicated to tweak as the factory grows.

As for wires we can just pretend all the sensors, switches, etc. are on a wireless network. Since the game has flying bots, I am sure we can all believe that electronic devices can communicate via wireless systems. Sci-Fi sounding as that is, I can believe it's realistic enough.

If there is a part of your program that has your users confused, frustrated, and often just give up on it, then you have to ask yourself: "could we do this better, or should we remove it, because maintain that code of the game takes more time than enjoyment players derive. "

That's the developers call. Right now it's more of a novelty kind of thing. Oh look, I can flip a light on if this happens. That's neat. Can I do anything else that makes it really productive <20 hours banging your head on the desk later> "No, not really."

[Frightning]

If you want a better first practical circuit to try making on your own. Have a look at Advanced oil processing and try and setup some circuits to control cracking of Heavy oil into Light oil and Light oil into Petroleum gas. The goal, imo, should be that you keep at least a modest stock of the first two, and make sure that the last isn't backing up the whole system (unless you just have more crude coming in than you need, but then cracking should stop if Petroleum gas gets too close to full). My preferred solution uses 3 combinators for each cracking process (regardless of number of cracking plants per process though).

[Hedning1390]

It is LITERALLY easier for me to just run around and do whatever a circuit would be expected to do then waste HOURS trying to figure out how to have a simple clock work; and still haven't gotten it to do so. I've been through the wiki and here's a suggestion, how about someone plop a blueprint into the wiki rather than trying to explain it in terms of stereo instructions.

I really don't see what is so hard to understand. Every game tick (60/s) each combinator takes what is currently on the input side, adds red and green signals together and then performs whatever transformation the player has chosen and outputs it on the output side. The conversion takes exactly 1 tick and all combinators are synchronous.

A basic clock therefore is a simple always on combinator (eg with condition wood=wood) which just outputs the input back to the input with a constant added to the system. Hence the first tick it will output 0, so the inputs are 0+c, next the outputs are 0+c so the inputs are 0+c+c and so on.

The whole point is that it is accessible to everyone and you don't have to know any programming to understand it. With any kind of typing comes notation and syntax which isn't self evident.

[quyxkh]

OP, each tick the signals on a wire are the sum of the signals on all connected output posts. Combinators operate on the sum of the signals on their connected input wires, and deliver the result on both output posts next tick.

The simplest counter is a pulse counter. If you want to count everything that passes through a belt segment you set it to read-pulse and wire it to an Each+0⇒Each combinator's input, and also wire that combinator's output back to its own input. So the signal on the wire is the sum of the belt segment's pulse output and the combinator's output (of its inputs from the previous tick). Just connecting wires is combining signals, this is not like coding programs, it's more like, I don't know, maybe some weird kind of physics. Maybe it's close to how electrical signals really work, minus the annoyances brought on by induction and resistance.

Rail signals don't have a read-pulse mode. So you have to convert the output to a pulse somehow. That's a puzzle too. All of this is a design puzzle. It's not much like programming, because the signals all get summed without you asking. A little mental aikido is needed, use the tools' strengths to get them to do what you want. Combinators deliver their results one tick later, to convert a level signal to a pulse you can add in the negated value after one tick, but the result can't be fed back because then the negator wouldn't see the original signal... and now you've got a pulse on two wires, the current level on one wire and the negated previous level on the other, so their sum is the net change from the last tick. But you don't want all the changes, you only want to count the changes from not-red to red, the _positive_ changes. For that, add an Each>0⇒Each, and wire its output to a counter.

You get to where you recognize wiring patterns. Where I can, I use red wires for negated values, for want values, for take pulses; I use green wires for positive values, have values, put pulses. So here,

snap@T102593=336x160+7.25-12,z2.jpg (3.98 KiB) Viewed 2216 times

it's pretty easy to read what's going on: the rail signal readout is going to a multiplier, both the readout and the red-wired multiplier result are going to a > decider, and its output is going to a feedback-wired adder. There aren't many things that could be but a pulse converter and a positive-pulse counter.