Bert Laverman

There was mention earlier of using decimal. Haven't done it myself yet, but will try. Maybe @BenBaron can provide a definite answer? Is it ">K:66106", ">K:#66106", or even just "#66106"? Bert

This is the big Flaps switch right? press and release? The switches show only a press, because the "button" is "held", but this is a toggle, so you get a press and release. Test: If you push the Flaps toggle and hold it, do you still get 2 events?

This is about the fact that, in the JSON file, "PressEvent" and "ReleaseEvent" are arrays. I was asking if that indicates there will be multiple entries in a future version of the tool, as it makes more complex logic possible. So, currently we have (are supposed to have): Process each Condition, and process each Condition's Variable area if that single Condition evaluates to true. Combine all individual conditions' results using the (to be added) ConditionLogic, and process all Variables if this results in true. If I have multiple "PressEvent" or "ReleaseEvent"

I understand, it's just that there were too many things unclear in the UI, and the JSON file seemed to unlock more/easier options. Ok, I thought the visual feedback was useful, especially if you are changing switches or knobs outside of the current view, but the reasons for adding the "X_" and "_X" around the text is still unclear to me. It just indicates one or more of the conditions did not match? That does not mean a problem, right? Ok, makes sense. So, questions left over: If I have both "Variables" and "Conditions", what is the ordering? F

Going back to the PMDG 737 NGXu SDK, I see they actually provide for three different ways to send events: Use SimConnect_SetClientData(), which uses the Event ID and the value of the field. Use SimConnect_TransmitClientEvent() with a locally bound id for the Event and the value of the field. Use SimConnect_TransmitClientEvent() with a locally bound id for the Event and the mouse-click values. Given that I see the standard profiles use either mouse clicks or values, I am assuming you use SimConnect_TransmitClientEvent() with whatever is passed in the Lvar. But why use

Nope, retract that. The start selectors are defined as "number" Lvars, while I followed the SDK (which uses "unsigned char") and made them "char". The Flight Director switches had a typo on my side. Actually, I used: $ strings PMDG_Translator.dll | grep AS_PMDG >PMDG_Translator-Lvars.txt $ and now I have a full list of all Lvars...

Another note: The PMDG translator appears to use an older version of the SDK. It doesn't know several fields.

Gérard, AFAIK the "INT" variables are local state for the Honeycomb Bridge, and can be created at will. The "INT:REV_0, bool" and "INT:REV_1, bool" are used to store the current state of the reversers, so you can use these in other buttons' conditions. Cheers, Bert

Additionally, I started redoing the lights, because the entries for the BCN AND land switch didn't work in the official KLM 737-800 BW. First, the current profile uses values 0 and 1 on "L:AS_PMDG_737NGX_EVT_OH_LIGHTS_ANT_COL", which doesn't work. They should be left-clicks, and (because left-click goes both ways for this switch) dependent on the current state. For button 20 (BCN On): { "DE": "", "EN": "", "FR": "", "ES": "", "Variable": "L:AS_PMDG_737NG

Ok, retested this. The language at top-level does indeed control which text fields gets selected, and the bridge will display it. Still, there is no way to enter these texts in the configurator. Also, only the text in the Event record is shown.

I'm trying to understand the format of the JSON file used to configure the mappings. Top-level, I have no big problems with "SaveName", "Version", "Data", "LEDs", and "ConfiguratorSettings". However, a little issue with "SaveName" is that, if it does not match the filename when stored in "honeycomb_profiles", it will be listed in the "Load Profile" list, but it cannot be selected and loaded. The "Language" field, what effect does it have? It is set to "DE" by default, but I see no way to change this. The UI language is set in the Settings dialog, but that is "English". Sti

Ok, here is me version of the PMDG profile for the Alpha. Alpha - PMDG NGXu.json

Better still, the axes now work both with and without FSUIPC. The only mystery I have left is that I made my own version of the PMDG NGXu profile for the Alpha, where I added bindings for switching views, only to find that after I activate them, buttons appear switched. My current profile, when loaded in the configurator, has: Button "Elev Trim A UP" set to "K:NEXT_VIEW" Button "Elev Trim A DN" set to "K:PREV_VIEW" Button "Elev Trim B UP" set to "K:ELEV_TRIM_UP" Button "Elev Trim B DN" set to "K:ELEV_TRIM_DN" Button "Aileron Trim Left" se

In FSUIPC, throttle calibration, you must use the "Set" button for processing because of the reversed axis, but then you must also check "No reverse zone" in the top-left. With that it should work!

Ok, update: I think the Bravo has very specific calibration requirements, so the re-install/upgrade of Prepar3D could probably have been reduced to removing the controls ("C:\Users\<username>\AppData\Roaming\Lockheed Marting\Prepar3D v4\Controls\Standard.xml") and calibration files. ("C:\Users\<username>\AppData\Local\Lockheed Marting\Prepar3D v4\Controls\Calibration.xml") Next step is to re-enable FSUIPC and see if the freshly calibrated axes will work as required. Bert