LeCuvier

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.