LeCuvier

@LowRider88: I'm not an experienced F-5E pilot, and I'm trying to replicate what you say, dogfighting off-line against a "Trained" AI MiG-21bis. The first couple of rounds saw me going down burning. So I changed my tactics. I avoid pulling too much G so I stay close to 300 kts. The action starts at about 35000 ft altitude but the dance rapidly descends to very low altitude and after several circles I get into a good position, and I either get him with the guns or he just crashes. The difficult part is not to lose him or stall when he climbs like a rocket, which is what he does when his position gets critical. Questions: 1. I keep the flaps in "Auto". Is that ok? 2. I read about "manoeuvring flaps", but I find no command binding for that, no matter what spelling of "manoeuvring" I look for. Is there any?

Yes, that would suit me fine. I hate the thing, and I have removed it from all the missions that I have created or modified.

Good information, I didn't know we had that command in the menu and tried it immmediately. It works, but don't forget to open the canopy before you ask the ground crew to remove the gun! In my opininion we should have a command for removing the flare gun in flight. I believe that the pilot could do that.

All the Interior Light knobs work fine with the mouse here. Both methods work - hold left button down and move the mouse cursor UP /DOWN - scroll wheel (for small movements)

@Flappie I don't want to finger-point, but this glitch shows that there is (or hopefully was) a gap in the test plans. I expect that your team has plugged the gap and it won't happen again. But there is another concern: This is a rather disastrous bug and it's all over the place in the forum. It's a show stopper for a lot of people. In my opinion ED is taking far too long to provide a fix. In my opinion, this would have deserved an emergency update. I reported this bug on 21-NOV-2021 and you confirmed it the same day (which I found positively remarkable). We have now suffered from it for almost a full month. That's too long for a show stopper. If a personal note is allowed: The management of control bindings is a permanent can of worms, and the binding name localization for WWII aircraft is an additional headache nobody needed. If I had to decide, I would get rid of it altogether and revert to the original binding names.

The Laser Arm switch can be controlled by a ON/OFF switch if you add this line to the file "default.lua": {down = sms_commands.LaserSw, up = sms_commands.LaserSw, cockpit_device_id = devices.SMS, value_down = 1.0, value_up = 0.0, name = _('LASER ARM Switch 2-Pos ARM/SAFE'), category = {_('Instrument Panel')}},

No. But as far as I see you have added the 2 lines of code twice: In lines 235 & 236, plus in lines 1015 & 1016. You must not duplicate lines of code! I recommend you delete the ones in lines 235 & 236. Also, enter a comment in line 1014 like "-- Lines added by myself" The "--" at the start of the line makes this a comment which is ignored by the software but helps you to find your additions. You will probably also want to add the missing lines for the Pnky Switch. And more...

You will have to copy the LUA code lines for the Warthog Throttle commands from "Throttle - HOTAS Warthog.lua" and paste into "default.lua". Both files under "...\DCS World OpenBeta\Mods\aircraft\A-10C_2\Input\A-10C_2\joystick". Don't use a word processing program for this. Notepad++ is fine. Make sure you copy complete lines including curly brackets and the commas at the enf of lines! If you miss any of those the file will no longer work.

That's for the keyboard bindings. The bindings for joystick,throttle etc. are in "DCS folder/mods/aircraft/bf-109k-4/input/bf-109k-4/joystick". We have statements from ED indicating that this binding name bug should be fixed in the upcoming update before Christmas.

This button is programmed to rotate at a fixed "speed", until its position matches the axis input value. There is nothing we can do about this behaviour. In "clickabledata.lua" the clickable rudder trim wheel is represented by this line: elements["RTRIM_WHEEL"] = default_axis_limited(_("Cockpit.SpitfireLFMkIX.trim_rudder"), devices.CONTROLS, device_commands.Button_44, 146, 0.0, 0.1, false, false, {-1.0, 1.0}) The 0.1 near the end of the line "... 0.0, 0.1, false, false, {-1.0, 1.0})" is the gain for the object type "default_axis_limited". It seems to have no effect for the rudder trim knob. I created a new axis command bound to the cockpit button and increased the gain to 0.5, but the button still turns at the same slow rate.

In "default.lua" I find these lines: { down = device_commands.Button_58, cockpit_device_id = devices.FUSEBOX, value_down = 1.0, name = _('Input.Bf109K4.cb_e103_1'), category = _('Engine Controls')}, {down = device_commands.Button_58, cockpit_device_id = devices.FUSEBOX, value_down = 0.0, name = _('Input.Bf109K4.cb_e103_0'), category = _('Engine Controls')}, {down = device_commands.Button_59, cockpit_device_id = devices.FUSEBOX, value_down = 1.0, name = _('Input.Bf109K4.cb_e103'), category = _('Engine Controls')}, So: "Input.Bf109K4.cb_e103_1" --> Governor ON "Input.Bf109K4.cb_e103_0" --> Governor OFF "Input.Bf109K4.cb_e103" --> Governor toggle ON/OFF Personally I use a more realistic 2-position switch command I added to the file: {down = device_commands.Button_58, up = device_commands.Button_58, cockpit_device_id = devices.FUSEBOX, value_down = 1.0, value_up = 0.0, name = _('Engine Governor 2-Pos AUTO/MANUAL'), category = _('Engine Controls')},

