<String> element and <Visible> tag issues in FSX

[taguilo]

Hi,

Navigating through the forum I came across this thread:

http://www.fsdeveloper.com/forum/showthread.php?t=174646

and also found more comments scattered in other threads as well.

Well, this is an "issue" (elegant synonymous of bug) in FSX, related to the way <String> element's scripts are stored into the element's display buffer. This affects both <Text> and <FormattedText> string types.
I'm not good at tech explanations, but I'll do my best to be understood:

This happens with a string element that is a direct child of a gauge; when it is created (at gauge's init, or by a panel/gauge redraw of any kind), if it has a <Visible> condition that is false at the first evaluation, the content of the script is not passed to the element's display buffer. Despite this, the script is indeed evaluated and its result saved in a "script buffer". When the next cycle comes, the script result is reevaluated and compared to what is currently in its "buffer"; if both are different the new result is transfered to the display buffer, otherwise nothing happens and the display buffer maintains its current data.When a <Visible> conditional is set to true, whatever is in the display buffer is made "visible" (transfered to the visible screen) BUT, as the display buffer is empty, nothing is shown. However, as soon as a new script result is at least one bit different from the previous, the display buffer is updated and, if <Visible>, transfered to the screen.
Naturally there's a simple way to overcome this "issue": to place the <String> element as a child (inside) of another element which is the one that contains the <Visible> tag:

For example, instead of this:

[FONT="Courier New"]<Gauge Name=...etc>

<Element> 
  <Position, etc>
  <Visible>Bool</Visible>
  <Text> or <Formattedtext>
   <String>...
[/FONT]

Write this

[FONT="Courier New"]<Gauge Name=...etc>

<Element> 
  <Position, etc>
  <Visible>Bool</Visible>
  <Element>
    <Position, etc>	
    <Text> or <Formattedtext>
      <String>...[/FONT]

When the parent element visibility comes to true, forces all its child elements to update their display buffers.

Hope it wasn't much

Tom

 

[tgibson]

Thanks for that workaround. I instead converted my Notepad gauges to Formatted Text, which does not need a Visible statement. While more work, it resulted in code that is much easier to read and I also took the opportunity to add some nice touches. But I will keep it in mind for future gauges.

BTW, another FSX bug that just bit me is that the Fuel Density variable (that uses pounds per gallon in FS9) does not work in FSX unless the units are instead in pounds. Thus you cannot use that variable in a gauge designed for both FS9 and FSX. Ugh...

Thanks again,

 

[taguilo]

... I instead converted my Notepad gauges to Formatted Text, which does not need a Visible statement.

Actually FormattedText is also affected but, as long as you could manage the conditional within the string script and not use a <Visible> tag, you're right and problem is gone. Unfortunately, there are situations in where two strings share the same display area and are very different is structure as to make the filter in their scripts; in these cases a <Visible> tag is unavoidable and the workaround solution comes pretty handy.

Tom

 

[teson1]

Tom,
thanks a LOT for this solution (not workaround) to the fs "issue" !
It would have saved me a lot of work if I'd known this earlier, but I sure will archive it at a preferred place.
Great info and explanation. Thanks again!

 

[chris]

Working on a panel in the usual manner. SDK open, multiple emacs windows open and FSX in windowed mode. Everything works, CAB it up and go for a 'real' flight in full screen mode.
Visible tags are broken! No display if the readout doesn't change. Back to FSX windowed - all is fine, full screen - broken. Much head banging until I found this thread.
Thanks a lot Tom, elements within elements fixed the problem.

 

[n4gix]

Well, this technique also serves to point out that quite frequently it occurs that there are more than one <Element> sections that will use the same <Visibility> condition...

...so it only makes good organizational sense to group all of them under one "Parent <Visibility>" section.