Factorio Forums

Loewchen wrote: Sun Nov 26, 2023 6:56 pm

DarkShadow44 wrote: Sun Nov 26, 2023 6:44 pm @Koub I only get "You are not authorised to read this forum."

It's trashed.

[Moderated by Koub : please don't add fuel to the fire, the whole discussion was moderated don't restart an argument.]

Request: TICK DELAY. A TICK DELAY option assigned a single numeric value. Its purpose would be to to delay the combinator updating its output for a given amount of in game ticks.

Tick sensitive circuits can be really tricky and often are encumbered by "blank" tick passthrough combinators that "bulk up" otherwise simple circuits in order to synchronize a given combinator's evaluation.

This is often problematic when we want to evaluate a single tick.

Example: a single tick is isolated from a given circuit network. It is evaluated by combinator A to produce output A. At the same time it also evaluated by combinator B to produce output B. Output B is then evaluated by combinator C to produce output C. Output A and output C are evaluated by combinator D to produce output D. If left untouched combinator D will asses output A, then output C. In order for this to work a "passthrough" combinator must be placed after output A and before combinator D so that Combinator D will assess both output A and output C at the same time.

Alternatively (hopefully ) Combinator A could be assigned a TICK DELAY value of 1.

Raatle wrote: Mon Nov 27, 2023 3:56 pm Request: TICK DELAY. A TICK DELAY option assigned a single numeric value. Its purpose would be to to delay the combinator updating its output for a given amount of in game ticks.

Tick sensitive circuits can be really tricky and often are encumbered by "blank" tick passthrough combinators that "bulk up" otherwise simple circuits in order to synchronize a given combinator's evaluation.

This is often problematic when we want to evaluate a single tick.

Example: a single tick is isolated from a given circuit network. It is evaluated by combinator A to produce output A. At the same time it also evaluated by combinator B to produce output B. Output B is then evaluated by combinator C to produce output C. Output A and output C are evaluated by combinator D to produce output D. If left untouched combinator D will asses output A, then output C. In order for this to work a "passthrough" combinator must be placed after output A and before combinator D so that Combinator D will assess both output A and output C at the same time.

Alternatively (hopefully ) Combinator A could be assigned a TICK DELAY value of 1.

I think a lot of this will be addressed by how capable the new decider combinator is. I haven't run through every possibility, but I suspect any decider combinator chain can be replaced by a single decider combinator in 2.0.

My 5 Cents to the Selector Combinator:

Making it possible to have control logic on one color and values on the other would be a great addition.

Essentially we have two different wires for receiving signals of different origin.. why not make them as atomic as they are with a simple toggle switch?

imagine setting the selector combinators output index through a green wire while providing a bunch of signals through the red wire, resulting in the nth index of red

computeraddict wrote: Mon Nov 27, 2023 5:15 pm

Raatle wrote: Mon Nov 27, 2023 3:56 pm Request: TICK DELAY. A TICK DELAY option assigned a single numeric value. Its purpose would be to to delay the combinator updating its output for a given amount of in game ticks.

Tick sensitive circuits can be really tricky and often are encumbered by "blank" tick passthrough combinators that "bulk up" otherwise simple circuits in order to synchronize a given combinator's evaluation.

This is often problematic when we want to evaluate a single tick.

Example: a single tick is isolated from a given circuit network. It is evaluated by combinator A to produce output A. At the same time it also evaluated by combinator B to produce output B. Output B is then evaluated by combinator C to produce output C. Output A and output C are evaluated by combinator D to produce output D. If left untouched combinator D will asses output A, then output C. In order for this to work a "passthrough" combinator must be placed after output A and before combinator D so that Combinator D will assess both output A and output C at the same time.

Alternatively (hopefully ) Combinator A could be assigned a TICK DELAY value of 1.

I think a lot of this will be addressed by how capable the new decider combinator is. I haven't run through every possibility, but I suspect any decider combinator chain can be replaced by a single decider combinator in 2.0.

Agreed, rather than adding a tick delay function the root cause should be solved.

pleegwat wrote: Mon Nov 27, 2023 7:46 pm

computeraddict wrote: Mon Nov 27, 2023 5:15 pm

Raatle wrote: Mon Nov 27, 2023 3:56 pm Request: TICK DELAY. A TICK DELAY option assigned a single numeric value. Its purpose would be to to delay the combinator updating its output for a given amount of in game ticks.

Tick sensitive circuits can be really tricky and often are encumbered by "blank" tick passthrough combinators that "bulk up" otherwise simple circuits in order to synchronize a given combinator's evaluation.

