Identification of signals based on their source in the circuit network
Posted: Sun Mar 07, 2021 5:18 pm
Currently, in a circuit network, we can easily perform operations with two different signals, but with signals from two separate sources only if we convert one, so we cannot make an accurate comparison over a certain amount of signal sources (from which the same signal comes), and if yes, circuit would take up unrealistically much space.
A solution to this problem could be to identify the signals by source(object) in approx. thus:
The format of the signs could be as follows: 'Coordinates of the building': 'Identifier consisting of 4 numbers and letters'
(e.g., X162; Y156: F2G3). Of this, in combinators and other buildings and entities, the last 4 letters would appear at the signal selector in a similar way to the one in the picture. To make it easier to identify signal sources locally, there could be a preview when the cursor is over that signal.
As you can see in the picture, the general shape of the signs would remain, and signals with a source ID would only appear if you right-click the generic signal, so they would still be just as easy to count regardless of the ID on them (if used).
Another problem may be that for larger circuits, the number of signals with the source ID would increase abruptly.
My suggestion for this problem is that the local identification of materials should be adjustable per source (e.g., box, circuit unit, other entity) and should not be labeled with a source ID by default.
Off topic:
I once read an idea that decisive combinators could have an adjustable else output.
Most players rejected this idea mostly because it would not be optimal for the program (plus 1 execution in the if sector), but as the player wrote, it would be optimal for the amount of space occupied in the playing field, and from writing two very similar conditions would also spare players (which would be two operations in the same way).
Link to the idea: viewtopic.php?t=64173
Picture of the implementation:
I apologize for the rudimentary nature of the designs.
Update:
The idea received a comment from Ssilk, one of the global admins. I agree with the two proposals he considers more useful, and would most likely have an additional effect on the idea I have written
{
viewtopic.php?f=6&t=56890 Separate signals to/from red and green wires
viewtopic.php?f=80&t=50283 Separated Handling of Red and Green Wires
}.
To the ideas I prefer, I would also list one related idea, viewtopic.php?f=6&t=94715 ‘Each on Red Circuit’ and ‘Each on Green Circuit’. It would make it much easier to separate the signals in my opinion.
God forbid us from implementing the other related idea(viewtopic.php?f=6&t=90147 'Combinator Logic Rework') in games. It wouldn’t really fit into the game if we would to run a thousand assignments in a single combinator, making it a programming language from the world of combinators.
However, I would support the creation of a similar control panel where existing combiner networks could be reprogrammed "remotely" if connected to that network. This control panel could exist as a physical entity, a building, or an object. Of course, due to the fixed structure of the combinators, the structure could not be changed, only the values and the operators.
A solution to this problem could be to identify the signals by source(object) in approx. thus:
The format of the signs could be as follows: 'Coordinates of the building': 'Identifier consisting of 4 numbers and letters'
(e.g., X162; Y156: F2G3). Of this, in combinators and other buildings and entities, the last 4 letters would appear at the signal selector in a similar way to the one in the picture. To make it easier to identify signal sources locally, there could be a preview when the cursor is over that signal.
As you can see in the picture, the general shape of the signs would remain, and signals with a source ID would only appear if you right-click the generic signal, so they would still be just as easy to count regardless of the ID on them (if used).
Another problem may be that for larger circuits, the number of signals with the source ID would increase abruptly.
My suggestion for this problem is that the local identification of materials should be adjustable per source (e.g., box, circuit unit, other entity) and should not be labeled with a source ID by default.
Off topic:
I once read an idea that decisive combinators could have an adjustable else output.
Most players rejected this idea mostly because it would not be optimal for the program (plus 1 execution in the if sector), but as the player wrote, it would be optimal for the amount of space occupied in the playing field, and from writing two very similar conditions would also spare players (which would be two operations in the same way).
Link to the idea: viewtopic.php?t=64173
Picture of the implementation:
I apologize for the rudimentary nature of the designs.
Update:
The idea received a comment from Ssilk, one of the global admins. I agree with the two proposals he considers more useful, and would most likely have an additional effect on the idea I have written
{
viewtopic.php?f=6&t=56890 Separate signals to/from red and green wires
viewtopic.php?f=80&t=50283 Separated Handling of Red and Green Wires
}.
To the ideas I prefer, I would also list one related idea, viewtopic.php?f=6&t=94715 ‘Each on Red Circuit’ and ‘Each on Green Circuit’. It would make it much easier to separate the signals in my opinion.
God forbid us from implementing the other related idea(viewtopic.php?f=6&t=90147 'Combinator Logic Rework') in games. It wouldn’t really fit into the game if we would to run a thousand assignments in a single combinator, making it a programming language from the world of combinators.
However, I would support the creation of a similar control panel where existing combiner networks could be reprogrammed "remotely" if connected to that network. This control panel could exist as a physical entity, a building, or an object. Of course, due to the fixed structure of the combinators, the structure could not be changed, only the values and the operators.
, btw, I was not able to embed the mp4 for better look, gif would probably be very big, so I added it as an attachment.