Duplicated lines in Options/Controls: Now mostly fixed

[LeCuvier]

A number of modules now show duplicated control binding lines which are displayed in orange.

This happens in cases where the same command is defined in two or more "default.lua" (or equivalent) files (for example one in the folder "joystick" and one in the folder "keyboard"). Normally these should show as one line in Options/Controls.

Due to the bug, we now see two lines. One of them allows binding only to a keyboard key, and the other one allows binding to the other devices like joystick. In some cases, the second line allows binding to all device columns.

 

 

I have seen the issue in the following modules:

AJS37, A-10C, F-5E, F/A-18C, FW-190D, Mig-21bis, NS-430, P-51D, Spitfire

 

Some aircraft don't show the issue at all (e.g. Bf-104K4, F-86F, Ka-50)

 

 

 

Further, there are cases where the "default.lua" has duplicated lines. Options/Controls now shows both of the duplicated lines and allows binding to them. I saw that in the AJS37 and in the AV-88NA.

 

 

I include a screenshot from the AJS37. The lines for "Autothrottle mode AFK" are due to duplicated lines in the "default.lua" under "Joystick". The other cases are from "default.lua" under "joystick" and "keyboard".

 

 

The issue causes user confusion.

Edited August 10, 2021 by LeCuvier

[Kiwispirits]

I have this problem as well. It appeared after installing F-14, then mapping some controls and axes for the F-14. My viggen mapping now has lots of duplicated red lines in it.

[Kiwispirits]

Tried uninstalling and reinstalling the Viggen, still have the duplicated lines and no way of removing them

[Redglyph]

A number of modules now show duplicated control binding lines which are displayed in orange.

 

To add some information on this issue:

 

I observed the same problem with the kneeboard controls on the MiG-19P but it disappeared on its own after starting a mission with the module and restarting DCS a few times (for other reasons). I changed other bindings so it may be due to that.

 

When I'm looking now at Config/Input/MiG-19P/keyboard/keyboard.diff.lua, DCS added one (?) of them as "removed" without my intervention. This command is in the common files, Config\Input\Aircrafts\common_keyboard_binding.lua (while yours is in the module's defaults):

local diff = {
["keyDiffs"] = {
	["d3003pnilunilcd100vd1vpnilvunil"] = {
		["name"] = "Kneeboard current position mark point",
		["removed"] = {
			[1] = {
				["key"] = "K",
				["reformers"] = {
					[1] = "RCtrl",
				},
			},
		},
	}, 

 

I confirm the same duplicated orange lines as you for the Viggen, but I haven't flown it so I can't say about the "auto-repair" which happened on the Farmer.

[Sajarov]

Any solution to this problem?

[HiJack]

The same problem in Combined Arms also.

[Mikkall]

Also wishing for a solution here. This hit me today when I fired up DCS.

 

Last night, everything was running normally, with one exception. When I tried to scroll the Data Cartridge it simply wouldn't (Lctrl-Lalt-C). I checked the controls a few times but no go. On a whim, I mapped that control to a toggle on my TM Warthog throttle... it worked. I ran a couple of missions and logged off. When I got DCS running today, I found the auto-pilot disengage button (warthog throt) wasn't working on the F-14. So I mapped it to the RDR-ALTM toggle on the Throttle, and it worked. After the mission I checked the controls and found it was still mapped to the original button (but, no dual-yellow lines). Then I got the Viggen going and found I couldn't turn pages on the kneeboard... checked controls and bingo, lotsa dual-yellow lines. I briefly skimmed through and saw a few others... Mig-21, C. Eagle, J11.

 

REALLY would like to get some answers here. This kinda screws everything up.

Edited April 8, 2019 by Mikkall

[LeCuvier]

...REALLY would like to get some answers here. This kinda screws everything up.

Control bindings have become a source of instability. And ED has made it ever more complex.

A) We now have 2 (TWO) sources of default binding definitions:

1. The lines beginning with "combos" in the file "default.lua". They cause the infamous multiple bindings when you add or change a game controller.

2. The default profile files ("...diff.lua" which now sit alongside the "default.lua"

B) Developers have duplicated lines in "default.lua"

C) Identical commands in the "default.lua" under "joystick" and under "keyboard", which used to be combined in one line in Options/Controls, now show as two separate lines with orange font (which normally signals an issue!)

D) Control bindings disappear sporadically and I don't know whether that's caused by A/B/C above or a completely different cause.

 

All of this combined creates some level of chaos and it's only understandable that people get confused and angry.

 

I would recommend for ED to get rid of the default bindings per A.1 and A.2 completely. And of course, the bug per C must be fixed.

 