This is often problematic when we want to evaluate a single tick.

Example: a single tick is isolated from a given circuit network. It is evaluated by combinator A to produce output A. At the same time it also evaluated by combinator B to produce output B. Output B is then evaluated by combinator C to produce output C. Output A and output C are evaluated by combinator D to produce output D. If left untouched combinator D will asses output A, then output C. In order for this to work a "passthrough" combinator must be placed after output A and before combinator D so that Combinator D will assess both output A and output C at the same time.

Alternatively (hopefully ) Combinator A could be assigned a TICK DELAY value of 1.

I think a lot of this will be addressed by how capable the new decider combinator is. I haven't run through every possibility, but I suspect any decider combinator chain can be replaced by a single decider combinator in 2.0.

Agreed, rather than adding a tick delay function the root cause should be solved.

How do you guys see the new selector combinator solving this? The new features are exclusive to the decider combinator. The arithmetic combinator is just as susceptible to the same problem. In the example what if combinator D is arithmetic?

As far as addressing the root cause.. I think you'd have to be able to string multiple arithmetic operations into the arithmetic combinator, all of which would have to be done in a single tick. The crux of the problem is concurrency. The new decider combinator combines multiple logical comparisons into a single tick but arithmetic operations are still untouched. Somewhere along the line something is gonna have to wait for something else.

So when I came here, I looked through the first couple of pages and the last couple and saw a couple of people posting the same thing I was interested in.

When I saw saw the name "Selector Combinator" I (I think justifiably) assumed that it would have the arbitrary ability to "Select" signals. The ability to filter signals, on either a whitelist or blacklist, is one of the things that I've wanted... literally every run that I've ever had. And yes, I'm aware of the option to add an arbitrary large number, then run it through a decider combinator, then output all signals greater than that number, then subtract off the number again. But it's several combinators for what feels like one of the most basic operations.

As I was getting ready to write the post, I realized that while the selector combinator lacks this functionality... I think it was actually added to the decider combinator. Unless I'm mistaken, I should just be able to make a decider combinator that has no condition (or it might require I create a 'true' condition as it's condition?) and then just... output the list of signals that I want filtered. It should even be able to pull the filters from either the red or green wires if I've got mixed signals. Does anybody else see a reason this wouldn't work?

Please also use the new compound decision tree of the decider combinator everywhere an entity has enable/disable. Every time one want's to enable an inserter when "stone > 1000 or stone brick < 10" it's a pain.

And maybe also make the arithmetic combinator use a expression tree and have little checkmarks for red/green wires.

2 mockups for an even better arithmetic combinator: The arithmetic operator for just one operation but with the option to pick wire colors. This would just be consistent with the decider combinator being able to pick wire colors.
An arithmetic combinator with complex expressions. This might be difficult as it would need a variable number of columns in the Expression tree. Since it's a tree there is no need for parens or precedences. The topology of the tree fully shows how the expression is calculated.

The yellow <> are there to change the shape of the tree. Clicking "<" or ">" (equivalent in this case) would turn "green * red + furnace" into "green * (red + furnace)". Programatically speaking they are are roll-left/right operation on the tree as you might be familiar from many balanced tree data structures.

Drag and drop operations might also be an option. For example you could drag the "*" or white square bracket down to make this "furnace + green * red". Or drag the green circuits down to make it "red * green + furnace".



Additionally I think a stacksize signal (like Each) would be very benefitial allowing the user to specify "each * stacksize" and "each / stacksize". The former currently needs 7 combinators (more if you need multiple constant combinators to define all the stack sizes) and the later is not generally possible in factorio now. The red/green selection would reduce this to 2 combinators (constant combinator + arithmetic combinator) in most cases but it's still bothersome to setup for each case.

A for effort, mrvn, but I dislike both the complicated mockup you made (the second one) and the idea of hiding even more logic inside combinator GUIs instead of physicalized in the game world.

If this is going to happen, I would rather be able to type an arithmetic expression on a single line, with good syntax highlighting and auto-complete of signal names/icons. I think the indented drag and drop style GUI would be too cumbersome for refactoring. It would also not be easy to read when there are many operations and levels of nesting.

But I am against this idea anyway (choosing input/output wires is fine though). Multi-conditional deciders are already going to compactify so much, we don't need even greater space-savings.

