Jump to content

Please explain the format of the profile JSON structure


Recommended Posts

I'm trying to understand the format of the JSON file used to configure the mappings.

 

  1. 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.
  2. 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". Still this field does not change. What does it control?

 

The "Data" field is an array of Button objects. Given that you already have other lists of names, I would suggest you add one for the names of the buttons and knobs, and change this to a map/dictionary. Also, any record that is essentially empty should be left out.

  1. Every button record has a number (already commented on that. Should be the button's name IMHO.) an array of press-events and an array of release events.

 

Events:

  1. A  text field keyed by the language. Why not a field that is named after the purpose of this text, and make it a map keyed to the language. Is the text supposed to be displayed by the Bridge when this event is triggered? Is that what "the other" menu option is about? I never actually saw it display anything, but that may be because I tested with text in the "EN" field, and top-level language "DE" was selected. Will retest.
  2. An array of variables, as well as an embedded variable, I guess. However, the embedded one has no "VariableIsCustom" flag. What is the purpose of the embedded one, because no profile is using it.
  3. An array of conditions, as well as an embedded one.
  4. Events, Variables, as well as Conditions all have these language-keyed fields. What are they supposed to do?
  5. At event level there is a "Repeat" flag, which appears to be for things like trimming, where you want to have that, but the flag is at the event level? Does this mean I can mix repeating events with non-repeating ones? Is the ordering of the events guaranteed? That makes for interesting semantics.
  6. What if I specify both variables and conditions?
  7. Are the conditions used for the event-level variables, or only for their embedded variables?
  8. If I have multiple conditions, does that use an AND?
  9. If I have multiple conditions, what of the embedded variables? Are they evaluated as soon as the partial condition matches?

 

Feel free to DM me if you want to take this off-line.

 

Cheers,

Bert

 

PS

Note that there are (at least) three distinct user-groups you're dealing with: First are the (complete) beginners, such as the new crowd brought in by MSFS 2020. Then there are those that have experience in dealing with FSUIPC (and potentially LINDA) through the UI only. Third are those that have dived in and programmed stuff using LUA in FSUIPC (and LINDA). The first group will be lost completely unless they have a worked-out profile they can load and use. The second will use the configurator, but need lists of Variable/Condition names, because none of the names match what they are used to. The last will (like me) try to understand what is happening in the JSON files and demand even larger amounts of documentation... and ask where they can plug in scripting. 😉

 

Harness the power of the crowd. They'll help you improve the software quickly.

Link to post
Share on other sites
3 hours ago, Bert Laverman said:

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". Still this field does not change. What does it control?

...

A  text field keyed by the language. ... Is the text supposed to be displayed by the Bridge when this event is triggered? Is that what "the other" menu option is about? I never actually saw it display anything, but that may be because I tested with text in the "EN" field, and top-level language "DE" was selected. Will retest.

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.

Link to post
Share on other sites

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_737NGX_EVT_OH_LIGHTS_ANT_COL",
              "Value": "536870912",
              "VariableIsCustom": true,
              "Condition": "L:AS_PMDG_737NGX_LTS_AntiCollisionSw, bool",
              "ConditionValue": "0",
              "ConditionIsCustom": true
            }

For button 21 (BCN Off):

            {
              "DE": "",
              "EN": "",
              "FR": "",
              "ES": "",
              "Variable": "L:AS_PMDG_737NGX_EVT_OH_LIGHTS_ANT_COL",
              "Value": "536870912",
              "VariableIsCustom": true,
              "Condition": "L:AS_PMDG_737NGX_LTS_AntiCollisionSw, bool",
              "ConditionValue": "0",
              "ConditionIsCustom": true
            }

 

The landing lights are a bit more complex, as they can be retractable or fixed, and the "guard" that the profile uses is not always installed. For example, the older models had all four switches with a guard, while the newer models only have two switches for the fixed lights.

 

