P3D v4 Setting L:vars in an Update section

[Harmless]

Hi, first time poster here, just getting started with XML gauges and hoping this isn't a stupid question...

I've successfully created a couple of simple XML gauges that use an Update section to define some L:var values. But in commencing a new gauge, I can't seem to get to first base even though I'm following the same structure.

Following is some test code that should display a white "20" on the image which is an almost-black rectangle. But it doesn't work and I don't know why. I've got GaugeDevDebug turned on, it doesn't report any errors when the gauge is loaded.

<SimBase.Document>
    <SimGauge.Gauge id="DG Radio">

        <Update>
            <Script>
                20 (&gt;L:FRED,number)
            </Script>
        </Update>

        <Image name="DG Radio back.bmp"/>
        <Size>300,150</Size>

        <Element id="Label">
            <FloatPosition>100,100</FloatPosition>
            <GaugeText>
                <Size>30,30</Size>
                <GaugeString>%((L:FRED,number))</GaugeString>
                <FontColor>0xFFFFFF</FontColor>
                <FontFace>Consolas</FontFace>
                <FontHeight>14</FontHeight>
                <HorizontalAlign>Center</HorizontalAlign>
                <Bright>True</Bright>
            </GaugeText>
        </Element>

    </SimGauge.Gauge>
</SimBase.Document>

All that's displayed is the image (almost-black rectangle).
It works if I replace <GaugeString>%((L:FRED,number))</GaugeString> with <GaugeString>20</GaugeString>.

- Is there an error in my code?
- Is the Element being drawn before the Update section is processed?

Thanks,
David

 

[COBS]

Hi David

Firstly , you are using " FSX syntax " but it appears that you are not adhering to the correct 'tag' structure ,
eg ;
<Update> vs <Update id="Update">
I suspect that your update is not being read .

You will find plenty of FSX syntax examples contained in the Boeing 737-800 Cab , unzip that to a folder and refer to the examples
to get the correct syntax structure , if you deviate from the correct syntax structure you are inviting problems .

Some examples

Example #1

<SimBase.Document Type="AceXML" version="2,0_Karol_Chlebowski_DEC_2009" id="PIGRADAR">
  <Descr>AceXML Document</Descr>
  <Filename>PIG_RDR.xml</Filename>
- <SimGauge.Gauge id="Gauge" ArtDirectory=".">
  <FloatPosition>0.000,0.000</FloatPosition>
  <Size>456,410</Size>
- <Image id="DAT77_backgrnd.bmp" Name="DAT77_backgrnd.bmp">
  <Transparent>True</Transparent>
  <Bright>False</Bright>
  </Image>
        <Update id="Update">
            <Script>
               20 (&gt;L:FRED,number)
            </Script>                  
        </Update>

Example #2

                    <Element id="AirSpeed">
                        <FloatPosition>280.000,5.000</FloatPosition>
                        <GaugeText id="AirSpeed_ Readout">
                            <Bright>True</Bright>
                            <FontColor>0xDACEDE</FontColor>
                            <FontFace>Arial</FontFace>
                            <FontHeight>16</FontHeight>
                            <GaugeString>%((A:GPS GROUND SPEED, knots)  ) %!4d!%</GaugeString>
                            <Size>40,35</Size>
                            <Transparent>True</Transparent>
                        </GaugeText>
                    </Element>

Example #3

                <Element id="LEG_Data">
                    <FloatPosition>0.000,42.000</FloatPosition>
                    <GaugeText id="Fltpln_NIL">
                        <BackgroundColorScript>0x000000</BackgroundColorScript>
                        <FontColorScript>0xDACEDE</FontColorScript>
                        <FontFace>Tahoma</FontFace>
                        <FontHeight>16</FontHeight>
                        <Tabs>0L,40L</Tabs>
                        <GaugeString>\n\n\n\t%NO%
                                \n\n\n\t%FLIGHT  PLAN%
                                \n\n\n\t%LOADED                          
                        %</GaugeString>      
                        <Length>350</Length>
                        <Size>350,270</Size>
                        <Bright>True</Bright>
                    </GaugeText>
                </Element>

Cheers
Karol

 

[Harmless]

Thanks Karol,

In going through your examples I found my error... I'd missed out the %!d! format in <GaugeString>. I know the syntax but didn't see I'd missed it, which is annoying.

