Filter logic connectors

[Fireball]

They are just one way connectors from other suggestion, but you can filter inputs

P.S. sorry for my English

P.P.S i have some more suggestions

[Lurkily]

If you mean ManTheMister's transmitter/receiver paired connectors, I think it involves a whitelist and blacklist on both transmitters and receivers.

[Fireball]

No, i mean one-way connectors (input only) with whitelist.

[Lurkily]

Input-only?  If there's no output, what does the input control?  Turning the connector on and off?

If might help if you linked to the suggestion that you're basing this on, so we're on the same page.

[Fireball]

Semi - automatic constructions?

(I can't find it now, maybe it got deleted/fundamentaly changed by author)

[ManTheMister]

 

this has a recieve-only with whitelist, and solves just about every other wireless issue that I can think of, especially when paired with Lurkily’s “events do not propogate without connection” suggestion.

[Lurkily]

I've made a number of suggestions on the subject myself, and me and Mister got to brass tacks a while ago and tried to really grind on the subject.  We ended up with that suggestion he linked.  It does address your needs, and I've tried to challenge it, and get others to challenge it, by finding a usage-case that it can't address; it's been very difficult to find anything.  Without getting overly weird or confusing or complex, I think that suggestion approaches an ideal solution.

In short, we localize logic so that it needs a connection, (besides making sense, it also provides information about disconnection that logic can use,) and instead of connectors, we pair up a transmitter and receiver part. Receivers poll all transmitters, and reproduce the signals that reach the transmitter.  They don't act as a hub, like connectors do now, (which is why they also act as splitters,) but they produce a signal like a 'button' logic part, speaking to parent and child parts.  Receivers and transmitters both have the option of either a whitelist or a blacklist, with an empty blacklist (all signals pass) being the default.  

That gives you control over the direction signals travel - from brain to subdrone, one subdrone to another, or subdrone to brain, whatever you like.  It also lets you control what signals pass.  Only certain signals, or all except certain signals.  It also provides feedback, if you engineer well, about when parts are connected.  You can design subdrones so that they can communicate back-and-forth with the drone brain, but using signals wisely, you can prevent any of the signals they use for command-and-control from being transmitted, so they can't interfere with each others' operation.

It does what you need and more; I'm still interested, though, if anybody can find a problem with it.  The best way to test an idea is to honestly try to defeat it.