What I tried is the following:

            {
              "DE": "Landing lights LEFT-FIXED ON",
              "EN": "",
              "FR": "",
              "ES": "",
              "Variable": "L:AS_PMDG_737NGX_EVT_OH_LIGHTS_L_FIXED",
              "Value": "536870912",
              "VariableIsCustom": true,
              "Condition": "L:AS_PMDG_737NGX_LTS_LandingLtFixedSw:0, bool",
              "ConditionValue": "0",
              "ConditionIsCustom": true
            },
            {
              "DE": "Landing lights RIGHT-FIXED ON",
              "EN": "",
              "FR": "",
              "ES": "",
              "Variable": "L:AS_PMDG_737NGX_EVT_OH_LIGHTS_R_FIXED",
              "Value": "536870912",
              "VariableIsCustom": true,
              "Condition": "L:AS_PMDG_737NGX_LTS_LandingLtFixedSw:1, bool",
              "ConditionValue": "0",
              "ConditionIsCustom": true
            }

This will flip each of the two fixed-light switches, if it is not on. This works fine, even if only one is off. Note the text is never shown: The bridge only shows the text at the Event level. However, if either switch was already in the intended position, the bridge shows "X_Landing lights ON_X", which is annoying, as there is nothing particularly wrong.

 

So then I tried with two PressEvents instead, and found that the bridge only does the last one in the array...

Link to post
Share on other sites

 Hi,

It would be great to get a picture showing the .json button number.

The Pdf supplied with the profiles makes it very difficult to understand, clone and adapt a profile for another aircraft.

 

Question also.

The button json description for the press event has

- a variable zone

          "Variable": "",
          "Value": "",
          "Condition": "",
          "ConditionValue": "",
          "Conditions": [],
          "Repeat": false

 

- and a variables array, with other contions array...

 

          "Variables": [
            {
              "DE": "",
              "EN": "",
              "FR": "",
              "ES": "",
              "Variable": "L:xxxx",
              "Value": "",
              "Conditions": [
                {
                  "DE": "",
                  "EN": "",
                  "FR": "",
                  "ES": "",
                  "Variable": "K:AP_ALT_VAR_INC",
                  "Value": "100",
                  "VariableIsCustom": false,
                  "Condition": "INT:FCU_SELECTOR, string",
                  "ConditionValue": "ALT",
                  "ConditionIsCustom": false
                },
				etc...
    		  ]
              "VariableIsCustom": true
            }
          ]

 

Is the first syntax a compatibity for the previous version YokeInput ?

I see the first form in used in your converted profile from YokeInput and the second in the new provided profiles...

 

Would also need to get definitive syntax rules.

 

In some of my converted profile I have  ">K:EventIID"

In your supplid profiles "K:EventId" (without ">")

 

In variables or conditions, sometimes there is a unit specified but I am not able to find a rule :

"Variable": "INT:REV_0,bool",

but  

"Variable": "L:ApDisconnect",

 

It also look like there are special driver variables like  "INT:FCU_SELECTOR, string" or  "INT:REV_1,bool"

 

So, I think we need some more info, and tutorial are not the best way to go (may be I am too old fashion ;)

Too much topics addressed in a single session when there is a need for more formal written document.

 

Hope I am not asking too much ;)

 

Thanks - Gérard

Link to post
Share on other sites

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

Link to post
Share on other sites
11 hours ago, Bert Laverman said:

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

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...

Link to post
Share on other sites

Going back to the PMDG 737 NGXu SDK, I see they actually provide for three different ways to send events:

  1. Use SimConnect_SetClientData(), which uses the Event ID and the value of the field.
  2. Use SimConnect_TransmitClientEvent() with a locally bound id for the Event and the value of the field.
  3. 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 the mouse-clicks at all?

 

Bert

Link to post
Share on other sites
  • Administrator

Hi guys,

 

while we always appreciate your input, naturally the focus lies on having all functionality availabe via the ConfigTool, so it does not make much sense explaining the .json structure. Plus, of course, it is also a question of limited human resources, which are now bound by fixing bugs, providing basic support and implementing missing items to maximize functionality while more and more users are getting their hardware. It is only after that "inital rush", that we might be able to delve into the more deeper topics, also documentation-wise. I hope this rationale is understandable.

 

So, for now let me only answer some small things:

 

On 2.1.2021 at 14:21, Bert Laverman sagte:

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.

This is because the whole language and text feature over the course of development has been more or less useful for debugging purposes only. That's why it is not very refined and currently also not manageable via the ConfigTool. We will see how this evolves in the future. If you feel it might be valuable to keep or even extend, just give us your thoughts on it.

 

On 2.1.2021 at 20:15, gaab sagte:

In some of my converted profile I have  ">K:EventIID"

In your supplid profiles "K:EventId" (without ">")

This is, because if the ">" is missing for variables where it needs to be (aka where you want to set a variable), it will be added automatically while parsing the .json. So, basically, it does not matter, if it is in the .json itself, or not.

 

vor 3 Stunden , Bert Laverman sagte:

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 the mouse-clicks at all?

Because there are events like with the FCU HDG, ALT, CRS where we just want to increase/decrease and not only set an absolute value. That's why we are making use of what PMDG provides in their SDK. 

Link to post
Share on other sites
11 hours ago, BenBaron said:

Hi guys,

 

while we always appreciate your input, naturally the focus lies on having all functionality availabe via the ConfigTool, so it does not make much sense explaining the .json structure.

 

...bound by fixing bugs, providing basic support and implementing missing items to maximize functionality

 

I undertand and it's OK.

 

Some suggestions for the configurator :

- confirm that the profile as been updated (and activated).

- for a next version : allow to customize the name of the buttons. For example your "Bus1 On" is my "Seat Belt Off". (could be a kind a "translation" table...)

 

 

Happy new year

 

Gérard

  • Thanks 1
Link to post
Share on other sites
18 hours ago, BenBaron said:

while we always appreciate your input, naturally the focus lies on having all functionality availabe via the ConfigTool, so it does not make much sense explaining the .json structure. Plus, of course, it is also a question of limited human resources, which are now bound by fixing bugs, providing basic support and implementing missing items to maximize functionality while more and more users are getting their hardware. It is only after that "inital rush", that we might be able to delve into the more deeper topics, also documentation-wise. I hope this rationale is understandable.

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.

 

Quote

This is because the whole language and text feature over the course of development has been more or less useful for debugging purposes only. That's why it is not very refined and currently also not manageable via the ConfigTool. We will see how this evolves in the future. If you feel it might be valuable to keep or even extend, just give us your thoughts on it.

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?

 

Quote

Because there are events like with the FCU HDG, ALT, CRS where we just want to increase/decrease and not only set an absolute value. That's why we are making use of what PMDG provides in their SDK. 

Ok, makes sense.

 

So, questions left over:

  1. If I have both "Variables" and "Conditions", what is the ordering? First all "Variables" are processed, then the "Conditions"?
  2. For events, there is no "OR" or "AND" on conditions like with the LEDs, check? (verified using the landing lights, I can throw all switches if needed in subsequent conditions)
  3. If each condition is processed independently, and can have zero or one variable, what is the use of a Condition without a variable?
  4. Only the last Event in the array gets processed. Bug? UI doesn't support it, but if having multiple conditions without variables is to have a use, this could become important. Having multiple (pressed/released) events would then be very useful.

I'll do a bit of a write-up for the PMDG Lvars and pass that along, so you can use that and we have something to use as reference. I tried searching for the event names in the configurator, but the packed Javascript blobs (if that is where they are) are too much of a hassle to unpack and search through. If you send me a list, I'll put in the finger-sweat and type out some text.

 

One thing that didn't work for me is a potential PMDG SDK issue: The position lights switch is supposed to use 0 for "Steady", 1 for "Off", and 2 for "Strobe and steady", but behaved differently.

 

The SDK:

    unsigned char   LTS_PositionSw;                     // 0: STEADY  1: OFF  2: STROBE&STEADY

 

