Red Dog

Point 5 is actually partially incorrect. A long TMS left initiates TDOA but a short TMS left displays the coordinates in the DED. Hence making you believe a steerpoint could easily be created if not already Mayve a M-SEL should make that an active steerpoint (untested) like any other markpoint It would be interesting to know if the threat ring would magically appear in DCS for the host if these coordinates are made into the relevant system SPI Logic is much better knowing the threat ring over the network is an error on DCS implementation side. It kinda solves the inconsistency indeed Can't wait to have a solid DTC in DCS because all these lines, PPt and threat rings are dearly missing - even if they are not updated with TDOA

it has nothing to do with public unclassified evidence It has to do with pure logic and common sense.

@Lord Vader I understand what you're saying which is indeed logic. But I'd like to know from an operational point of view how the mechanisation of what you explain is efficient from a SEAD pilot perspective.... in DCS Starting a SEAD mission, we don't know where the mobile or hidden SAMs are. And that's expected. We love that So I understand that the SAM rings are not accurately placed. Matter of fact they are not placed at all since we do not have DTC allowing us to place PPT, Lines and SAM rings on the HSD But When a guy locates an emitter with the HTS pod He doesn't get the SAM threat rings. But if he sends that emitter through the network to his wingmen, then these guys have the SAM threat rings For the guy having sent the position of the emitter to have the SAM threat ring, a wingman who has received the data through the network has to send it again to the original guy. Then the original guy gets the SAM rings in his aircraft. Or is there something I didn't get? Realistically thinking, and with the danger of SEAD business, Do you guys really think it's been planned like that in the real F-16? It seems very dangerous, quite unefficient and way too long to avoid being shot down. Food for thoughts .

Doesn't work in DCS - you cannot test AR on the ground as when you do it, the NWS button doesn't disconnect but enables the nose wheel system... This is mandatory if you want to refuel on the ground as it depressurize the tanks and allows to fill them correctly Failure to open AR door in DCS before refuelling on the ground will provide abnormal fillup which is indeed a good point

I'm not a VR user but I do have mouse related issue in DCS as well. I think I found the solution. Might be interesting to you guys The issue I have is that my mouse cursor is erratic when I am in the UI of DCS. It doesn't happen all the time, just sometimes for no particular reason. When it happens the mouse cursor slighly oscillates and drift for a very long time before stopping (withou me moving the mouse) When the mouse cursor stops drifting, it's not where I placed and I have to move the mouse to get the cursor on the UI button I want, and the problem starts again. While that happens, DCS in the task manager is using a lot of ressources and is red coloured, which is not the case when that particular issue doesn't happen. I'm sure you can imagine that setting up a mission is a nightmare in such condition. particularily in MP Anyway, I have been searching issue for this for a long while and only whne I read this post I realised it might be a mouse setting. I have a Razer Basilisk V2 mouse. You can adjust the mouse cursor speed with specific mouse buttons And yesterday I found out that the issue is only happening when my mouse cursor is too fast. When I decrease my mouse cursor speed with the Razer settings, the problem in DCS disappears. Slow mouse speed = OK in DCS Fast mouse speed = NOK in DCS For records, I do not have such problem in other sims (FS, Xplane, BMS etc it's only in DCS and I run multiscreen in all of them I haven't found the specific mouse speed threshold yet but you guys indeed might want to decrease the mouse cursor speed to avoid the framerate hits Hope that helps and hoep that ED looks into that mouse cursor speed issue

I'd say it doesn't happen for TDOA Master. Not specifically flight lead but rather the guy initiating TDOA