I'm new to XML and I find it very verbose so I experimented to find out which attributes are mandatory or optional. Eg, only using the id=" " attribute when it's helpful, not on every tag that accepts it.
When I insert the %!d! my "minimalist" code in the original post, it works. But I take your point, I need to be careful about cutting corners.

David

 

[tgibson]

If you are new to XML, might I suggest you look at FS9 format for your simple gauges? Except for a very few vector (?) drawing operations, it can do almost everything that FSX syntax can do, with a lot less typing. I would guess that 90% of XML gauge developers use FS9 format for most of their gauges.

 

[Harmless]

That's interesting. Because I'm starting out, I my instinct was to learn the current XML format. Are there any concerns about missing out on enhancements to the language?

 

[COBS]

Hi David

I agree with Tom's suggestion above about FS9 format (syntax) , it's more compact and less verbose .
Go to to the fs2x website , click Tutorials , and download the 4 tutorials , keep them as a reference resource .

Cheers
Karol

 

[Vitus]

Hi Harmless,

I think I have to disagree with Karol's approach. I think it's good practice to use the more modern standard. I'm not quite sure what's wrong with your code, it might be that you are not using the right header. Here's an example of the FSX-style header I use, that works well:

<?xml version="1.0" encoding="UTF-8"?>

<SimBase.Document Type="XML" version="1,0" id="book1_page1">
  <Descr>XML Document</Descr>
  <Filename>page1.xml</Filename>
  <SimGauge.Gauge id="page1">
    <FloatPosition>0.000,0.000</FloatPosition>
    <Size>736,503</Size>

    <UPDATE>
      <Script>
        (L:PAYLOAD UNITS,enum) 0 ==
        if{
          1.0000 (&gt;L:PAYLOAD UNIT WEIGHT FACTOR,number)
        }
        els{
          2.20462 (&gt;L:PAYLOAD UNIT WEIGHT FACTOR,number)
        }
      </Script>
    </UPDATE>

And here's an example of a properly integrated gaugeString:

        <Element id="wnb_pilot_weight">
          <FloatPosition>0.000,14.000</FloatPosition>
          <GaugeText id="GaugeText">
            <FontColor>darkblue</FontColor>
            <Alpha>True</Alpha>
            <FontFace>Comic Sans MS</FontFace>
            <FontHeight>11</FontHeight>
            <GaugeString>\{itl}%((A:PAYLOAD STATION WEIGHT:1,kg) (L:PAYLOAD UNIT WEIGHT FACTOR,number) * )%!1.0f %((L:PAYLOAD UNITS,enum) 0 == )%{if} kg %{else} lbs %{end}</GaugeString>
            <HorizontalAlign>RIGHT</HorizontalAlign>
            <Size>150,80</Size>
            <Transparent>True</Transparent>
          </GaugeText>
        </Element>

I hope it helps. (Yes, shoot me for using comic sans!)

Cheers,
Vitus

 

[Harmless]

Thanks Vitus,

You've missed my reply to Karol (post #3), the error was omitting the string format component in <GaugeString>, eg, %!d!. I know the syntax, but I stared at the code for ages without spotting the omission! My original post was a stupid question after all.

