LeCuvier

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.

And what, please, is the PTS? Found it: Power Transmission Shaft.

3-position switch should be OK. I don't have one available but I tested by just holding the L or R pushbutton down. However, you should remember to set the switch to OFF position when the engines are up and running. Else, the crank switch in the cockpit will stay in the L position forever. This might not do any harm as the cranking is done with bleed air from the APU, and the APU shuts down when the engines are operational; but it certainly doesn't look right.

For a test, I bound the "Engine Crank Switch - Left" and "Engine Crank Switch - Right" ( not the "Cycle" commands), plus the OFF position to a pushbutton each and tried 3 scenarios: 1. Everything cold, just pushing the two buttons for left and right momentarily. The switch stays left or right only as long as I hold the button down. As expected 2. Everything cold, except Battery ON, using the 3 bound buttons: Briefly pushing the Right button, the right crank switch goes to ON and holds forever. Briefly pushing the OFF button sets the switch to the (center) OFF position. Briefly pushing the Left button, the left crank switch goes to ON and holds forever. 3. Running the training mission for Cold Start until both engines are fully started and the APU goes OFF: Used mouse clicks for all steps except for the Engine Crank switch where I used the bound pushbuttons. Everythings works as expected, including the crank switch holding in R or L position as it should. In conclusion, the crank switch works as expected. It's electro/mechanically held in the L or R position as long as necessary. Battery ON is the only prerequisite for holding the switch in L or R position at start-up. Note: Once the engines are fully operational, the switch no longer holds in L or R. I did not test at what point this interlock kicks in. So it would appear that the issue is not in the ED software but in your setup. I suppose you verified that your switches work with other commands? Note: I did not try what happens if I use a 3-position switch that stays in the L or R position. You should probably use something that provides just momentary contact closure.

When I use the APKWS rockets I like to designate the target from the TVV. I use these steps: From TVV (Total Velocity Vector), with TGP on Right MFCD Set HUD as SOI Throttle Coolie Hat Up Short Slave TDC to TVV Throttle China Hat Aft Short Manoeuvre TVV near Target Ground-stabilize the TDC Stick TMS Forward Short Make SPI Stick TMS Forward Long Slave All to SPI Throttle China Hat Forward Long After these steps, I set the TGP (right MFCD) as SOI etc. I have been using this process for a long time without problems. But several updates ago I started seeing this failing. When I push the China Hat Forward Long, the SPI simply disappears. Note: It doesn't fail every time, but now most of the time. As a work-around, I set the TGP to boresight and create the SPI from there. But I would really like to use the TVV. I attach a track. A-10CII cannot SLAVE ALL TO SPI.trk

Also, a track file with the name "LastMissionTrack.trk" is automatically saved when you exit from a single-player mission. Unfortunately, when you have replayed this track, this file gets overwritten with the track of your replay. So, if you want to view the original track before posting it, you need to create a copy with a new name.

@jackd I don't see any track in your posts. Please post a track so we can see what you are actually doing! Also, the "gun bars" are just ammo counters. Even after setting them alll down to zero I can still fire all guns. They have nothing to do with your ability to fire the guns.

What are you talking about? There is nothing wrong with the weapons. If you need help with something, be specific!

They are under "DRIVE:\Eagle Dynamics\DCS World\CoreMods\aircraft\FA-18C\UnitPayloads". Unfortunately there are two and I don't know which one you'd need to edit. But if you delete payloads from the file, they will pop up again after an update I suspect. So you need to backup your modified file (or use OvGME). PS: The payloads created by the user are under "C:\Users\USERNAME\Saved Games\DCS\MissionEditor\UnitPayloads". There is no equivalent in the game folder structure.

@MarcT-NL I experimented with such a setting when I started flying the Mossie. Early on, when the mission started in the air, the trim axes were badly off and I had to spend too much time trimming before I could engage in action. I came up with a custom command (with a bit of LUA editing) that set all 3 trim axes to reasonable values (not neutral) with a single button depress. The starting trim settings are now improved so this issue went away. Now that solution could be used to set all 3 trim axes' values = 0 (= neutral). I just tried that, and when I push the button the Mossie quickly goes into a steep climb. Not good! The following LUA line (added into the "default.lua") creates a new command "Trim Preset Airborne". It sets the 3 trim axes to reasonable in-flight values for a loadout without bombs: {cockpit_device_id = devices.CONTROLS, pressed = device_commands.Button_17, down = device_commands.Button_54, up = device_commands.Button_52, value_pressed = 0.33, value_down = 0.18, value_up = -0.1, name = _("Trim Preset Airborne"), category = _("Flight Control")}, The line contains 3 value statements. If value = 0 Then axis = Neutral. Value > 0 --> Turn clockwise. Value < 0 --> turn counter-clockwise. value_pressed sets the Tail Trim (elevator); Value > 0 --> Turn clockwise value_down sets Rudder Trim ; Value > 0 --> Turn clockwise value_up sets Aileron Trim ; Value > 0 --> Turn counter-clockwise In my opinion, such a command is more helpful then setting all to Neutral.

