Wireless modules should not act as splitters.

[Lurkily]

I think in the example, the bottom left LED should light up.  (All buttons and LED's are set to 'X')  It would allow us to activate an 'if' gate beyond a splitter to control a split-off drone part, effectively allowing us to segregate transmitted commands so that only those we need are transmitted. Furthermore, it just makes sense.  There's no reason for the wireless transmitter to act as a splitter - that's what we have splitters for.

Signals transmitted from the core by the wireless part should be sent to only child parts.  Signals generated by those child parts should be able to propagate to the wireless part's parents.

[Ookami-sama]

It does look strange that a branch with one splitter, then one connector, currently makes two completely separate modules.

In my mind, and to word it differently, a given signal should propagate all the way until it reaches a dead end or a logic splitter, both up and down the genealogy of components. It would let one e.g. produce several modules using a factory (splitter - logic for behaviour - connector - logic for receiving orders), then give them commands from which automated actions ensue: all drones would receive the signal, and none would interfere with each other's business.

In other words: yes.

[notsew93]

If things were to be changed as Lurkily Suggests, then I would finally be able to activate a factory printed drone on-demand, while also having the drone be split and not cross-talk with its brothers. As things are now, it really is an all-or-nothing deal with transmitting signals. 

Unfortunately, I fear that this change could require up to a total rewrite of the logic propagation - at present, there are no examples that I know of that pass certain signals selectively based on where they are sourced from. 

Plus, if the wireless transmitter passes signals from the core up and down, but only returns signals from below, then suddenly it is asymmetric. How would a player figure out such a strange property without essentially a paragraph-sized tooltip?

Other solutions to this problem could include the logic splitter being toggleable with a key, assigning a whitelisting-type behavior to the wireless connection part, or making logic cut off when parts are disconnected like how fuel and energy are dynamically shared/cut off. 

Don't get me wrong, I like the idea, and firmly believe that a lack of answer to this problem is holding the game back. Is there a even better solution though, that fixes this problem cleanly, intuitively, and without feeling like it is a quirky band-aid to an underlying propagation model problem?

 

[Lurkily]

3 hours ago, notsew93 said:

without feeling like it is a quirky band-aid to an underlying propagation model problem

I don't think this is a band-aid. I think this plus local logic is a complete solution that fulfills a multitude of logic requests.  Switchable splitters, wireless single -key transceivers, wireless transmitter/receiver pairs, they're all attempts to solve one little corner of the problem.  I don't think new logic parts are a solution.  I think they are the band-aid.

Propagation is a pretty simple thing in principle, and when you need it to be selective, there's not usually a lot of more elegant solutions than making it selective - though I'd be pleased if someone managed to prove me wrong.

3 hours ago, notsew93 said:

Plus, if the wireless transmitter passes signals from the core up and down, but only returns signals from below, then suddenly it is asymmetric. How would a player figure out such a strange property without essentially a paragraph-sized tooltip?

 

 

"Allows non-wireless signals to pass freely."  Is this less intuitive than a wireless connector blocking connections when we already have a connection blocker part right next to it?  The game doesn't imply it should, real life doesn't imply that it should, the player has no reason to expect it.

In my opinion, the most confusing part of wireless connectors - that they speak only to children - is already in the game.

3 hours ago, notsew93 said:

Unfortunately, I fear that this change could require up to a total rewrite of the logic propagation - at present, there are no examples that I know of that pass certain signals selectively based on where they are sourced from. 

 

I see a couple of paths to implementation present themselves, based on how logic works, which isn't fully clear. If parts reach out to find all connected signals, this might be more challenging than if each part receiving a signal forwards it on. 

What you would need is to differentiate wireless signals from normal signals.  Once you have that, it's as easy as disregarding signals that are wireless, and a child of yourself, and the child of a wireless part. 

But if signals actually do propagate, (in code, not in gameplay - parts might query for connected signals instead) I don't see much issue.  Have the wireless part propagate signals as normal, but have a special case for its own signals to propagate only to children.

 

 

[notsew93]

If I had to hazard a guess, I'd say that logic variables are global as a remnant of when everything was global, including fuel/energy. Later, they would have added the logic splitter feature by splitting of a branch of the tree model of the drone, by saying "all logic is global, except for logic parts which are descendants of this splitter block - they get their own section, inside of which is locally global." Then, when the added they logic connector part, they added a feature to the logic splitter, which now says "you know that cordoned off local global logic section downstream of this wireless connector? Yeah, actually that's the same region as the drone core global logic area now."

So if this is how they implemented it, no logic connections are calculated at drone flight-time, (except factories, which would increment a region defining prefix for each new splitter or connector) and no signals are *actually* "propagated" part-to-part. Every logic part is assigned a logic region number based on the tree subdivisions created by the splitter/connector parts, and every part within a region label communicates using local global variables. In the case of the wireless connector, instead of incrementing a new region label they just assign the "region 0" of the core. Inside a region, physical connection/decoupling does not matter and in fact is not even detected by the game from a logic tracking standpoint. 

This is speculation of course, but this explanation fits all facts I know of. 

Because I suspect that the logic is done in this way, any change to the logic that would "just change the propagation rules" would require a front-back re-write, because logic is not "propagated" in the first place. 

I'm not saying it shouldn't be changed, I guess I'm just trying to say that some changes that seem small  may not actually be. Even some of the changes that I suggested would be big changes if this is correct.

 

[Lurkily]

The devs have said that logic's connectivity, like fuel and energy, could be changed easily; that they made an arbitrary decision that it should be global, rather than there being a constraint upon it or having a reason for it, that it may change again in the future.  When splitters happened or why splitters happened isn't really relevant to what should happen.

13 minutes ago, notsew93 said:

If I had to hazard a guess

The speculation you describe basically amounts to parts querying for connected signals, and can use the solution I presented for that.  Find a way to differentiate the signal, and generate a duplicate differentiated as wireless on the correct tree.  If a signal is wireless, and a wireless part is among your parents, then the call's for you.

There are a lot of problems - code always presents a lot of problems.  A coder's job is solutions, and I think the beginning of a solution to any possible propagation model is pretty clearly visible.  Only the details are left, and those we can't predict without knowing the code.

[Lurkily]

As for a method of differentiation, prefix a wireless signal with a character the player can't use, some weird unicode character.  If a wireless part is your parent, strip those when you find that signal in your region of the signal tree, or when you query, or when signals propagate.  However it works.

[Lurkily]

I have revised my opinion.  I'm now a proponent of a different suggestion. If you upvoted this, please consider uprooting that, after reading my reasoning here: