Heading bug weirdness

[Stinger2k3]

Hi John,

I am trying to use an external rotary encoder to set the heading.

Using control "Heading_Bug_Inc" assigned to my encoder in fsuipc7 increases the heading in 10 degree increments. I would like 1 degree increments. So i did a log trace to see what was happening when setting the heading by mouse.

Using the mouse scroll wheel to increase in 10 degree increments shows as ....

2002719***EVENT: Cntrl= 65879 (0x00010157), Param= 0 (0x00000000) HEADING_BUG_INC

Using the mouse click to increase by 1 degree increments shows as ....

2010938***EVENT: Cntrl= 65879 (0x00010157), Param= 0 (0x00000000) HEADING_BUG_INC.

So is it possible to assign an event rather than a control?

To add to this weirdness i have the pfd and mfd screens detached onto other physical screens and the increments changes from 10deg to 3deg dependant on which screen my mouse is active in. (This is when using my encoder to operate HEADING_BUG_INC.)

Regards

Keith

[roa]

I am using Opencockpits MCP and all rotaries works fine with 1 degree increments. I am not using FSUIPC7, but Oi4FS. As it works in Oi4FS, it should also be possible to get it working correctly in FSUIPC7, I guess.

[Pete Dowson]

7 hours ago, Stinger2k3 said:

Using the mouse scroll wheel to increase in 10 degree increments shows as ....

2002719***EVENT: Cntrl= 65879 (0x00010157), Param= 0 (0x00000000) HEADING_BUG_INC

Using the mouse click to increase by 1 degree increments shows as ....

2010938***EVENT: Cntrl= 65879 (0x00010157), Param= 0 (0x00000000) HEADING_BUG_INC.

So is it possible to assign an event rather than a control?

Sorry, but your two log extracts are identical for both operations!

The term "event" comes from the format names given to controls by SimConnect: "KEY_EVENTS" are controls normally assigned to keys or buttons, whether in FSUIPC or in the Sim.

FSUIPC always used the term "control", historically, because these things were always tabulated in an FS module called "controls.dll". So, the terms event and control are interchangeable.

A single "HEADING_BUG_INC" should increment by 1 degree, but it can be accelerated to operate in 10's if several such controls/events are sent in a short time, like a second. This is part of the automatic control acceleration applied by FS when a button or key is held to repeat. It's a built-in facility to allow larger changes to be made without it taking all day!

Pete

 

[Stinger2k3]

8 hours ago, Pete Dowson said:

Sorry, but your two log extracts are identical for both operations!

The term "event" comes from the format names given to controls by SimConnect: "KEY_EVENTS" are controls normally assigned to keys or buttons, whether in FSUIPC or in the Sim.

FSUIPC always used the term "control", historically, because these things were always tabulated in an FS module called "controls.dll". So, the terms event and control are interchangeable.

A single "HEADING_BUG_INC" should increment by 1 degree, but it can be accelerated to operate in 10's if several such controls/events are sent in a short time, like a second. This is part of the automatic control acceleration applied by FS when a button or key is held to repeat. It's a built-in facility to allow larger changes to be made without it taking all day!

Pete

 

Hi Pete,

Yes, the trace i did shows exactly that. . That they are the same other than the Event name.

I am now wondering if it could be something to do with my Leo Bodnar encoder as others are not experiencing the same problem. Are you aware what time interval Msfs requires for encoders? This worked fine with FSX so I am wondering if I need to orogram the encoder to put out a shorter time per indent.

Thanks

Keith

[Stinger2k3]

Ok,

I have done some experiments this morning using different pulse widths for my encoder. I tried various setting between 8ms and 200ms. None cure the problem I have. My encoder still turns the heading bug in 10 degree increments when my mouse is active on the main VC screen. (Using Heading Bug Inc in fsuipc7)

Again I detached the PFD screen onto another monitor, made my mouse active on that monitor then turned the encoder. The first time I did this the heading bug turned 1 degree. I then went back to the VC screen -10 degrees, back to the PFD screen but this time I got 10 degrees!!

I also tried Heading Bug Inc Fast in fsuipc7 but this also results in 10 degree increments.

I read forum posts that some, but not all, others are experiencing the same so it appears to be a MSFS bug. 

I will report to Zendesk

regards

Keith

 

[Stinger2k3]

19 hours ago, roa said:

I am using Opencockpits MCP and all rotaries works fine with 1 degree increments. I am not using FSUIPC7, but Oi4FS. As it works in Oi4FS, it should also be possible to get it working correctly in FSUIPC7, I guess.

Out of interest, do you use the glass cockpit g1000 or G3000/G5000 ?. The reason I ask it that it seems that it may be caused by the detachment of the PFD/MFD screens. I found out that if I detach the PFD screen, drag it onto another monitor, i can use the knob I have assigned to produce 1 degree increments as long as the mouse is active in the PFD screen window. The moment I go back to the main view with the mouse it defaults to 10 degree increments. This is using both FSUIPC7 and MSFS directly to assign the heading bug.

[pellelil]