1. Land is virtually free in this game. There is no real obstacle to finding space for combinators which would be solved by this feature.
2. Combinators look cool. Complex logic should look cool. Stuff hidden inside GUIs doesn't look cool. Diegetic interfaces (in-world stuff) IS cool. ("Rule of Cool")
3. If there are problems with working with combinators as a unit of logic (instead of GUI tree elements), then such problems could be addressed in other ways, which could also benefit other areas of the game. For example, one problem I often face is refactoring the layout of combinators after having figured out the logic. This is currently a huge pain, but could be vastly improved by allowing small entities near the player to be nudged, or for cut & paste to remember wire connections between cut and non-cut entities.

I feel like the primary motivation for forcing this multi-operation feature into arithmetic combinators is just for the sake of parity/symmetry with decider combinators (symmetry is overrated). I feel like people are thinking about this feature more because it is fun to think about, a fun challenge in and of itself, but that doesn't mean that it's a good change to the game. In other words, you are thinking too much how it COULD be done, versus whether or not it SHOULD be done.

It seems like it is simply assumed that this would be a good change, but I would like to see one strong motivating argument or use case for it. Before/after pictures ideally. Otherwise I am convinced this is just change for the sake of change, change for the sake of symmetry, and it will come at the cost of coolness and simplicity.

I just realized last night that the R/G choice on the output of a arithmetic combinator makes no sense. If you don't want the result on the green wire then don't connect a green wire.

SupplyDepoo wrote: Thu Dec 07, 2023 6:01 am A for effort, mrvn, but I dislike both the complicated mockup you made (the second one) and the idea of hiding even more logic inside combinator GUIs instead of physicalized in the game world.

If this is going to happen, I would rather be able to type an arithmetic expression on a single line, with good syntax highlighting and auto-complete of signal names/icons. I think the indented drag and drop style GUI would be too cumbersome for refactoring. It would also not be easy to read when there are many operations and levels of nesting.

But I am against this idea anyway (choosing input/output wires is fine though). Multi-conditional deciders are already going to compactify so much, we don't need even greater space-savings.

What exactly don't you like in the first mockup if choosing the input wires is fine? That is literally all it adds to the already shown interface for the 2.0 combinators.

As for typing in an expression on a single line: I thought about that but then you have to add parens and match them, figure out the right precedence for each operator and whether it is left or right associative and the user has to figure out all that stuff as well. For example take the shift operator: Is A << B + C mend to be (A << B) + C or A << (B + C). Surprise: In C and other languages it is the later. How confused do you think users will be when the precedence and associativity is not what they imagine?

Secondly typing in the item and signal names is hard, more so with non english speakers and translations. You have to type in the internal name like angle-crushed-ore-4. At a minimum that needs an item/signal picker.

SupplyDepoo wrote: Thu Dec 07, 2023 6:01 am

1. Land is virtually free in this game. There is no real obstacle to finding space for combinators which would be solved by this feature.
2. Combinators look cool. Complex logic should look cool. Stuff hidden inside GUIs doesn't look cool. Diegetic interfaces (in-world stuff) IS cool. ("Rule of Cool")
3. If there are problems with working with combinators as a unit of logic (instead of GUI tree elements), then such problems could be addressed in other ways, which could also benefit other areas of the game. For example, one problem I often face is refactoring the layout of combinators after having figured out the logic. This is currently a huge pain, but could be vastly improved by allowing small entities near the player to be nudged, or for cut & paste to remember wire connections between cut and non-cut entities.

I feel like the primary motivation for forcing this multi-operation feature into arithmetic combinators is just for the sake of parity/symmetry with decider combinators (symmetry is overrated). I feel like people are thinking about this feature more because it is fun to think about, a fun challenge in and of itself, but that doesn't mean that it's a good change to the game. In other words, you are thinking too much how it COULD be done, versus whether or not it SHOULD be done.

It seems like it is simply assumed that this would be a good change, but I would like to see one strong motivating argument or use case for it. Before/after pictures ideally. Otherwise I am convinced this is just change for the sake of change, change for the sake of symmetry, and it will come at the cost of coolness and simplicity.

There is a problem with doing complex logic with separate arithmetic combinators. Each combinator adds a delay of 1 tick. For one thing that makes complex arithmetic slow to react. That delay can have real issues when you control logistic chests or filter inserters with it. Too long of a delay and the inserter will complete an extra swing before you can compute a new filter for it and you get the wrong items.

Secondly the delay means you easily end up with information from different ticks. Take for example A * B + C. This takes 2 combinators and then you add A * B from tick 1 to C from tick 2 giving you a result at tick 3 skewing the result. To get the right answer you need to do A * B + C * 1, adding an extra delay on the C input. Often you don't care abut the timeing skew but when it is important things get ugly quickly.

