Sensor module tweak

[Levarith]

Instead of having the sensor module check for the content of a display block it should check the output.

For instance, I want to create an auto pilot that will fly exactly to a specific sector and then fire a huge stop effect on my ship so in one display block I use [sector] and the other I use the target coordinates 2,2,2

Currently it doesn't read as true even if the output of both display blocks is the same.

 

[Valck]

Yes, but what if you need to check whether "[password]secret" and "secret" match? If output were what is checked against, "[password]secret" would match the empty string "", which is most likely not what you'd want.
[doublepost=1477244135,1477243788][/doublepost]Maybe another tag "[cooked]" could be used to see whether the other display's interpreted output matches, eg.
Display A has "[sector]", display B has "[cooked]2, 2, 2", and if A's processed output reads "2, 2, 2", the sensor indicates a match.

 

[TheGT]

Yes, but what if you need to check whether "[password]secret" and "secret" match? If output were what is checked against, "[password]secret" would match the empty string "", which is most likely not what you'd want.
[doublepost=1477244135,1477243788][/doublepost]Maybe another tag "[cooked]" could be used to see whether the other display's interpreted output matches, eg.
Display A has "[sector]", display B has "[cooked]2, 2, 2", and if A's processed output reads "2, 2, 2", the sensor indicates a match.

It would be easier if some things were just exceptions to this rule, like [password]

 

[Valck]

It would be easier if some things were just exceptions to this rule, like [password]

I think that would be less versatile, but not necessarily more intuitive, for any amount of "some" greater than <insert arbitrary number here>

 

[Levarith]

But the [password] already has special exceptions that other things dont. And how is it less versatile to check output? I agree with TheGT, that should be the exception not the rule. I can't think of any other scenario where it would be better to check input...

 

[Valck]

how is it less versatile to check output?

Because you close the door to other variables or modules further down the road that could make use of a raw versus a cooked interpretation; either that or you have to have a growing list of "some" exceptions that work differently from everything else.

 

[Levarith]

If you want raw data you can enter raw data as the output. Being able to say "if [variable] equals ___" is way more usefull than just passwords which are the only exception to using output over input

 

[Valck]