I don't think this have to do with FSUIPC. There is a bug in FS2020. If any of my 2/3 ways switches on my Warthog Thorttle are left in their on-position the headed-bug jumps in 10° interval, even if those 2/3 ways switches are not configured to do anything. As soon as I set the 2/3-way buttons to their off-position I can change the heading in 1° increments.

This is both observed using the mouse to rotate the heading knob on the visual autopilot or if setting up a button on my joystick to change the heading bug.

[Stinger2k3]

10 hours ago, pellelil said:

I don't think this have to do with FSUIPC. There is a bug in FS2020. If any of my 2/3 ways switches on my Warthog Thorttle are left in their on-position the headed-bug jumps in 10° interval, even if those 2/3 ways switches are not configured to do anything. As soon as I set the 2/3-way buttons to their off-position I can change the heading in 1° increments.

This is both observed using the mouse to rotate the heading knob on the visual autopilot or if setting up a button on my joystick to change the heading bug.

 

10 hours ago, pellelil said:

I don't think this have to do with FSUIPC. There is a bug in FS2020. If any of my 2/3 ways switches on my Warthog Thorttle are left in their on-position the headed-bug jumps in 10° interval, even if those 2/3 ways switches are not configured to do anything. As soon as I set the 2/3-way buttons to their off-position I can change the heading in 1° increments.

This is both observed using the mouse to rotate the heading knob on the visual autopilot or if setting up a button on my joystick to change the heading bug.

Thanks for that information. I will do more investigations to confirm..

[pellelil]

Just to clarify, as of now I have not done any axis/button assignment via FSUIPC, and all my assignments are currently done within MSFS. But I guess FSUIPC will be affected by this bug as well.

[Stinger2k3]

Ok, so i have now cleared any bindings in msfs and set them by using FSUIPC7. All works ok and the heading and alt sel is behaving normally.

I have done this for the default C172 G1000 aircraft.

There  are a couple of buttons i have not been able to map which ideally i need but I can operate them at the start of my flight with the mouse.

Avionics BUS1 and BUS2 (not available in FSUIPC but can be operated by assigning in msfs to an external momentary push button) and MFD soft buttons (i tried mapping soft button 12 in Fsuipc but it does not seem to work)

It seems that if you assign anything in msfs with SET in the name it causes the heading bug issue.

Thanks for your comments which put me on the right track and I hope my findings may help you and others

Keith

1 hour ago, pellelil said:

Just to clarify, as of now I have not done any axis/button assignment via FSUIPC, and all my assignments are currently done within MSFS. But I guess FSUIPC will be affected by this bug as well.

 

[John Dowson]

On 10/13/2020 at 10:08 AM, Stinger2k3 said:

I read forum posts that some, but not all, others are experiencing the same so it appears to be a MSFS bug. 

Did you get this working? It does seem top be an MSFS bug - see https://forums.flightsimulator.com/t/heading-increment-bug-10-degree-instead-of-1-explained/290173

John

[Stinger2k3]

Yes, it is working fine for me now John, thanks to FSUIPC7. It happens when a non momentary switch is set to an msfs function within msfs. I guess it then ties up cycles? . In fact  use it to my advantage, i have a non-momentary switch set to an msfs function which I temporarily flick when I want larger increments. This works for both the heading bug and the alt select function.

Trouble is, whilst I have been scenery designing I have temporarily forgotten which switch I used on my cockpit for this!

Regards

Keith

[Juxpax]

I'm trying to get around this issue by re-programming the on/off switches to send momentary button presses using FSUIPC 7, but my Honeycomb Alpha yoke has more than 32 buttons, and FSUIPC seems to recognize only buttons 0-31. 

Any ideas how to access the missing 3 magneto switch buttons (32, 33 and 34)?

[John Dowson]

On 12/27/2020 at 11:13 PM, Juxpax said:

Any ideas how to access the missing 3 magneto switch buttons (32, 33 and 34)?

To recognise buttons outside of the 0-31 range, you have to use lua. There is a lua script provided called HidDemo.lua (in the lua examples zip in your documentation folder).
Add that to your FSUIPC7 installation folder, and edit to provide your devices vendor and product ids. Also, auto-start the lua by adding it to the [Auto] section of your FSUIPC7.ini file.

There are many posts on how to do this - try checking the forums if you require further help before posting again.

John

[Juxpax]

Thanks, John, I figured it all out, although it took time to find all the "many posts" that you were referring to, and gather the correct bits and pieces together. I managed to properly get past the 10 degree bug - including all the added weirdness that the Honeycomb Alpha yoke causes, which was also discussed in yet another thread.

The thread that helped with the Honeycomb Alpha specific issues is linked below (for future reference), although the naming of the thread made it hard to find since I was looking specifically for a solution to the 10 degree bug, which the linked solution also solves.

 

[John Dowson]

@Juxpax Glad you figured it out. Yes, the information is spread about a bit and difficult to find. It would be good to create a FAQ entry for the Honeycomb Alpha I think, as well as the Bravo. I'll look into this in the new year, when time permits.

John

