Renko

I see you too have the Virpil T-50CM3 Throttle I think there are some unresolved issues with that hardware in DCS. In the Changelog from https://www.digitalcombatsimulator.com/en/news/changelog/release/2.9.20.15010/ There is a fix for the same hardware on the F16 : "Fixed: Duplicating Thrust axes on the VPC Throttle MT-50CM3 joystick." And I had reported an issue with it in the Apache forum last May with the T-50CM3 Throttle, but got no answer from ED. Curious that my issue is that the controls are reverting to default when i shutdown and restart DCS, in certain conditions.

First of all, thank you for answer this thread Yes, same USB port for each device of the sim hardware always. It keeps the same ID so that way DCS keeps the keybinds In the input folder (AH-64D_BLK_II_AI_Menu) there is no .diff.lua file asociated to the throttle for George AI, because i have no custom keybindsfor the throttle there The situation does occur each time i start DCS. Meaning samething happens if i start it tomorrow, or if i enter and exit seconds after reaching the control menu to clear those controls. Each single time it resets. But as i said in May: I think when this section its empty DCS forces an uncommanded back to default keybind for my throttle. If i make a custom keybind in that section of George AI even with one button on the Throttle, so a file is created in the input folder, the issue i have doesnt happens. But if then i clear again that category and restart DCS, it will happen again. That Throttle section will be populated again with the default keybinds I think its reverting for some reason to default. Its the only module where that issue happens.

Agreed. Its a beloved module for sure. It shows by how the former devs push that last great big update before the Kiowa launched, and even some community members helped selflessly to push it forward. Both did an outstanding work. Hope we will get an update as soon as posible on this situation

Please can this be checked At September 18 with the DCS version 2.9.20.15010, it still happens. Each single time DCS starts And yesterday patch included a fix particulary to the same hardware that has this issue in other module. The VPC Throttle MT-50CM3 null

BTW I just realised one thing that could make the solution more easy for you guys, but im not 100% sure. I cannot try because i dont have display export in DCS. Seeing the AMPCD from the thread i quoted it seems that the solution could be achieved with only working in the Luma channel. Because the map colours seems to be okay. So if you dont need to transform the colours and only need the luma, that makes things way easier. If thats the case you could achieve a solution by just adjusting with a custom curve or with gamma values. Here is an example with one of the OP screenshots and a quick custom curve i just did in some external software. I tried the same in Photoshop with a similar curve. And both make those two almost identical, the priamry display and the external one.

I would like to offer some advice on this matter, as I have some knowledge in this area. Maybe this will help the team get on track to resolve this issue. First of all i will make one assumption on those colour spaces, because those may deviate from the Rec.709 & Rec.2020 specs. We have some sort of HDR Color Space in the game primary display, lets call it HDR. And the export display is some sort of SDR Color Space, lets call that SDR. So if thats the case you will only need to transform from one Color Space to the other. In this case you will need to transform that SDR to HDR, in the values that DCS uses. This is nothing special. In the industry converting from one Color Space to another is a pretty common thing to use on daily basics. So the only thing ED will need to provide is a Trasnformation Matrix for that SDR to HDR color space. Probably should be pretty straight forward to do a custom LUT (Look-Up Table). Or use an existing one if it complies with Rec.709 and Rec.2020 specifications. And you could provide one. Where? Well just like you have that drop-down menu called "Color Grading" that are just LUTs ( a LUT is a Trasnformation Matrix). There you can have one at least that transforms from SDR to HDR values but it will only affect the export display you choose. So you will solve this issue with that. This user here has done a Colour Space Transform without knowing by using Reshade. And you can see that works well enough, and its is just that. Transform SDR values to a similar HDR ones from the primary display. So if DCS supports having some LUTs for "Color Grading". It should be able to give in the same manner a LUT that transforms SDR to HDR values and only affect export display. If the team wants to find more info on how this technical Colour Space Transforms works they can google "Color Space Transform HDR to SDR". They should be able to find good info. As I mentioned earlier, if DCS already supports LUT, this feature could be applied just to exports from a technical standpoint. Hope it helps

Now we have at least one entire single player campaign that needs you to have those lines in order to play. I wonder if a user who adds this will remember to remove after playing Still unclear to me, sorry i'm a bit clueless with all this, but if i leave that autoexec.cfg after playing a trustworthy mission/campaign it could be an issue for me as user. That I wouldn't have before this update? Sort of like leaving the door open

Can confirm this behaviour Easy to test for them. Just launch Instant Action Caucasus Refueling F16 Mission. Accelerate time and you will see the AI doing that refueling loop. The two-ship AI that are refueling when you arrive are doing what the OP has described. I had to gun down the F16 to practice refueling

As the title says, add an option on the Special tab of a module that will give the user the option to set a custom dtc file to be the new default for that module. You would have to include checkboxes where you can select which parts/sections of that file will be loaded for that new default. Otherwise, if all the data in the file is loaded, it will create conflicts with missions, campaigns and MP server missions. For example if i want only the countermeasures but it will load the default comms too, i will lost all those presets for comms. Or nav data I think this will be great to have and will serve the purpose most users will be using the DTC for. For example, if you are only going to use the DTC for stablising a new custom default CounterMeasuresSystem programs, and want that every time you sit in that module that data will be always the new default you set in the Special Tab.

Just saw a user posting this video on ED's discord, with some custom scripts and voice overs. I'm going to leave this here as a reference for the devs Because I think this kind of communications would be great to have for this CrewChief system. Better than the current ones for SlingLoad, as these are more accurate and frequent.

Thanks, but thats just a work around. As i said in my first post this behaviour is not how it should be. And i checked that with an active pilot of a Hook

This with the current patch (DCS 2.9.17.11733) it still have issues null

Yeah, good idea. It could work as a workaround for a two-way-switch in the Hotas

Thanks Bignewy I saw all those keybinds, in fact in my track i use too "move fwd" and "move backward as i sad in the first post. And its great to have all those options for sure. But for people with limited keys, you will still lose that OFF position logic. The only issue i see with this Switch is that you "jump" the OFF position without triggering the logic. I think with that image and my track is clear to see. If i pressed RESET and then ARM, and it triggers the OFF logic when passing through all will be fine. I know is a minor thing, but i noticed this issue while trying to map that switch into the Hotas. Regards!

@BIGNEWY sorry for the ping. but without a reply i dont know who tag this thread as "not a bug" Sorry but it is clearly a bug. I did not say that the logic of each position of the three-position-switch is wrong. That works fine. Im saying that i can pass from ARM to RESET position, without passing through OFF. Which is physically impossible looking at any three-position-switch, because you need to pass first through OFF to be able to reach RESET. And i think you can agree with me on that. And since it jumps the OFF position, it doesnt trigger any of the logic the OFF position does. nullnull