Thirdly there are only 2 signal colors. That means you can only propagate the signal in so many ways before signals from different inputs affect each other. Then you have to add even more combinators with "EACH + 0 = EACH" just to isolate signals adding more delays and confusion with wires going every which way.

Remember that you can not see what a combinator does. Without alt view you see the operator but not the signals, with alt view you see the signals but not the operator. And you never see the output choice. Eigther way you see less than half the equation. So I challenge you to your claim that an expression tree would be harder to read than a bunch of combinators berried under a nest of wires.

The complexity could also be limited to a maximum number of operations to keep the expression simple and the internal data structure of the combinator at a fixed side so it doesn't need to use allocations and indirections. Something like 7 operators and 8 inputs for example. Maybe something that fills up a cacheline exactly. I would hate such a limit on principle but reality is what it is.

I also challenge the assumption that a drag&drop in the expression would be harder than having to rewire separate combinators.

mrvn wrote: Thu Dec 07, 2023 7:39 am Secondly typing in the item and signal names is hard, more so with non english speakers and translations. You have to type in the internal name like angle-crushed-ore-4. At a minimum that needs an item/signal picker.

Nope. Factorio rich text means you can add signals with a button to text boxes, like in other text fields in the game. You don't have to type the internal name. Though I would prefer typing the internal name in some cases, especially if things what can be inferred wasn't required to be typed out.

You brought up several good points. I'm not against your suggestion as much anymore, but I want to present some more alternatives.

mrvn wrote: Thu Dec 07, 2023 7:39 am I just realized last night that the R/G choice on the output of a arithmetic combinator makes no sense. If you don't want the result on the green wire then don't connect a green wire.

Hmm, it could be useful if multiple outputs were allowed.

mrvn wrote: Thu Dec 07, 2023 7:39 am What exactly don't you like in the first mockup if choosing the input wires is fine? That is literally all it adds to the already shown interface for the 2.0 combinators.

I don't dislike the first mockup, I just didn't word it clearly.

mrvn wrote: Thu Dec 07, 2023 7:39 am As for typing in an expression on a single line: I thought about that but then you have to add parens and match them, figure out the right precedence for each operator and whether it is left or right associative and the user has to figure out all that stuff as well. For example take the shift operator: Is A << B + C mend to be (A << B) + C or A << (B + C). Surprise: In C and other languages it is the later. How confused do you think users will be when the precedence and associativity is not what they imagine?

Secondly typing in the item and signal names is hard, more so with non english speakers and translations. You have to type in the internal name like angle-crushed-ore-4. At a minimum that needs an item/signal picker.

Color highlighting or underlining could be used to clarify the first issue. Also, the new combinator output signals pane makes it easier to experiment and learn how things work. So in your example, you could check the precedence by trying different values for C.

As for typing signal names, assuming that all the translated names are unique within a given language setting, the game could let us type the translated name and convert it automatically. I think uniqueness is a safe assumption, but I could be wrong. The internal name could serve as a fallback perhaps.

Alternatively, typing a letter into the expression field could instantly bring up a signal picker with the search bar already focused so you could basically type start typing the translated signal name, which would go straight into the signal picker search bar, and then just click the icon, or better yet, use the arrow keys (while holding alt or something) to select the exact signal and then hit enter/return. Better keyboard-accessibility/-navigability of GUI has been requested elsewhere too.

mrvn wrote: Thu Dec 07, 2023 7:39 am There is a problem with doing complex logic with separate arithmetic combinators. Each combinator adds a delay of 1 tick. For one thing that makes complex arithmetic slow to react. That delay can have real issues when you control logistic chests or filter inserters with it. Too long of a delay and the inserter will complete an extra swing before you can compute a new filter for it and you get the wrong items.

Secondly the delay means you easily end up with information from different ticks. Take for example A * B + C. This takes 2 combinators and then you add A * B from tick 1 to C from tick 2 giving you a result at tick 3 skewing the result. To get the right answer you need to do A * B + C * 1, adding an extra delay on the C input. Often you don't care abut the timeing skew but when it is important things get ugly quickly.

Thirdly there are only 2 signal colors. That means you can only propagate the signal in so many ways before signals from different inputs affect each other. Then you have to add even more combinators with "EACH + 0 = EACH" just to isolate signals adding more delays and confusion with wires going every which way.

