LeCuvier

My user mods are not of the nature that would change which procedure is called by the buttons on any screen. Still, I disabled all my mods with OvGME and I ran a Repair, and the problem still persists with the two FW-190. I tried some more: Bf-109: no problem A-10C II: no problem P-51D: It happens, and the track it shows me is total rubbish. Spitfire: No problem P-47D-40: no problem Mosquito: crashed when the mission was loaded and I hit the "FLY" button. Twice in a row. F-16: no problem F/A-18C: no problem

At the end of the mission, when the "Debriefing" page comes up, we have (among others) the buttons labelled "WATCH TRACK" and "FLY AGAIN". Hitting "FLY AGAIN" normally lets you fly the same mission again from start. In the two versions of the FW-190 however, hitting the "FLY AGAIN" has the same effect as hitting "WATCH TRACK". So, instead of starting a new mission, you see the replay of the mission just completed. This is quite annoying and should be easy to fix in about one line of code!

I apologize. You're right, I must have looked at the Hornet. Sorry.

Thank you! The result of your cross-check with he AGM-65F gives me hope that the problem may not be too difficult to correct.

Thank you, @Yurgon!

I have been flying the A-10C since it became available, using AGM-65D for years without problems. Among others, the mission "Kashuri Gap" was one of my favourites. That mission is no longer included with the A-10C II, but I kept a copy and updated it to the A-10C II. In that mission, the Maverick has become almost totally useless because the roads used by the red tanks have poles almost everywhere. I did not keep a copy of the old Caucasus map, but I suspect that it didn't have this profusion of poles. I suspect that the problem began with the poles in the "new" Caucasus map. So let's get rid of the poles! I'm afraid that's wishful thinking

Not sure that will help much. In my track, at least one of the tanks is in the middle between two poles, and the AGM does not kill it. It's as if the poles "distracted" the missile.

I find that power line poles along the road make it almost impossible to kill MBT's with IR Mavericks. I have not tried othe Maverick types. I can lock the tanks with the TGP no problem. I can slave the Maverick to SPI. The problem occurs when I push the TMS forward short in order to get a Maverick lock on the target. In that moment I can see see the SPI moving slightly away from the tank. The AGM usually hits a pole. Even if it doesn't hit the pole, it doesn't achieve a direct hit on the tank, and the tank is either just damaged, or totally unharmed. I attach a track where I fire 4 Mavericks at 4 MBT's and get no kill. Test AGM-65D with Poles.trk Edit: I tried the same scenario with AGM-65H, but the result is not better.

Isn't that what the command "Ejection Seat SAFE/ARMED Handle - SAFE/ARMED" does?

I have LUA edits for the file "default.lua" that handle items 1 (first paragraph only), 3 and 4 of the original post. As to item1 (second paragraph) and item 2: we cannot create incremental commands via LUA edits. However it is possible to create distinct commands for desired axis positions.

The command "iCommandChangeRWRMode" is designed to work with a pushbutton. You cannot change its function.

I have adapted the old "Clear Tkvarcheli" for the Ka-50 III and added 2 wingmen. The wingmen have always been misbehaving. The last update fixed one of the issues: When we had to land somewhere to elude F-5 fighters that were going for us, two of them collided or ran into trees, or staid airborne forever and were shot down. But another issue still exists: When we have killed all targets and I send them back to base, one of them tends to crash into trees, and the other flies to the enemy FARP, sometimes landing safely and sometime killing itself. This happens at the end of a long mission and therefore I didn't save a track which would be huge and unreliable.

Sorry, but but I do not understand what you are trying to achieve. The switch version of this command, for use with HOTAS, button box etc. already exists. This is the LUA line: {down = iCommandChangeRWRMode, name = _('RWR/SPO Mode Select'), category = _('Sensors')}, Creating a duplicate command with a different name won't do any good. The switch command has the same functionality as the keyboard command, so it shows on the same line in Options/Controls, under the same name. The unpredictable behaviour you observe might be caused by you replacing "down" with "pressed" which is probably not compatible with this particular command.

I tried but I cannot make it work.

The R4M rockets work fine after you jettisoned the bomb rack of the SC50 bombs. Which means that you have to use your bombs first. I tried the same scenario with the SC500 bomb and found that the SC500 bomb rack doesn't come off when you press the Jettison button ("Jettison Fuselage Stores"). And consequently, I could not fire the rockets. Is this a bug, or is it how the real thing worked? Unfortunately the flight manual doesn't go into these details. Speculating... In a scenario where you carry a SC500 bomb (maybe to attack a ship), you would probably not want to carry rockets, they would be just dead weight. And takeoff with a SC500 under your belly is hard enough without any extra weight (for me at least).