Of course StarMade could profit from having a language interpreter and fully programmable modules (and believe me, I'd love to have that, too), but this is how Schine implemented it, at least for the time being.
I merely pointed out how the current system would fail with what you suggested in your first post, and offered an alternative without breaking existing functionality.
I'm not saying this is the "right" or only way it could be done.

 

[Lone_Puppy]

Perhaps a compromise. A way for use to use both input and output. Use an alternative to square brackets to indicate to the interpreter that you want to read the output. For example;

Reading input surround the variable with square brackets like [sector].
Reading output surround the variable with parentheses or brackets like, {sector} or (sector).

Just a thought.

 

[Snapems]

Yes, but what if you need to check whether "[password]secret" and "secret" match? If output were what is checked against, "[password]secret" would match the empty string "", which is most likely not what you'd want.
[doublepost=1477244135,1477243788][/doublepost]Maybe another tag "[cooked]" could be used to see whether the other display's interpreted output matches, eg.
Display A has "[sector]", display B has "[cooked]2, 2, 2", and if A's processed output reads "2, 2, 2", the sensor indicates a match.

Wait, you just made the opposite argument. The string "[password]hello" sensor-compared to "hello" is true. That means it IS comparing the output of [password] not the input (which must be null). Because as you can see, those strings are NOT the same.
But comparing "[sector]" with "2,2,2" fails. This Is inconsistent with the variable [password]!

So many many things could be done if it was somehow possible to get at the very juicy data in those display variables with sensors!
Please make this a thing ASAP!

The 3 ways to let us get to the data:
#1: The Displayblock-copy w/ activation blocks; copies the results of the variables.
#2. Regex Replace looks at the results of the variables.
#3. Sensor Comparison looks at the results of the variables.

I would be happy with any or multiple of these 3. It feels like because as I said, the result of [password] = null is compared by the sensor block; that option #3 is intended, but just broken atm.

 

[Levarith]

No. Password is just ignored for purposes of comparison the only thing it does is tell the display not to actually print whatever comes next but to store it on that module.

He is correct, currently checking output would compare nothing to whatever you typed because password is an identifier not a variable.

 

[Snapems]

Oh I think I just figured out why you guys are confused...
I think you guys think that the "output" of display blocks with "[password]hello world" in it is null (blank). But from the sensor' block's point of view, it's not empty; it contains "hello world"

You have block A: "[password]hello world"
Block B: "hello world"
And then you connect a sensor block to compare them.
It compares them as true.. So think about what's happening to cause that to be true.
The game must convert [password] to "" (null). And then AFTER compare the 2 strings.
So compare that to what happens when you use "[sector]"
There is no conversion on it. UNLIKE [password]. (which again, only the [password] part is converted to "")

As you can see [password] is evidence FOR comparing the output of variables, not against.

Again, please please rush this as a feature.
Think about how cool it would be to compare display modules with [shieldPercent] and [sector] and [armorHpPercent] and [power]!
The arguments against this are invalid!!!

 

[Calhoun]

Oh I think I just figured out why you guys are confused...
I think you guys think that the "output" of display blocks with "[password]hello world" in it is null (blank). But from the sensor' block's point of view, it's not empty; it contains "hello world"

You have block A: "[password]hello world"
Block B: "hello world"
And then you connect a sensor block to compare them.
It compares them as true.. So think about what's happening to cause that to be true.
The game must convert [password] to "" (null). And then AFTER compare the 2 strings.
So compare that to what happens when you use "[sector]"
There is no conversion on it. UNLIKE [password]. (which again, only the [password] part is converted to "")

As you can see [password] is evidence FOR comparing the output of variables, not against.

Again, please please rush this as a feature.
Think about how cool it would be to compare display modules with [shieldPercent] and [sector] and [armorHpPercent] and [power]!
The arguments against this are invalid!!!

You've missed out a vital thought there. The sensor sees "HelloWorld" because [password] is not part of the string, like the <Style> formatting.

If this suggestion were in place, the sensor would then be comparing "[password] Hello World" and "Hello World", which then fails.

 

[Snapems]

If this suggestion were in place, the sensor would then be comparing "[password] Hello World" and "Hello World", which then fails.

This statement is 100% incorrect. The exact opposite occurs. If this suggestion was NOT in place, the sensor would fail, but sense it IS in place already with [password] (but with nothing else), it succeeds. [password] is the only thing that is already following the suggestion of the OP. And yet somehow you guys are using it as an argument against the OP's suggestion, and it's driving me up the walls.

Let's go through this once more...

Original Blocks:
Block A: "[password]Hello World [sector]"
Block B: "Hello World 2,2,2"

Here's how they're compared right now with the sensor block:

Step 1: A Parser runs on both modules.
A becomes: "Hello World [sector]"
B becomes: "Hello World 2,2,2"
Step 2: The strings are compared.

So the change suggested is to include [sector] and the other variables in the parser so it would look like this:

Step 1: A Parser runs on both modules.
A becomes: "Hello World 2,2,2"
B becomes: "Hello World 2,2,2"
Step 2: The strings are compared.

I'm a computer programmer, I've literally worked on several parsing engines very much like this. - Please ensure you understand my posts before you respond. My heart can't take this...

 

[Levarith]

[Password] isn't compared to anything. All it does is tells the display block not to output the next bit. It gets ignored for purposes of comparison. Other than that input is compared not output.
My idea was for it to compare output except in cases of [password]

 

[Ithirahad]

Ultimately, this is not already implemented for technical reasons.

When you type "Current Location: [sector]" into a display block, "Current Location: [sector]" is stored in the ship's metadata.

When you compare strings, it compares strings from metadata.

If memory serves, what you see, the actual sector readout - "3, 4, -7" or whatever - is put in on the fly just before it renders the text.

The change you are suggesting would mean either having sensors become able to intercept the changed text (the changes required to do that would cause performance issues) or having the variables somehow update the stored metadata constantly as the read values from the ship change, which, though I'm not certain, sounds like it would cause performance issues as well, given how much those values update.

 

[Snapems]

They already specifically avoided possible performance issues by using a per-request method. That means the variables could only be requested per-second - which, simply can't cause an issue.

The fact that it's able to show a player that information instantly is proof that getting that data once per second is a non-issue.
"technical reasons" are not really an excuse here. You're talking about the sensor block as if it's not an element in a game. The data is ether there or not, and we know it's accessible. There isn't confusion on 'what object the display block is on'. So we should know everything about that object.
You sound like in your post you're some sort of authority, and know the woe's involved with this. But I know the code can't possibly be so obfuscated to the point where this isn't a less than 20 minute implementation w/o any performance issues.

Levarith Again, the sensor IS comparing the "output" of [password]. As the "input" of "[password]" is "[password]" and the output is "". - Looking at it from the eye's of the sensor block, which is the only eye's we care about. It's not "except in cases of [password]" - it's "Exactly like in the case of [password]".

Edit* Minor clarrification

 

[Ithirahad]

AndyP knows more... here is hoping he shows up here.

 

[Levarith]

Levarith Again, the sensor IS comparing the "output" of [password]. As the "input" of "[password]" is "[password]" and the output is "". - Looking at it from the eye's of the sensor block, which is the only eye's we care about. It's not "except in cases of [password]" - it's "Exactly like in the case of [password]".

Edit* Minor clarrification

The input to the display module is [password] + string and the output is "" so it cannot be comparing the output or it would be true if compared to any empty display module. Therefore it must compare the input with the way it is currently implemented. You are looking at [password] as a variable that we can edit, it isn't. It is a tag that the display block reads and receives the instruction to output nothing, nothing more.

 

[Snapems]

The input to the display module is [password] + string and the output is ""

Wrong;
The output of "[password] + string" is " + string"

Looking at it from the eye's of the sensor block, which is the only eye's we care about

I think you guys think that the "output" of display blocks with "[password]hello world" in it is null (blank). But from the sensor' block's point of view, it's not empty; it contains "hello world"

The string "[password]hello" sensor-compared to "hello" is true. That means it IS comparing the output of [password] not the input (which must be null). Because as you can see, those strings are NOT the same.

Please ensure you understand my posts before you respond. My heart can't take this...

Edit: removed sarcastic comment... >_> Sorry, frustrated.
But stop looking at the display blocks, and start comparing them via sensor block. That's what this topic is about. Not the fact that you see a blank display block when [password] is in it; that's irrelevant, because that's not what the sensor block sees. Do you think the "output" of password is to erase everything in the display block? Think it out, read my posts.