Syncing up delays is not an issue for me personally, but I have a better idea to address it in a more gamey and immersive way: a kind of beacon-like new entity that synchronizes all of the combinators near it.

With this new beacon type, a chain of combinators would be evaluated at once, starting with any combinators that have inputs coming from outside of the beacon's area of effect. After that, the next set of combinators to be evaluated would be ones that receive input from the first set, and so on until all of the combinators have been evaluated, and any outputs connecting to entities outside of the beacon's area of effect would be the final output for that game tick. Every combinator would be evaluated only once to prevent infinite loops. Also because of this, the amount of computations would be similar to if the combinators were evaluated normally.

With the new quality system, higher quality could extend the area of effect, or it could be that the normal quality adds a delay of 4 or 5 ticks to the output, and each higher quality could remove one tick of delay, down to one. Additional beacons could be placed either to extend the area in a single "network" (logistic network style), or each beacon could create its own network, taking only 1 tick to evaluate however many combinators you could fit around it (different networks would not be allowed to overlap).

This would solve the issue of timing in a way that is maybe not as simple as multi-operation combinators, but IMHO more fun and visually interesting. It would be a step toward making combinators an interesting challenge in and of themselves (as a crudely engineered, primitive puzzle piece, not as a container for arbitrary amounts of logic), rather than just a means to "mod" your game without having to write any Lua.

mrvn wrote: Thu Dec 07, 2023 7:39 am Remember that you can not see what a combinator does. Without alt view you see the operator but not the signals, with alt view you see the signals but not the operator. And you never see the output choice. Eigther way you see less than half the equation. So I challenge you to your claim that an expression tree would be harder to read than a bunch of combinators berried under a nest of wires.

I wish that alt view showed more information when zoomed in. With the current 1.1 combinators it'd be easy to fit every piece of information on top of the combinator if the zoom level was close enough. Additionally, I think there could be a cursor tooltip when you hover over a combinator that shows the complete configuration plus live updating input and output signals. So you could peek into any combinator at any zoom level, with alt mode on or off, and while having another GUI open (multiple open GUIs could be another enhancement btw). This feature could be extended to other circuit-connected entities. And while it could also be shoved into the regular tooltip at the side of the screen, I think having a tooltip at the cursor (in addition to the regular tooltip) with only the most essential info would be worthwhile, at least as an option that could be off by default.

Also, regardless of any other changes in 2.0, wire highlighting on hover should be stronger than it is currently, and some small indication should be given wherever a wire actually connects to an entity versus where it's just passing over it. Also, the red and green connection points on every entity should be diagonally offset from each other so that red and green wires never fully overlap each other.

mrvn wrote: Thu Dec 07, 2023 7:39 am The complexity could also be limited to a maximum number of operations to keep the expression simple and the internal data structure of the combinator at a fixed side so it doesn't need to use allocations and indirections. Something like 7 operators and 8 inputs for example. Maybe something that fills up a cacheline exactly. I would hate such a limit on principle but reality is what it is.

Seems reasonable.

mrvn wrote: Thu Dec 07, 2023 7:39 am I also challenge the assumption that a drag&drop in the expression would be harder than having to rewire separate combinators.

Rewiring could also be improved. For example, shift+click on a combinator's input side or output side, or on another entity, could remove connections like it does for copper cables and electric poles. Shift+click while having a specific abstract wire tool active could limit the connection-breaking to that specific wire color.

Control+click with a wire tool could disconnect an existing wire while leaving the other end(s) connected, and letting you connect that end to something else.

Combinators could be fast-replaceable or force-buildable while preserving wire connections.

Etc...

These tricks could be explained in tooltips or tutorials by the way, and beginners could ignore them, while heavy circuit network users could work more efficiently.

Admittedly many of these ideas could also complement new multi-op combinators, perhaps to a lesser degree, and the GUI for multiple operations is probably easier to implement.

Food for thought... maybe someone makes a mod for some of this.

SupplyDepoo wrote: Thu Dec 07, 2023 10:27 am You brought up several good points. I'm not against your suggestion as much anymore, but I want to present some more alternatives.

mrvn wrote: Thu Dec 07, 2023 7:39 am I just realized last night that the R/G choice on the output of a arithmetic combinator makes no sense. If you don't want the result on the green wire then don't connect a green wire.

Hmm, it could be useful if multiple outputs were allowed.

Exactly. I realized that the arithmetic combinator only has one output making the red/green choice obsolete.

