mmmPI wrote: ↑Tue Nov 14, 2023 11:34 pm
To me round number meant integers as opposed to decimal as is often used in comon langage and i thought it for the weights of item.
The quote from #382 is
This created some kind of rough base for testing, and we then modified many things a lot. Most non-intermediate utility stuff was cut to be at most 1 stack per rocket, many things were rounded up, etc. In some cases, we bent things a lot, science packs are expensive, but they can't be recycled, so we allowed 1,000 to fit in a rocket. Modules are expensive, but a whole stack can fit a rocket, because recycling modules is just silly.
To me the rounding refers to rounding up the number of items in the rocket, not the weight, you might be right that they rounded up to a whole number not one that's 1 sig fig and all 0s, so there might be 73 items in a rocket >_<
TheRaph wrote: ↑Thu Nov 16, 2023 7:21 pm
That is a definition based on your point of view.
Having a arithmetic combinator multiply "coal" by 3 and sending solution to red channel on "A" and to green channel on "coal", could be defined as one task or as two.
I can not spot the difference of the example in FFF: Sending "check-mark" = 1 AND "red-circuit" = input-count. This are also two tasks, which could be separated into two combinators.
Same as in my example but different outcome.
I'm with Qon you're asking for a combinator to perform two completely different bits of logic and have two completely different outputs on each wire this causes a number of problems with teaching people how combinators work, it could make some combinator logic more compact in some ways but it also causes an explosion of issues.
Since you cannot see the difference between what is being proposed and what you're suggesting I'm going to go through every variation I can think of and build up to why I believe Qon is arguing against this idea.
In the simplest case if you're asking Green to output something when the logic is true and Red to output something else when the logic is false this is doable several ways, you can copy and invert the logic to a second combinator, something necessary if the timing is critical or output an extraneous control signal and then invert it with the desired outputs with a second combinator. I would actually be okay with having both a True and a False set of outputs within a decider combinator but they shouldn't go to different wires. All outputs go out on all connected output wires in my opinion and I know that's what you're proposing to change, there are good reasons for that rule.
However, it feels like what you're asking for is different results on each wire with different logic leading to each wire not simply inverted logic, an example might be (if x > y then green x = x) + (if y > z then red z = 1) + (if x > y AND y > x then y both = y) within the same combinator, the bits of logic (especially x and z outputs) might have nothing to do with each other, I'm going to call these dual combinators
The biggest issue I see comes when you're copying and pasting the value of a dual combinator from one build into another (because we're lazy people and copy-paste is easier than setting up a huge complex array of logic a second time) you run into problems, maybe because of something else going on in the new circuit you have/need the red and green output wires swapped compared to the donating circuit. A newbie might copy and paste expecting the same functionality from a dual combinator but might get something broken half the time... with the proposed decider combinators having dozens or hundreds of conditions with AND and OR logic between them (if not other operators like XOR and NAND as requested on the thread) a newbie or even an experienced person might not be able to tell at a glance if the 'broken circuit' is because some set of signals in among the 100s of settings that were copied and pasted is doing things not quite intended or if the two outputs of a dual combinator were relatively swapped, and most people are going to look at the logic first not to check if the outputs are in the right places.
"It's broken I must have wrong logic" is always going to be an easier thought than "it's broken I must have connected the colours backwards" because one is "I didn't understand something when I started the process" [excitement to learn] and the other is "I'm a complete moron and need to go back to preschool and learn my colours" [frustration borne exclusively of dual combinators]
It's less of a problem if you play single-player all the time and you're the only person who has had any input in how the combinators in your world(s) work and you have a perfect memory for how each combinator is set up... but if you use community blueprints, or work on multiplayer or follow tutorials on youtube or are just plain forgetful you may not fully understand every nuance about what you're copying any more than most people understand how some minecraft redstone builds work, so when you copy parts of it you will expect it to act the same as a component as when it's in it's the original location. You might be able to understand it with a little work but it might not be entirely intuitive. But Dual Combinators have 2 sets of logic so if you're copying one because you've tracked down and are expecting it to contain Function A and you get Function B instead that's going to be annoying and a barrier to you learning how things actually work, yes you're getting exactly what you copied but if you don't understand it enough to know that's what you copied that's just going to stop you trying to learn more... if you're trying to filter liquids for example and the decider puts all Liquids on Green and all Items on Red... you've only ever connected the Red side by chance cause it's something you've taken from other places but this time you need it on green that's going to severely annoy and confuse you.... And it might not be trivial to swap the behaviour either. If each input is checked individually and sent to an output separately that could be 100s of operations to change or hundreds of signals to reassign from Red to Green and/or Green to Red (or use an extra combinator to invert the signal but that's the thing your suggestion is trying to avoid)
I agree with you that the FFF is suggesting compressing the logic of several combinators into one and compressing several combinators doing the exact same logic into one. This is not really equivalent to what you're asking for.
Why you and I think this (and Qon doesn't) might be the way we are looking at it.... The current proposed solution can pretty much be spread out into two arrays of combinators (as well as red each*-1 => green and green each*-1 => red, and other delays/filters), one array of decider combinators to come up with a single true/false signal (you can do every comparison between any values on red/green with each other or with constants) and a second array of arithmetic combinators (that multiplies each desired output signal(s) by the true/false value). This would do everything that the FFF384 Decider combinator can do, it might take a lot more time to set up and more ticks to process but it would give you the same outputs (even isolating Red/Green inputs/outputs in 99% of cases)
And what you're asking for might seem kind of related, I actually think you're asking for the ability to reuse the intermediate logic steps, so if Block of logic A then X on Red and if Block A and/or Block B then Y on Green, you could do this relatively easily with the current combinators so it almost feels like you're losing that option. In fact, with the full layout, you can do a lot more and wouldn't be limited to just 2 wire outputs from intermediate steps so it might feel like the new logic is more restrictive. But as you point out yourself with
TheRaph wrote: ↑Thu Nov 16, 2023 7:21 pm
this feature would not be mandatory to use. If you like to have different combinators for different channels you are free to do so - but I would like to have selectable outputs.
the expanded ways of doing things will still exist, there's nothing I see in the new implementation that stops people from building as though using current/legacy combinators. But what Qon is arguing I believe (and what I'm saying for certain) is that by implementing your suggestion you make them a more powerful tool but also a much more complicated one to learn and use. You're adding 1 more setting that feels small and only impacts how the combinator behaves in a tiny way but you're in effect multiplying the possible problems each combinator can cause within any system by at minimum 4, for every "is my logic wrong" step you also have to ask "am I outputting the right things onto the correct wire(s)" which has 4 answers (for each output in the combinator -> Red, Green, Both, Neither [which you can use for internal debugging]). Right now all the outputs of all places that have outputs are 'tied together' whatever is being output is being put onto all connected wires, this is true on belts, boxes, inserters as well as combinators.
Having two separate combinators doing similar very complex logic might be annoying given how powerful the new combinators appear to be, but it's also easier to understand and debug especially as you get into playing with more complicated combinator systems... Yes, you're still going to have to debug but you won't have to debug both the logic and the outputs in concert with one another... And you can always separate out those common logic blocks so you don't have to recreate them, even though that comes with a slight processing delay.
And this comes from someone who has asked for Arithmetic combinators to do "multiple things" in this thread. I'd like for Arithmetic combinators to do the logic
A*X => Q, A*Y => P, A*Z => R... I could set up several combinators to do them separately I totally agree, but the combinator is providing the same logic on the left side (in my opinion) and the right side outputs are put onto all wires.... why do I say A*X the same logic as A*Y? well if we say A is blue science signal and X, Y, and Z are constants for how many red circuits, Engines and Sulphur are in each blue science, the logic is "calculate the components necessary to make the inputs", and while I would like this (and it has many other applications) I don't necessarily need it, and while it is 'more complex logic' and 'combining combinators' when anyone copies these setting from one place to another it's still going to work exactly the same in the new location regardless of which wires any player chooses to connect, the logic might still be wrong but it's all going to be wrong in the same place(s) as if it were expanded. My suggestion has limitations too as whatever A and the operator are they must always be the same things for all equations in that arithmetic combinator, you can't do 2 completely different operations like A * X and B + Y, I think this is right in line with how the proposed Decider works, after all from the expanded way I explained above it does that same math of True * {selected outputs} which is so close to A * {selected Variables}
Henry Loenwind wrote: ↑Tue Nov 14, 2023 7:31 pm
It is conflicting because data about how the condition is set up and data about what the combinator is doing is mixed together. That may be ok when checking why a combinator is misbehaving, but when trying to read how it is set up, it is confusing.
I really don't see it that way. It starts black, you put in all your code it updates green/black letting you know if it's behaving correctly you move on. The colour makes practically no difference to what you're inputting unless you find white on green a difficult set of colours to read.... though all the interactive elements, numbers, checkmarks and signal variables seem to be on a black background anyway.
Henry Loenwind wrote: ↑Tue Nov 14, 2023 7:31 pm
You
It's have
like to
every consciously
second ignore
word half
belongs of
to what
a you're
different seeing
sentence.
THAT'S NOT WHAT'S HAPPENING WITH THE COLOURING IT'S MORE LIKE THIS WHERE I'M TELLING YOU I'M SHOUTING BY USING ALL CAPS AND RED TEXT AT THE SAME TIME AS TELLING YOU MY POINT, IT'S ADDITIONAL INFORMATION THAT GIVES CONTEXT TO THE SENTENCE NOT TWO SEPARATE SENTENCES GOING ON AT THE SAME TIME.
not that I'm mad really
What you're arguing for by moving/getting rid of the green is more like getting rid of/changing the grammar. You still want the information available to you but not in quite that location... you can get used to new grammar I promise
You want every statement to go "TRUE: X * Y = Z" or "FALSE: X * Y = Z" when what's being shown is X * Y = Z is true cause all caps and x * y = z is false because no caps. Except it's not even modifying the letters maybe 'X' * 'Y' = 'Z' vs ,X, * ,Y, = ,Z, is actually a better analogy. Not that it matters because after you use it a little bit you can get used to either one.
Henry Loenwind wrote: ↑Tue Nov 14, 2023 7:31 pm
I didn't particularly like it with the train configuration either, but there a major difference is that you usually configure a train when it is stopped and doesn't show the green background.
That's fair, but the way I see it is that they have to make both look the same... and having done that it actually makes the train station settings a tutorial for combinators. They have to change both or change neither and I think they'll have a whole lot of pushback changing the trains again and very few people actually have a problem with actually using that UI, there may be conceptional/intellectual reasons to dislike it, but it's entirely usable and functional, even people who had issues with it to begin with got used to it.
Henry Loenwind wrote: ↑Tue Nov 14, 2023 7:31 pm
That's more an issue with the wire icons than with my suggestion. But icons are one of the easiest things for a mod to change, and there are a couple of colourblind mods out there already. (PS: Although, I'm a bit disappointed the game doesn't use slightly different icons already. I understand that for plates and tiered machines, where it would be visual clutter that'd make it harder to see what are variants of the same, but wires easily allow for same-looking but different icons by simply changing which corner the wire end is in.)
I've asked for more colours in this thread and while I see it might be easy enough to change the symbols for 2 colours it might not be so easy with more, and that only solves the issue with the icons, it doesn't solve the issue with Red/Green Wires in the overview, yes it lets you easily identify Red vs Green symbols but if you can't tell if the signal wire carrying the signal in the first place is Red or Green knowing which symbol isn't as useful.... And I know mods which do fix it but it shouldn't be down to mods to make a game accessible IMO
Henry Loenwind wrote: ↑Tue Nov 14, 2023 7:31 pm
And for the status indicators, black/green works for them, too. Or filled and solid circle. or X and checkbox. (BTW: I made them a bit small in my picture. They should be a bit bigger and have more horizontal room.) A circle is just the quickest thing to add in an image editor.
This is true but it's the same thing, the less obvious the change the more it feels like a style choice, having it be a black to green dot in some ways might look like the configuration is not filled in vs is filled in as much as the current configuration is true vs false... or the black might not be obvious on the black background
Henry Loenwind wrote: ↑Tue Nov 14, 2023 7:31 pm
TBH, after making the image, I tend to like the "..." indicator better than my original suggestion of nothing. It makes it clearer that that's not a button that does something but one that brings up a dialogue. There's a reason the File menu has "Save", "Save as..." and "Recent >" with different symbols at the end.
While I agree in principle, it works that way on Windows, Linux and Mac, I disagree in Factorio, they don't use the ... model anywhere else in the game the add description I'd assume opens up a text box modal so I don't see it as necessary to indicate how the button does what it does especially given it's not a complex menus of options, menus have One Click Actions (nothing), Multi Click Actions (often ...), and Display Sub Menu ( > ) knowing how the items behave before you click them is super important because navigating to the same point in the menu tree might not be straight forward, the Multi Click Actions ... I often see it as telling you "this is too complicated to do within the structure" rather than 'this opens another modal' which is why it can be used on mobile phones to indicate the location of a menu