Combinitors Output (input count)

[DaveMcW]

I am only suggesting to change the output(input count) function when it pertains to a single item output, such that it outputs the input count OF THAT ITEM.

Resurrecting this topic.
This change will most probably happen in 0.13(It took a long time, I know).

If this is the change you are referring to, I am all for it.

I don't think it would break any of my combinator designs. Mainly because the current implementation of "single item output(input count)" is so bad that I never use it. But even if something did break, getting a one-combinator demultiplexer would be worth it.

[bcRIPster]

Right now I see no good reason why you would want to use a decider to take one input and merely output it as something different.

1) I use this as a diode as first suggested. Yes, I might work around this as noted. An actual diode would be nice.

2) I use this MORE often to create variable aliases so I can reuse designs without having to change multiple inputs. e.g. "packaged" components in the EE sense, For example, there is no arithmetic operator for modulo but I need it sometimes so I made a blueprint for one. BUT, for complex logic units I'm too damn lazy to change "red science pack" to "whatever the new thing is" in the 17 places it appears. So, instead, I alias "whatever the new thing" to "A" using a decider that does nothing but output whatever I want to "A". That way, I can reuse the same blueprint while changing nothing because everwhere "generic thing" appears its set to "A" inside the blueprint.

Making me manually change things definitely goes against automate everything.

PS OTOH anyone advocating for ^= in a decider has my vote

ZOMG yes. All the basic inversion functions needed badly: not equals, complement of, etc.

[bcRIPster]

Making something that behaves differently in "this one special case" is inconsistent code, and therefore BAD code.

If you want a part that does something different, make it a different part.

[zerohourrct]

When I was first playing with combinators I was confused by this behavior; I expected 'A' input > 1, 'B' Output (input->output) to just pass the 'B' channel from input to output. I haven't used this functionality yet myself, but I can see its appeal for blueprint use as stated by bcRIPster. I'm also strongly against breaking any existing functionality with existing blueprints and save files.

What I really wish is that the 'output 1' could be set to ANY constant, not just 1, but would default to 1. I also wish the 'false' state output could be set to something other than 0. This would enable much simpler designs in many cases and still does not obsolete arithmetic combinators.

Perhaps an additional radio button could be added called 'gate' or 'pass' or 'diode' that provides the 'expected' functionality of passing the selected output channel from the input, and the existing behavior could be left intact.

It should be noted that the Everything channel input-> output will still provide this functionality, but it will also pass all channels.

[siggboy]

I'm absolute and 100% in favour of making this change (i.e.: the decider will output the count of the TARGET item and not of the item being decided on).

The current behaviour of the decider is, in fact, very confusing, because what you do in the user interface is selecting a signal for output, and right next to it you specify "Input count", but the combinator does output the count of something else entirely instead of the signal you just selected.

Please make the change as suggested by OP in the next version.

And also add a "not equals" to the decider combinator while you're at it .

[bcRIPster]

Eh, no. This will break peoples builds. Did you not read the rest of this conversation?

[Twinsen]

Eh, no. This will break peoples builds.

Breaking some things between game version is perfectly acceptable. This is why it's early access. The quality of the final version always takes priority.

So the change was implemented. It will be there in 0.13.0.
Decider combinator "input count" option makes the combinator copy the count of the specified output signal from the input signals, instead of copying the count from the condition.

[siggboy]

Completely awesome, thanks. Plus I agree when you say that breaking things is OK between major releases.

Advanced combinator circuits are completely arcane. There is no way to make any change in this area without breaking something, in some map that is being played right now. Having said that, the change in question is not going to affect the case where you set the decider to "output everything (input count)", which arguably is by far the most common case. The second most common case is "output X (count 1)", which, again, is not going to be affected.

The only circuits that are actually broken are those which use the obscure behaviour of the current decider, that will recolor the decider signal to something else -- and you can easily fix that by using a dummy arithmetic combinator instead.

[bcRIPster]

Eh, no. This will break peoples builds.

Breaking some things between game version is perfectly acceptable. This is why it's early access. The quality of the final version always takes priority.

Maybe when you're changing something that adds value. But when you're just changing something so that it doesn't work like you would expect to appease a hand full of forum users, that's not really progress. I'm pretty sad to see that this is the direction things are going.

[siggboy]

Maybe when you're changing something that adds value. But when you're just changing something so that it doesn't work like you would expect to appease a hand full of forum users, that's not really progress. I'm pretty sad to see that this is the direction things are going.

Don't be a drama queen. "The direction things are going." As if this really minor change (it will probably be a one-line diff in the VCS) changes the direction of the game.

The discussion on this has been open for a year now, so it doesn't look to me like this decision was made on a whim (but it could have well be, if I was the dev responsible for this I would have made the change long ago and dropped it in a maintenance patch, that's how minor it actually is -- "Fixed decider combinator to meet user expectations.").

[bcRIPster]

You know what. I'm not being a drama queen. I was warned before I even posted that this was how this was going to end up. But I thought to myself, no these guys seem to be pretty solid. I'll plead a case against this ridiculous idea based on good coding practices. Having something behave contrary to logic to appease someone in a forum simply for their own convenience is not good practice. It's how all of these early access games end up buried in a mile deep of overly complicated UI and logic and to hell if anyone can ever figure out how something is going to even work unless they're reading all of these damn posts to figure out every edge case that's been invented to appease someone.

I was warned that there appear to be a few people in this forum that shut down anything that isn't "the right way" (cough, their way), because their way is clearly the only right way to do things. But again, this seemed like a clear cut case of something to argue against. So what the hell, let's try and speak up for once.

And you know what? I should have listened and not bothered saying anything at all.

There. I've put my foot in it. You'll discount me as a troll now. Whatever.

Peace out. I've downloaded my pre-0.13 offline build and that looks like what me and my friends will stick to playing until we see how the final game ends up.

[pompetardo]

I think what we need is another combinator that work like a filter inserter, it receives one signal (selected from one of the wires) and only allows that signal or signals to pass from the other wire. That could be very useful when you want to automate something where you don't know what you want to filter yet. For example, I'm making a generic mine that extracts from an area equivalent to the max distance between 4 roboports in square, the objective is to mine whatever is there and auto classify it without reducing the throughput. Each line of classifiers can be assigned to any of the available materials depending on the percentage of total availability. That way I don't have to build from scratch each mine depending on the shapes of the yields that are mixed. And to do the control part has been a pain in the ass, just reached about 60 combinator already hahaha but once it's finished it'll be just a blueprint to keep expanding my mega modular base mega fast.