All keybinds have an option "on release"

[FalcoGer]

Some of the key binds have special key binds that turn an option off when the key is no longer held down. An example would be the auto pilot mode switch for the A10-C. This is presumably because the Thrustmaster warthog throttle sends a separate and continuous "button" for the up and down position but no button for the center position. I would like to use the thrustmaster warthog throttle for other aircraft too. For example I use the EAC switch for master arm in most planes and the radar altimeter switch for laser arm. However most key bindings don't have that second, special option, so I have to toggle the switch twice to toggle the switch in the aircraft once, because it toggles only on the pressing part.

 

I propose the solution to the problem: Don't have those special key bindings and get rid of them. Instead every single key binding has a selectable option (for example make it a checkbox) that toggles the binding "on release". This option should not be in the key binding itself, but rather in the key press you set up for the switch. This ensures that all bindings can stay as they are right now, only expanded by default with the on release option off.

 

In my example I would set "Master Arm - ON" to the button press. Because the button press is continuous it will stay on. Then I set "Master Arm - OFF" to the very same button, but check "on release". So when the button is released (ie. I put the switch back into the off position on my physical device), the continuous button press is no longer a thing and the on release key event fires, putting the switch back into the off position. This requires that the same button may do multiple things, so long as on release is set on one but not the other key binding.

 

To go along with that I would request that all switch positions have their own keybindings, all switches have a toggle key bind and all switches with more than 2 states have a cycle up and cycle down key bind, with the option to wrap around or stop at the highest/lowest position. The generation of those key bindings could reasonably be automated by labeling switches, switch positions and switch categories in metadata.

 

Doing this would allow the greatest freedom for setting up our input devices in any combination we desire.

Edited October 6, 2021 by FalcoGer

[cfrag]

I like the idea of a button to trigger on release (or more generally: to trigger on state transition). That being said, however, I think for clarity we should look at how DCS works with controller hardware.

 

The three-way switches in the TM Throttles may work slightly differently from what you describe. They are in hardware two separate switches that each only generate a signal when either in "up" or "down" position, and neither will generate a signal when in the middle (both off). So when you flip one of these switches up, the software sees (e.g.) button 15 depressed (on), and when you re-center them, button 15 stops indicating being pressed. When you then flip the switch down, it will indicate a different button (e.g. button 16) is being pressed. In effect, the Hardware pretty much only generates 'keypresses' similar to a keyboard, except it looks to the software that you keep holding down that button as long as that switch is in the up or down position. Now, depending on how the TM's microcontroller works, the two-state switches may ALSO work differently: They can either generate multiple signals for up and down positions (as different buttons, so for Windows, two different buttons light up for either position), or a single button that indicates ON when the switch is in one position, and OFF in the other.

 

It's also important to remember that for most high-end joysticks, you seldom see the state of any hardware in their raw state: there is a small computer (a microcontroller) inside that translates raw input to logical output as seen by Windows, it re-programs/re-maps "anything to anything". So we usually don't know, nor care how the real hardware is arranged - the microcontroller can flip, combine, mix and transmogrify any hardware input to generate any logic output. You often can control some of this with software the joystick vendor packages with the hardware. Some software may even be able to encode hardware button transitions to separate button presses.

 

Now, I still agree that I'd like to have that "Transition" option (a button firing on state change) supported natively in DCS, but that requires two significant enhancements:

• Detecting a button signal on state change rather than simply mapping current state (today, buttons don't generate a signal when their state changes on->off or off->on. The program simply reads the current state, and acts accordingly. That is very different from generating a signal when the value changes, as that requires retaining the last state for comparison. One is simply reporting a state, the other is actively triggering a function exactly once when the state changes/transitions). Currently, the modules individually implement state change detection based on the aircraft model state (i.e. gear up, flap notch down). I suspect that this is to manage complexity of the controls layer, and because there are very few real-world objects that work on switch transition - almost all work based on switch state (note: of all things, modern keyboards also work on button transition in addition to state, so go figure  ).
• When you are able to assign button transitions to functions, you must be able to assign the same button (but different transition direction) to multiple functions (say button 3 --> On maps to Boost Pump On, button 3 --> Off maps to Boost Pump Off). This may require extensive changes, and potentially makes the currently not-too-user-friendly Controls Interface even more cumbersome. It also often introduces hardware-to-model synchronisation issues when you start a model (or re-spawn) when switches are in different positions than the model assumes (initial positions versus actual), so this needs to be worked around as well.

I would like transition detection as an optional enhancement to the way it works today. I agree that this would greatly enhance the capabilities of DCS's control interface, and I'm strongly in favor of that. Until then, you may have some (DCS-external) alternatives:

• You can use macro software like Joystick Gremlin or Voice Attack (both excellent software, I'm affiliated with neither except being a satisfied user) to map a button transition to a function. This software can usually be configured to map differently for each game (but not differently for each module inside DCS)
• Use your hardware's software to implement this. It's been a while since I used TM hardware, but the Hog Stick/Throttle combos used to come with software (TARGET?) that you could use to program all kinds of advanced button functionality. My current hardware (Virpil) comes with highly advanced (and exceedingly user hostile, which seems to be par for the course for this kind of software) apps to re-program every switch - it can map button states (on/off) to different buttons, can create button signals for specific throttle positions, and (IIRC) even create a pulse (only have it briefly ON while a button is continuously depressed in hardware) on a button's transition to ON. Other microcontrollers' software may be able to 'latch' pushbuttons: report them an ON on the first push, and require a full cycle OFF-ON to turn them (logically) off again. Since all this is completely separate from DCS, this can simultaneously be a curse and and a blessing, because if you fly different planes this may not work, and (worse) create problems if you play different games (but who does that, is there any game life outside DCS? I think not  ) with the same joystick hardware.
   

Cheers

-ch

 

Edited October 6, 2021 by cfrag

[Tippis]

2 hours ago, cfrag said:

Now, I still agree that I'd like to have that "Transition" option (a button firing on state change) supported natively in DCS, but that requires two significant enhancements:

• Detecting a button signal on state change rather than simply mapping current state (today, buttons don't generate a signal when their state changes on->off or off->on. The program simply reads the current state, and acts accordingly. That is very different from generating a signal when the value changes, as that requires retaining the last state for comparison. One is simply reporting a state, the other is actively triggering a function exactly once when the state changes/transitions). Currently, the modules individually implement state change detection based on the aircraft model state (i.e. gear up, flap notch down). I suspect that this is to manage complexity of the controls layer, and because there are very few real-world objects that work on switch transition - almost all work based on switch state (note: of all things, modern keyboards also work on button transition in addition to state, so go figure  ).
• When you are able to assign button transitions to functions, you must be able to assign the same button (but different transition direction) to multiple functions (say button 3 --> On maps to Boost Pump On, button 3 --> Off maps to Boost Pump Off). This may require extensive changes, and potentially makes the currently not-too-user-friendly Controls Interface even more cumbersome. It also often introduces hardware-to-model synchronisation issues when you start a model (or re-spawn) when switches are in different positions than the model assumes (initial positions versus actual), so this needs to be worked around as well.

Isn't that the thing, though? That's already how DCS works internally — it's just not exposed on the bind screen because each function activation has the “on-press” and “on-release” bits hard-coded into their control definitions. The state changes are already what's being processed (and we already have that issue where controller state and in-game state are desynced, and where the “sync controls on start” option is… not really working at all for most complex inputs).

 

The change with this kind of scheme would be that, instead of having all these extra options (that the module developer may or may not choose to put in) for all the different potential variations of on-press/on-release combos needed to cover all the types of hardware, you could just list the core functions and let the player choose whether they should be activated on a press, on a release, or on a press-release combo.

 

It would require a fair amount of rework, granted, but only in the sense that all bind definitions everywhere (and that… quite a few in total )) would have to be discombobulated from their current state so that the press/release sequence is no longer part of that definition. But the rest is already how the game operates internally. As for complexity, that other game also already has exactly this and its highly popular alternative config/launcher software provides a good example of how the binding process can be implemented without being all that different, and not all that much more complex, than the way DCS currently works.

[cfrag]

7 minutes ago, Tippis said:

Isn't that the thing, though? That's already how DCS works internally — it's just not exposed on the bind screen because each function activation has the “on-press” and “on-release” bits hard-coded into their control definitions.

 

That may indeed be the case, good point - I honestly don't know, except that I do see the relevant tool tips enumerating the attached events in the assignment dialog, just like you say. Looking at the hardware config files, they currently only assign a button index to a named function, and it seems to me that a button is bound to the down event. Although quite possible, that doesn't necessarily mean that the engine today fully supports detecting and generating transition events, it could merely mean that when the engine detects an off->on transition, it generates the press_down event, and later generates the corresponding "release" event - but (my conjecture!) only does so if it was preceded by an on-event. Meaning: if a button starts in the wrong state, it won't generate the correct transition the first time. Also, I don't know if the engine has provisions to assigning separate triggers to send release-events to separate functions (i.e. the down/release events seem to bound to the function that is triggered, not the button that triggers it). So yes, with some luck the foundation is already there, and 'all' that is needed is a (major) tweak to the interface (and of course configuration files, hopefully backwards compatible, as setting up controllers for more than 20 modules is a hassle). 

 

[jvp89]

“<@273412638602690560> I think isn’t the first time that I mention that with no initiative from my side to put it on the wishlist for the dcs core, nevertheless would be cool to have some dynamic inputs settings like having a option for pressing and releasing a button on a joystick or hotas, that way we could use a switch in two ways. Like for example: pressing joy1 -> master arm On and releasing joy1 -> master arm OFF. To a switch that just counts or it’s activated only when is flipped up and nothing happens when’s down. And In this case leaving the developers no need to code special key commands to deal with that. ”

just post this in dcs discord, it’s almost the same ideia!! Hope that comes true!!

[FalcoGer]

I have no idea how DCS handles input internally. Generally in game design you have a game loop where you do mostly 3 things.

1. Handle Events
2. Update
3. Draw

You run this loop indefinitely until the event handling says it should not anymore. Naturally it gets more involved with exceptions and special cases and multi threading as software gets more complex.

Typically, at least I do so, event handling consists of either listening to windows events, which will be things like "mouse move, key down, key up." In some engines there are two methods of getting keys. A text mode and a key press and release mode. Text mode is used, who would've thought, to read text from the input device, such like when you press and hold a button it will fire the event in accordance with the repetition frequency set in your operating system, or automatically use capitalized letters in the event message when holding shift, etc.

The other is used for raw key events. A key event could include modifiers or not. A release key event could be it's own object type or it could be just a generic key event with the type member being release (which would be ideal here, but the other option wouldn't be infinitely harder if the class structure is sane, just dynamic type checking is slightly more complex and resource intensive than to check an enumerated value)

Typically in game design, whenever an event is fired you check if you want to handle it in a large select statement or list of if statements and if you wish to handle it, you then alter some data that is then evaluated in the update statement. Typically you don't poll the device for it's current state. You assume it didn't change since the last time you got an event message.

If this is indeed how DCS works then handling key up events would require marginal reworking. Some key up events are already handled though, such as the special options for 3 position switches like the A10C warthog throttle pinkie switch, which reverts to OFF when either key or button is released.

I envisioned it in such a way that the change for the user only means that it acts as another modifier, along with shift, alt or ctrl. This is distinguishing it from a normal press and allowing a normal binding and a release binding to exist at the same time (as with the other modifiers), and allowing the existing logic for assigning buttons to persist as it is, needing no further adjustments. In that way none of the existing bindings should be affected in any way. The special options existing so far could be marked deprecated or somehow automatically converted, but would remain unaffected directly.

This would create a unified interface, module makers don't need to worry anymore about if they should make any or all buttons have such a special options, needlessly bloating up the controls list or making people disgruntled about not having the laser arm switch in the ka50 be turned off if you flick the radar altimeter arm switch, to which you bound it, on the warthog hotas, but at the same time have the master arm switch do exactly that with the EAC arm switch.

[Tippis]

It's worth just having a quick look at how binds are actually defined in DCS, and why this option isn't really a big ask, comparatively.

The simplest and most immediate example I could find was in the universally available TF-51 module, straight out of DCS World\Mods\aircraft\TF-51D\Input\TF-51D\joystick\default.lua where the plane's base controls are set up:

{down = iCommandPlaneUpStart, up = iCommandPlaneUpStop, name = _('Aircraft Pitch Down'), category = _('Flight Control')},

It's pretty self-explanatory, really. If the bound control is detected in a “down” state, send the internal iCommandPlaneUpStart message to make the aircraft pitch down. If the bound control is detected as released — “up” — send iCommandPlaneUpStop and stop pitching down. This control is set up this way because you want a continuous pitch change as long as the button is held, rather than pulsed inputs depending on some arbitrary polling rate. This is not how all controls are set up and the choice of how you want the controls to behave will obviously depend on what kind of control it is. For some, you might want that pulsed input, for others, the underlying controls are set up in such a way that it won't really matter and you don't need separate start and stop states. Further down in the same TF-51 input definition file, for instance, we find this for trim controls:

{pressed = device_commands.Button_11, cockpit_device_id  = devices.CONTROL_SYSTEM, value_pressed = -0.1, name = _('Trim Aileron Left'), category = _('Flight Control')},

Here, every polled event where a button press is detected yields a change in a numerical value — start and stop events run the risk of making that value spin too quickly or too slowly or just not precisely enough.

 

Basically, the functionality is there and is ubiquitous in all modules. What this kind of option would do is allow the player to separate the “down” and “up” commands in the bind above and assign different device inputs to them. But to offer full customisation, it also needs to sort of work the other way around: things that right now are set to trigger on a button down event need to be assignable to a button up; some momentary actions might need to be split apart; and some up/down combos might need to be possible to chain together so that a singe button push activates both the commands, regardless of whether a button-up event is detected or not.

The tricky part in making this player-controllable rather than something that is hard-coded into the module itself is that 1) you have to expose a lot more of the guts of the underlying input messaging, 2) defaulting will require a huge re-think since you'll still want both that press and release action on the same button by… well… default, and give the option to separate the two if the player's input device works with that kind of setup, and 3) there's a huge number of input definitions that will need to be looked over and separated in this way in modules that have barely been touched for almost a decade. It's a pretty significant amount of work for what is technically a fairly simple change, to the point barely being a change at all.

