Keypress and presets work but confusing results

[DaveSCUSA]

Hi agian John,

I'm confused.

I followed your advice. I did reconfigure the keypad using Right Ctl, Tab and letter/number to define the keys, 1 thru 12.

When I assigned them to presets using the UI, the keys shown as tab+rctl+nn. They were defined in DA62.ini (see attached). However, the event logs show multiple controls executed from the key presses (see FSUIPC7.log attached). For example:

   209578 *** EVENT: Cntrl= 67064 (0x000105f8), Param= 0 (0x00000000) ENGINE_MASTER_2_TOGGLE
   209656 *** EVENT: Cntrl= 67565 (0x000107ed), Param= 0 (0x00000000) ORNI_BOOST_SET or
   226250 *** EVENT: Cntrl= 67007 (0x000105bf), Param= 1 (0x00000001) SET_STARTER1_HELD
   226328 *** EVENT: Cntrl= 66178 (0x00010282), Param= 0 (0x00000000) ATC_MENU_7
   226422 *** EVENT: Cntrl= 66178 (0x00010282), Param= 0 (0x00000000) ATC_MENU_7

I really don't undeerstand now.

Is there a way to use a keypress to toggle using [Key] definitions (without Lua)? An example, to execute preset DA62_RH_Fuel_Control_On with the first push and preset DA62_RH_Fuel_Control_Off with the second push.

Again, thanks.

DA62.ini FSUIPC7.ini FSUIPC7.log myevents.txt

[John Dowson]

11 hours ago, DaveSCUSA said:

When I assigned them to presets using the UI, the keys shown as tab+rctl+nn. They were defined in DA62.ini (see attached). However, the event logs show multiple controls executed from the key presses (see FSUIPC7.log attached). For example:

   209578 *** EVENT: Cntrl= 67064 (0x000105f8), Param= 0 (0x00000000) ENGINE_MASTER_2_TOGGLE
   209656 *** EVENT: Cntrl= 67565 (0x000107ed), Param= 0 (0x00000000) ORNI_BOOST_SET or
   226250 *** EVENT: Cntrl= 67007 (0x000105bf), Param= 1 (0x00000001) SET_STARTER1_HELD
   226328 *** EVENT: Cntrl= 66178 (0x00010282), Param= 0 (0x00000000) ATC_MENU_7
   226422 *** EVENT: Cntrl= 66178 (0x00010282), Param= 0 (0x00000000) ATC_MENU_7

I really don't undeerstand now.

I cannot tell what is happening as you have not activated logging for Buttons & Keys. Please do this, also set logging for Events, and remove all other logging, and then show me the FSUIPC7.log file showing your issue. If you open the logging console (Log->Open Console), you should be able to see what is happening in real-time and this might give you some insight, Otherwise, attach your log here and I will take a look.

Also please check and remove any key press assignments in MSFS for any key combination assigned in FSUIPC7.

11 hours ago, DaveSCUSA said:

Is there a way to use a keypress to toggle using [Key] definitions (without Lua)? An example, to execute preset DA62_RH_Fuel_Control_On with the first push and preset DA62_RH_Fuel_Control_Off with the second push.

You can do this if there is something that holds the state of the fuel control (i.e. on or off). This may be an lvar or a simvar. You would need to add this to a spare FSUIPC7 offset, if not already available, then overload your key press assignment (i.e. assign both to the same key press) and then add an offset condition on each assignment, so only one is executed. Alternatively, you can define the presets so they only actually do anything if the state is correct, and overload your assignments to send both presets. Then only one should actually do anything.

You also seem to be duplicating MF presets (available in the events.txt file) in your myevents.txt file. Why are you doing this? Better to just use the MF presets, but if you want to use your own then you should at least give them a unique name. As you are using the same preset names as MF, I do not know which preset definition will be executed - it could be either.

John

[DaveSCUSA]

Thanks John,

