A New Logic Solution?

[Garheardt the Black]

Logic idea; Frequencies.

 

Lets say it was possible to have multiple command stacks in the drone core, each with a unique identifier, like a tag. A "frequency," if you will.

Right now, each item has a blank where you can designate a tag. Imagine if there was an additional set of blanks where you can designate a "send" and "receive" frequency.

Imagine If a block has a  "send frequency" designated as "Drone 1". That block can only send commands to other blocks with their "receive frequency" designated as "Drone 1". 

multiple identical drones being manufactured? Split them off with a logic splitter, then set the frequency blocked on the splitter to whatever frequency you don't want cross talking. This leaves the split off drones free to communicate on other frequencies. 

Tired of building identical drones, then having to re-tag each one with "turn left 1, turn left 2..3...4" simply put in a unique tag frequency. Now, instead of having to change scores of unique tags, you only have to fill in 1 per block. 

How to switch default input frequencies? set a logic block with the default "receive frequency" and fill in the "send frequency" to whatever frequency you want.  

So, that's my idea! Rock on.

 

 

[ManTheMister]

I think that a better system of logic splitters and connectors would be a better option than a whole new system in the drone editor.

[Lurkily]

This could work; but I do think there are better solutions. 

[Ookami-sama]

Printing two drones with the same factory would make it so their « Send » and « Receive » frequencies are the same, I believe. These frequencies could maybe save some time, but it sounds a little much to add when a list of current tags and keys and a few tweaks, like editing a tag without having to type it whole again, could do the same.

As in, click a component; you can now read on the left of your screen a list of all parts that are children to it, with their settings next to their names; click to the left of the « 1 FETCH BALL » tag; press Del to delete the « 1 » suffix, press 2; press Enter, or select next tag. Your tag is now « 2 FETCH BALL ». Tadaaaam.

A tag for tags would kind of make me eager to read some Kafka again.

[Lurkily]

 But those drones would be behind a splitter.  The commands sent to them would be on one frequency; that can trigger a signal localized by a splitter on a different frequency. 

 

[Ookami-sama]

So your drones would still crosstalk if they originated from the same factory. Same input, same output, same channels (this F word is getting on my nerves for some reason), same interactions with the rest of the craft. If the first drone sends a channel 1 (CH1) signal to something on the main craft, which does whatever it should do on CH2, then second drone will send another CH1 signal and it will be the same all over again. If one part is to receive on CH1 and emit on CH2, I am pretty certain I can instead prefix the tags with CH1 and CH2 respectively, to the same effect.

I reckon tags ignore splitters, too, so I am not sure what you are trying to get me at. Perhaps I am just too tired.

[Lurkily]

You may be right; I'll process this more later.  I got the itis right now. 

[Garheardt the Black]

This is how I imagine it working.

 

How it currently works for reference:

Sending to a part blocked by a splitter:
(CORE)---SIGNAL---(SPLITTER) *SIGNAL BLOCKED* 

Receiving from a part blocked by a splitter:
(PARTS)---SIGNAL---(SPLITTER) *SIGNAL BLOCKED* 

 

How it could work:

Sending to a part blocked by a splitter:
(CORE)---SIGNAL ONE---(SPLITTER SET TO BLOCK SIGNAL ONE) *SIGNAL BLOCKED* 
(CORE)---SIGNAL TWO---(SPLITTER SET TO BLOCK SIGNAL ONE)--(LOGIC BLOCK RECEIVING SIGNAL TWO AND TRANSMITTING SIGNAL ONE)--
--SIGNAL ONE----(PARTS)

Receiving from a part blocked by a splitter:
(PARTS)---SIGNAL ONE---(SPLITTER SET TO BLOCK SIGNAL ONE) *SIGNAL BLOCKED*
(PARTS)---SIGNAL ONE---(LOGIC BLOCK RECEIVING SIGNAL ONE AND TRANSMITTING SIGNAL TWO)---SIGNAL TWO---(SPLITTER SET TO BLOCK SIGNAL ONE)--
--(CORE)

(PARTS)--SIGNAL TWO---(SPLITTER SET TO BLOCK SIGNAL ONE)---(CORE)

 

This would allow greater control over how our drones communicate, similar to other proposals with one advantage; workshop efficiency. The more drones you have at a time, the more you find yourself with huge numbers of near identical sets of logic blocks that have to have all of their tags changed in order to keep them from interfering with one another. It gets harder when you want to be able to activate and deactivate them independent of one another. You could put them behind a splitter, but then you can't communicate with them either. With this system, you could leave all of your tag logic alone, split their signals off, then use another signal to bypass the splitter. Then you just convert the signal into whatever signal you need with a logic block on the far side of the splitter. 

