Factorio Forums

Sorry for the subject title...

TL;DR: something has to be done with the circuit system... - More discussion than suggestion...

----

example: ----

Circuits are complicated, confusing, visually annoying. But dunno what do to would be the best.

It's not the same fun as creating "circuits" in Minecraft. For example using chests as a computer memory is simply ridiculous.

Maybe there should be an extra toggle option to display the circuit stuff, i.e. including the wires to hide the wire salad.

Maybe there should be just some kind of computer box for circuits instead of the comparators.

The computer box on the other hand should either use a simple BASIC*) "script" interpreter or some kind of graphical programming, using 1x2-elements (input&output) and wire tiles in a grid, perhaps making a kind of schematic...

The computer "building" should be 2x2 in size, having 2 inputs and 2 outputs for red and green networks each.

Both solutions are ridiculous much work though. But if you worry about performance: it would still be more efficent than the current higgledy-piggledy wiring.

----

*) would look like this:
IF (#<channel>:<signal><operation>#<channel>:<value/signal> [{AND|OR} #<channel>:<signal><operation>#<channel>:<value/signal>]) THEN
- might/can only take up to 2 logically combinable comparsions - to keep conditional branching compact in case.
"channel" is one of "#A", "#B", "#Ar", "#Ag", "#Br", "#Bg" - the input connectors, represented by red, green or yellow "A" or "B" symbols in the program editor GUI, where "#A" and "#B" are adding the same signals from the red and green network
Signals and operations are graphically selected from the list, they may also be "EVERY", "ANY" and "EACH" in case.
(Optimisation: there are several variations of the instruction: "IF (...) THEN", "IF (... AND ...) THEN" and "IF (... OR ...) THEN")
- there maybe also IS_NULL and IS_NOT_NULL as a quick operation option

ELSE_IF (<just the same as IF>) THEN
short for "IF ... THEN {...} ELSE { IF ... THEN ... END_IF } END_IF"

ELSE
Done if all IF/ELSEIF statements before are not true

END_IF

OUT #<channel>, {#<channel>:<signal>|value}
Puts out/changes the given signal or value to the channels "#C", "#D", "#Cr", "#Cg", "#Dr", "#Dg"
You would have to use "OUT #..., #...:EVERY" to "pipe" all signals from the input to the output, but better should only "pipe" what you need.

IN #<channel>:<signal><operation>{#<channel>:<signal>|value}
Manipulates incoming signals like the arithmetic combinator. After referring to the given channel, the signal is manipulated in the given way, but only internally.

END
Stops the program interpretation; at this point all signals are really put out to the networks

<Label>:
A jump mark, just a number from 1 to 9. Programs shouldn't be very large anyway.

GOTO <label>
Continues the program at the given label. You can only jump to labels behind your GOTO line, therefore you can't create loops except externally via your wiring. Only needed if/because you can't make random AND/OR comparsions with the IF statement.

I agree that the circuit network can be very overwhelming for new players. Therefore, at the very least, Factorio should offer some kind of advanced tutorial which teaches you common things to do with the circuit network. This has already been discussed in the following thread:

viewtopic.php?f=6&t=40703 Circuit Education

It may also be nice to have a more powerful entity, such as a processor which can be programmed with assembler instructions, such as MOV (copy to/from register), JMP (jump to label) and CMP (compare register contents with input value). This works very well in the games TIS-100 and SHENZHEN I/O. In these games, you have multiple processors that each have one or two registers and can interface with external memory modules. However, this would only be of interest for advanced players and would not make the game any easier for new players.

In your post, you suggest having IF, ELSE_IF, ELSE, END_IF. This feels too high-level to me. If you allow such structured programming constructs, you might as well allow the player to write code directly in LUA (which is the language Factorio uses for mods). I am against this, as Factorio is all about creating great things from simple building blocks.

Factoruser wrote: Sat Oct 06, 2018 1:35 pm It's not the same fun as creating "circuits" in Minecraft. For example using chests as a computer memory is simply ridiculous.

Although it is possible to use chests as memory in Factorio, one would normally use combinators for that. See this section of the official wiki page for more information.

It's not overwhelming, it's making a cable tangle if you try to make more sophisticated circuits, and you can hardly see HOW you wired the elements together. Therefore a programming language won't be THAT user-unfriendly compared. But it should be like the shown primitive BASIC, not Assembler. This would cover the skills of the majority of all players best.

My BASIC only allows signal processing of the circuits. And LUA has an IME rather bad-designed syntax - you need too many unnecessary (punctuation) characters; if you'd confront ordinary players with it, they will just produce a dozen syntax errors but nothing that ever works. Further you won't hack a source code, you are "drawing" it; selecting "IF" or "OUT" from an instruction list for example. There is no text parser except if you have an import/export option. Internally you have to store a signal-ID of course as "iron-plate" for example, it might change resp. no longer exist with other mods or newer versions.

I have to work with high level languages and with simple signal flow 2D languages for automatisms regularily. The signal stuff in Factorio is quite confusing. There is no easy way to convert between singal level logic and signal edge trigger logic. There are no easy to implement delay element. And an R/S latch should also be it's own element. And in the end all logic elements like AND/OR/NAND/XOR are missing. You can implement them, but it's way too complicated to become useful.

But to be honest, building serious stuff in Minecraft is mind numbing and cumbersome too.

On a second thought. Yes, you can emulate logic gates using the arithmetic signal stuff. But it's still making it not easier to work with. What is missing, is a way to define your own combinator devices in terms of the existing basic ones (constant, decider, arithmetic). You can already blueprint them, thats great. But it does not allow me to abstract away how a clock is defined. I still need to know where and how to connect the wires properly. I also have to use the same signal names the blue printed circuit defined for me to use. It's like using global variables everywhere.

If you could define your own AND/Clock/XOR/RS-Latch combinator device, where the user of the device sets the input and output signals him/herself, you could actually properly build more abstract logic upon the existing combinators.

You can do anything with the factorio "combinators" but the point is, how easy. One big problem is, that you have to regard how the "combinators" are connected. A single wrong wire destroys the whole concept, and you hardly see which "combinator" is connected with what. Because you can only make a single comparsion with one "combinator", you actually need at least three buildings just for a simple "if value is between A and B".

It would be a great relief therefore if you could just use at least 2 conditions in the decider combinator and combine them with AND or OR.

It might be a bit easier further, if you won't have to connect all combinators manually for example, i.e. if one output touches an input, they are getting wired automatically...

But still, aesthetically it would be better if you have just a box at the side of your constructions which is doing all the "math". You may even wire in this box like now on the map, but this might be more difficult to realise and less performant. And it still won't solve the clearness problem.

Factoruser wrote: Sun Oct 07, 2018 12:47 pm You can do anything with the factorio "combinators" but the point is, how easy. One big problem is, that you have to regard how the "combinators" are connected. A single wrong wire destroys the whole concept, and you hardly see which "combinator" is connected with what. Because you can only make a single comparsion with one "combinator", you actually need at least three buildings just for a simple "if value is between A and B".

Yes, thats what I meant too. For proper development you would have to be able to build small building blocks, like the "if value is between A and B", debug it once and then package that as new "combinator" block/component. Blue prints already help with wiring of course, but you can still easily mistake wiring other functional block to that.

I would also argue that dealing with logic gates is much easier, also for new and inexperienced players. But I also see, that you still need combinators that calculate analog signal values.

I'm not sure which solution would be better resp. easier to implement... At least you'll still need a kind of code that represents the logic of your combinator. It would be cool though if you might have an in-game puzzle where you draw a kind of circuit schematic...

A while back I put together a few proposals I thought would work to expand the combinator system in interesting way.

viewtopic.php?f=6&t=58050

Instead of wide-sweeping changes, why not one change: a toggle for each combinator's input/output for the origin/destination of the signal (Red/Green/both wire(s))

The combinator menu would (in words) look something like: Each on Green > 0 -> Each on Red
(Outputs Red signals that are larger than 0 on Green)

Or a more novel utility: Iron Ore on Green > Iron Ore on Red -> Iron Ore on Red
(Outputs Red signals that, on Green, are larger than Red)
(Tests across the same signal from different wires, currently not possible)

The mechanic should only output the value from the first input in the logical test when tested across individual wires. (I believe, to avoid short-comings that I can't forsee, like testing on both colors but outputting the value on Red; which value--on Red or Green--do we output?)

For instance:

I want to filter one signal from many, and I want to set which via a constant combinator (my preferred "start" mode for a circuit").

In v.16 current, I have to first filter say positive numbers from the total (1 decider), set constant say iron ore to 1 and amplify it to -2^32 (1 constant, 1 arithmetic), sum these two signals and decide if its less than zero (1 decider), then regain my input value by subtracting -2^32 (basically adding 2^32, without the sign bit) (1 arithmetic).

In the proposed mechanic, I could simply set constant say iron ore to 1, feed that into decider on Green, and total signal on Red. Then I could decide: if iron or (on Red) > 1, output iron ore input count (on Green). The corresponding output would ideally not sum, but rather simply filter Green signal through; in just two combinators



The list goes on as to how many combinator contraptions would be simplified. And I believe the circuit network would be easier to understand if we make a combinator behave more like a single logic gate (with the added functionality of course)

Has anybody thought of this? (Edit: Totally, with pictures)
Let me know what you guys think! I love circuits and the current challenges they pose, but I hate smh that I need 4 combinators to filter a positive signal from noise.

I’ve also made suggestions viewtopic.php?f=6&t=62138#p376047