I can't find that one either LeCuvier, at least not in the default. It's one that you have to custom add and redo after every update. It would be great if all of these indeed could be added in the default install. - PNEU/ ELEC (currently assigned in my system as a DX entry) { down = alt_commands.ELEC, up = alt_commands.ELEC, value_down = -1.0, value_up = 0.0, cockpit_device_id = devices.AAU34, name = _('Altimeter Mode Switch ELEC/OFF'), category = {_('Instrument Panel')}}, { down = alt_commands.PNEU, up = alt_commands.PNEU, value_down = 1.0, value_up = 0.0, cockpit_device_id = devices.AAU34, name = _('Altimeter Mode Switch PNEU/OFF'), category = {_('Instrument Panel')}}, - EJECTION SEAT ARM/SAFE (currently not assigned (left empty) -- Self added Sept2024 { down = iCommandPlaneEject, pressed = iCommandPlaneEject, up = iCommandPlaneEject, name = _('Eject (press once)'), category = _('Systems')}, { down = cpt_commands.EjectionSafetyLever, cockpit_device_id = devices.CPT_MECH, value_down = 0.0, name = _('Ejection Safety Lever, SAFE'), category = {_('Systems')}}, { down = cpt_commands.EjectionSafetyLever, cockpit_device_id = devices.CPT_MECH, value_down = 1.0, name = _('Ejection Safety Lever, ARMED'), category = {_('Systems')}}, { down = cpt_commands.EjectionSafetyLever, up = cpt_commands.EjectionSafetyLever, cockpit_device_id = devices.CPT_MECH, value_down = 1.0, value_up = 0.0, name = _('Ejection Safety Lever, ARMED/SAFE'), category = {_('Systems')}}, - FUEL QTY TEST momentary (currently assigned in my system as keyboard "CTL ALT w") {down = fuel_commands.FuelQtySelSwTEST, pressed = fuel_commands.FuelQtySelSwTEST, up = fuel_commands.FuelQtySelSwTEST, cockpit_device_id = devices.FUEL_INTERFACE, value_down = 0.1, value_pressed = -0.1, value_up = 0.1, name = _('FUEL QTY SEL Knob - TEST Button Special'), category = {_('Instrument Panel')}}, Please ED, do something about it.

Thank you very much.

problem solved LeCuvier I restored the default file and all problems disappeared Many thanks for pointing me to the source of the issue. I doubt I would have thought about the default file being the culprit You help is invaluable. Many thanks

I do. after updating I always add a line to default key and joystick LUA; doing this for ages? But maybe I did something wrong in the last modifications. I do have backups too. Joystick default modification for missing PNEU/ELEC default (joystick) for adding PNEU switches to BU0836A (D:\DCSWorld_OpenBeta\Mods\aircraft\F-16C\Input\F-16C\joystick) line 138-139-140 -- Self added January 2024 { down = alt_commands.ELEC, up = alt_commands.ELEC, value_down = -1.0, value_up = 0.0, cockpit_device_id = devices.AAU34, name = _('Altimeter Mode Switch ELEC/OFF'), category = {_('Instrument Panel')}}, { down = alt_commands.PNEU, up = alt_commands.PNEU, value_down = 1.0, value_up = 0.0, cockpit_device_id = devices.AAU34, name = _('Altimeter Mode Switch PNEU/OFF'), category = {_('Instrument Panel')}}, keyboard default modification forCorrecting FUEL QTY TEST default (keyboard) for correcting bug on FUEL QTY TEST (D:\DCSWorld_OpenBeta\Mods\aircraft\F-16C\Input\F-16C\keyboard) line 289-290 -- Self added feb2024 {down = fuel_commands.FuelQtySelSwTEST, pressed = fuel_commands.FuelQtySelSwTEST, up = fuel_commands.FuelQtySelSwTEST, cockpit_device_id = devices.FUEL_INTERFACE, value_down = 0.1, value_pressed = -0.1, value_up = 0.1, name = _('FUEL QTY SEL Knob - TEST Button Special'), category = {_('Instrument Panel')}},

here's a specific example Trim nose down is supposed to be SHF+CTL+F3 Here's what I have in the config First I see more assignation than the single SHF CTL F3 I see a RCTL; having been inserted before my own custom declaration, it wasn't so before. The line ressembled the trim left and right which apparently don't see to support the issue and when I click on that keybind to see where it is declared twice: It's empty, usually I see where it is declared another time, here nope. It's getting weirder

yes it's modified date. Maybe the issue is elsewhere Agreed with the red exlamation marks. I concur I had that when there was some sort of conflict. I solved all of these before so I am positive that the key config I had in June had no red exclamation marks I'll test wat you suggest and make a few screenshots. But as always many thanks for your attempts at helping. I understand this is difficult and there's no obligation of results

Thanks LeCuvier for once again coming to the rescue I do have backup and I have reapplied it, but I still have the same issue in DCS after having applied my backup The date of my backup also still match the date of my keyboard.diff.lua in the saved folder, which I found weird. I would have assumed that an update changing that file would have changed the date as well. Mine is dated 8th may 2024, when I did my last modification. And saved a backup. They are indeed in the F-16C_50\keyboard folder. I have rather the feeling that this file doesn't talk to the default file anymore ... ??

Hello gents, I am using a complete custom key assignation. That means I'm not using the default keypresses but custom keypresses for my cockpit switches across different simulators that allows me not to reprogram the pit each time I switch sim Anyway it worked for years without a problem I did not fly DCS since June and I updated two or three time without really flight testing each update during the summer. Today testing the pit, none of my previous assignation work , the pit does not respond in DCS (it does with other sim) and I see a lot of red exclamation marks in the keyboard config I did not have before I suspect my personal key assignation got changed somehow... I remember that for the F-16 controls, we had F-16sim and F-16game before. Now we only have F-16. Maybe that's the reason? and maybe that's been changed with one of the summer updates? Now Anyone could point me towards a possibility to revert my F-16Sim custom key assignation to the now unique F-16 key config? I suspect it's only a matter of LUA file renaming but I'm a little bit lost on the specificities to do that. The goal is to obvious avoid redoing the whole assignation which took me years to setup. Many thanks for any help

It has nothing to do with the F10map. I have the issue just entering the UI from windows. even before I do anything. It's just painfully slow UI once I launch DCS it can last 10 minutes and then go away and come back 3 minutes later. It's basically impossible to navigate in DCS UI and certainly not launch a flight. I actually can see the issue even before I am in the DCS UI because DCS takes 3 times more yime to load. And if I am typing a forum message like now on a browser while DCS is loading or in the UI my keyborad responds every 3 seconds to a letter. the whole computer slows down When the issue happens, my VRAM is far from being maxed out. I'm at 17-18% VRAM use and 10% CPU use. DCS in the process is highlighted as using a lot of energy. This has been happening for me usually after DCS updates for a couple starts then seemed to vanish until the next update. But since last update where I installed Kola at the same time it doesn't go away it's besically everytime I launch DCS