1. YES, it worked before, for years! 2. I cannot agree with your programmatic logic. If GROUP DEAD would mean that the object no longer exists, then you could not even check for its DEAD status. 3. YES, I have applied the same work-around

First of all, I do understand the logic of LESS THAN But, as I clarified in my August 27th post, the trigger fails if I kill ALL elements of the target group in one attack. With zero elements of the group alive, the condition "LESS THAN 50% ALIVE" should evaluate to TRUE and the trigger should activate. It doesn't.

Some people posted a similar issue for the P-51, and I provided a solution for a wheelbrake command ON/OFF with pressure reduced to 50% (could be anything else). If that's of interest I can post the equivalent for the Kurfürst

I'm not personally affected by this issue as I use MFG pedals with analogue brake axis signals, plus I don't fly the Mustang much. But I got curious and looked for a way to produce an ON/OFF braking command with reduced "power". And I got there after some trial and error. I added this line of code to the file "default.lua" under "DRIVE:\Eagle Dynamics\DCS World\Mods\aircraft\P-51D\Input\P-51D\joystick" : {down = iCommandWheelBrake, up = iCommandWheelBrake, value_down = 0.0, value_up = 1.0, name = _('Wheelbrakes Both 50%'), category = _('Flight Control')}, This creates a new command named "Wheelbrakes Both 50%". When you press the bound button, both brakes get 50% "pressure", and when you release the button the pressure is reduced to 0. This command has an inversed signal: Signal = 1.0 --> pressure = 0 Signal = 0.0 --> pressure = 50% Signal = -1.0 __> pressure = 100% With this in mind you can vary the pressure produced by a button press. I bound the new command with the 50% signal to the pinky button on my VRP stick for a test, and my first landing was not brilliant but safe. One could make the brakes a bit softer by changing the "value_down to a higher value like 0. If you want to use a keyboard button, you need to add the command to the "default.lua" under "DRIVE:\Eagle Dynamics\DCS World\Mods\aircraft\P-51D\Input\P-51D\keyboard"

Glad to hear that you could solve your problem!

It seems that your "default.lua" is different from mine. Here is a screen capture of the 4 TRIM lines from my Options/Controls: The lines mean the same, but the wording is quite different. You have not modified the "default.lua", have you?

The red "!" flags in these two examples are caused by the invalid syntax of these lines. They have the characters like ";;LCtrl" immediately following each other without a "+" in between. Now I wonder whether the invalid code is in the file "Keyboard.diff.lua" under Saved Games, or in the "default.lua" under "DRIVE:\Eagle Dynamics\DCS World\Mods\aircraft\F-16C\Input\F-16C\keyboard". Can you send me both via PM?

Are you sure you are looking at the "Date modified" and not the "Date created"? I'm also wondering about the red "!" in the Options/Controls screen. They might indicate "double binds" (key codes bound to more than one command). If you move the ".diff.lua" away or rename it, do the red "!" flags go away? In that scenario I suspect that the default bindings defined in the file "default.lua" under "K:\Eagle Dynamics\DCS World\Mods\aircraft\F-16C\Input\F-16C\keyboard" would take over. You will find those insufficient as they exist only for a small part of the flight and combat commands. In that state, you might just enter a few of your custom binds and verify that they work, before spending more time. It's really difficult to guess what's going on without having the full picture.

Not having access to your data I can't be sure what happened. But it sounds as if ED, in the course of an update, changed your keyboard bindings. I use only very few keyboard binds, but I have seen the same happen to game controller binds. ED should never change these files, but unfortunately it happens. I therefore keep backup copies of the binding files which are under "C:\Users\XXXX\Saved Games\DCS\Config\Input\". I also document my bindings in an Excel format. This makes it easier if I have to re-do my bindings. The keyboard binds for the F-16 are in the file "Keyboard.diff.lua" under "C:\Users\XXXX\Saved Games\DCS\Config\Input\F-16C_50\keyboard". I suppose you have no "good" backup of this file. In your place, I would want to keep the key codes in the simpit unchanged. I would delete the corrupted "Keyboard.diff.lua" and re-enter the keyboard bindings manually. After testing the set of bindings, I would make a backup copy of that file to a safe location .

The trigger "GROUP ALIVE LESS THAN" works for me if I kill the majority of the group's elements, but not all. It fails only if I kill all elements in a single attack. In your scenario it should work, because you will never kill all elements of the group in one attack.