SupplyDepoo wrote: Thu Dec 07, 2023 10:27 am Syncing up delays is not an issue for me personally, but I have a better idea to address it in a more gamey and immersive way: a kind of beacon-like new entity that synchronizes all of the combinators near it.

With this new beacon type, a chain of combinators would be evaluated at once, starting with any combinators that have inputs coming from outside of the beacon's area of effect. After that, the next set of combinators to be evaluated would be ones that receive input from the first set, and so on until all of the combinators have been evaluated, and any outputs connecting to entities outside of the beacon's area of effect would be the final output for that game tick. Every combinator would be evaluated only once to prevent infinite loops. Also because of this, the amount of computations would be similar to if the combinators were evaluated normally.

There is a mod that lets you create a custom combinator out of other combinators by placing them on another surface and connecting the wires to them. So you get your nest of combinators and wires but you also only need a small fixed sized space. Everything inside the combinators surface could be evaluated in a single tick.

Except there is one problem. You can make a loop. Connecting an output to an input quickly creates a situation where you can't evaluate the result as it never stabilizes to a fixed value. The tick delay is frequently a required feature as much as it is a bother.

SupplyDepoo wrote: Thu Dec 07, 2023 10:27 am Also, regardless of any other changes in 2.0, wire highlighting on hover should be stronger than it is currently, and some small indication should be given wherever a wire actually connects to an entity versus where it's just passing over it. Also, the red and green connection points on every entity should be diagonally offset from each other so that red and green wires never fully overlap each other.

I wish that hovering over a wire would highlight that wire. When hovering over a combinator you always get both the input and output wires highlighted.

Or hovering in the middle could highlight both input and output but hovering at an end would only highlight that end.

SupplyDepoo wrote: Thu Dec 07, 2023 10:27 am

mrvn wrote: Thu Dec 07, 2023 7:39 am I also challenge the assumption that a drag&drop in the expression would be harder than having to rewire separate combinators.

Rewiring could also be improved. For example, shift+click on a combinator's input side or output side, or on another entity, could remove connections like it does for copper cables and electric poles. Shift+click while having a specific abstract wire tool active could limit the connection-breaking to that specific wire color.

Control+click with a wire tool could disconnect an existing wire while leaving the other end(s) connected, and letting you connect that end to something else.

Combinators could be fast-replaceable or force-buildable while preserving wire connections.

Etc...

These tricks could be explained in tooltips or tutorials by the way, and beginners could ignore them, while heavy circuit network users could work more efficiently.

Admittedly many of these ideas could also complement new multi-op combinators, perhaps to a lesser degree, and the GUI for multiple operations is probably easier to implement.

Food for thought... maybe someone makes a mod for some of this.

Note: The drag&drop also isn't intended primarily for reconfiguring an existing expression but to build it in the first place. Say you entered "A + B" and now you want to multiply by C. So you add "*" and get "A + B * _". Now you have to change the "*" to get "(A + B) * _" and add "C". Then you figure out you actually want "D - (A + B) * C". So you add "-" and drag it to the top. Without the ability to rearange you would have to start again.

It's easier to have "add to the end" and "move to the right place" as in other widgets instead of some new way to insert operators in the middle somewhere.

mrvn wrote: Thu Dec 07, 2023 8:57 pm Except there is one problem. You can make a loop. Connecting an output to an input quickly creates a situation where you can't evaluate the result as it never stabilizes to a fixed value. The tick delay is frequently a required feature as much as it is a bother.

That's pretty easy to detect though, if you're doing it in-engine. A simple topological sort (O(n)) can put all combinators in dependency order if there are no cycles, and also tells you when a certain dependency does cause a cycle - these simply become tick delays. And as long as the connections do not change you do not need to recompute this.

To finish this up, add some visualization of places where you introduced the tick delay, and add a new combinator type which explicitly *does* introduce tick delay.

I still think we REQUIRE stack comb in the game because there is currently no way to DIVIDE an input signal by respective stack sizes. I.e., you are designing a Garbage Collector for your interrupt-based trains (a system that scans logistics inventory and pushes all items that can & should occupy a full train to a train). Let's assume we use 1-2 trains (1 locomotive, 2 cargo wagons). The train can hold up to 80 stacks of items. Okay, we know how to deliver it; we know how many to deliver, but WHAT to deliver?

What we SHOULD ACTUALLY do, is to export a logistics network inventory, divide it by a respective item stack size and select all signals >= 80. From those, we can now select a random one to put into a train. (The reverse, however, is quite possible because, unlike vector by-component division, vector by-component multiplication is possible due to the power of math.)