[toby23]

On 10/12/2020 at 11:33 PM, Pete Dowson said:

A single "HEADING_BUG_INC" should increment by 1 degree, but it can be accelerated to operate in 10's if several such controls/events are sent in a short time, like a second. This is part of the automatic control acceleration applied by FS when a button or key is held to repeat. It's a built-in facility to allow larger changes to be made without it taking all day!

Pete

 

Hi Pete,

Would it be possible to simulate the acceleration of turning a dial in SU9 as setting the heading bug with a rotary switch is currently taking all day! Thank you, Toby

EDIT - I just found the preset commands 'Heading Bug Inc/Dec Fast' in FSUIPC but they jump 10° at a time. I would like 1° when I dial slowly and 10° when I'm spinning faster to get to where I want to be, if that's possible?

[John Dowson]

23 hours ago, toby23 said:

I just found the preset commands 'Heading Bug Inc/Dec Fast' in FSUIPC but they jump 10° at a time. I would like 1° when I dial slowly and 10° when I'm spinning faster to get to where I want to be, if that's possible?

Yes. How you do this depends upon whether your rotary has one or two buttons (a fast and a slow button) in each direction. For the latter, it is just a matter of assigning to the slow/fast increments for each button. If your rotary only has one button in each direction, you can use a lua script to trigger virtual flags for fast/slow movement in each direction, and then assign the the slow/fast flag accordingly. A lua example plugin script is provided that does this - see the lua examples zip file in your FSUIPC7 installation folder. There is also a specific version of this script available (in another forum post) that is specific to the HoneyComb Bravo, which controls the trim wheel as well as the rotary in this manner.

John

[toby23]

On 6/12/2022 at 1:13 PM, John Dowson said:

There is also a specific version of this script available (in another forum post) that is specific to the HoneyComb Bravo, which controls the trim wheel as well as the rotary in this manner.

John

Hi John,

Thanks for your advice. I found the Rotaries.lua which is the one I think you mean?
I'm afraid programming that is beyond my skill level at the moment.

Can I just put it in the lua folder and use it or will that not work? How would I assign the correct button or action to each switch?

Thanks,

Toby

[John Dowson]

14 hours ago, toby23 said:

Can I just put it in the lua folder and use it or will that not work? How would I assign the correct button or action to each switch?

You have to edit the Rotaries.lua to specify the correct device/joystick id and also the button numbers that your rotary uses. You also have to have the lua auto-started by adding it to the [Auto] section of your FSUIPC7.ini file (see the section Automatic running of Macros or Lua plugins in the Advanced User guide). Once the lua is configured and running, you can then assign to the virtual buttons you see in the Buttons assignment panel when you turn your rotary. If you see the original button numbers instead of the virtual ones,  you can use the IgnoreThese ini parameter (in your [Buttons] or profile-specific [Buttons.xxx] section) - again, see the Advanced User guide for details).

John

[toby23]

35 minutes ago, John Dowson said:

You also have to have the lua auto-started by adding it to the [Auto] section of your FSUIPC7.ini file 

John

Thanks for your advice, will try today. I added [LuaFiles] 1=currheading for the script that I use to the FSUIPC7.ini file and it works. I do not have an [Auto] section. ini attached.

FSUIPC7.ini

[John Dowson]

1 minute ago, toby23 said:

I added [LuaFiles] 1=currheading for the script that I use to the FSUIPC7.ini file and it works.

You should not manually change that section - it is automatically managed by FSUIPC by scanning for lua files in your installation folder. What works?

2 minutes ago, toby23 said:

I do not have an [Auto] section.

Then add/create one!

3 minutes ago, toby23 said:

ini attached.

What is your lua file called - isn't it Rotaries.lua? If so, then it is not in your FSUIPC7 installation folder. If you called this file currheading.lua (which you shouldn't, as it controls/changes the rotary, not what you have assigned the rotary to do) then it should automatically appear under your [LuaFiles] section, and you should not need to add this manually...

John

[toby23]

I didn't mean to confuse you, apologies.

I haven't added or edited the Rotaries.lua file yet, I wanted to understand how it works first and was waiting for your reply.

I have created a separate lua file to control a button press to assign heading bug to current heading, that is called currheading.lua and is in the main FSUIPC folder and is assigned to a button on my throttle and works correctly.

Why do I need an [Auto] section if FSUIPC scans for lua files and adds them to the [LuaFiles] section?

 

[John Dowson]

1 hour ago, toby23 said:

Why do I need an [Auto] section if FSUIPC scans for lua files and adds them to the [LuaFiles] section?

The [Auto] section is used to start/run the lua. This is used for luas that are not ran activated on a button press, but use one of the lua event.* functions to wait for an event. The Rotaries.lua uses the event.timer function to poll for the button states.

Of course, you don't have to auto-start the lua if you don't want to, but it needs to be started somehow so that it can poll for the state of your rotary buttons. You usually do this from the [Auto] profile-specific [Auto.xxx] section, but you can always start it on a button or key press, but it makes more sense to have this script auto-loaded.

John