- Joined
- Sep 10, 2013
- Messages
- 818
- Reaction score
- 708
These are a mixture of new and old suggestions as was recently discussed in chat by several SMD users.
1. Why wireless blocks are limited as-is
- Unreliable: As they are the sole means of transmitting signals, but as they at the same time are prone somewhat prone to erroneous behavior, they are the weakest link in the chain, and this effect becomes stronger the deeper the docking chain is.
- Lack of ease of use: A connection must be manually created or edited via C-V. This must be done either as astronaut, or hopping between the build modes of two separate entities.
- Inflexible: Communication between two entities must be known and prepared for (in hardware) in advance. Connections must be made between instances of blueprints, not blueprints themselves (the latter allowing truly modular design).
2. Recurring idea A: Logic beams
- Most flexible solution to non-moving docked entity communication, allowing for modular dockable logic without bothering with the interface problem after defining an interface once spatially (via logic beam emitter and detectors, could even be the same block somehow or repurpose existing blocks like astrotech)
3. Recurring idea B: Transmitter/Receiver blocks
- Very easy to use, flexible even for independent entity communication by making receivers and transmitters have a "frequency", and the former would receive transmissions sent on the same frequency by the latter
- Frequency could be set either like rail speed, by linking the blocks in question to a fraction of activation blocks (or instead of fraction, just use the number of ON activation blocks)
- Another way to set frequency with a huge adress space (avoiding collision issues) is to use display blocks and a [FREQUENCY] tag that works like the password tag (does not display frequency).
- Faction and public permission blocks could alter which signals are accepted by a receiver block.
1. Why wireless blocks are limited as-is
- Unreliable: As they are the sole means of transmitting signals, but as they at the same time are prone somewhat prone to erroneous behavior, they are the weakest link in the chain, and this effect becomes stronger the deeper the docking chain is.
- Lack of ease of use: A connection must be manually created or edited via C-V. This must be done either as astronaut, or hopping between the build modes of two separate entities.
- Inflexible: Communication between two entities must be known and prepared for (in hardware) in advance. Connections must be made between instances of blueprints, not blueprints themselves (the latter allowing truly modular design).
2. Recurring idea A: Logic beams
- Most flexible solution to non-moving docked entity communication, allowing for modular dockable logic without bothering with the interface problem after defining an interface once spatially (via logic beam emitter and detectors, could even be the same block somehow or repurpose existing blocks like astrotech)
3. Recurring idea B: Transmitter/Receiver blocks
- Very easy to use, flexible even for independent entity communication by making receivers and transmitters have a "frequency", and the former would receive transmissions sent on the same frequency by the latter
- Frequency could be set either like rail speed, by linking the blocks in question to a fraction of activation blocks (or instead of fraction, just use the number of ON activation blocks)
- Another way to set frequency with a huge adress space (avoiding collision issues) is to use display blocks and a [FREQUENCY] tag that works like the password tag (does not display frequency).
- Faction and public permission blocks could alter which signals are accepted by a receiver block.
and the logical beams can solve and implement many constructions
