Attach pins on notes inside combinators

[Yuki_Nagato]

What?

Allow add a pin to other (circuit) entities or locations inside combinators' note, more: support blueprint(to pin corresponding entities inside the blueprint).

Why?

Notes are generally a good thing, but their use is limited that they can only "describle" the intention of this entity and their related entity, but not clearly help others to find related entity. Most of my complex circuit network's magic happens on how wires are connected, and wires are not clear enough to see how they are structured. If I can pin every related entites so that: when talking about that constant combinator is meant to set need, I can jump to that combinator, it will be much easier to keep track of circuits.

[mmmPI]

That will cause trouble if you pin in the description something that is not contained in the blueprint : "this combinators trigger the put in the norther outpost".

One way i found to alleviate the need for this is to use numbers for combinators, : " 14 : this combinators trigger the combinator 12 and 17 at the same time" , and then you click the other combinators to see which is the 12 and which is the 17 because you are not sure the 14 is properly connected or something.

If you can put them in a sort of grid it can also help to use coordinate like combinator A5 or B5 would be just above each other on 2 different rows.

[Yuki_Nagato]

That will cause trouble if you pin in the description something that is not contained in the blueprint : "this combinators trigger the put in the norther outpost".

One way i found to alleviate the need for this is to use numbers for combinators, : " 14 : this combinators trigger the combinator 12 and 17 at the same time" , and then you click the other combinators to see which is the 12 and which is the 17 because you are not sure the 14 is properly connected or something.

If you can put them in a sort of grid it can also help to use coordinate like combinator A5 or B5 would be just above each other on 2 different rows.

Your idea is great help for this scenario! And what I'm suggesting is about improving this kind of communication, so that we can keep track of these info easlier and focus more on logic.

As about the blueprint problem, that's what "more: support blueprint" mean: we need to consider what will happen when we blueprint them. For example:

• Don't support these pins: easiest to get it implemented quicker;
• Save these pins but ignore not included ones;
• Or, ask the player whether to include pinned components that wasn't blueprinted when blueprinting (I think this would be helpful too, so that we can use pins to easily extract one circuit logic out of a deeply coupled system.