I've now re-instated the attributes and sub-tags in the <SimBase.Document> tag, as per yours and Karol's suggestion. But note that my code (post #1) does in fact work when I put the %!d! in, ie, in this case the problem wasn't caused by omitting header data.

Still thinking about the schemas... I like the idea of using the current FSX schema, but almost all the help on this forum and others sites is in FS9.

Comic Sans on a gauge?? Ugh!

David

 

[Vitus]

Oh sorry. Looks like I only read the topic half-arsed.
I honestly don't understand why so many are still hell-bend over the fs9 code. Granted, it takes some time to get used to the "new" scheme. But come on! FSX is 11 years old! It's funny that there's still so little support in terms of tutorials and examples.

Maybe some of you could enlighten me why that is? Are there things that don't work with FSX syntax?

oh yeah... comic sans. Well... I DO feel embarrassed about it. But maybe it makes you feel better to know that I'm only displaying numbers using that font?

 

[chris]

FS9 syntax works with a lot less verbosity.
Why go with the FSX syntax for no gain (apart from the one thing that FSX can do that FS9 can't - I forget what it is (shows how important it is)).

 

[MIL-STD]

Hello all,

I don't want to drag this o/t, but a thought or two re: schemas.

For what it's worth, as far as I understand the sole benefit of the FSX schema is certain abilities relating to the drawing of dynamic arcs. Although it is indeed good practice (institutional context depending etc.) to focus on the latest programming standard, I think an exception can be made for XML in the MS/LM simulator series, given that it is highly specialised, and limited solely to these platforms.

Having worked with the earlier XML schema since 2003, I've found that essentially anything else is quite achievable using it, with far less code, and, as you note, it is much better documented (in terms of serious developmental effort and resulting code snippets). Indeed, not that this makes any difference, but I do recall reading somewhere a long time ago that, when it was first developed, the FSX schema was originally never intended for gauge work, hence the verbosity (though this could be very wrong). I do not so much think it's a case of people being 'hell bent' on sticking with an older schema, out of some wilful stubbornness, it's just that - in my experience - it's far more compact, and easier to debug. I do recall it handles text formatting better too, in certain cases.

The fact that it worked as well in FS9/FSX during the 'crossover' period, most definitely helped keep it going with payware developers, and the fact it continues to function in P3D (I can't speak for Dovetail's efforts) is a further incentive to avoid reinventing the wheel. That said, if I was starting over today, I'd probably throw my lot in with C languages, as the learning could be useful outside FS.

In terms of supportability, XML code I wrote originally for FS02, before porting over to FS9/FSX, is still working without issue in the latest version of P3D. Given this longevity, I would think it's more likely the XML standard would be deprecated entirely in future, than for the FSX schema to be given priority. Even then, for me, it's not proven very difficult to convert FS9 to FSX, as the challenge of gauge coding is in the formulae and scripting logic, than the actual structure.

Anyway, this is merely my own view, so by all means go ahead and explore the FSX schema - it's not going anywhere, there are indeed people using it quite happily, and we have the benefit of multiple approaches (though you might need to get familiar with at least some of the FS9 basics, to make effective use of the existing tutorial code out there).

 

[Vitus]

Hey guys,
thanks for the clarification. It's interesting to hear your perspective.
I used the FSX scheme right from the start and never really thought about it. It took me some time to understand that the FS9 XML tutorials won't work for me, but once you got a gauge set up it's pretty much a matter of copy & paste for me.

 

[MIL-STD]

That much is very true - once the pain of development is done, and you have old code to re-use, life is a lot easier, whatever one's native language!

 

[COBS]

.......... but I stared at the code for ages without spotting the omission! My original post was a stupid question after all.
David

David , the point is that you missed it , and I missed it as well , there is never a 'stupid question' , we work in isolation and small errors or omissions will occur
from time to time whether you are new to xml or an old hand , and often it is the case that those errors are difficult to find without help at forums .
As you can see from this thread , not only is the error resolved , but also a discussion of ideas ensues , and that alone is very important .

I couldn't count the number of times that tossing ideas about and the resultant discussions has helped me come to terms with complex concepts and the
coding of several instruments , without the help here I would never have achieved some of my instruments .

Cheers
Karol

 

[MIL-STD]

I would simply like to second Karol's post above - there is absolutely no such thing as a stupid question. Out of a desire to work out the problems for myself, I refused to ask for help in forums for many years, and, although I did it, I spent far more time than necessary over what were often simple, small errors. To ask would have given me precious time to do better things, and could have helped me come to grips with certain possibilities a lot earlier!

 

[n4gix]

Rather than regurgitate all of the excellent pros and cons of the Great FSX Schema versus FS9 Schema, I'd simply bring to the discussion one salient point, which in the fullness of time will likely end the debate once and for all...

That point being that FSW from DTG only supports the FSX Schema. So anyone who wishes to release freeware or payware that will work in FSX, P3Dv4, and FSW will have no choice but to switch to the more verbose XML paradigm. Darn it!

 

[EduHir]

Bill,
but in P3Dv4 does the FS9 schema work properly???

Edi

 

[n4gix]

Yes, so far at least. I've not found anything that's failed to work as scripted.

 

[Harmless]

Thanks for all the suggestions and supportive comments, it's very helpful.
David

 

[taguilo]

I believe FSX schema had two reasons to exist:

- To be used together with the ACE editor tool, for which the FS9 schema, with inline parameters, wouldn't fit propely.
- To allow binary compile, in .spb format, of XML parameters (NOT scripts) in order to protect gauges from unwanted replication.

Tom