LeCuvier

It seems to me that this is a "very early" access release. Looks like they were in a hurry to release something to generate revenue. Hopefully Magnitude 3 will add a lot of bindings over the coming months (or years? ) and hopefully they will try to be as good as Heatblur in this; the Phantom 4 is a model for doing it right! So any work you do yourself adding bindings needs to be re-done when the stock file has changes/additions after updates, unless you use the Command Injector by @Quaggles (which I do). I did experiment a bit and found that the Magnitude 3 approach is pretty much in line with how ED does it. So the same approach to modding should work fine. The limitation for modding is what handles they provide in "clickabledata.lua". I looked specifically at the flaps switch. Flap positions range from 0% (UP) to 50% (DOWN). The stock commands (+/-) change the flap position in steps of 10%. So in order to go from UP to DOWN you have to click the bound button 5 times. I don't like that. I want to switch directly between UP, DOWN and 30% (for takeoff from carrier), using the 3-position flap switch on my TM Warthog throttle. I ceated 3 new lines in the "default.lua" under Saved Games (using the Command Injector): {down = device_commands.iCommandFlaps, cockpit_device_id = devices.CONTROL, value_down = -1.0, name = _('Flaps to 0 DEG (UP)'), category = _('Flight Control')}, {down = device_commands.iCommandFlaps, cockpit_device_id = devices.CONTROL, value_down = 1.0, name = _('Flaps to 50 DEG (DOWN)'), category = _('Flight Control')}, {down = device_commands.iCommandFlaps, cockpit_device_id = devices.CONTROL, value_down = 0.6, name = _('Flaps to 30 DEG from UP'), category = _('Flight Control')}, The command "Flaps to 30% from UP" is bound to the OFF event of the Flaps switch "UP" position. It does nothing when you use it from the DOWN position I tried this on my rig, and it works fine..

This should not happen unless you hit one of the "Clear..." buttons on the binding screen. The bindings are saved in one file per game controller under Saved Games in the folder "C:\Users\YOUR_USER_NAME\Saved Games\DCS\Config\Input\F-16C_50\joystick". These files have the extension ".diff.lua". Keyboard bindings are in the folder "...\keyboard". Just in case you have some instability in your set-up, you may want to save backup copies of these files in a safe disk location.

The Heading and Course setting switches are not meant to be bound to Rotary Encoders. I have bound them to UP/DOWN toggle switches on my button box and that works fine. Rotary encoders produce a burst of very short contact closures when you turn them. The Heading and Course switches need to produce prolonged contact closures for as long as you depress the switch UP or DOWN. I use rotary encoders for HMD OFF & Brightness, and for the AAU-52 Altimeter Pressure knob, and they work fine there.

I recommend to use the Command Injector by @Quaggles. With this solution, your default.lua adds are in default.lua files under Saved Games. See https://forum.dcs.world/topic/270487-quaggles-dcs-input-command-injector-mod-store-custom-input-commands-safely-in-saved-games-instead-of-merging-them-with-developer-changes-each-update/#elControls_4651461_menu This involves replacing the original "Data.lua" under "...Scripts\Input" with the one modified by the author. You obviously have to back this modified file up, but it's only this one file as opposed to multiple "default.lua" (depending on how many aircraft you have). But the big advantage of this solution is that you don't have to rework your mofified "default.lua" when ED makes changes/additions to the original one. Also, lots of additions were compiled by @Munkwolf. They are available here: https://github.com/Munkwolf/dcs-community-keybinds

Since some time now (over several releases) I see that the replay does not show what really happened. After very few minutes, it shows me firing into the air far away from my targeted bandit. It doesn't matter which aircraft I fly. This makes the tracks totally useless for documenting bugs or simply reviewing my mission. Am I the only one experiencing this?

Of course they can. But they obviously don't see this as a priority. This thread starts in January 2021 and they have never responded in any way.

I was eager to try the new "Save Mission" feature. So I started a Bf-104 mission from the "My Missions" folder "C:\Users\hans\Saved Games\DCS\Missions\Bf-109K-4\Caucasus". I ended the mission in the middle and hit the "Save Mission" button. When the new screen "Export to Miz:" screen popped up, it showed the missions in the FW-190D folder "C:\Users\hans\Saved Games\DCS\Missions\FW-190D9\Caucasus" (attached screenshot). I tried the same process with the A-10C II and the F/A-18C, and the same FW-190D folder popped up. So if some I had just entered a file name for the saved mission, I would struggle to find it when I want to continue the mission. In my opinion this is a bug. The "Export to Miz" screen should open in the folder from where I selected the original mission.

DCS World provides correct default assignments for all axes and switches on HOTAS Warthog throttle and stick when used for the A-10C. You should not have to set anything up. Just try, and if anything does not work as expected, come back with specific questions.

As far as I can see, the bindings with "<>" in their name are pretty much all for maintained 3-position switches (ON1 - OFF- ON2). Example: Autopilot ROLL 3-pos Switch: HDG SEL <> ATT HOLD Autopilot ROLL 3-pos Switch: STR SEL <> ATT HOLD When the switch is in the ON1 position, Heading Select is activated, in the OFF position it's Attitude Hold, and in the ON2 position it's Steering select. Unfortunately, ED programmers are consistentl inconsistent. After all, the binding names are just text strings with no influence on functionality. So to the "/" character: Sometimes it's used to provide some structure within the naming. Example: A/A refueling - "Ready for precontact" radio call But sometimes it's used exactly like the "<>" sequence. Example: Autopilot Pitch Switch ALT HOLD/OFF Autopilot Pitch Switch ATT HOLD/OFF And sometimes the "/" is used for ON/OFF toggle commands, where sucessive activations of a button toggle beteen two states. Example: Canopy OPEN/CLOSE You cannot rely on these charactersn have consistent meanings, not even within a module and even less between modules. The "Add Combo" in the right-click menu does the same as double-clicking on the assignment field. It opens the Assignment Panel where you click on a button or switch, or enter a keyboard code, to bind the respective command.

