Red Dog

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

for me the stutters happens mainly in the UI and when I go external view or F10 map. Launching a mission is a nightmare as my mouse and keyboard are unresponsive in the UI, ometimes for as long as 5 minutes I can't alt tab, I can't click a button, the mouse is still on the desk but the mouse cursor in the UI is slighly drifting. Once i'm in pit it usually works well unless I go external view or the F10 map, then it starts again and usually result in a crash. Yesterday night a MP mission finished like that after 40 minutes of flying, (after a good fight in the Ui setup up the flight) I switch external view (F2) and it started to pause and freeze. I couldn't come back in the pit (F1) and remained frozen until it crashed. I don't get the issue all the times. It's not consistent

I agree and it is quite annoying. It was introduced with the pilot, which in not active in the attached screenshot. It started to happen without changing reflections setups (I'm on static for both MFD and canopy) right after the 3D pilot update. The first time I thought the crew chief forgot to clean the canopy. This reflection is very annoying

It was built in 2004-2005. I can't remember specifics but back then it was all homemade. Sorry that it won't help much

I agree, it would be better if ED had a better beta test system in place which would prevent breaking things more than adding new things. But I do not agree that a manual would be the solution, I also feel the changelog isn't too bad What ED critically need is better Q&A and at least checking not only the new features but also the old features to ensure nothing was broken by inducing new feature. (i.e: betat test) That's a Q&A dept and that Q&A dept could issue instruction to devs and issues small mini procedures for the community to overcome the broken things until they are fixed in the next release. I know a bit about writing F-16 sim manuals and I can tell you that this is already very hard to do when all is more or less stable. And it takes quite a while (usually during which dev cycles continue) Doing this for FCS F-16 in it's current cycle of updates is a big no no. The writer would turn crazy in less than 6 months. He would basically suffer the same issues you guys are reporting. My past experience taught me it is almost impossible, frustrating and a source of conflict to write a manual when the software is being contantly updated and when 1 step forward induces 2 steps backwards most of the release cycles. I did start writing DCS F-16 manual but it is pointless as long as the above points are not addressed unfortunately. So here's a vote for better Q&A ED

Here's some real pit building Late last year I bought a 3D printer and I needed an easy part to learn 3D design and printing 1 0 1. The FDR will be the perfect candidate. The FDR is a Flight Data recorder attached to the left side of the Aces II I learned Fusion 360 as I designed it. Then I had to learn the process of 3D printing where everything is important, placement of the parts, exposure time, type of resin, supporting your piece, thinking upside down ... lots of fun as well and a few hair less on my skull due to scratching That was a lot of fun and I really enjoyed it. The top connector part is screwed on the FDR bottom plate and the bottom connector is screwed in from under. After a good wash, the resin was primed in white. The seat plate painted in light grey and screwed on the seat side The FDR has been painted in bright Daygloo orange (Tamiya TS-12)and the connector was given a lot of attention with different shades of metal paint, that took quite a while to get right. I cut a length of the real wire harness I had hanging from a real connector and attached inside the FDR and made it pas through the connector, the loose end will be attached to the seat side. As I don't have the seat rails, that will have to do. I didn't make the lanyard yet as I have nothing to attach it to (no rails again) Final FDR with stickers For those interested the STL files are available. FDR box, lid, attach plate and the 2 connectors

Thanks Smith, Doesn't make us younger does it You already nailed your pit. It's indeed exactly what is needed, the rest is overkill ... Well done. I started with Flanker 1.0 and Flanker 1.5 ages ago. I must say I have a sweet spot for the flanker airframe as well Helios. It actually allows to hide a panel and I use that feature to hide the instrument and make room for the DCS kneeboard - which is a pain to set at fixed coordinates Hey Bud - It's been another life. Glad to see you're still around as well

Next one: embedded checklists in the CPD with the DCS kneeboard

Here's the first of I hope many series of Vlogs using the pit: MP Air to air refuel in the persian gulf

The F-16 cockpit was started in 2004 and built for Falcon 4.0. It flew BMS for 15 years. Since 2021 I switched to DCS and today I am ready to restart publishing Vlogs flying the pit. The pit flies both sim without reprograming, so all key inputs are common between DCS and BMS, it took a while to setup. The software interface is also common thanks to a little software gem called DCStoF4 allowing to put life in the DCS cockpit by reading the BMS shared memory. This may sounds strange to most of you but when all the cockpit has been interfaced to read the BMS shared memory, it's much easier to keep doing it rather than reprogramming the multiple third party apps that are necessary to interface the pit. The small caveat of course is that the BMS shared mem needs to be active when I run DCS. Small price to pay to have a pit flying two totally different sim. Full report of the WIP build is on Viperpit Enough talk, Here's an introduction picture of the pit and I will use this topic to post Vlogs of solo and MP flights with the F-16 in DCS

Sec checks are still impossible to perform at ramp due to the above. so kind bump for this issue hoping to see it solved one day

bumped into this issue as well the FUEL QTY TEST keybind seems to emulate the FUEL QTY NORM position however they may have different keypress declared in the controls. It works fine in the UI - control options. Moving the rotary switch to TEST shows test and moving it back to NORM shows the keybind for NORM. All other position works equally fine But in 3D it is different QTY TEST cannot be emulated, rotary remains to NORM NORM works as all other positions (RSVR, INT WING, EXT WING, EXT CENTER) - using the declared keystroke for QTY NORM moves the switch back to NORM => OK - using the declared keystroke for QTY TEST moves the switch back to NORM => not OK It is easily checked by placing the rotary to INT RES (any position except NORM) for instance and using the keyboard to type the keystroke for TEST => knob goes back to NORM Thanks LeCuvier for your work around, I'll implement it right away.

not an option I'm afraid

Hello gents is there a way to have more radio menu shortcuts a la A/A refueling - "Ready for precontact" radio call @LeCuvier ? This one above is really helpful to avoid having to mess with the radio menu options close to the tanker. Alternatively, is there a way to declare more custom ones line the one above for instance: A/A refueling - "Intent to rejoin" radio call Ground crew - "Place chocks" radio call Ground crew - "Remove chocks" radio call (the last two not being so critical since we're on the ground and could navigate the menu - but IMHO at least the request join up with tanker would be useful. Many thanks as always

Just want to confirm this issue. At night when you dim down the in game MFDS (F-16 in my case) to a non bright level, the exported MFDS are completely invisible It would be great if both in game and exported have the same BRT levels Hopefully that gets sorted one day.

another vote for this to be enhanced a bit. I feel the left one UP and Down is OK but the right one Forward and Backward is a real pain to see both during daylight and night AAR The issue I feel is not really brightness but lack of contrast due to a white line of lights against the green reference light. That is what makes it very hard to see IMHO just removing that white line would tremendously help In the above picture I know I'm great on up and down but I have no way to know where I am front/aft from the light only

file sent and thank you as always

yep, first thing is to ensure you have admin rights with notepad++ then from my understanding (Lecuvier will correct me if I'm wrong) then you can either do it in keyboard\default.lua or joystick\default.lua depending if you want to assign this to a keyboard keypress (then do it in keyboard\default.lua) or a DX button of one of your button boxes or joysticks - then do it in joystick\default.lua I did it in joystick\default.lua and assigned it as a DX button of one of my BU0836

in my case as soon as I declare the RWR in my multi screen lua file, following the above procedure, my multi screen lua files gets deleted from the list of LUA files DCS sees from the UI .Just like I reported there: If I remove my lines for exporting "RWR" from the multiscreen lua files, then at next boot DCS sees my multi screen lua file again but as soon as I declare RWR I'm toast I feel DCS really does not want you to export it honestly though I dropped trying exporting the RWR when I fought that issue a few days ago. I tried this morning again following this topic procedure and I hit the exact same issue again. Don't know why it seems to work for some but not for me in any way

You're right, I found them - even better Silly me then, I must have missed them the first time To my defense Pitch trim knob really doesn't make me think of the ADI, but rather the MAN TRIM pitch controls (which are not in the instrument section) My apologies. and thank you

Could I abuse and ask the same for the ADI adjust symbol? (the small airplane model used to set right in the center of the ADI) It's currently implemented as a potentiometer, but not as a key as far as I can see. Probably not something widely used, but in a pit with the seat adjust and flying IFR, it is useful Thanks I tried this: { down = alt_commands.ADI_ZeroPitchTrimLeft, up = alt_commands.ADI_ZeroPitchTrimLeft, value_down = -1.0, value_up = 0.0, cockpit_device_id = devices.ADI, name = _('ADI Trim Knob - CCW'), category = {_('Instrument Panel')}}, { down = alt_commands.ADI_ZeroPitchTrimRight, up = alt_commands.ADI_ZeroPitchTrimRight, value_down = 1.0, value_up = 0.0, cockpit_device_id = devices.ADI, name = _('ADI Trim Knob - CW'), category = {_('Instrument Panel')}}, and although I see the lines in the control binding screen, assigning it and testing it does not give any result. The default potentiometer assignation works though

I'd rather wish for ED to look up this problem and let us move both the kneeboard and the control indicator as we users would see fit without breaking the IC? I'm sure it's not on purpose that it breaks the IC, it's just an omission because the kneeboard and the stick indicator (and maybe others) have not been taken into the multi monitor big picture (pun intended) Maybe the right way to fix this is to let us manage these two with dedicated common viewports. Problem solved. - No more weird default position which change from one user to another - Users gets flexibility and can place their stuff where they want it - No IC failure - everybody happy and sorry for the added work for the devs. So Ed, pelase report this issue and see if this can be fixed - Thanks In the meantime, we'll have to find or own way till this is addressed eventually.