This translates to "L:AS_PMDG_737NGX_LTS_PositionSw,number" with "(L:AS_PMDG_737NGX_EVT_OH_LIGHTS_POS_STROBE)" as the event, but I had to use 2 for "Steady" and 0 for "Strobe and steady", while immediately switching from 0 to 2 did not work.

 

Going to write a small piece of C++ to test this directly against the SDK to verify.

 

Cheers,

Bert

Link to post
Share on other sites
  • Administrator

Hi Bert,

 

Zitieren

, 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?

Exactly right.

 

Zitieren

1. If I have both "Variables" and "Conditions", what is the ordering? First all "Variables" are processed, then the "Conditions"?

Read in conjunction with your second and third point. First the "Conditions" are evaluated and their "Variables" are executed. If the "Event"s "ConditionLogic" evaluates to true, also its "Variables" will be executed, if defined.

 

Zitieren

2. For events, there is no "OR" or "AND" on conditions like with the LEDs, check? (verified using the landing lights, I can throw all switches if needed in subsequent conditions)

This will be coming in some of the next updates for the ConfiguratorTool. Actually, the bridge module already allows for using "ConditionLogic" within "PressEvent" or "ReleaseEvent".

 

Zitieren

3. If each condition is processed independently, and can have zero or one variable, what is the use of a Condition without a variable?

Related to 2.: All the conditions will be individually evaluated and if true their variables will be executed, if defined. Additionally, if all conditions meet the requirement of the "Event"s "ConditionLogic", its "Variables" will be executed, if defined.

 

Zitieren

4. Only the last Event in the array gets processed. Bug? UI doesn't support it, but if having multiple conditions without variables is to have a use, this could become important. Having multiple (pressed/released) events would then be very useful.

I don't think I understand. You can only have one "PressEvent" and one "ReleaseEvent".

Link to post
Share on other sites

Ok I am trying to setup profiles to work with Non-PMDG aircraft such as the Leonardo Maddog and the TFDI 717. I've used FSUIPC for years but since there are buttons on the throttle that it will not see being over 32 buttons I am forced to use the configurator and things it is asking for is totally new to me.

 

Can you input Event IDs in either Hex form or Numerical form, if yes, where, and does it need a Key value, if so what is that value. I've tried using K since it looked like maybe that was it, but no dice. I know you guys are busy as people are getting these now, but some at least basic description of what kind of data goes where would be really helpful.

 

Thanks!

Link to post
Share on other sites
  • Administrator
vor 37 Minuten, moosestaffa83 sagte:

Ok I am trying to setup profiles to work with Non-PMDG aircraft such as the Leonardo Maddog and the TFDI 717. I've used FSUIPC for years but since there are buttons on the throttle that it will not see being over 32 buttons I am forced to use the configurator and things it is asking for is totally new to me.

 

Can you input Event IDs in either Hex form or Numerical form, if yes, where, and does it need a Key value, if so what is that value. I've tried using K since it looked like maybe that was it, but no dice. I know you guys are busy as people are getting these now, but some at least basic description of what kind of data goes where would be really helpful.

 

Thanks!

Hi,

 

a good starting point to get a general idea of the ConfiguratorTool is this channel on YouTube.

 

Neither do I own one of those aircraft, nor do I know their SDK...a quick google search brought me to this document. At first glance, those event id's might be simply used in conjunction with the K:ROTOR_BRAKE event. So, simply convert from hex to dec and input the number into the "Value" field like in the shot, where I did that for "GROUND SERVICE ELEC SWITCH":

image.png

 

To interface with an LVar, use the "Custom Var" from the "Variable" field like that:

image.png

 

But like I said: I honestly don't know if this will work.

Link to post
Share on other sites

Ok, I think that did work, but looking at the FSUIPC log as I'm pressing the button, it shows the toggle is actually firing off twice every time I hit the switch. I'm using the Flap paddle at the moment in testing. I'll try some of the other buttons and see if they do the same thing. Not sure why it is sending a double command. It is not set to repeat in the config tool.

Link to post
Share on other sites