For myself, I have begun to remove the "combos" statements from "default.lua". It's tedious and time-consuming as I have a fair number of modules, so progress is slow.

[Mikkall]

Tried uninstalling and reinstalling the Viggen, still have the duplicated lines and no way of removing them

 

 

And I downloaded DCS-Stable, installed Viggen, 14, 18 and the problem showed up there.

 

C'mon ED, this is game breaking stuff.

[Mikkall]

 

For myself, I have begun to remove the "combos" statements from "default.lua". It's tedious and time-consuming as I have a fair number of modules, so progress is slow.

 

Which "default.lua(s)?"

[LeCuvier]

Which "default.lua(s)?"

If we take the Viggen in OB as example, the "default.lua" is in the folder "\Eagle Dynamics\DCS World OpenBeta\Mods\aircraft\AJS37\Input\joystick". The defaults that cause problems are in the "axis" section down around line 385:

{[b]combos = defaultDeviceAssignmentFor("roll")  ,  [/b]action = iCommandPlaneRoll           , name = _('Roll')},
{[b]combos = defaultDeviceAssignmentFor("pitch") , [/b] action = iCommandPlanePitch       , name = _('Pitch')},
{[b]combos = defaultDeviceAssignmentFor("rudder"), [/b] action = iCommandPlaneRudder       , name = _('Rudder')},
{[b]combos = defaultDeviceAssignmentFor("thrust"), [/b] action = iCommandPlaneThrustCommon, name = _('Thrust')},

After removing the "combos" statement (bold letters above), they look like this:

{action = iCommandPlaneRoll           , name = _('Roll')},
{action = iCommandPlanePitch       , name = _('Pitch')},
{action = iCommandPlaneRudder       , name = _('Rudder')},
{action = iCommandPlaneThrustCommon, name = _('Thrust')},

Note 1: an update or repair will restore the original file. I use OvGME to back modified files out before the update and restore them afterwards.

Note 2:

There are also combos statements for key commands, like these:

   {combos = {{key = 'E', reformers = {'RShift', 'RCtrl'}}}, down = 3405, cockpit_device_id = devices.FLIGHTDATAUNIT, value_down =1.0, name = 'Ejection seat arm', category = 'Flight Control'},
   {down = 3405, cockpit_device_id = devices.FLIGHTDATAUNIT, value_down = 0.0, name = 'Ejection seat Safe', category = 'Flight Control'},
   {combos = {{key = 'C', reformers = {'RShift', 'RCtrl'}}}, down = 3406, cockpit_device_id = devices.FLIGHTDATAUNIT, value_down =1.0, name = 'Canopy close', category = 'Flight Control'},
   {combos = {{key = 'C', reformers = {'RAlt', 'RCtrl'}}}, down = 3406, cockpit_device_id = devices.FLIGHTDATAUNIT, value_down =-1.0, name = 'Canopy open', category = 'Flight Control'},

These don't cause conflicting commands.

Note 3:

The file for the Viggen contains a pair of lines that's not just duplicated but triplicated: The "Trim: Rudder Left" and "Trim: Rudder Right".

In lines 30, 31:

 {pressed = iCommandPlaneTrimLeftRudder, up = iCommandPlaneTrimStop, name = _('Trim: Rudder Left'), category = _('Flight Control')},
{pressed = iCommandPlaneTrimRightRudder, up = iCommandPlaneTrimStop, name = _('Trim: Rudder Right'), category = _('Flight Control')},

Then in lines 329 - 332:

{down = 3713, value_down = -1.000000, up = 3713, value_up = 0.000000, cockpit_device_id = devices.FLIGHTDATAUNIT, name = _('Trim: Rudder Left'), category = _('Flight Control')},
{down = 3713, value_down = -1.000000, up = 3713, value_up = 0.000000, cockpit_device_id = devices.FLIGHTDATAUNIT, name = _('Trim: Rudder Left'), category = _('Flight Control')},
{down = 3713, value_down = 1.000000, up = 3713, value_up = 0.000000, cockpit_device_id = devices.FLIGHTDATAUNIT, name = _('Trim: Rudder Right'), category = _('Flight Control')},
 {down = 3713, value_down = 1.000000, up = 3713, value_up = 0.000000, cockpit_device_id = devices.FLIGHTDATAUNIT, name = _('Trim: Rudder Right'), category = _('Flight Control')},

So when you bind a switch to "Trim: Rudder Left" you have no idea to which one of these lines you are binding. I removed the lines 329 - 322. I had to re-bind one of the commands because it was bound to a deleted line; but from now on it should be stable.

Last note: all edits should be done with the free Notepad++ or equivalent.

[Mikkall]

