FSXA Question on XMLTools (Tom)

rcbarend · 22 Sep 2019

Hi Tom,

I'm using XMLTools_v201 in FSX-Accel, and I have a question on XMLEVENTS (v1.1)
Using this code:

XML:

<Update Frequency="1"/>

<Element>
  <Select>
    <Value>
      'b' (>C:XMLKEYS:KeyName,string)
      '10061 (>K:PANEL_ID_TOGGLE)' (>C:XMLKEYS:KeyString,string)
      (L:TrapsEnabled,bool)
      if{ (>C:XMLKEYS:KeyCaptureOn,bool) }
      els{ (>C:XMLKEYS:KeyCaptureOff,bool) }

      (L:TrapsEnabled,bool)
      if{
        'a' (>C:XMLKEYS:KeyName,string)
        '10060 (>K:PANEL_ID_TOGGLE)' (>C:XMLKEYS:KeyString,string)
        (>C:XMLKEYS:KeyCaptureOn,bool)
       }

      'FLAPS_DOWN' (>C:XMLEVENTS:EventName,string)
      '(L:Test10,number) ++ (>L:Test10,number)' (>C:XMLEVENTS:EventString,string)
      1 (>C:XMLEVENTS:CaptureEvents,bool)

    </Value>
  </Select>
</Element>

The first 2 parts (using XMLKEYS) does exactly what I would expect: so intercepts the keystrokes and (conditionally) executes the PANEL_ID_TOGGLE event.
However, the 3rd part (using XMLEVENTS) puzzles me ...

1. When I write either 0 or 1 to C:XMLEVENTS:CaptureEvents , makes no difference. The Event is allways captured.

2. Unlike with a keystroke with XMLKEYS, an event with XMLEVENTS is still seen and executed upon by FSX.
(meaning the event FLAPS_DOWN is not "intercepted" but just "monitored" and increments the L:Test10 var).
I remember we discussed that in the past, but I forgot the conclusion …..
So what I expected it to do: when trapped, the event is NOT executed by FSX. Just the defined code.

Can you shed some light ??

Best regards, Rob

taguilo · 23 Sep 2019

Hi Rob,

XMLEVENTS capture won't prevent the event to be triggered. However, as it is possible to detect the value being passed to the event, it is also possible to trigger another event according to that value.

For example:

Code:

    <Macro Name="e">C:XMLEVENTS</Macro>
  
    <Macro Name="OnEvent">
        '@1' (>@e:EventName,string) '@2' (>@e:EventString,string)
    </Macro>

    <Macro Name="AXIS_RUDDER_SET">
        (L:Load_pilot,enum) 0 ==
        (L:WindowShadeLeft,enum) 0 == and
        if{
             0 (>K:RUDDER_SET)
             quit
           }
        *AXIS_RUDDER_SET sp0
        l0 (>L:RudderDisplay,number)
  
    </Macro>

    <Element>
        <Select>
            <Value>
                (L:EventInitLoad,bool)    
                if{ quit }  
                @OnEvent(AXIS_RUDDER_SET,@AXIS_RUDDER_SET)  
                1 (>L:EventInitLoad,bool)    
            </Value>
        </Select>
    </Element>

In this case, if pilot and shadeleft are both 0, rudder will be physically centered otherwise animation display will follow axis_rudder value processed by the event.

Hope this helps

Tom

rcbarend · 23 Sep 2019

taguilo said:
XMLEVENTS capture won't prevent the event to be triggered. However, as it is possible to detect the value being passed to the event, it is also possible to trigger another event according to that value.

Hi Tom,

Thanks, clear ....
As to the example: that was allready clear with your Throttles example in the documentation.

But if you ever consider an optional update/extension of XMLEVENTS (if even possible):
What I'm looking for is a way to "intercept" (==block) an event under some conditions.
I have several applications for that....

Example (for Flaps):
Suppose I want to (conditionally) block a change in Flaps position, I can do it two ways now:

1. Capture the standard Flaps keys (F5 to F8).
But that isn't "foolproof", since it depends on the actual user Flaps keys/buttons assignments.

2. So what I usually do:
Check for a change in FlapsHandle position (== compare the current position with the one in the previous gauge schedule) and then "correct" the Flaps change with another Flaps command if required.
That allways works, but the disadvantage of this method is, that you visually see a (very short) change in Flapsposition (and/or hear a short Flaps sound).

Hence, I'm still looking for a way (in an XML gauge) to actually (conditionally) prevents an event to trigger the related action in FS.
Simular to capturing a key/button.

Rob

taguilo · 23 Sep 2019

rcbarend said:
That allways works, but the disadvantage of this method is, that you visually see a (very short) change in Flapsposition (and/or hear a short Flaps sound).

Here you have an example of how to control flaps without those unwanted effects:

Code:

    <Macro Name="FLAPS_INCR">
        (L:FlapsByUSer,bool)
        if{
            0 (>L:FlapsByUSer,bool)
          }
        els{
             (L:Electrical Main Bus Voltage,Volts) 10 &lt;
             if{
                  1 (>L:FlapsByUSer,bool) (>K:FLAPS_DECR)
                }
           }
    </Macro>
   
    <Macro Name="FLAPS_DECR">
        (L:FlapsByUSer,bool)
        if{
            0 (>L:FlapsByUSer,bool)
          }
        els{
             (L:Electrical Main Bus Voltage,Volts) 10 &lt;
             if{
                  1 (>L:FlapsByUSer,bool) (>K:FLAPS_INCR)
                }
           }
    </Macro>

   
    <Macro Name="FLAPS_UP">
         (L:FlapsHandleIndex,enum) 0 >
         if{                
             (L:FlapsHandPerPrev,percent) 163.83 * (>K:FLAPS_SET)   
            }
    </Macro>

    <Macro Name="FLAPS_DOWN">
         (L:FlapsHandleIndex,enum) 6 &lt;
         if{
              (L:FlapsHandPerPrev,percent) 163.83 * (>K:FLAPS_SET)
                2 (>L:FlapDirectionLever,bool)
            }
    </Macro>

    <Macro Name="FLAPS_4">
         (L:FlapsHandleIndex,enum) 6 &lt;
         if{
              (L:FlapsHandPerPrev,percent) 163.83 * (>K:FLAPS_SET)
                2 (>L:FlapDirectionLever,bool)
            }
    </Macro>

    <Macro Name="FLAPS_SET">
        (L:FlapsByUSer,bool)
        if{
            0 (>L:FlapsByUSer,bool)
            (A:FLAPS HANDLE PERCENT,percent) (>L:FlapsHandPerPrev,percent)   
          }
    </Macro>

    <Element>
        <Select>
            <Value>
                (L:EventInitLoad,bool)     
                if{ quit }   
                @OnEvent(FLAPS_INCR,@FLAPS_INCR)
                @OnEvent(FLAPS_DECR,@FLAPS_DECR)
                @OnEvent(FLAPS_UP,@FLAPS_UP)
                @OnEvent(FLAPS_DOWN,@FLAPS_DOWN)
                @OnEvent(FLAPS_4,@FLAPS_4)
                @OnEvent(FLAPS_SET,@FLAPS_SET)
                1 (>L:EventInitLoad,bool)     
            </Value>
        </Select>
    </Element>

I believe you will figure out how it works

Tom

rcbarend · 24 Sep 2019

Hi Tom,

Yes, after some further experiments, I surely understand now (I hope)….LoL.
And with that, the current working of XMLEVENTS is good enough for me.

If other people are interrested, I'll explain the differences (Tom, please correct me if I'm wrong).

I will use an example, stripped to the bone.
In this example, I want to force the Flaps fully UP when a FlapsDown event is detected.
NOTE: the three methods below do not functionally work exactly the same, but they explain the timing !!!
Hence, I use a gauge schedule time of 1 sec, to make it more clear.

Method-1:

XML:

<Update Frequency="1"/>
<Element>
  <Select>
    <Value>
      (A:FLAPS HANDLE INDEX,enum) 0 !=
      if{ (>K:FLAPS_UP) }
    </Value>
  </Select>
</Element>

Advantage: as simple as it gets (and will also force the Flaps UP if Flaps are extended to any other position).
Disadvantage: there is a Flaps correction delay anywhere between 55 and 1000 msec.

Method-2:

XML:

<Update Frequency="1"/>
<Keys>
  <On Event="FLAPS_DOWN">
    (>K:FLAPS_UP)
  </On>
</Keys>

Advantage: I can't think of any, other then it only corrects the FLAPS_DOWN event.
Disadvantages:
- The code will only work when included in a gauge that is defined in a view/window that is currently Active.
- There is a Flaps correction delay anywhere between 55 and 1000 msec.

Method-3 (using XMLEVENTS):

XML:

<Update Frequency="1"/>
<Element>
  <Select>
    <Value>
       'FLAPS_DOWN' (>C:XMLEVENTS:EventName,string)
       '(>K:FLAPS_UP)' (>C:XMLEVENTS:EventString,string)
    </Value>
  </Select>
</Element>

Advantages:
- The Flaps are corrected at Framerate instead of the (min) 55 msec XML gauge schedule time, so there's no visible/audible side-effect of "correcting" the Flaps position.
Because the event capture, and correction script line (>K:FLAPS_UP), is executed at each frame.
- The code will work in any Active view/window
Disadvantage: None.

So I'll know what I'll be using in future designs ….LoL
Thanks again Tom, for such a great addon that makes my life (as a simple XML gauge designer) a lot easier.....

Cheers, Rob

taguilo · 24 Sep 2019

Hi Rob,

You pretty much got it.

However, an important observation: when you issue

'FLAPS_DOWN' (>C:XMLEVENTS:EventName,string)
'(>K:FLAPS_UP)' (>C:XMLEVENTS:EventString,string)

you are actually storing a script to execute every time FLAPS DOWN event is triggered; unless you want to change that script regularly (which is not recommended), you don't need to update both commands on every gauge cycle; it may be done once in a dedicated <Element>, like in the example I provided above:

(L:EventInitLoad,bool)
if{ quit }
....Store event scripts....
1 (>L:EventInitLoad,bool)

Tom

rcbarend · 24 Sep 2019

taguilo said:
you are actually storing a script to execute every time FLAPS DOWN event is triggered; unless you want to change that script regularly (which is not recommended), you don't need to update both commands on every gauge cycle;

Hi Tom,

Yes, that was clear too.
I just stripped the code to the bare minimum, to explain the differences in execution response time and view independancy, to "undo" a user-given event.

I just have a final question on the var (C:XMLEVENTS:CaptureEvents,bool)
The documentation suggests that
0 (>C:XMLEVENTS:CaptureEvents,bool)
stops all defined capturing, while
1 (>C:XMLEVENTS:CaptureEvents,bool)
starts all defined capturing again.
But no matter if I write 0 or 1 , the events are allways captured.
So I'm puzzled what the var actually does.

By the way:
(>C:XMLEVENTS:ClearEvents,number) does work, so I could use that to stop capturing; and start capturing again, by writing the event scripts again. That does work (tested it)

Rob