Ok this may be more of a question for the guys at TFDI, but I'll post it here too since I'm still not sure how the json is actually communicating with the sim differently than FSUIPC does.

 

In FSUIPC if I set a button as a custom using either the hex or the decimal version... in this example 0x121A6 which equals 74150, pressing the button toggles the Engine 1 Fuel switch. 

 

The Log file shows:
***Event: Cntrl= 74150 (0x000121a6), Param= 0 (0x00000000) <74150>

FS Control Sent: Ctrl=74150, Param=0 <74150>

***Event: Cntrl= 66494 (0x000103be), Param= 0 (0x00000000) TOGGLE_FUEL_VALVE_ENG1

(When the above shows, the fuel valve operates normally as a toggle with the button)

 

However when I put the decimal code into the Honeycomb Configurator the switch toggles twice (so fast you can't see it - but I can see the effects briefly) and the log looks like this:

 

(The 74150 is listed as the Variable in the .json)

***EVENT: Cntrl= 66494 (0x000103be), Param= 74150 (0x000121a6) TOGGLE_FUEL_VALVE_ENG1

***EVENT: Cntrl= 66494 (0x000103be), Param= 0 (0x00000000) TOGGLE_FUEL_VALVE_ENG1

 

Interesting note: If I use the 66494 number in FSUIPC, it behaves just like when I use either number in the Honeycomb Configurator and duplicates with every button push.

Any thoughts?

Link to post
Share on other sites
17 hours ago, BenBaron said:

I don't think I understand. You can only have one "PressEvent" and one "ReleaseEvent".

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):

  1. Process each Condition, and process each Condition's Variable area if that single Condition evaluates to true.
  2. 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" entries, as is indicated by the data structure, I can do the above several times, which allows me to have e.g. unconditional and conditional blocks combined, or several conditional blocks dependent on different conditions.

 

Cheers,

Bert

Link to post
Share on other sites
9 hours ago, moosestaffa83 said:

Interesting note: If I use the 66494 number in FSUIPC, it behaves just like when I use either number in the Honeycomb Configurator and duplicates with every button push.

Any thoughts?

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?

Link to post
Share on other sites
On 1/5/2021 at 1:44 AM, gaab said:

Some suggestions for the configurator :

- confirm that the profile as been updated (and activated).

- for a next version : allow to customize the name of the buttons. For example your "Bus1 On" is my "Seat Belt Off". (could be a kind a "translation" table...)

 

After several Configuration Profiles built, considering the number of switches (specially on the Bravo), it would be very useful to have a "Configuration" summary :

 

An html file, with ONE line per Button (or LED), listing only the variable(s) and assigned value (one extra line only in case of existing Release Event), with the option to list also the unassigned buttons.

 

 

Example :

  Elevator Trim A Up    Press [K:ELEV_TRIM_UP]
  Elevator Trim A Down  Press [K:ELEV_TRIM_DN]
....
  Toggle 3 ON           Press [L:DC_Gen1_sw (1)]
  Toggle 3 OFF          Press [L:DC_Gen1_sw (0)]
.....
  MultVariable ex       Press [K:LANDING_LIGHTS_ON, L:MY_LANDING_SW (1)]
.....
  Press/Release         Press [L:MyLVar (1)]
                        Release [L:MyOtherVar (-1)]

If Option not allocated buttons
  Elevator Trim B Up   
  Elevator Trim B Down 

 

Thanks  :)

 

Gérard

  • Thanks 1
  • Upvote 1
Link to post
Share on other sites
  • Administrator
On 5.1.2021 at 09:36, Bert Laverman sagte:

I'll do a bit of a write-up for the PMDG Lvars and pass that along, so you can use that and we have something to use as reference. I tried searching for the event names in the configurator, but the packed Javascript blobs (if that is where they are) are too much of a hassle to unpack and search through. If you send me a list, I'll put in the finger-sweat and type out some text.

 

One thing that didn't work for me is a potential PMDG SDK issue: The position lights switch is supposed to use 0 for "Steady", 1 for "Off", and 2 for "Strobe and steady", but behaved differently.

 