It just so happens that I’ve been thinking about what I wanted to change for a couple of months or what I’m already changing with mods, I hope you, the developers, will see this message and it will at least add weight to some of the proposals, although to be honest I don’t hope for anything, in my eyes you look like “if the decision has been made, then we won’t change it”
If I found that someone suggested this, I will try to attach a quote below my proposal
I'm sorry right away if my ideas are a little contradictory, I've been collecting my desires all this time

• separate input/output
  as many have mentioned, it would be great if it would be possible to send different signals to different outputs, although personally I don’t quite like this in the context of combinators, where I wrote below where it is desirable (in the fff screenshots it seems like this is implemented only on the decisive , but then it’s confusing that there is no such thing on the other parts that I mentioned below, including the arithmetic combinator).
  • separate input/output is personally useful to me when setting up the next sushibelt, it irritates me that the network “noise” from the wire through which the manipulators report can set filters for other manipulators (yes, I use filtering inserters in the sushibelt). It would help a lot here if I said that we take the switching condition/filter from green and the number of items taken is given to red, of course, this can easily be corrected with the help of 2 diode combinators, but this is space
  • - it would be nice for the request chest not only to have a read mode and a request mode separately, but to be able to work with them simultaneously but via different wires

    SLB wrote: Wed Nov 15, 2023 10:02 am

    Qon wrote: Tue Nov 14, 2023 10:04 pm

    TheRaph wrote: Sun Nov 12, 2023 10:22 pm I would like to have an option not only to select different outputs but also choose the channel (red or green) to output to.

    This seems pretty pointless. Why would you want this?
    If you don't want signals on green wire, just don't connect it.
    If you want other data on green wire than red wire, make a separate combinator.

    Select to input data from the green line
    and output data from the red line
    This helps one-compartment entities like the blue and green boxes simultaneously perform circuit setup requirements and read their stores
    This makes for a perfect drone unloading station, or circuit-controlled cache of green boxes.

  • choosing which wire the signal can be sent to, you don’t have to enter 2 checkboxes, you can use the same element as in splitters, a ternary switch, and there may be a separate checkbox to turn on any output, but this doesn’t really make sense except for debugging purposes

• Selector combinator
  • let the index select more than 1 signal

    Batadon wrote: Sat Nov 11, 2023 6:02 pm The sorting feature looks really useful! It would be even better if you can not only say "sort from biggest to smallest, then give me the signal at index n" but also "sort from biggest to smallest, then give me the first n signals". I suppose I can also just do that myself, but that still would be a really nice thing to have.

  • amount of specified signal from another channel

    JAetherwing wrote: Fri Nov 10, 2023 4:39 pm - Selecting a signal by type (i.e. send stone=1 on the red wire and get at the output whatever the value of stone is on the green wire) You can currently do that for positive signals only with a subcircuit of four combinators and some integer overflow dark magic, so having the option to use a single combinator with built-in functionality for that would be amazing.

  • the index operator needs an operator for the total number of signals, I have an idea how to do this but I don’t want to mess around with memory cells
  • I hope the index can be selected by a variable and not statically, and if it’s a variable, then you can select the wire from where we get the index and from where we select the signals

