Maybe we need a new, heat power interface. I agree it would be useful.

According my explanation, it doesn't matter before or after droppoint the turn starts. The only important thing - find out where perpendicular part is, and then apply "far side". I failed to understand diamond explanation, maybe I just haven't tried enough :). I like my explanation, it works.

In L3 if we consider the 'right' side from the belt perspective before the turn, we are supposed to consider it's a horizontal belt going to the west. It then becomes a vertical belt going north.

In L3 the inserter seems to drop AFTER the turn. So as in L8.

L3 and L8 acts like perpendicular ...

Why do you use speed modules and beacons here? They increase energy cost per produced item. If you need throughput, just build bigger assembler array.

disentius wrote: Wed Jun 12, 2019 10:20 pm helps with balancing.
3x yellow -> 1x blue

3x yellow are also splitted for two blue belt lanes, so single lane takes 1.5 of yellow. There should be no problems with the throughput.

Chest balancing is made by madzuri circuits, splitters are not necessary for this.

Are yellow splitters necessary?

The EC setup has 3 inserter positions that put items on the "left side" (right from the belts perspective) and only 1 that drops items on the other side (stack inserters). That is one problem I have with the current inserters.


It's because the single rule "left/right" would be ...

Cadde wrote: Fri May 31, 2019 10:58 pm I never look at the items on a belt to see if it's compressed or not. That would be maddening.
I just use the debug tools (even though they are not meant for gameplay stuff) until we get a better way of detecting usage.

What tools do you use to test belt compression?

I'm not sure if I understand your problem. You'd like to fill top-right side of the belt on the corner?

Concrete came from the Dectorio.

But the rules are still way more (irreducibly) Qonvoluted than "far right quadrant" would be and which would also give balanced results in the number of ways to output to each side.


Usability is more important than intuitive understanding. The curved belt case is not a rocket science and can be ...

No one managed to predict what U, V, W & X would look like.

Please, don't forget me :). I proposed a rule and submitted an illustration. The corrected rule also works for other cases.
If you think it's wrong, please argue.


Sure, you will be remembered for getting U-X right and some other ...

Qon wrote: Fri Jun 07, 2019 9:24 pm No one managed to predict what U, V, W & X would look like.

Please, don't forget me . I proposed a rule and submitted an illustration. The corrected rule also works for other cases.
If you think it's wrong, please argue.

3. Curved belts acts like perpendicular and starts to turn past drop point. That’s simple, though not so intuitive, and you may need to think a couple

Wrong.
In O & P you can't say it is perpendicular and that it starts to turn past the drop point. Because it starts out parallel before the ...

It’s a good topic. I needed to think to get the answer. The rules are:

1. If the belt is perpendicular, the item is dropped on the far side. That’s simple and intuitive.
2. If the belt is parallel, the item is dropped on the right-hand side. That’s simple and intuitive too.
3. Curved belts acts ...

Regarding "best practice": As a programmer and one who works with C++ there are hundreds if not thousands of "best practices" for how people think C++ should be written and for every one of them there are an equal amount or more people arguing it should be done another way. Having worked on ...

I don't disagree. Of course you're free to play the game the way you want. Even in really inefficient ways that could be avoided with minimal effort. That's your choice.

But if people are asking for core game mechanics to be changed to suit their individual playstyle, especially ones which might ...

You can, you just don't want to.

I can only think of one situation where I was annoyed by the kind of issue you describe and it was solved by using buffer chests. If it takes a very long time for constructor bots to build something because the resources and the destination are very remote from ...

What OP really wants is the age old idea of "build my next blueprint with my personal robots only", but as that would require a complete rewrite of how robots work it's not gonna happen as has been said many times.

Does it really require to rewrite robots’ behavior? It looks like blueprint items ...

Which network? All of them?

What about multiplayer? Are you toggling networks which belong to your force, i.e. shared with other players who didn't want that behaviour toggled?

You can avoid this situation simply by not having roboport construction coverage where it isn't wanted or needed.


I ...

TL;DR
Add button “Toggle robotic network” to disable construction robots from stationary roboports.

What ?
I’d like to have some way to make some construction/deconstruction using personal robots only, even if robotic network is available on that area.


ToggleRoboport.png

Why ?
It’s a ...