But, again, it means that the player will have to work closer to the subsurface command messaging rather than the more immediately obvious descriptions of what any given input is doing on a higher level. This is a level of geekery and faff that not everyone will enjoy or want to bother with. To re-use that first example, it's much easier for the player to grasp “press this button to pitch down” compared to having to juggle “press this button to start pitching down” vs. “release this button to stop pitching down”. The three-way balance between good defaults, clear descriptions of actions, and customisability will be tricky more from a user interface perspective than anything else.

[FalcoGer]

I don't think it's necessary or smart to expose the guts of the message system to the player. It makes a complicated setup even worse. There needs to be no change other than the extra key binding option. To use your example if the player binds key release to pitch down (which would be possible but stupid to do), then releasing the key would from then on continuously pitch the aircraft down and when pressed it would then send the stop pitch down message.

Or the other example when the key is released, the aircraft would trim roll with a value of -0.1.

In that way nothing else has to change, no key bindings have to be looked over or redone as a dependency of this, and you get all the extra functionality that is required.

If you were to introduce the underlying message system, it would basically ask the players to program their own input system, potentially with cryptic message names, which is a bit much. It would also require this single change to have a knock on effect on all modules, so every developer needs to go over all their modules and redo inputs. All the players will have to rebind all their buttons. It's a huge mess and a big no-no.

Sometimes such changes are necessary, but this is not one of those times.

All I want is that if I put a button on my control into the off position (i.e. the button press vanishes from DCS's point of view) then the switch in the cockpit is toggled. And I want that option for all available switch positions. And to do that the simplest option is to have an on release settings for each key bind. The switches should have a "switch on", "switch off" and, "switch toggle" by default. Everything else should be up to the player.

Edited October 25, 2021 by FalcoGer

[FalcoGer]

This seems to have been quietly added (or I'm blind) to one of the latest OBs in the form of "button_off" bindings.

Thank you ED.