In a way, we're already using multiple signals when we use switches and "and" gates. This would be an easier way to do that as well, I think.  

[Ookami-sama]

Channels for logic splitters to receive and send tags, when said splitters are supposed to block keystrokes but do nothing of tags... It is convoluted, and the only argument you have is that it would make duplicating parts of your crafts easier (identical drones would still have the same features, same input, output, channels etc., no progress in that area). As such, I would wholly prefer a way to make editing easier indeed, without frilly channels that would act solely as tag prefixes, as well as a few tweaks to the way keystrokes are transmitted. See this suggestion for information:

 

[Garheardt the Black]

Respectfully, I don't think you're understanding the concept I'm attempting to communicate. The splitters I described wouldn't be transmitting anything. They'd simply block the signals you told them to. Also, I detailed more than one reason why the system could be useful. 

My basis for the idea goes back to radio controlled vehicles. They don't cross talk because they can designate different frequencies to communicate on. Same for aviation; different channels for different purposes. Sometimes, when looking for solutions to virtual simulation problems, I find it useful to look at how the real world equivalent goes about it.

But alas, c'est la vie.

[Ookami-sama]

More than one reason, you say.

On 11/22/2018 at 3:21 AM, Garheardt the Black said:

multiple identical drones being manufactured? Split them off with a logic splitter, then set the frequency blocked on the splitter to whatever frequency you don't want cross talking. This leaves the split off drones free to communicate on other frequencies.

If you print several crafts with the same factory, they will all have the same input, output, channels, and lastly behaviour, so there is no improvement there. Send a tag and all drones will react to it.

If some different drones should communicate among themselves but not with other parts, you can solve this problem by giving them relevant tags and keystrokes, much like you prevent e.g. a thruster from being activated when a factory is ready to print, no improvement with channels either.

If some identical drones should not communicate among themselves, use keystrokes and a splitter.

On 11/22/2018 at 3:21 AM, Garheardt the Black said:

Tired of building identical drones, then having to re-tag each one with "turn left 1, turn left 2..3...4" simply put in a unique tag frequency. Now, instead of having to change scores of unique tags, you only have to fill in 1 per block.

If you make, through editing, several crafts that should be, in terms of logic, separated from one another, then you can give them tags to the same effect, without any sort of radio channel, as you said, and the only thing channels would solve is the task being quite tedious. Or, alternatively, and before some answer is implemented, you could use keystrokes for all things related to the inner workings of each drone, seeing as how these are effectively blocked by logic splitters. If it is making it easier that you seek, a simple way to edit tags more quickly would do the job, without any supplementary feature to take into account when crafting drones.

That makes it one reason (ease of use), unless I failed to see another or I should count the invalid ones. In the first case, please do enlighten me; in the second, I will forfeit this discussion.

          

Having attended a few classes for engineers to be, I have an idea of what it means to look for solutions, yes. Still, this one is, from what I gather and unless I am completely off the tracks, inadequate. Not bad, just not optimal, because it would solve one issue that, while important, could be taken care of in a more logical and intuitive way. Namely: a list of tags and a way to edit them quickly, rather than having to click a few times and type them whole.

As a side note, a way to make it less tedious is to use abbreviations instead of words: « Subdrone turn left » can be made « SL ». Prefix is S, so it is the Subdrone that is concerned, and actual tag is L, left. Noting these down on a sheet of paper or in a text file can come in handy, too.

[ManTheMister]

If you only want to send OR recieve signals from the drones, then they wouldn’t crosstalk. You could send all of them a command without any of them crosstalking.

though I think that this would be a better solution

 

[Lurkily]

19 minutes ago, ManTheMister said:

If you only want to send OR recieve signals from the drones, then they wouldn’t crosstalk. You could send all of them a command without any of them crosstalking.

though I think that this would be a better solution

 

Funny, I JUST put up a post in Discussion, asking people to challenge what we discussed in that thread.  That is over here: 

 

[Garheardt the Black]

Ah well. The more ideas, hopefully, the better end result. Consider this a dead one  

[Lurkily]

No worries; always good to get ideas 'in the wild'.  While I worked with Tandem games (I use the word 'worked' loosely, as I helped design a skill update, but was never on a payroll) some of the things I didn't see promise in spawned conversations that led to really good ideas.  Keep on posting 'em.