LeCuvier

Check your axis bindings! This looks like you have not removed the duplicate bindings that are caused by the defaults.

Actually, I would have been surprised if had been fixed so quickly.

It's not fixed, and ED probably consider it low priority because you can still trim full range with buttons.

After updating with today's hotfix I tried again, and after 12 missions I was about to shout "halleluyah!". But after I launched the 13th mission it crashed. Earlier it would crash mostly after less than 5 missions. Does this mean that stability is improved, or was the fact that I could run 12 missions in a row without a crash just a fluke? I would like to see someone else try to run a dozen or so short missions in a row. Anyway, it should not crash even after 20 missions. Also, I wonder if I would get the same issue if I flew 12 missions in a row with any other fighter. dcs.log

So with your plan, you would always be in either "Parking Brake" or "Anti-Skid" mode. Does that make sense?

The issues I found concern 4 of the internal lights: LH Instrument Lights, RH Instrument Lights, Bomb Aimer's Panel Light and Compass Light. The issues are: 1. The Increase/Decrease key commands are reversed. We need to bind them "the wrong way around". 2. When you use the (corrected) INCR command, the light intensity increases up to a point and then the light goes Off completely. I created key commands with different action values and found that this happens at about 85% INCR. I find this very confusing. If you bind to the related axis commands you see the same strange behaviour. Maybe somebody will tell me that this is how the real thing worked, but in my opinion it's a bug. I don't know whether ED will fix this in the near future and therefore prepared a little work-around that allows me to turn these 4 lights on without fumbling. I created a key command for each of the 4 lights for binding to pushbuttons. When I push one of the buttons, it will turn the related light up to 85%. These are the lines I added to "default.lua": {down = device_commands.Button_17, cockpit_device_id = devices.SWITCHBOARD, value_down = 0.85, name = _("LH Instrument Lights 0.85"), category = {_("Environment System"), _("Electrical System")}}, {down = device_commands.Button_55, cockpit_device_id = devices.SWITCHBOARD, value_down = 0.85, name = _("RH Instrument Lights 0.85"), category = {_("Environment System"), _("Electrical System")}}, {down = device_commands.Button_61, cockpit_device_id = devices.SWITCHBOARD, value_down = 0.85, name = _("Bomb Aimers Panel Light 0.85"), category = {_("Environment System"), _("Electrical System")}}, {down = device_commands.Button_14, cockpit_device_id = devices.SWITCHBOARD, value_down = 0.85, name = _("Compass Light 0.85"), category = {_("Environment System"), _("Electrical System")}}, Note: If you find 85% too bright you can use a lower value. I don't see the need for turning the lights Off. But you can easily create such commands using "value_down = 0"

If you used to have two lines of code that means your physical switch has two switched connectors. If I remember right you call that a single pole double throw switch in US speak. That would work with these two lines of code: {down = fuel_commands.DumpSw, cockpit_device_id = devices.FUEL_INTERFACE, value_down = 1.0, name = _('Fuel Dump Switch ON'), category = {_('Left Console'), _('Fuel Control Panel')}}, {down = fuel_commands.DumpSw, cockpit_device_id = devices.FUEL_INTERFACE, value_down = -1.0, name = _('Fuel Dump Switch OFF'), category = {_('Left Console'), _('Fuel Control Panel')}},

Good to know, thanks!

I understand you want to use a single 2-position ON/OFF switch. If that's right, you can add this line of code: {down = fuel_commands.DumpSw, up = fuel_commands.DumpSw, cockpit_device_id = devices.FUEL_INTERFACE, value_down = 1.0, value_up = -1.0, name = _('Fuel Dump Switch 2-Pos ON/OFF'), category = {_('Left Console'), _('Fuel Control Panel')}},

You cannot fix this. It's a reported bug that only ED can fix. The only work-around is to use button commands (like on a POV hat)for the 3 trims.

Well, so we have good news and bad news. I'm relieved that you could reproduce it so quickly, so our reports have credibility, and hopefully the bug will be addressed with some priority, although ED have probably ordered "All hands to the Apache pumps!" PS: I'm happy I could re-activate my mods. I couldn't even get the guns to fire; but that's not a subject for this thread.

