Logic with Display Modules

[Taxicap1729]

The display modules are currently only useful for static text but dynamic text would add a lot to the atmosphere of starmade, so I will add my suggestion below.

There were already some topics on more options for display module logic
e.g. here or here
While not totally different from this idea I want to propose a method that might fit better in the block based system of starmade.

There would be 3 base rules to alter the text on the Display Module (from now DM) that can change everything you want and 3 rules that will trigger logic output on specific conditions.
To alter the text of a DM the logic block must be adjacent to the DM that should be changed, this should help to distinguish the different modi (change text and create logic output).

1. A not signal that is adjacent to a DM and activated will erase the text of the module
2. A button adjacent to a DM and linked to a second DM loads the text of the second DM into the DM its adjacent to.
3. A and block adjacent to a DM and linked to a second DM will add the text of the second DM to it's adjacent DM when activated.

4. A and block that is linked to two DM will generate a true signal if textA equals text b
5. A or signal will generate a true signal if one word is contained in both texts. (Any word of textA in textB or vice versa)
6.A not signal will generate a true signal if the words in both texts are distinct.

With this 3 easy to use rules fot textbuilding you could build every text that matches into a display module (also some complex text displays might need a lot of logic, but that is already the case for a lot of things .

I hope you like the idea, feel free to post your addisions.

 

[NeonSturm]

please compare. check passwords before open a door.

 

[Taxicap1729]

Comparing might be more difficult because every input to the DM would have to update the logic signals.
Maybe it could be like a and signal linked (or adjacent) to two DMs outputs true if they are the same and false otherwise.

 

[NeonSturm]

Comparing might be more difficult because every input to the DM would have to update the logic signals.

False. Only when it changes.

Maybe it could be like a and signal linked (or adjacent) to two DMs outputs true if they are the same and false otherwise.

That is comparing. lol
You may be interested into this : https://en.wikipedia.org/wiki/Trie#Bitwise_tries
You only need to check a few letters per input and do just as much logic as you would have to do if you process the output of a timer-circuit (which already exists).

 

[Taxicap1729]

Shure, only when it changes. And it changes on input.

please compare. check passwords before open a door.

That is comparing. lol

So you want comparing, but don't want comparing? I don't really understand that.

For the usecase: "Input password open door"
You would just have a DM with the password and one for the input. Both are linked to a and signal. If your input password is correct you get an active signal, as simple as that. (You could additionally link a not signal to the input DM to erase it after correct password input)

 

[NeonSturm]

Shure, only when it changes. And it changes on input.

Every input a LETTER changes, not the LOGIC OUTPUT of a DM.

The logic output changes when a pattern starts to match or stops matching.
Also you commit the whole text as once after pressing OK. And that happens how often?
Have you read the wikipedia article? It might give you an idea how to progress through many possible matching patters without LAG.​

So you want comparing, but don't want comparing? I don't really understand that.

I said "lol" because you did contradict yourself.

For the usecase: "Input password open door"
You would just have a DM with the password and one for the input. Both are linked to a and signal. If your input password is correct you get an active signal, as simple as that. (You could additionally link a not signal to the input DM to erase it after correct password input)

Well I was thinking a step further more like:

DM1 -> and -> {DM2…s, logic-block}

logic-block receives true if DM1 contains all DM2s's texts.​

DM1 -> or -> {DM2…s, logic-block}

logic-block receives true if DM1 contains at least one DM2s's texts​

DM1 -> not -> {DM2…s, logic-block}

logic-block receives true if DM1 contains none of DM2s's texts​

Which would not lag with bit-wise tries (a letter consists of zeroes and ones)​

 

[Taxicap1729]

It seems we have understood each others ideas, just our expression is different.
I don't really care if it's implemented with tries or a simple x.equals, although tries seem to be a overoptimisation for the first implementation.
Also I'll add your suggestions to the first post.