I confirm, the undercarriage does not "drop" when you activate the "Notzug" lever. I tried both with a bound pushbutton and by mouse-clicking in the sim cockpit. But I think you will have to provide a track for the bug to be considered.

The engine is just fine here. When I engage into a turning fight, it runs at full power with MW-50 for long periods of time and it does not die on me.

When I replay your track I see the rudder flapping. But when I take control, the rudder is steady and controllable. Therefore, it's not a problem of the Bf-109 module. My conclusion is that your rudder somehow gets erratic control inputs. You say that the rudder works fine in all other modules, therefore there must be a problem in your control settings for the Bf-109. If you have any mod related to the Bf-109, I recommend you verify that it's not causing the problem, by disabling it.

ED, unlike Heatblur, has rarely ever reacted to this kind of requests. That's my experience since I bought the Dora license in 2014. I then learned to edit the "default.lua" files. That was cumbersome early on as I had to restore my additions after every update. Then I installed JvGME and then OvGME, and that made the handling much easier. But it required using "frozen" files which over time started to miss updates. Finally now (some time ago actually), @Quaggles developed the command injector which I have adopted after some hesitation. Now, the added LUA lines go into "default.lua" files under the "Saved Games\" folder structure and they are no longer affected by updates. Now, only one LUA file ("Data.lua" under "DRIVE:\Eagle Dynamics\DCS World\Scripts\Input") is modified in the Games folder structure, and that's easily managed with OvGME. I have lots of modules with their LUA additions and it does not look like a "workaround" for me. I wouldn't want to fly DCS World without these adds. And I'm grateful that the software is open for making such additions. Because no software will ever make everybody happy. My only request to ED would be to make the Command Injector part of the stock software.

Thanks for enriching my English vocabulary! (I'm German) And good luck!

What does this mean: "but I neednulled to change the values "? In the video I see the switch flipping around, but I never see the cover moving. You have bound switches to two different versions of "coolant close". Why? You are apparently using a 2-position switch for coolent OPEN/CLOSE, and using the _OFF event which is not reliable. I would have thought that you used a 3-position switch for Open/Auto/Close. Actually, in order to understand what's going on I would need to know what kind of switches you use. Anyway the whole thing is tricky. In the real-life cockpit the switch and cover are obviously electro/mechanically connected to force the switch to Auto when the cover is closed. If you don't have the same interlocks in your sim cockpit, the view of the virtual cockpit might sometimes not match what your sim cockpit shows. It might therefore be easier to set "Automatic" before closing the cover.

Can you try these lines for the Coolant switch? If that works we can create the same function for the Oil switch. It works here. {down = device_commands.Button_1, cockpit_device_id = devices.ENGINE_SYSTEM, value_down = 0.1, name = _('Radiator Coolant Switch CLOSE'), category = _('Radiator Air Controls')}, {down = device_commands.Button_1, cockpit_device_id = devices.ENGINE_SYSTEM, value_down = 0.3, name = _('Radiator Coolant Switch OPEN'), category = _('Radiator Air Controls')}, Good luck!

Try these 2-position commands for the two radiator switch covers! {down = device_commands.Button_3, up = device_commands.Button_3, cockpit_device_id = devices.ENGINE_SYSTEM, value_down = 1.0, value_up = 0.0, name = _('Radiator Coolant Cover 2-Pos OPEN/CLOSE'), category = _('Radiator Air Controls')}, {down = device_commands.Button_4, up = device_commands.Button_4, cockpit_device_id = devices.ENGINE_SYSTEM, value_down = 1.0, value_up = 0.0, name = _('Radiator Oil Cover 2-Pos OPEN/CLOSE'), category = _('Radiator Air Controls')}, Try this for the supercharger switch cover: {down = device_commands.Button_2, up = device_commands.Button_2, cockpit_device_id = devices.ENGINE_CONTROL_PANEL, value_down = 1.0, value_up = 0.0, name = _('Supercharger Switch Cover 2-Pos OPEN/CLOSE'), category = _('Engine Control Panel')},