• something that is not really related to the topic but I don’t want to create a separate topic
  • the sizes of the combinators and everything that relates to them do not correspond to the functionality, for example, why the “distribution box” that is placed on the devices is actually the same decisive combinator, only instead of entering the circut network it controls the device (although manipulators can return a value, albeit with instability over time)
  • configurable constant output
    there are a lot of messages in this thread about this
  • How many conditions can be added to the desider combinator? by the looks of the gui from the screenshots it's 4, I hope more
  • function for the capacity of the rocket, why not make a general function so that you can read something similar for the specified storage (in fact, I don’t know if it’s needed, because you can already calculate the stack size and set the number of slots)

    Somtuk wrote: Fri Nov 10, 2023 1:27 pm The solution I came up with (which might be too complex/weird to implement in the UI) is why not combine bullets d, e, and f? That is to say, why can't the output be a list of properties that we choose to have the selector extract from the input? This would made Mode 2 much more generic. You could extract/select the capacity of containers, or even inserters. Not just rockets. With this in mind, that would merge bullets d, e, and f into 1 and become:
    "Output the property value of the input item". Mode 2 becomes generic!

    AvengerStar wrote: Fri Nov 10, 2023 7:01 pm If that is the case (I'm not entirely sure to be honest, it could use some clarification), then I would like for this functionality to be extended to all storage types: chests, train wagons, what have you, and have whichever type of storage be selectable through the combinator's menu. That on its own would simplify some of my trains' circuit logic even further (and ironically run counter to my earlier lamenting, but I'll embrace this new direction well enough).

  • gGeorg wrote: Fri Nov 10, 2023 12:43 pm when value in the slot is over 1000 it (I assume ) shows shortened version. Like 14k of Stones.
    Can you make an mouse_over_tooltip which shows the exact number like 14 237 ?

    I support!
  • if we improve the decisive combinators then what about the arithmetic one? adding input/output display is good but it pales in comparison to the new capabilities of the solver

    JohnyDL wrote: Fri Nov 17, 2023 11:41 pm here's the whole message about it, I'll just leave a link to it

  • I don’t know if anyone talked about this, but the function of calculating the weight (I hope it’s still stacks), as a feature, you can think about a function that will return the number of occupied cells for the entire input, well, it won’t go beyond the idea, because if there is a way to find out the size of the stack, then this can be calculated without special functions
  • I still want to receive more detailed information about the reactor/heat pipes and not control reactors based on third-party information (the amount of steam in the barrels) but here I am very not sure about this proposal, because it simplifies the correct control to level 1 combinator (play with the mod reactor interface)
  • speaking of liquids, I’m already tired of putting tanks where they are not needed just to turn the pump on and off
  • priority of combinators in the electrical network
    those who built sushibelt or any other logic sensitive to signals will understand me, the solution at the moment is to make a separate network for powering sensitive logic, but, again, why should I do this if combinators essentially play an important role on some bases by type introducing a reserve of steam electricity when solar panels fail
  • In general, for me, the game has long had a question about remote transmission of signals, especially when you need to send 2 sets of different signals along the green and red channel to 2 different points of the base without crossing them, but it seems to me that this should be solved in the new version and they just didn't show us the solution
  • I often avoid using the red wire due to the fact that I can't see it well, I don't seem to have any vision problems but I think I'm not alone, I would like the ability to recolor the wires in the game settings
  • This is probably a stupid idea, but what about setting up a filter for splitters? the same for input and output priority. It seems logical to use >= 1 for the priority of the selected side and <= -1 for inverting the priority

These changes look great! I've struggled a lot in the past with the overly-simplistic nature of the existing combinators myself, so this is great.

One question/suggestion: would it be possible to have combinators generate basic descriptions, which can then be overridden by user-defined ones? Kind of like an abstract syntax tree, perhaps? Take this example from the FFF, for instance:



The rules seem simple enough that a basic plain text explanation of what the combinator is doing could be generated from them. There's an input signal, and a condition that operates on that input signal, and then an output signal, so some form of static analysis after a user changes something could theoretically spit out some plain language text like: "If [accumulator_signal_icon] is [less than] [20], output [green_signal_icon] with value [1]."

That could be a really valuable tool for people trying to learn circuitry and signals. Though I could certainly see it being an unnecessary complication, or perhaps even untenable when you get to more complex signals.

And now that I write this out, I haven't considered localization. Damn.

Well, I wonder if that'd be possible as a mod instead...

Angush wrote: Fri Jan 19, 2024 2:29 am One question/suggestion: would it be possible to have combinators generate basic descriptions, which can then be overridden by user-defined ones? Kind of like an abstract syntax tree, perhaps? Take this example from the FFF, for instance:

The rules seem simple enough that a basic plain text explanation of what the combinator is doing could be generated from them. There's an input signal, and a condition that operates on that input signal, and then an output signal, so some form of static analysis after a user changes something could theoretically spit out some plain language text like: "If [accumulator_signal_icon] is [less than] [20], output [green_signal_icon] with value [1]."

That could be a really valuable tool for people trying to learn circuitry and signals. Though I could certainly see it being an unnecessary complication, or perhaps even untenable when you get to more complex signals.

Well, I wonder if that'd be possible as a mod instead...

No, not possible. Actually this is kind of the most unreasonable request possible.

Of course for some simple circuits this kind of static analysis is possible, but then it is also quite useless.

But that kind of detail in your proposed description in the image would have to be tested for as a separate case to generate that sentence structure. And even simple versions would quickly hit cases where the game would need a formal verification language to see if each type of circuit system description would be applicable. And you would need an AGI or something to get decent descriptions in more general cases. And combinators are turing complete, so complete generality is proven to be impossible (halting problem).

Instead of outputting a random signal, how about iterating through each index?