I grew up about 20 km east of the Nörvenich airbase, will never forget the howl of the F-104G Starfighters flying quite low above our house. Unfortunately, this part will not be included in phase 1 I guess.

Quaggles "injects" added lines from a new "default.lua" under "Saved Games". This added file includes your additions only. Therefore, additions to the core "default.lua" by ED cause no conflict. When you set up the Command Injector you will create these new "default.lua" files under Saved games, and move your additions from the core files to the new files under Saved Games.

I agree, I use the the Input Command Injector by @Quaggles too, and it saves me a lot of trouble and work.

These defaults are normally stored in the files "F16 MFD 1.diff.lua" and "F16 MFD 2.diff.lua" under "DRIVE:\Eagle Dynamics\DCS World\Mods\aircraft\F-16C\Input\F-16C\joystick". Maybe they are corrupted? I would delete these files. Also if files with the same names might exist under "Saved Games" I would delete those as well. (if you want to be extra-cautious, re-name them instead of deleting). And then run a repair. This should restore the original default bindings. I'm saying this based on my understanding of the functionality; I don't have the MFD's.

100% agreement. I'm not sure that it's a good idea to extend the flaps at 400 km/h or more, but in a turning fight speed tends to slow towards 300 km/h and then I extend the flaps to landing position as @kablamoman says. This gives me the decisive edge over over P-51D and P-47D AI. When you are near stalling condition at high engine power, be careful with the throttle as a sudden change of propeller torque can produce a dangerous roll.

I re-tested today and found the AP working fine. I could not find any of my HOTAS switches making a difference. So that's a bit mysterious. Note: Two days ago, I had increased the pitch axis deadband to 5% and it was still not working. Today I reduced the deadband to 2% and I could get the AP to kick in. 1% wouldn't work. I then re-calibrated my joystick, and reduced the deadband to 1% and the AP still works. My conclusion: people struggling to make the AP engage should should make sure their stick is well calibrated and, if that's not enough, increase the deadband. The failure I experienced 2 days ago would not be fixed by that approach though. It remains unexplained.

I have not flown the F-16 recently. When I did in the past, I always found that the AP was working. When I saw this thread I decided to give it a try, and I could not get the AP to work the way I had experienced earlier. Even after setting a 5% deadband on the pitch axis, I could not see the pitch AP kick in. The AP switches in the sim do respond to my switch inputs.

In the file "clickabledata.lua" these switches are grouped under "--To-Do list". I tried to create a binding for one of them, but that did not work. I guess that there is no functionality other than clicking the items with the mouse. And I doubt that the video recording capability will ever be implemented.

I totally agree, ED should add all the bindings available in the "default.lua" to the files for the MFD's. But I don't expect ED to make the change. I use the Command Injector by @Quaggles which uses one modified LUA file in the game folder. Of course I still have to use OvGME or another mod manager to protect that mod. But now, the additions to the module-related files are in the Saved Games folder structure and are no longer wiped out by updates. I have been using this for about a year now, and I'm happy with the solution.

I found the culprit: it was me! I have made an external (MS Access) application that writes to "Options.lua" primarily to set the wanted screen export configuration. Note: the current launcher is limited to 3 presets. My app does not have that limitation. And the presets have names like "F/A-18C, Big AMPCD + IFEI on RH monitor" which is better than just a number. My app captures the current Options.lua in a database and changes some lines depending on the preset I have selected. Unfortunately I had captured the Options.lua at a moment when "weapons" was true. I have now added a line to all my presets to enforce "weapons" = false. I apologize for having wasted your time on an issue where the ball was in my court.

I had unticked this option yesterday from the Options screen, and my Options.lua reflects this. So there is no problem writing to that file.

Unlimited Weapons was activated again yesterday without me ticking that option. I noticed when I was in a mission with the Ka-50 III, and I had already fired 7 Vikhr missiles, and when I checked my missile load it was back to 12. So today I went back to Options/Gameplay, and yes, Unlimited Weapons was ticked. So I unticked it again and closed the screen with the OK button. I then flew a Ka-50 mission (a modified version of "Clear Tkhvarcheli") and fired Vikhr's at everything hostile, and, lo and behold, I never ran out of Vikhr's. After the mission, I checked the option again, and yes, it was ticked. The "LastMissionTrack.trk" is over 25 MB so I cannot attach that. The mission does not enforce "Unlimited Weapons" so the issue is not caused by the mission. So I suspect that it's the Ka-50 III.

Thanks for checking! Unfortunately(?) it's a random bug, and I do not encounter it every day. It's just when I notice that after a prolonged dogfight my ammo counters still indicate "full", that I go to Options to check and see the issue. It's obviously a difficult one to reproduce. P.S. I don't use Unlimited Weapons at all. So it's not a case of having forgotten to turn it off. And I have not enabled it in mission options. But I will check the mission next time I see this.

Winding up the ammo counters is not a prerequisite to firing the guns. The guns will fire even if the ammo counters are all the way down.

Po ingliskiy pozhaluysta!

Since the last update, this option has repeatedly been re-activated. I'm obliged now to check after every launch of the game to verify that it has not come back again. The software should not change these options unless the user has entered the change.