ZeroGravitas

You mean, that's how it should currently work? Because it's nothing like that in practice (for me, as I say above). Could that do with a bug report?

Two key/tag inputs - enable/disable. Or just disable (logic =1), then call it a "Kill Switch". Like the Logic Splitter, it affects all parts downstream on it's connection graph. Disables all logic input/output of those blocks. Would be a simple way to cease the function of all the drones in a swarm, for example. Might need a counterpart, like the logic connector... Might be able to build the functionality into the Splitter, instead, depending on the envisioned use cases.

How about having a separate Logic Gateway block that only forwards one global key/tag to the split drone section? (And maybe one key/tag outbound, too?) As per this suggestion. I really want to be able to enable/disable my whole swarm, for example, but can't see a way to do it, currently (without a mechanical relay). Maybe the Logic Connector doesn't work as intended? (It didn't make sense to me, that it connects it's parts *only* globally, not within the split off section/drone too.)

I've been assuming that blocks already quietly repair themselves over time, so they only die from taking heavy damage in a short space of time. Right?

+1 for Logic Tunnels/Gateways/Key forwarding, whatever you want to call it.🙂 I'd really like to be able to enable/disable my swarm's movement. The only way I can think of doing this, currently, is via a clunky mechanical relay (motorised pivot and self-distance sensor setup).

I had been thinking more of a list of keybindings (and tags) that's clickable to highlight the blocks using them. Different colour highlight for input verses output (or the input/output symbols overlaid). Quite a big think to code, for a QoL improvement, with new UI and all that.

Since yesterday? Was there an update (I don't see an announcement)? Do you mean it's in a dev build? (Are you a dev?) That sounds really handy.🙂 I wonder if it was tried already, but without the flat edges it tended to get rotated out of alignment too much (with the force of any other blocks attached to it)...? Hmm, I wonder how much more computationally intensive that would make the detection... Also, harder (and more cluttered) for the game to illustrate the detection area. Maybe a proximity sensor instead...? With circular detection area. You could currently sweep out an an arc by putting a distance sensor on a motorised axel - far slower and more fallible, but cool looking. (Something for a separate thread.)

This is currently my biggest issue and suggestion. It looks like the order of my drones gets shuffled after restarting the game. I can see no pattern to how they are listed - not alphabetical or chronological... Tick box selection for these typical sorting options might be a basic solution. But I'd really love some kind of custom folder/tagging system, to separate out the sumo drones, at the least. And to be able to see more of them on screen at the same time (because my short term memory is bad and and bad at finding things in a long list). It also doesn't make sense that you have to scroll all the way back to the bottom, for your most recent drone, each time you go back to the select screen. Thanks, great game so far.🙂

+1 for simple block replacement. It would be a hughe QOL improvement; it's such a headache unpicking the spaghetti to change out core parts. I'd suggest using one of the keyboard modifiers [Shift], [Ctrl] or [Alt] for this, so you just drag a new block over the top of the old, and instead of attaching, it swaps it out (show different symbol there, of course). I think you should have made the rest a separate thread, to keep things simple and avoid clouding the discussion/voting. (Maybe a moderator could split the post if you agree.😉)

When I was just trying to set a system up for automated delivery I just left my drone core in the resource hopper (to home in on that, after rising to max altitude). A bigger problem was the bug that resources won't currently enter containers that have been printed (and are still attached). But I believe the devs are onto that already. Yep, definitely. Maybe empty too...? (Easier to work around.) Maybe a whole new resource sniffer (sensor) instead of over-loading the current ones...? But options are good.🙂