I've done what you suggested. I appoligize for the misunerstanding I had over the Input Event Assignments. Chalk it up to old age.

Apparently, one can't compound a keypress. When I use the UI for the Fuel Valve controls (there are 2 On and Off) only the last assignment for a keypress exists in the .ini.

I have corrected it manually. When I fly the DA62, only the first keypress works. I have set the Fuel Selector entry in the apron.flt to 0. If I start on the Apron, the keypresses turn the fuel levers on but not off again.

If I start on the runway, the fuel levers don't respond (turn off). Are kepresses allowed to have compound .ini entries?

Thankfully all othe keypresses work (thanks to you). Perhaps I'll put the fuel off on the rear indent on the throttles in the Bravo.

I would switch back to the C510 if there were presets available. Are you going to publish presets for the C510? There are many Alpha and Bravo users that would appreciate it.

Thanks again. 

FSUIPC7.log FSUIPC7.ini myevents.txt

DA62.ini

[John Dowson]

29 minutes ago, DaveSCUSA said:

Apparently, one can't compound a keypress. When I use the UI for the Fuel Valve controls (there are 2 On and Off) only the last assignment for a keypress exists in the .ini.

A compound key press would be a key press that is dependent on another key being pressed. I think what you are talking about is overloading your assignments, i.e. having multiple assignments to the same button.  To do this, you need to comment out the first assignment, make the second assignment, and then uncomment the first. See this post:

You can also do the same to overload buttons.

You can also do compound key and button assignments. Compound button assignments are described in the Advanced User guide. For compound key assignments, you would have to use a spare FSUIPC offset. As well as the two assignment lines for the key press, you add a third assignment on the key you want to use to compound with, and assign this to set an offset value to 1 on press and 0 on release. You then add an offset condition on your original key press assignments, so that one is used when the offset holds 1 (indicating the compounding key is pressed) and the other when the offset holds 0.

You can do something similar to have alternating assignments on a key press. You would need 3 assignments to the same key press, the two you want to alternate, and a third one that toggles the first bit in a (spare) FSUIPC offset. The two alternating key presses would then have an offset condition on the state of this offset. So when you press the assigned key(s), this would send one control, depending on the state of the offset, and then change/toggle the value in the offset. The next time you pressed the key(s), the second assignment would be sent (as the offset now holds a different value), and then the offset would be toggled again to go back to its original value.

Try setting this up yourself, otherwise I can take a look but not until next week now. I have already spent a lot of time helping you - I really need to get onto other things for a few days. 

44 minutes ago, DaveSCUSA said:

I would switch back to the C510 if there were presets available. Are you going to publish presets for the C510?

No, because as I keep telling you, the C510 is mainly using Input Events, and you cannot use input events via calculator code/presets. I can share my assignments to the input events - I will add these to the other thread when I get time.

[John Dowson]

1 hour ago, DaveSCUSA said:

When I use the UI for the Fuel Valve controls (there are 2 On and Off) only the last assignment for a keypress exists in the .ini.

When you have overloaded (i.e. multiple) assignments to a key or button, only one assignment is shown in the UI and it will be greyed-out and you cannot edit or change it. You can only modify such assignments by directly editing the ini file.

The issue with these assignments:

Quote

9=188,24,PDA62s_LH_Fuel_Control_On,0                         -{tab+,<key: Press=Preset Control }-
11=188,24,PDA62s_LH_Fuel_Control_Off,0                         -{tab+,<key: Press=Preset Control }-
13=186,24,PDA62s_RH_Fuel_Control_On,0 ;:key: Press=Preset Control }-         -{tab+;:key: Press=Preset Control }-
15=186,24,PDA62s_RH_Fuel_Control_Off,0 ;:key: Press=Preset Control }-     -{tab+;:key: Press=Preset Control }-

is that both will always be sent. You can add an offset condition as I already outlined, or possibly define a new toggle preset, that looks at the value of A:FUEL TANK SELECTOR:1 and then triggers the correct event.  So, rather than:
 

