MSFS20 Event management

[eric_marciano]

I am building an alternative PFD for the Asobo A320 Neo in JavaScript, for training purpose. It works quite well but I still have questions about the interaction between the virtual cockpit and the instrument code in JS.
I found out some interactions works through local variables (L:vars) but I am more interested in the events. For example, my PFD receives an event named "BTN_LS" through the "onEvent" function when the LS button is pressed in the VC. This is perfect, I receive hte event and can take the necessary action. In that case, I toggle the LS display in my PFD.
The problem is that I don't understand why my PFD receives this event. My PFD class replaces the existing PFD, so the class name is A320_Neo_PFD, which extends the BaseAirliners class. I don't see any code that subscribes to the "BTN_LS" event.
For testing purpose, I created another instrument with my own class name, not replacing an existing one, which also extends BaseAirliners and it receives no event at all.

I guess the PFD is configured to receive this event, but how? Where?
I would also like to know where this event is triggered. I looked into the model behavior files and all other files and couldn't find the way it was triggered to be received by my PFD.

Any information is welcome.

Thanks,
Eric

 

[B21-soaring]

Here's some clues & apologize if everything below is obvious and your question is much more about the specifics of unpicking the class hierarchy that gets you from BaseAirliners to BaseInstrument. I'm writing a 'PFD-like' gauge but I've worked my way backwards through the asobo-instruments-navsystems code so that I can use the 'component' classes (particularly MapInstrument) in my own custom instrument subbed from BaseInstrument.

Are you aware of the new HTML/JS custom events in the model/<aircraft>.xml file?

e.g. <Code>(&gt;H:lx_s100_mc_up)</Code> will send the custom event lx_s100_mc_up to *all* your gauges.

The BaseInstrument class (the parent of all Asobo instrument sub-classes) has a method (that you typically override) onInteractionEvent e.g.

    // **********************************************
    // Receive model/AS-33.xml click events
    // **********************************************

    onInteractionEvent(_args) {
        if (! this.ELECTRICAL_MASTER_BATTERY) {
            return;
        }
        if (_args[0] == "lx_s100_mc_up") {
                this.mc_knob_delta = 1;
                this.update_maccready();
                return;
        }
    }

Within the class hierarchy you're using, I think it's likely some BaseInstrument onInteractionEvent() method is calling the onEvent method of its child objects and to understand what its doing you'd need to follow that logic though by the tried-and-tested way of wading through the Asobo code for days on end . I have seen a similar concept that the Update() method of BaseInstrument actually eventually calls onUpdate(_deltatime) in some instrument sub-classes.

I think the availability of this new event support is possibly the reason the SDK refers to the 'KEY_THROTTLE_INCR' etc as "Legacy Event IDs" but can't be sure...

Also be aware the 'touch' events for flat screen devices (probably not the PFD you're working on) are creating entirely within the HTML/JS using javascript element.onClick = my_callback; standard functionality.

Here's a free tip that was extremely difficult (for me) to work out - pieces of the PFD code are hard-coded to display at 1000x1000px. E.g. you may have a Bing map, but the road network is an SVG overlay, and you may want content of your own that you layer over other content also. The trick is to render the Asobo content into a 1000x1000 div and use a CSS transform to scale/translate/rotate that as you need. In my case my gauge is 'portrait' (it's in a glider), I overlay a custom representation of the 'task' (route), and so needs to zoom/rotate these layers in sync. Basically you need the square 1000x1000 area of the Asobo content to be big enough that it covers your display area regardless of rotation.

Obviously it's lot easier to start with something from asobo-vcockpits-navsystems (e.g. AS1000), get it working on your panel, build a custom surround, copy as many of the Asobo source files as you want to mess with, and chop it about from there - right or wrong I've done the reverse of that and built up a new instrument from BaseInstrument and used elements from asobo-vcockpits-instruments e.g. MapInstrument and SvgMap

 

[eric_marciano]

I thank you for this information. The first part of your answer is exactly what I am looking for: understand the logic behind an event generated by a VC interaction.
As I play with the Asobo A320, I obviously looked into the A320_NEO.xml file located in the model subfolder. I understand what you wrote about the event generation, but I couldn't find any occurrence of the kind of code in this XML. I couldn't even find anything similar...
When I press the LS button to show/hide ILS information on the PFD (see image below), a "BTN_LS" event is generated and my PFD catches it. It works perfect, nevertheless I couldn't find how this event is generated, the A320_NEO.xml file didn't help.

