P3D v4 Script error in P3Dv4

[rcbarend]

Hi,

Can anyone explain why the XML gauge line

      (L:VSTOLMode,enum) 4 == (>L:ChuteVisible,bool)

is flagged as a "script error" in P3Dv4 ??

The codeline DOES work Okay, and I DO know how to code it differently to avoid the error.
But I just like to understand why P3Dv4 thinks this is improper coding.

The only reason I can think of, is that P3Dv4 doesn't like a logical value ("true" of "false") to be assigned to an Lvar.
But if that is true, why is code like

   (L:VSTOLInit,bool)
   if{
     etc.

then NOT flagged as an error ?

Sounds inconsistant to me …..

Rob

 

[tgibson]

I assume the gauge code checker in the sim simply didn't have that possibility flagged as one, and thus it's flagged as an error.

 

[WarpD]

Without seeing the actual log entry, I couldn't begin to state anything regarding why or why not.

 

[Deleted member 1281]

I guess we need more context... In V4.5 I used this snippet via a mouse click:

  (L:VSTOLMode,enum) ++ (>L:VSTOLMode,enum)
  (L:VSTOLMode,enum) 4 == (>L:ChuteVisible,bool)

Works as intended and no error shown in the log.

 

[rcbarend]

I guess we need more context... In V4.5 I used this snippet via a mouse click:

  (L:VSTOLMode,enum) ++ (>L:VSTOLMode,enum)
  (L:VSTOLMode,enum) 4 == (>L:ChuteVisible,bool)

Works as intended and no error shown in the log.

Thanks for all the reactions.
I dont use P3Dv4 myself, so I will ask the guy who reported this to me to post detail on the error log.

Rob

 

[=rk=]

Oh, that little window that pops up after the sim closes. I've been getting that almost since day one of P3D and I don't even trouble myself to check the log any more. Just a bunch of dotted t and crossed i errors and in the years since, none of them have piled up to amount to any sort of simulator nuisance, beyond the requirement to dismiss yet one more window.

 

[WarpD]

According to L-M... each of those errors impacts performance of the sim.

 

[spokes2112]

Just ideas...
Maybe the return of 4 == returns a "true" not a 1 or zero.. ( I know, not likely) Therefore the write to "chute visible" is an invalid type.
The following may get rid of the error.

 (L:VSTOLMode,enum) 4 == if{ 1 (>L:ChuteVisible,bool) }

Maybe the var "L:VSTOLMode,enum" has no value assigned (written) to it prior to the "equal to" comparison?

According to L-M... each of those errors impacts performance of the sim.

Also wouldn't the same script checking also impact sim performance on load? Finding all those "just a bunch of dotted t and crossed i errors" isn't free.
Finally who is to say that the checking itself doesn't have errors in it.

 

[WarpD]

Just pointing out that they recommend, strongly, that these issues be resolved. Not ignored.

 

[taguilo]

dont use P3Dv4 myself, so I will ask the guy who reported this to me to post detail on the error log.

That guy gave you a bad report. There is nothing wrong with that script as it is written therefore it won´t throw any error by itself. Problem is elsewhere in the code.

Maybe the return of 4 == returns a "true" not a 1 or zero.

There´s no "true" or "false" return, ever. Evaluations always put 0 or 1 in the stack. If there is an LVar assignment following, it will take that value.

Also wouldn't the same script checking also impact sim performance on load?

Yes. Script checking occurs only once, at gauge load. Therefore impact, though minimum, is here and not at run time.

Notice that any invalid text included in a script will be parsed on every cycle, and then performance will be affected, even loss being insignificant.


Tom

 

[WarpD]

That script can raise a content log error entry in Prepar3D.
True is not 1... EVER. True is only legitimately tested as a value being NON-ZERO. Testing for 1 doesn't make it 'true', as anything non-zero is treated as true by the CPU.

 

[taguilo]

That script can raise a content log error entry in Prepar3D.
True is not 1... EVER. True is only legitimately tested as a value being NON-ZERO. Testing for 1 doesn't make it 'true', as anything non-zero is treated as true by the CPU.

Ed,
Please read my post. The stack knows nothing about true/false concept, hence the parser returns any evaluation in which A A == as 1 and A B == as 0. No other result is supported.

Tom

 

[WarpD]

I was referring to how one should determine if something's a 'true' or a 'false'. Never rely on a value that is expected to be 'true' being a '1'.

 

[n4gix]

Correct, Ed. MS makes it very clear that a Boolean is either zero or not-zero.

 

[taguilo]

Correct, Ed. MS makes it very clear that a Boolean is either zero or not-zero.

I agree.
Funny thing is that the xml parser uses a convention for executing if{ } conditionals. So the value in the stack just before an if{ } is first converted to integer and then evaluated to determine whether the conditional shall be executed or not.

Then, for example,

1.00 if{ } -> condition executed
45.12 if{ } -> condition executed
-23.93 if{ } -> condition executed

0.45 if{ } -> condition NOT executed
-0.32 if{ } -> condition NOT executed

Tom

 

[rcbarend]

Thanks for the response sofar.
As said, the original code line worked OK.

But I sent this P3Dv4 user a new version of the gauge that contains this code line, now coded as

      (L:VSTOLMode,enum) 4 == if{ 1 } els{ 0 } (>L:ChuteVisible,bool)

No doubt it will work the same, but maybe this gets rid of the "script error" in the log.
I'll let you know the result.

Rob

 

[WarpD]

Why would you not write it this way?

(L:VSTOLMode, enum) 4 == if { 1 (>L:ChuteVisible, bool) } else { 0 (>L:ChuteVisible) }

The way you've written it tends to obfuscate the actual intent and makes things more difficult to review. Since there's zero performance penalty for the way I wrote above, I don't understand why you wouldn't write your code to be as clear and concise as possible. It's not always just you who looks at the code ya know. LOL

 

[Deleted member 1281]

Why would you not write it this way?

(L:VSTOLMode, enum) 4 == if { 1 (>L:ChuteVisible, bool) } else { 0 (>L:ChuteVisible) }

The way you've written it tends to obfuscate the actual intent and makes things more difficult to review. Since there's zero performance penalty for the way I wrote above, I don't understand why you wouldn't write your code to be as clear and concise as possible. It's not always just you who looks at the code ya know. LOL

Because that will get him at least two errors in the error log, and will not work at all.

@Tom, could you re-check this on your setup:

0.45 if{ } -> condition NOT executed
-0.32 if{ } -> condition NOT executed

I find that in both cases the condition IS executed... tested in FSX and P3D v4 using the script

-0.32 if{ 1 (>L:yy,number) } els{ 999.9 (>L:yy,number) }

 

[WarpD]

Because that will get him at least two errors in the error log, and will not work at all.

While I didn't bother to be 100% with the syntax... your response doesn't actually answer the question. I'll ask again...
Why would you not write it this way?

(L:VSTOLMode, enum) 4 == if{ 1 (>L:ChuteVisible, bool) } els{ 0 (>L:ChuteVisible) }

 

[rcbarend]

While I didn't bother to be 100% with the syntax... your response doesn't actually answer the question. I'll ask again...
Why would you not write it this way?

(L:VSTOLMode, enum) 4 == if{ 1 (>L:ChuteVisible, bool) } els{ 0 (>L:ChuteVisible) }

A matter of personal preference, I guess.....
So I don't agree my "style" of coding it is less clear.

Rationale:
The code writes either a 0 or a 1 to the Lvar, so why mention the Lvar name twice ?
Which becomes even more apperant when one uses complex conditions with multiple value possibilities for the Lvar.

But you may disagree ... No problem ...LoL

Cheers, Rob