Quote

DA62s_LH_Fuel_Control_Off#(A:FUEL TANK SELECTOR:1, enum) 0 != if{ (>K:FUEL_SELECTOR_OFF) }
DA62s_LH_Fuel_Control_On#(A:FUEL TANK SELECTOR:1, enum) 19 != if{ (>K:FUEL_SELECTOR_LEFT_MAIN) }

use something like:
   DA62s_LH_Fuel_Control_Toggle#(A:FUEL TANK SELECTOR:1, enum) 0 == if{ (>K:FUEL_SELECTOR_LEFT_MAIN) } els{ (>K:FUEL_SELECTOR_OFF) }

Not 100% sure that is correct as I don't know the range of values for A:FUEL TANK SELECTOR:1 or what they mean without checking, but that preset code just assumes 0 is off and any other value is on.
Using that, you only need the one assignment.

The preset for the right fuel control toggle would be similar but use the appropriate A:vars and K:events.

[DaveSCUSA]

Thanks again. Will presets be able to include Input Events? 

[John Dowson]

17 minutes ago, DaveSCUSA said:

Will presets be able to include Input Events? 

I have told you this many times now...the last time:

50 minutes ago, John Dowson said:

No, because as I keep telling you, the C510 is mainly using Input Events, and you cannot use input events via calculator code/presets.

 

[DaveSCUSA]

John, 

You don't have to be so adamant. You have much more knowledge and intimacy with FSUIPC than most of your customers. If we ask dumb questions it's because we haven't a clue how simconnect works, where things are in the documentation or even most of the MSFS functionality.

An example is how to read button/key log entries. If there is documentation, we can't find it.

Thanks again.

[DaveSCUSA]

Thanks John, 

You don't have to be so adamant. You have much more knowledge and intimacy with FSUIPC than most of your customers. If we ask dumb questions it's because we haven't a clue how simconnect works, where things are in the documentation or even most of the MSFS functionality.

An example is how to read button/key log entries. If there is documentation, we can't find it.

Cockspur C510 customers with Alpha and Bravo would be highly appreciative to know the bindings. Especially if FSUIPC was the only product to offer bindings.

Thanks again.

[John Dowson]

11 hours ago, DaveSCUSA said:

If we ask dumb questions it's because we haven't a clue how simconnect works, where things are in the documentation or even most of the MSFS functionality.

It is not a dumb question - just one that you have already asked several times already.

11 hours ago, DaveSCUSA said:

An example is how to read button/key log entries. If there is documentation, we can't find it.