I have just now removed all mods and run a repair. My GPU drivers are up-to-date. I did a session with the Anton, and I could reproduce the described issue in the 3rd or fourth mission. I attach the log file. Whoever tries to reproduce, please note that you may have to do 5 or more successive missions before you run into the problem. My PC has "only" 16 GB of RAM. If this is a memory problem and you have a 32 GB monster, you might not be able to reproduce the failure (my layman's thinking). dcs.log

Just now, the freeze happened when, after exiting from the mission, I hit "Watch track". This time I could kill DCS with task manager before Windows crashed. @Art-J: I attach the mission file. It's a mission I set up myself from under "Saved games". I do not believe that the issue is mission-related. But sometimes I can fly the mission 4 or 5 times before the crash occurs. Dogfight vs P-47D-30-Early.miz

After some practice I can fly the jug quite precisely, without a stick extension but with 15% curvatures on pitch and roll. You have to keep in mind that it has a huge mass. Because you don't see it responding as fast as a Spit, Mustang or Kurfürst, you tend to over-control and then of course it will over-respond. Knowing this, I have learned to use the controls gently. I'm not there at all with the Mosquito which seems even worse, but I may never get to master this one because I hate its messy cockpit (not ED's fault, just reality).

I tried the Anton, and in fact there is an issue. I conducted 3 successive sessions, each with several runs of the same mission. Two of the 3 sessions produced the crash after a number of runs, always with the same mission. In both cases the game froze at the very start of the mission, just after hitting "Fly". In both cases, I could not get out of the frozen game with [Esc], and I could not even end the game with task manager. Windows did not respond to anything and I had to kill the Windows session with the Power switch. I attach the log files for both sessions. The log files (I cannot interpret them well) might confirm another issue which I have had with the Anton for a long time: After ending a mission you can can hit "Close" to return to the mission selection, or "Fly again" to fly the same mission again. When I hit "Fly again" it does not open a fresh mission but instead replays the mission I've just ended, as if I had hit "Watch Track". This sounds like a different issue, but maybe it's related and so I mention it. dcs.log.old dcs.log.old.old

Please do not paste the text of a logfile directly into the post! Just attach the file. Nobody wants to scroll forever just to find the next post.

I use the TM WH throttle and the slider shows the same issue. ED have redefined the trim axis ranges and with sliders we can only cover 50% of the trim ranges. It's a bug.

This report confirms something I found. I created button commands that set the trim values to desired values. Normally the trim values from -1 to +1 should cover the full trim range from 100% nose-heavy to 100% tail-heavy, with 0 = neutral. Instead, the action value +1 is neutral and -1 is 100% nose-heavy. So there is no way within the range of the slider to set elevator trim tailheavy at all. The same seems to happen with the two other trim axes. Aileron trim is available from 100% left to neutral , and Rudder trim from 100% right to neutral, both for action values -1 to +1. Note: when I set action values with a button command instead of a slider I can use action values > 1. I use these commands to preset the trim in air-starting missions where the nose tends to go down at mission start. Edit: I did some more testing with my button commands and found: The full trim ranges for the 3 axes now require action values from -1 to +3 instead of the normal -1 to +1. The sliders on our game controllers can only produce signal ranges from -1 to +1. Thus we can only trim one half each of the trim ranges. Specifically, we cannot trim via axis commands... 1. the elevator tail-heavy 2. the ailerons right-wing down 3. the rudder left To have the full story I want to add: We can still trim through the full ranges with POV hats. @NineLine: this is clearly a bug. Please report!

Yes, in fact ED missed something. I added the missing line of code below to "default.lua" and now I can cage and uncage the artificial horizon: {down = device_commands.Button_8, cockpit_device_id = devices.AH, value_down = -1.0, name = _('Horizon Uncage'), category = _('Front Dash')}, However, the two commands are reversed. So the names of the two commands should be swapped! I also find that the animation is weird. In order to go from OFF (= Caged) to ON (= Uncaged), you need to turn the knob counter-clockwise the long way around. I would bet that that's wrong. @NineLine: Please report!

Try those (RDR CURSOR...):

Which instrument would indicate the need to open them? Oil temperature?

I never ckecked those. Could that be the reason why the jug sometimes starts shaking in flight? Will check cowl flaps next time I fly the jug! I always assumed that they were automated like in the Dora.

No, these commands have no parameters that you could modify in "default.lua", and there is nothing at all in "clickabledata.lua" as the throttle lever is not "clickable" in the sim cockpit.

Some Quickstart missions are obviously done in a hurry. I tend to copy the interesting ones to Saved Games and modify them so they make sense.

you mean the "booster coil" like the "Zündspule" in a car, I get it. So the Mossie provides both a battery-powered booster coil and the magnetos (which are basically little generators) for generating the high voltage pulse. Why did they design so much redundancy into the ignition system? Having two magnetos per engine is already a level of redundancy I would think.