MeduSalem wrote:aeros1 wrote:- Other operators - Really we have already all analogue logic operators which can be used as such *OR* is "+", *AND* is "*" *NOT* is "=0" output 1. This is even enough to write memory cell which can read and write information. What would be severly more useful is actually have counter. Not like it is impossible to write with memory cell though in fact if you don't normalize memory cell you get counter. And other operators are not required XOR is !(A==B) XNOR is A==B. Bitwise combinators are closer to useful, an selector ones would be at least somewhat usefull and preform unique option
[/list]
For example if you want to compare if both any amount of Iron Ore AND Copper Ore exist (meaning both could be any number greater than 0) you are out of luck though. Then you have to use the cumbersome approach of first scaling both signals down to either being "0" (if it doesn't exist) or "1" (if amount of ore is greater 0) using deciders so that they can be compared and then with a third decider compare if both signals in sum are >1. And for OR you basically have to do the same, just that you'd check if both signals in sum > 0.
No, I think aeroes has a point there. In your example you can multiply Iron and Copper and the result will be positive if and only if both are present (that's the equivalent of a logical "AND"). The logical "OR" is simply the sum of both (zero only if none are present).
Therefore I don't really understand what the "AND"/"OR" operations in a combinator would actually do.
XOR, however, can NOT be simply expressed as "!(A==B)" (which is "A != B"), because we're not dealing with binary values only. So that's one case where you have to normalize to "1" before you can do the operation.
So it renders certain contraptions really an overcomplicated mess because you have to use 3 combinators where one with an appropriate "AND" comparison (or "OR" respectively) would completely suffice.
Maybe it's a little more difficult to understand how you do these logical operations, but it certainly does not create a mess.
Again, AND/OR would just be aliases for "+" and "*", and XOR would be the ugly stepchild of "!=" because it would normalize the inputs to "1"/"0" under the hood.
The problem for most players is that those are operations in the ARITHMETIC combinator, when you'd actually expect a DECIDER combinator to handle that. ("AND"/"OR" are much closer to decisions, even though a programmer will recognize that it's actually boolean arithmetic.)
Furthermore, there are lots of places where you cannot use arithmetic, to wit in all those places where you can specify a "circuit condition" (inserters, train stations, power switch, ...). I guess those are the places where the AND/OR stuff is actually missing; right now you have to do the arithmetic outside, then output a virtual signal and do the comparison on that signal.
BTW "!=" (not equals) is totally missing from the comparison operations. (That makes XOR difficult even after you've normalized to "1"/"0", because you still can't perform the "not equals" operation straight away, you can only output a "false" virtual signal and have to interpret that as the inverse of "true". But not having "!=" as an operation is awkward in many other situations as well.)
What is making a mess quite often is that you cannot specify a constant value directly as an output. You have to go through outputting "1" and then multiplying by the desired constant (as pointed out earlier in this thread already). That's one of the things that could easily be added, without confusing anybody and the UI for that would be obvious as well.
Bitwise operations are totally missing, many can not be emulated easily. However, if those were to be added, we'd also require a "decoder combinator", that would output the individual bits of the input. Just having bitwise stuff without that is somewhat pointless in my eyes (a decoder can be made with integer arithmetic shenanigans, but that's probably over the head of most people, even those who know what bitwise operations actually are).
Now we're in the area of having to deal with groups of signals already (decoded bits are distinct signals). That's something which became more apparent in 0.13 due to the filter inserters. If you have a bunch of signals it's just very awkward if you need to pick one (and you do not know which one you're picking). So we need the "anything" output in the decider.
On top of that you have to start using virtual signals since you can't compare the original values directly, which makes things more complicated for the average user.
Well, no, that's only necessary if you want to perform an "XOR". Also, if you're doing a "logical" operation, the output will always be abstract, so you'd output a virtual signal anyway. Again, it boils down to these things being arithmetic operations in Factorio, not something the decider combinator does.
It's an accessibility problem and a reason why a lot of people avoid getting into Circuit Network stuff because it seems overly complicated for anything more than just turning on/off some pumps in your refinery (the only real application as many deem).
There are too many quirks right now, because two worlds collide (doing the "really simple stuff" vs. "going hardcore"), and there are not enough tools to systematically build complex circuits.
In my opinion the two worlds should be more cleanly separated. Make some REALLY simple combinators for the easy stuff, and then give us a blackbox combinator where you can build proper circuits in an environment that's suitable. In that environment you could shed all of the arcana and quirks that stem from the fact that the combinators need to offer straighforward solutions to trivial cases.
If dedicated AND/OR comparisons would treat a signal value as "true" as long as it's anything BUT zero it would help with some contraptions greatly
Dedicated "AND/OR" would only help in those cases where you do not already use combinators (i.e. for conditions set directly in entities). Because if you do use combinators, then those operations are easy (as explored above).
Wow, this has become a lot longer than planned.