Controls / key mapping

Please set an option in controls / key mapping to define each function as a toggle key, up and down switch and analogue axes for every module.

It´s a pretty mess, what we are doing so far with external tools, .lua editing and what not, to map the keys for our simpits.

In addition to the three types of buttons and switches mentioned above, there would be also a type of switch with an up-, center- and down-position of great advantage to map our simpits properly.

Another pain in the *** beside the absence of these control options is, that with every DCS update or patch, we are forced to redo all the adjustments to our individual hardware configuration for every module!

Love the progress DCS is taking with every update - this is a wish to bring to your attention.

Every option? Only the relevant ones certainly.

But this isn't just up to ED, this is up to every module developer to implement individually.

Yeah, I was actually thinking of the same options for every key function.

What we need is a general overhaul of the control setup. Looking into each key/function to decide how it might be mapped for a hardware switch, is much more work for the developer, than the invention of a general standardized option menu for every key/function, to enable the user to customize the function for his individual hardware and concept of mapping. Furthermore a general option menu should work for every module the same. If someone at ED do care for it and developes a working algorythm for it, then it could be hand over to any 3rd party developer as a template, where the 3rd party developer only need to fill in the usable functions of its own new module and don´t need to spend time and work into inventing an own concept for mapping his module.

Just read through the forum: there are everywhere issues with the key mapping for most of the modules. And there will be many more modules coming, following the current announcement. This will escalate the messy situation with configuartion setup, we are currently facing. There need to be a standard for key mapping, which satisfies all the different hardware and simpit configuration out there.

It´s not that someone made a mistake, it´s about paying attention to the development of hardware configuration on the user side.

With recent update, there was an improvement with the configuration setup, but there is still space for some more significant improvement.

Adding an option menu to each function the same, where each user could choose, if a function should be bind as a) a toggle key/button b) a switch key with up/ down c) a switch key with down/up and d) analogue axes is less work in the development, than looking into each key separately.

With these four options for every key, every user is free to customize the functions for his individual hardware configuration.

You´re surely right saying it doesn´t make sense to have an option for an analogue axes for an obvious switch key, like gear up/down, but people are not stupid and won´t map this option unless one decides, that it make sense for his own configuration by having mapped on to analogue axes. The point is, that the function need to be customizable by the user and not predefined by the developer, what is neither satisfying for the user, nor for the developer.

Another interesting example might be the cockpit lighting for the F-14 Tomcat, which is in the cockpit done by a up/down function in 9 steps - for the user it would be much better to have this mapped on analogue axes, if he got an analogue hardware switch and there were an option to customize the function within the control setup.

Also the developer are forced to push out the modules as fast as possible, but the experience shows, that the control setup at this stage in module release is always neglected and the graphical issues always got priority before there is even time for a developer to take care of the control setup.

In my opinion a proper control setup with the freedom for customization for individual hardware has got a much more bigger impact on the DCS experience, than having four types of clouds for example.

Another argument to bring standard customizable functions to the control setup is the increased development of additional hardware on the market for flight sims, like the new VKB Thrust controller, new button boxes, and more of this. Everything grows, DCS modules, supporting flight sim hardware and user demands. To face this growing development there need to be some advanced standards for the growing complexity.

Sorry can't agree with most of what you wrote. Ranging from the "not realistic goal" to the "actually more work to module developers" to the "you don't understand the scope of it".

Now that you´ve mentioned, lxsapper, I can´t do any other than totally agree with you, that it is defenitely not a realistic goal to configure your HOTAS as you wish it.

And for sure, as you noted, it is actually more work to module developer setting up three binding methods for any key, than setting up three different binding methods for hundreds of keys.

But the most embarassing of your comment is that you don´t understand the scope of it, which is why any medium intelligent person is able to redo the missing configuration options by editing the default.lua for exactly the attitude the switches need to have, what surely is the intention of the developer, right?

Sorry man, but you better get back commenting in the "we-want-a-Tic-Tac-Toe-UFO-in-DCS" thread or any other kindergarden discussion.

Well, this thread sure is headed for a quick closure with that kind of mudslinging…

Which is all kinds of silly since the OP's suggestion isn't particularly out there, unrealistic, or in any way excessive. The functionality already exists in the game — it's just not exposed on the bind screen and everyone is instead limited to ugly non-permanent hacks or restricted to what the module developers can be bothered to implement based on their understanding of what's reasonable to provide to a good segment of the userbase.

If it was possible to simply assign — for any given input — whether it should trigger on button down, button up, or both, all that hassle would be gone. The developers would just have to list the bindable function and wouldn't need to consider what switch abstractions might be useful. Users would not have to worry about how to translate those inputs and abstractions to their specific setup of buttons, toggles, latches, switches, dials etc. No custom LUA would be necessary to cover pretty much all conceivable input devices.

It would greatly simplify everything for everyone (except for ED in implementing the UI and the bind-translation code… but that would be a one-time affair).

It´s something wishful meanwhile, as I used to edit the default.luas now for years with all the inconviniences accompanied.

Regarding my response I wouldn´t give an explanation too much space here as it is not my topic.

Just let me mention, that this response is more the reflection of the attitude in the addressed comment, which me personally makes me stay away from discussions, even I would like to add something or participate in.

The attitude of formulating a comment around provocation instead of dialogue related statement is quite present in any Internet forum. It´s easy to scare these, as the weakness in these commenting minds are obvious.

My wish here is important for me and I don´t want to have a low-level communication connected to it.

Well, I won´t change anyones attitude - people are what they are... maybe Internet forums are not for me and it´s sometime better to stay away from these.

Thank you for your understanding and sum up my intention in better words, than I could do as a not native english speaking person.