Combinator Size / Combinator Board
Posted: Thu Dec 22, 2016 12:05 pm
I know the devs are in the works for optimizing combinators but i don't know if they are considering this - maybe this was suggested before - but i did not find anything in the "frequently suggested" section:
If you have a bunch of assemblers or furnaces and want to use combinators you have to make one primary decision:
Are all assemblers controlled by on combinator network as a whole (All receive the same signal) or do you want every assembler controlled by it's own combinators (would be much more dynamic).
All controlled by one combinator network:
+just one central combinator hub
-you have to make sure that every assembler (and other entities interacting with that assembler) is in the same state, so that no assembler hangs "midstate"
Every controlled by it's own network:
+indivual configuration
+dynamic load balancing or such
-extreme size growth
Imagine a eletric furnace which is 3x3=9 tiles in size. Adding a combinator just rapidly increases the space:
+1 combinator: 11
+2 combinators: 13
+3 combinators: 15
+4 combinators: 17
+5 combinators: 19
For some tricky logic you need much more combinators. But even at 4,5 combinators you doubled the size of a single furnace(-block)
My suggestion would be to reduce the size of the combinators. I know that 2x1 combinators are that size so you could easily identify input and output and it would be hard to use a 1x1 combinator. So my suggestion goes further:
One Entity as a "Combinator Board" (size 2x2 maybe) that could be stacked with components. The most work would be to implement the ui for the combinator board - but i think it would be worth it - combinators are generally choppy to use currently (I know the devs are aware of that).
If you have a bunch of assemblers or furnaces and want to use combinators you have to make one primary decision:
Are all assemblers controlled by on combinator network as a whole (All receive the same signal) or do you want every assembler controlled by it's own combinators (would be much more dynamic).
All controlled by one combinator network:
+just one central combinator hub
-you have to make sure that every assembler (and other entities interacting with that assembler) is in the same state, so that no assembler hangs "midstate"
Every controlled by it's own network:
+indivual configuration
+dynamic load balancing or such
-extreme size growth
Imagine a eletric furnace which is 3x3=9 tiles in size. Adding a combinator just rapidly increases the space:
+1 combinator: 11
+2 combinators: 13
+3 combinators: 15
+4 combinators: 17
+5 combinators: 19
For some tricky logic you need much more combinators. But even at 4,5 combinators you doubled the size of a single furnace(-block)
My suggestion would be to reduce the size of the combinators. I know that 2x1 combinators are that size so you could easily identify input and output and it would be hard to use a 1x1 combinator. So my suggestion goes further:
One Entity as a "Combinator Board" (size 2x2 maybe) that could be stacked with components. The most work would be to implement the ui for the combinator board - but i think it would be worth it - combinators are generally choppy to use currently (I know the devs are aware of that).