The SDK:

    unsigned char   LTS_PositionSw;                     // 0: STEADY  1: OFF  2: STROBE&STEADY

 

This translates to "L:AS_PMDG_737NGX_LTS_PositionSw,number" with "(L:AS_PMDG_737NGX_EVT_OH_LIGHTS_POS_STROBE)" as the event, but I had to use 2 for "Steady" and 0 for "Strobe and steady", while immediately switching from 0 to 2 did not work.

 

Going to write a small piece of C++ to test this directly against the SDK to verify.

 

Cheers,

Bert

 

Hi Bert,

 

if you would be willing to provide a list of the PMDG variables, that would be of course very helpful and reduce the strain on me ;). Regarding the position light switch: I remember that when I was creating the profile some time ago, I also saw that issue, but simply put it down to an error in the SDK, that one can easily circumvent. So I didn't continue to bother with that one switch.

Link to post
Share on other sites
8 hours ago, Bert Laverman said:

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?

Yes holding the flaps switch in that position reports two events. As does using the other buttons. Again, if I use the 66494 in FSUIPC on ANY button I get the same response, two events. But if I use the 74150 it behaves normally. It seems when I use 74150 in the Honeycomb tool, it is being converted to the 66494 and thus giving me the double command. But I still don't understand why 74150 and 66494 seem to be referenced to the same command. Interestingly if I assign a command that the sim and FSUIPC recognize but the aircraft wouldn't such as the command for the Engine 3 Fuel Switch (since the aircraft has only two engines) it only reports one event. 

Link to post
Share on other sites
On 1/3/2021 at 9:28 AM, Bert Laverman said:

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

Looks like "INT:REV_0, bool" is not internal to the bridge  and P3D dislikes it !

 

Error: Invalid variable (missing ':', did you forget a macro?): INT:REV_0.

 

Is this syntax only meaningful with the "PDMG" interface ?

 

Anyway, this could be replaced by an usual LVar....

 

I really start to like this Beta Throttle - and Notepad++ is my friend ;)

 

Gérard

 

Link to post
Share on other sites
  • Administrator

Hi Gérard,

 

where does this message pop up:

"Error: Invalid variable (missing ':', did you forget a macro?): INT:REV_0." ?

 

This is internal state and cannot be used anywhere else. In this case, it prevents unlocking engine 1 full reverse, if the reverse lever has not been lifted up.

Link to post
Share on other sites
13 hours ago, BenBaron said:

Hi Gérard,

 

where does this message pop up:

"Error: Invalid variable (missing ':', did you forget a macro?): INT:REV_0." ?

 

This is internal state and cannot be used anywhere else. In this case, it prevents unlocking engine 1 full reverse, if the reverse lever has not been lifted up.

I understand the idea and found it very insteresting.

I borrowed this approach from one of your PMDG profile - and I saw it first on PMDG forum concerning Bravo and Reverses...

I implemented it in a non-PDMG I built for a turboprop. It is why I was wondering if that could be the reason.

 

The error is in the infamous(!) ContentError.txt which is always ON on my PC (and helped me to address a lot of XML errors in a lot of aircraft - no name ;)

 

I have found the reason (my error) and was able to fix it, but the configurator is partly guilty !

 

When creating a condition, you have a dedicated field for the unit

 

P3-D2021-01-08-17h11s01813.jpg

 

but when creating the variable, there is no such unit field.

I did not specified in the name field the unit (ok, my fault, but I plead not guilty), and I got the message.

This means that the INT field is not recognized as such and sent to the simulator, which in turn is unhappy ;)

 

Adding the ",bool" solves the issue.

 

P3-D2021-01-08-17h10s24497.jpg

 

Please, we definitively need a short document which describes the different syntax cases. Because, if I look in the various profiles published, I don't see a unit specified for the variable, if it is a L:xxx. It is very confusing and it is not the "detail" you pay attention to in a tutorial...

 

Consider also for the next release, better check of the input by the configurator.

 

Cheers - Gérard

 

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...