Jump to content

Bert Laverman

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Bert Laverman

  1. Ok, here's what I did: Download your file and rename it to something that does not clash with my current profiles, I used "Test - PMDG_NGX(u)_Yoke.json". Open the file with Notepad++, but any text editor will do. At the top, update the name in "SaveName" to exactly match the name of the file, excluding the ".json" extension: { "Version": 1, "Language": "DE", "SaveName": "Test - PMDG_NGX(u)_Yoke", "Data": [ Start the configurator and import the profile, using "Actions" -> "Open Settings" -> "Import Profiles" -> "Select File". After selec
  2. Ok, that is an important clue: The apps are very sensitive to the syntax of the file. Can you share it?
  3. Jason, I have noticed similar behavior at times, and generally had luck with a middle-click (Open in new tab) in Chrome. To ensure you draw attention from the Aerosoft team, who are responsible for the site, please ask questions in a topic with the title describing the issue. This topic discusses the PMDG profiles themselves, not the download site. Cheers, Bert
  4. Ok, that is strange, because they are quite common. In fact, the Aerosoft provided profile uses them. Have you entered them using the configurator or manually in the JSON file? If the latter, will you share one of the entries? Also, when Prepar3D is running and you open the addon dialog, does it show both the Honeycomb bridge and the PMDG translator? Bert
  5. Juergen, can you tell me which PMDG L-Vars are not working? Also, just to add to the list of "standard" checks: is "EnableDataBroadcast" set to 1 in the "737NGXu_Options.ini" file? Cheers, Bert
  6. Scott, As an argument against: Prepar3D does not support profiles, so if you fly with different aircraft you'll be unable to easily change the assignments, and the LEDs in the Bravo will not work. However, if you want to really do this, you have several options: To keep the LEDs working, simply remove all assignments. The "lightest" change, so it becomes a temporary test, is to manually change the "add-on.xml" file in the installation directory of the configurator. You can just rename the file, or put a "<!--" at the start of line 3 (in front of the first "&l
  7. Ooooh! That picture! Isn't that when they pulled the cooler off of a 1GHz Athlon and compared it to what happens with a Pentium? (of that time) I remember that. The Athlon smoked itself into oblivion, while the Pentium throttled back and played Doom (at a horribly slow rate) and survived... Oh man, that brings me back... Bert
  8. 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
  9. 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?
  10. 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"
  11. 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
  12. 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
  13. 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...
  14. Another note: The PMDG translator appears to use an older version of the SDK. It doesn't know several fields.
  15. 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
  16. 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
  17. 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.
  18. 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
  19. Ok, here is me version of the PMDG profile for the Alpha. Alpha - PMDG NGXu.json
  20. 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
  21. 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!
  22. 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
  23. Oddly enough, only the throttles. I am currently doing the next sensible thing, aka "the morning after pill": Downloaded the latest point-release of Prepar3D 4.5 ( and upgrading it. Also (backed up and) deleted Prepar3D.cfg and all Controls files. Doing the upgrade in the component-by-component style: first uninstalled the Client and installed the latest. (with the removals mentioned above) The good old Beech Baron (kept a backup from when it was still bundled) worked fine. Now doing Content and Scenery, will also remove the FSUIPC INI file to r
  24. I spent a partly happy, partly frustrating day with my Bravo. My setup used to be Prepar3D 4.5, with FSUIPC 5 for the axes, and LINDA 3.1.x for the buttons. When the Alpha came I simply did not install the associated software, because it was too much focused on mapping buttons to keystrokes, which is kind of doubling the effort, because you then still have to map that key in Prepar3D. Since then the Configurator has grown, but I never noticed. Sorry. Now with the Bravo you need the new software, because of the lights, and you can simply load empty profiles for the buttons. Then the
  25. I had everything up and working, when I enabled the PMDG Translator. I am unsure, but it may have been enabled already. The Configurator gave no feedback saying if the activation failed or succeeded, but at next startup, Prepar3D started asking for reconfirmation of all addons. In C:\Programdata\Lockheed Martin\Prepar3D v4\add-ons.cfg, the PMDG translator was mentioned, but the bridge no longer, and the appropriate menu options were gone. After manually adding the entry, everything worked again. Bert Laverman
  • Create New...