On this same image, you can see the 2 three-way switches that lets you select ADF/OFF/VOR mode for the Navigation Display. Any action on this switches doesn't generate any event, even if I would like to.
This is what I don't understand. How events are generated and why does it work for the LS button and not for the 3-way selectors? Still a mystery for me...

I also thank you for the second part of your answer but it is not relevant in my case. This is because I don't use SVG, I use a canvas instead. I create a canvas with the size of the instrument (1280 by 1280 for the PFD) and I draw everything in it using the Javascript drawing primitives, exactly like I used to do in GDI+ with fs9/FSX/P3D. It works perfect and it is fast. I don't use any part of the existing PFD, I do it all by my code.
My only problem now is to integrate it properly with the aircraft VC.

 

[eric_marciano]

Quick correction to my answer: I found interesting information in Airbus.xml (located in fs-base-aircraft-common\ModelBehaviorDefs\Asobo\Airliner), especially this part:

<Component ID="#NODE_ID#" Node="#NODE_ID#">
<UseTemplate Name="ASOBO_GT_Push_Button">
<LEFT_SINGLE_CODE>
(L:XMLVAR_TRK_FPA_MODE_ACTIVE) ! (&gt;L:XMLVAR_TRK_FPA_MODE_ACTIVE)
(&gt;H:A320_Neo_CDU_AP_TRK_FPA)
</LEFT_SINGLE_CODE><!-- TODO -->
</UseTemplate>
</Component>

This is exactly what you were describing: the A320_Neo_CDU_AP_TRK_FPA custom event should be sent to all gauges. I guess it is sent when the TKA_FPA button is pressed on the CDU. The problem is that I never get this event in my gauges, never received through the onEvent function of any of my instrument class. Where did I go wrong?

 

[B21-soaring]

Ah - sorry I didn't understand your approach completely. Here's what I would do:

(1) use the in-game SDK Window -> 'ModelBehaviours' , select the Local Vars (?) tab and watch the L:XMLVAR_TRK_FPA_MODE_ACTIVE variable to see if it's toggling when you click the button in the VC. That'll be a clue whether the XML code is firing at all. If it does, I'd inject some extra code to toggle another var to double check.

(2) Work through the ALL the XML templates between the model/<aircraft.xml> and the base level code - it's tedious but then I'd know exactly what few lines of XML the original declaration turns into, for clues. Personally I use Windows "GIT Bash" and the "grep -r" command to find references in the asobo-xxx modules - it's pretty quick.

(3) Work backwards through JS Class BaseAirliner until you reach BaseInstrument (I reckon it will be only a couple of jumps), to see what happens to mangle the onInteractionEvent into onEvent.

 

[eric_marciano]

(1) Thanks again, you helped me find the local var that is updated when these switches are used, it is XMLVAR_NAV_AID_SWITCH_L1_State and 3 other similar ones.
Now I understand the status of these switches is managed through local variables and not through events. I also found the XMLVAR_TRK_FPA_MODE_ACTIVE variable as you explained and it is updated as expected when I press the button in the VC. Nevertheless, as far as I remember I have never been successful in reading these L: variables. I tried to read throttle position with SimVar.GetSimVarValue("L:XMLVAR_Throttle1Position", "number") and it didn't work, I need to test again.

(2) I use the findstr command in a command prompt window, very similar to grep, but I will have a look at GIT Bash, thanks for the info.

(3) I already dug into the BaseAirliner code several times, but it is so hard to read... The JS code is long and not clear, with many jumps because of class inheritance, and I know I will have to do it again. I regret Asobo didn't write a good SDK for us, it would be so much better than this guess game...

Thanks again for your help.

[EDIT] I could read the XMLVAR_NAV_AID_SWITCH_L1_State local var, no problem. My PFD and ND will look better

 

[B21-soaring]

sounds like you're in good shape... my advice if you share L:var booleans between XML and JS is use SimVar.GetSimVarValue("L:var","bool") ? true:false;