Much appreciated. Thank you.

[Knock-Knock]

Mirage is hit by this too. Pretty much all kneeboard bindings and some countermeasure program selector thing.

[LeCuvier]

It's obviously a problem with control bindings in general. Not a problem of one or few modules. If some modules don't show it (yet?) it might be just a question of time before they show it too.

I have reported the problem in November last year, but the thread does not show as [REPORTED] which probably means that ED or the moderator are ignoring it. Ignoring => no action. I hope I'm wrong.

[SGT Coyle]

+1 on everything LeCuvier said.

Please make resolution of this bug a priority.

[Mikkall]

It's obviously a problem with control bindings in general. Not a problem of one or few modules. If some modules don't show it (yet?) it might be just a question of time before they show it too.

I have reported the problem in November last year, but the thread does not show as [REPORTED] which probably means that ED or the moderator are ignoring it. Ignoring => no action. I hope I'm wrong.

 

Took the Viggen out last night and the Kneeboard (what initially caused me to notice the problem) worked fine... as did Trim controls. Both still show duplicates int he controls setup. Weird stuff, even the bug is buggy.

[BaD CrC]

All helicopters have this problem too. Not a show stopper but confusing.

[Hamilton]

+1 on everything LeCuvier said.

Please make resolution of this bug a priority.

 

+1

[imacken]

Been several threads on this already, and I haven’t seen one that is marked [REPORTED]!

[rob10]

Sorry to revive an old thread, but I solved this (very easily) after a considerable amount of searching/playing and this was the most relevant thread that came up when I started my search, so I figured I'd come back with my solution.

 

 

What it seems is that if you have a command "name" - say "Landing Gear UpDown" - in more than one .lau (for example keyboard and Joystick - HOTAS Warthog) AND they have DIFFERENT CODING it will give you the duplicate and orange colour. So when I edited so that an actual switch (rather than a button) would RAISE and LOWER the Gear in the Joystick .lau depending which way it was thrown but left it named as "Landing Gear UpDown" (same as the push button in the Keyboard .lau) you get the orange duplicate. If I change the name in the Joystick .lau to "Landing Gear UpDown - 2 pos" it still has 2 entries but no orange colouring.

 

Fortunately this is cosmetic anyway, but nice to get rid of it since it was a distraction and I wasn't sure it was just cosmetic.

If the entries are in RED, then you likely do have an actual problem somewhere.

[AstonMartinDBS]

Same issue here (current OB)

[DimSim]

This reappeared again for me after installing F-16C, though it is the Mirage 2000 that has messed kneeboard bindings.

Last time, I fixed by editing the Mirage keyboard config and deleted duplicate config entries. This time there are no duplicates and the config file is identical to a backup I made months ago.

Have not found a solution yet, but I need that kneeboard to work in flight!

 

Beta 2.5.6.55960

 

EDIT: Some minutes later, after about 4 restarts, since I was checking version and testing other aircraft profile, the issue has disappeared. I did nothing. I did not modify the config files. It appears this is an intermittent bug, or part of a group of related bugs.

[TAW_Impalor]

Hello. Any progress on identifying the cause of this bug? I am having the exact issue as in the previous post: my custom keyboard binding to operate kneeboard in Mirage sometimes stop working and duplicate orange lines appear instead. Restart DCS and the issue MAY go away. Super annoying as it prevents me flying Mirage on MP servers that require full alignment. 

[Frederf]

Orange labels indicate that the text label is identical despite the action definition is different. In certain cases this is not even a real problem except for the warning color.

 

For example if keyboard/default.lua has "This Cool Action {up = action.3333 down = action.6666" and joystick/default.lua has "This Cool Action {up = action.5555 down = action.1111" then you'll get two listings in the action list with "This Cool Action" but they won't share the same line in the table because their programmatic contents are different. You'll notice in the examples above the keyboard action only has a keyboard cell in the grid and is missing the joystick cells while the next duplicate action is the opposite.

 

If you just go into one of the lua's and change it to say "This Cool Action (joystick)" you'll see the highlight go away as now different action definitions have non-identical text titles.

[LeCuvier]

I agree it generally doesn't cause any malfunction, and therefore it's not a critical defect. But the orange color generally is meant to signal an issue and therefore it causes confusion and should be considered a bug. I'm referring to the frequent situation where the "default.lua" files under "\joystick" and under "\keyboard" have identical lines.

Earlier versions of the software showed this as a single line in Options/Controls and in black. And somewhere around March 2019, ED made a change to the software which brought us to the current situation. And as it's low priority it might stay with us forever, unless a lucky software change brings the smarter logic back.

Edited August 8, 2021 by LeCuvier