The log entries should be self-explanatory, and any information logged that isn't you can ignore (as that is for me to diagnose issues). You shouldn't expect to understand everything logged, but you should be able to use the log to determine what is happening (i.e. what button was pressed, what assignment, if any, was triggered, etc. What entries doyou not understand? There is no documentation on the log messages and I am certainly not going to provide any.

Note the format of the ini file entries for button/key assignments are described in the Advanced User guide, if that is what you are after.

 

 

[DaveSCUSA]

9 hours ago, John Dowson said:

It is not a dumb question - just one that you have already asked several times already.

Beacuse we may not understand or of continued confusion.

9 hours ago, John Dowson said:

You shouldn't expect to understand everything logged, but you should be able to use the log to determine what is happening (i.e. what button was pressed, what assignment, if any, was triggered, etc. What entries doyou not understand? There is no documentation on the log messages and I am certainly not going to provide any.

I am confused why there are so many KEY entries with "136203 .. KeyUp received from FS but not programmed", especially with keypresses that are KEYUP with no key down. Or with keys that are not programmed in a profile.

If there is a discussion on debugging (Advanced User guide) other than Lua, I've not found it.

Thanks

[John Dowson]

40 minutes ago, DaveSCUSA said:

I am confused why there are so many KEY entries with "136203 .. KeyUp received from FS but not programmed", especially with keypresses that are KEYUP with no key down. Or with keys that are not programmed in a profile.

Key logging will log all key press/release events seen (i.e. that MSFS sends). You will see a lot of KeyUp as this is continually sent until the key is released (check the repeat flag). This is completely normal.

Do you actually have an issue?

42 minutes ago, DaveSCUSA said:

If there is a discussion on debugging (Advanced User guide) other than Lua, I've not found it.

 

43 minutes ago, DaveSCUSA said:

If there is a discussion on debugging (Advanced User guide) other than Lua, I've not found it.

No:

9 hours ago, John Dowson said:

The log entries should be self-explanatory, and any information logged that isn't you can ignore (as that is for me to diagnose issues). You shouldn't expect to understand everything logged, but you should be able to use the log to determine what is happening (i.e. what button was pressed, what assignment, if any, was triggered, etc. What entries do you not understand? There is no documentation on the log messages and I am certainly not going to provide any.

 

[DaveSCUSA]

27 minutes ago, John Dowson said:

Key logging will log all key press/release events seen (i.e. that MSFS sends). You will see a lot of KeyUp as this is continually sent until the key is released (check the repeat flag). This is completely normal.

Do you actually have an issue?

Just asked for input of why there are KEYUP when I haven't pressed any keys. 

[John Dowson]

14 hours ago, DaveSCUSA said:

Just asked for input of why there are KEYUP when I haven't pressed any keys. 

FSUIPC7 is just logging what it sees (i.e. is received from MSFS). If FSUIPC7 is logging a key press, then it has received this from MSFS. 

If you haven't pressed the key, then something else must have sent it - key logging logs all key events received from MSFS. These can come from the keyboard or from a program that is sending keys to MSFS, including FSUIPC7. Anything sending keys should also a corresponding release for each key press.

Logging of a key press/release looks like this (when the key is assigned in FSUIPC7):

Quote

   320750 KEYDOWN: VK=81, Waiting=0, Repeat=N, lParam=0 (0x0), Shifts=1
   320750 Executing InputEvent 'HANDLING_Yoke_Hider_1' [69] with parameter 1.000000
   320750 .. This key is programmed in FSUIPC7 'Keys' options
   320875 EV_KEYDOWN received: 0x51 (Q): repeat set (rate=100/25)
   320875 KEYDOWN: VK=81, Waiting=0, Repeat=Y, lParam=1073741824 (0x40000000), Shifts=1
   320875 .. This key is programmed in FSUIPC7 'Keys' options
   320906 EV_KEYDOWN received: 0x51 (Q): repeat set (rate=100/25)
   320906 KEYDOWN: VK=81, Waiting=0, Repeat=Y, lParam=1073741824 (0x40000000), Shifts=1
   320906 .. This key is programmed in FSUIPC7 'Keys' options
 ...
   321406 KEYDOWN: VK=81, Waiting=0, Repeat=Y, lParam=1073741824 (0x40000000), Shifts=1
   321406 .. This key is programmed in FSUIPC7 'Keys' options
   321406 EV_KEYUP received: 0x51 (Q)
   321422 KEYUP: VK=81, Waiting=0, Shifts=1, lparam=0 (0x0)
   321422 .. KeyUp received from FS but not programmed
 

So the initial key down is received, then the repeats, until the key-up is received. The key I pressed was assigned with 'No repeats', so the assignment (to Input Event HANDLING_Yoke_Hider_1) was only executed on the initial key presses.

The logging will look slightly different if the key is not assigned, and you will only see a few repeats (although I am not sure why without checking).

[DaveSCUSA]

Thanks John, 

You don't have to be so adamant. You have much more knowledge and intimacy with FSUIPC than most of your customers. If we ask dumb questions it's because we haven't a clue how simconnect works, where things are in the documentation or even most of the MSFS functionality.

An example is how to read button/key log entries. If there is documentation, we can't find it.

Thanks again.