Please add Bindings for Pedal Micro Switches

[Lurker]

18 hours ago, Torun said:

But I also have an alternative suggestion, one that I'd ideally like to see as an option alongside the keybind. Not just an adjustable deadzone for the hold to activate, but a moving one, that would establish each time the trim button is released. Instead of trimming the rudder itself, it would move the zone on the rudder axis where the heading hold engages, and disengage heading hold and move to stabilization when trim is held. Basically: Why not tie the microswitches to the trim button?

 

If I'm following your train of thought correctly, this would mean that every time the trim button is pressed the Heading Hold is disabled, and then is engaged once again when the trim button is released, with the caveat that it would recognize where the pedals are currently set at (or trimmed at) and take that as a baseline from which to disengage the Heading hold from. 

Unfortunately this would also mean that unless you press the trimmer, heading hold would not be disabled and we are back at square one. In a scenario where you are trimmed out for an attack run (for example) and you need minor corrections on the rudder so you can bring guns or rockets to bear on the target, you don't really want to trim, but you also don't want the Heading hold to fight your inputs....

I think that an option for springless pedals should be added to the DCS Hind. (Sort of like the different control options for different types of cyclics or joystics that already exists). That way you can tell the module what type of pedals you have (either spring, or springless) and it would adjust the control and AP logic accordingly. 

Edited February 9, 2022 by Lurker

[Lurker]

Also while we are theory-crafting for a better microswitches solution, a really simple and elegant solution just occurred to me:

Disengage autopilot heading hold whenever physical pedal input is detected. Do not base it on pedal deflection (as it is currently implemented).

- So if pedals are left alone (no movement on axis, irrespective of where on the axis the pedals are currently left at) AP Heading hold is engaged

- Axis movement is detected, AP heading hold is disengaged. 

I don't know whether that is possible to code within the DCS framework though, or how hard it would be to do so. 

[AeriaGloria]

1 hour ago, Lurker said:

Also while we are theory-crafting for a better microswitches solution, a really simple and elegant solution just occurred to me:

Disengage autopilot heading hold whenever physical pedal input is detected. Do not base it on pedal deflection (as it is currently implemented).

- So if pedals are left alone (no movement on axis, irrespective of where on the axis the pedals are currently left at) AP Heading hold is engaged

- Axis movement is detected, AP heading hold is disengaged. 

I don't know whether that is possible to code within the DCS framework though, or how hard it would be to do so. 

I think this was talked about on first page, that would make coordinated turns at constant rate and bank angle very difficult as as soon as you are in a stable turn and not moving pedals heading hold would instantly start to fight your turn and when reaching its limit automatically trim the pedals 

[Lurker]

18 minutes ago, AeriaGloria said:

I think this was talked about on first page, that would make coordinated turns at constant rate and bank angle very difficult as as soon as you are in a stable turn and not moving pedals heading hold would instantly start to fight your turn and when reaching its limit automatically trim the pedals 

Yes, you are absolutely correct. For some reason this didn't occur to me 

The more I think about it the more it seems like microswitches need to be a bind-able option with our DCS Hind. Either that, or an AP system would have to be implemented that is completely different than the one in the real Hind. 

Edited February 9, 2022 by Lurker

[AeriaGloria]

2 minutes ago, Lurker said:

Yes, you are absolutely correct. For some reason this didn't occur to me 

The more I think about it the more it seems like microswitches need to be a bind-able option with out DCS Hind. Either that, or an AP system would have to be implemented that is completely different than the one in the real Hind. 

I don’t think there’s an easy way out except what DCS does best, giving us detailed control over the system that allows us to control the system according to our intentions the way it is done with real pilots placed feet on the pedals via dedicated bindings and their according functions over the AP 
 

A special options selection could either make the heading hold disappear and I don’t see that as ideal, you could have special options affect the need of the bindings but I assume the current function could be left at default until the the virtual pilot uses the bindings at which point control is taken by the virtual pilot being the simplest and most direct solution to bettering the simulation 

[GregP]

13 hours ago, Lurker said:

I think that an option for springless pedals should be added to the DCS Hind. (Sort of like the different control options for different types of cyclics or joystics that already exists). That way you can tell the module what type of pedals you have (either spring, or springless) and it would adjust the control and AP logic accordingly. 

Well there is already the 'rudder trimmer' option that presumably is intended to be used with springed pedals, where the user would want to return them to center when pressing the trim button.  The question is (and which I posed in my thread in the bugs section) whether this 'rudder trimmer' option has any effect on the way the yaw AP works, i.e. is the yaw AP designed to mostly work acceptably for normal center-spring pedals only?  Or does leaving that option unchecked (for users of springless pedals) somehow adjust the yaw AP to recognize that the at-rest position of the pedals is not always near the center?

Edited February 9, 2022 by GregP

[Lurker]

13 hours ago, GregP said:

Well there is already the 'rudder trimmer' option that presumably is intended to be used with springed pedals, where the user would want to return them to center when pressing the trim button.  The question is (and which I posed in my thread in the bugs section) whether this 'rudder trimmer' option has any effect on the way the yaw AP works, i.e. is the yaw AP designed to mostly work acceptably for normal center-spring pedals only?  Or does leaving that option unchecked (for users of springless pedals) somehow adjust the yaw AP to recognize that the at-rest position of the pedals is not always near the center?

 

The less said about the rudder trimmer the better. I don't like the function, and it's counterintuitive in a terrible way. Not to mention the fact that sometimes you DONT want to trim. That's why tying trim to AP Heading hold is not a great idea. 

As for the second part, yes, the YAW AP only works (sort of) for springed pedals. However there is something strangely off in the way it engages and disengages, which is why most people fly with it turned off. Which is definitely not how it's supposed to be done in the real Hind. 

Edited February 10, 2022 by Lurker

[AeriaGloria]

THANK YOU VERY MUCH!!! 
 

Newsletter mentions changers in way yaw autopilot changes mode, pedal micro switches simulation, and the yaw autopilot heading hold trim adjustment even when pedal trim is selected off!!! This is everything I wanted!!!

In addition getting the side selector issue fixed, KM-2 so we can have true heading, 

ATGM desync which was my only remaining multi crew issue. 
 

I am very happy, can’t wait!!!!