I suspect that, for some reason, the Resolution selected on the Optios/System screen does not match the actual resolution of your monitor. I tried this hypothesis on my system. My monitor has a resolution of 2560 x 1440, and normally that's what I have selected in Options/System. When I change that option to 4240 x 1440 then my monitor shows the left 60% of the DCS World screen spread over the entire width of my monitor. That sounds about like what you describe. If my guess is right: Just set the Resolution in Options/System so that it matches your monitor's pixel size. You should find the right values in the dropdown, but you can also overwrite it if you don't see the right values. And if you don't use a multi-monitor configuration, the field "Monitors" should be set to "1 Screen". If this doesn't help you need to provide more specifics about your setup, plus a screen copy of the Options/Systems page.

Sounds like you haven't fully read my original post. I'll say it short and sweet: The file produced by the "Make HTML" function shows the bindings not only for the selected device. That's the point of this bug report.

One of my queries does that; but it does not tell me whether or not a given command is available for the keyboard and that's the core of the issue as I stated in my initial post.

That's about what I'm doing, but I take it from Excel into a MS-Access database. That's a better tool for data work. I've set filters to hide the axes based on the hash field, and everything that has "Special for Joystick" in the category. Apart from those I don't see anything I could use as filter criteria.

I have not used the RWR export recently due to its limited value. But I'm sure ED has made some change in this functionality, because the F/A-18C RWR display in Helios, which used to work ok, produces only blurs since the last update. I do not intend to invest more time into this.

The "Make HTML" function should produe a list with theavailable commands and their bindings for the selected device/column. In older releases it produced a very basic output, but it did list the commands for the selected device. In the current version it produces improved content, but the commands in the list are not limited to those available for the selected device. So, for example, the list for the keyboard includes all axis commands, plus commands that are only available for HOTAS devices. As an example I attach the Keyboard file for the F/A-18C. It contains axis commands at the end of the file. I can actually filter the axis commands out based on the "Hash" starting with "A". But there is no way to filter the commands that are only available on HOTAS devices. I'm trying to use this file to manage keyboard bindings for the Hornet, but with the current content it's useless for my purpose. I wouldn't mind having all commands listed if there were a field indicating the which devices can use the respective commands. Keyboard.html

Yes, consistency in structure and wording is key to make VA usable at a large scale. Plus, I discovered you have to use correct English. Example: I had commands starting with "Wingman" (I'm German and tend to join nouns), and I pronounced them loud and clear. But VA never recognized them. Reason: The Windows speech recognition would return "wing man" (which is correct English I believe) while VA expected "wingman", and VA is not smart enough to understand that these are equivalent.

Yes I know, it's a very inconsistent language.

So far I have only created the voice commands for communication with wingmen, as they have default bindings and they are good for all aircrafts. When I looked at Hornet-specific commands I found that none of those I wanted to start with had default key bindings. So I will now start with figuring out a good approach for defining sets of key combinations that make some sense and that don't conflict with the few ED has provided. I'm not going to try and get a few commands in quickly; I want to do it right.

Background: I'm trying to set up Voice Attack profiles for the Hornet (could be any other module). This requires that I assign keyboard key sequences for each of the commands I want to triger by speech. Sounds easy. Issue: The Hornet has about 1000 commands that can be bound to keys, but only about 240 have default key sequences defined. In simple words, only about 25% of the possible commands have default key sequences. For all other commands (the ones I'm interested in), I have to decide which key sequence I want to use, and enter them in Options/Controls, before I can do anything in Voice Attack. That's a huge task being dumped on the individual users. And there is a fair chance that over time ED will define default keyboard bindings for some of the commands and use key sequences that we have already used for other commands. The potential for confusion is great. And a lot of duplicated effort across the user community. Because, the problem I'm having with Voice attack is the same for users of TARGET or any other software that generate keyboard key sequences. My request is that ED should provide complete sets of keyboard default bindings early on in the life of a new module.

That's fairly easy. First, add this line of code to the file "Throttle - HOTAS Warthog.lua", in the "axisCommands" section close to the end of the file: {action = 3001, cockpit_device_id = 7, name = _('HUD Brightness Axis')}, Then bind the new command "HUD Brightness Axis" to the slider. Finally open "Axis tune" and set Saturation Y = 50% This is necessary because the command uses only 50% of the input signal range) Slider = True (ticked) Invert = True

You guys are sharp! Yes, the default bindig is for a single slider driving the thrust for both engines. So maybe the guy has not replaced the default bindings with the desired one?

The option "Synchronise Cockpit Controls ..." is nothing to do with that issue. I would suspect there is a problem with the throttle device. Have you tested it in Windows "Devices and Printers"? Do both axes show movement?

The issue is reported and, according to @Flappie, internally fixed. We should see the fix in the next OB update.