Red Dog

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.

Hello Gents, I have been working with the multi screen setup of DCS for the past week trying to reactivate my 5 screens in my F-16 cockpit I have two configurations made in parallel (both for F-16) - A custom one I manage myself - An Helios one managed by Helios Both have their own lua file. The custom one is named RD_pit.lua and the Helios one is named Helios.lua RD_pit extracts both MFD, the EHSI and the RWR. I couldn't make the RWR to work in any way I tried, but MFDs and EHSI worked fine Helios extracts only EHSI and RWR but RWR wasn't working either Here's the RD_pit _ = function(p) return p; end; name = _('RD_pit'); Description = 'my 5 screens pit setup. Main is 0.0 3440x1440'; Viewports = { Center = { x = 0; y = 0; width = 3440; height = 1440; viewDx = 0; viewDy = 0; aspect = 2.388889; } } LEFT_MFCD = { x = 3515; y = -5; width = 500; height = 500; } RIGHT_MFCD = { x = 4140; y = -5; width = 500; height = 500; } CENTER_MFCD = { x = 3441; y = 481; width = 750; height = 750; } RWR_ALR56 = { x = 4345; y = 481; width = 750; height = 750; } EHSI = { x = 3659; y = 1175; width = 330; height = 330; } UIMainView = Viewports.Center GU_MAIN_VIEWPORT = Viewports.Center Here's Helios _ = Function(p) return p end Name = _('Helios') Description = 'Generated from Compatible Helios Profiles' F_16C_EHSI = { x = 3648, y = 1205, Width = 330, height = 330 } F_16C_RWR = { x = 4224, y = 525, Width = 750, height = 750 } Viewports = { Center = { X = 0, Y = 0, Width = 3440, Height = 1440, Aspect = 2.38888888888889, Dx = 0, Dy = 0 } } UIMainView = Viewports.Center GU_MAIN_VIEWPORT = Viewports.Center Both were working fine when correctly declared in DCS setup UI (screen resolution and pointing to the relevant lua files for screen setup.) This worked until this morning, see the other topic I posted with that working RD_pit screen configuration. I was changing the RWR names back and forth trying to make it extracted and then I noticed a first weird thing: On one test, DCS displayed on ther whole resulution, not only the main screen as usual. This usually happens when the resolution is made greater than 3440x1440 (in this case: 5229 x 1504) and the monitor config is missing and DCS reverts to one screen. But when I opened the monitor drop down, I noticed my RD-pit file was listed TWICE although there was only one file in the config\multiscreen folder I reassigned one of the two - assuming it was a glitch and they would be identical and DCS rebooted When DCS opens, I get back in the config menu and to my surprise, no RD-pit are listed again. None, the name simply vanished from the list Yet it is indeed in the correct place (look at picture below) in the windows folder. It simply is not seen by DCS anymore. I do see the HELIOS one though - so I activated this one and DCS reboots again. I am again in DCS with DCS being isplayed correctly on the main screen but monitor set to 1 monitor and this time the HELIOS lua file is not visible anymore either from the drop down monitor list? truely weird as with the setup to 1 montor, DCS should be displayed all over my 5 screens, which is not the case. As before with the RD_pit occurence, Helios.lua file is indeed at the place where it has always been. Next time I start DCS, both Helio and RD_pit are invisible from the monitors drop down list and DCS is displayed all over my 5 screens - which is rather hard to manage since the small screen are scattered in the pit Here's the drop down open (in two picture to see the full list) Here are the folder in windows: 1. Main install folder As you can see the RD_pit is there as it's always been - but it it not seen by DCS anymore? 2. saved game folder As you can see the Helios is there as it's always been - but it it not seen by DCS anymore? I trying many things to make them reappear in DCS, now way !! I even copied the content to a new file (Config_0124 that you can see from the above folder list) and edited it's name accordingly with notepad++ But as you can see from the UI picture above, even that one is not appearing in the drop down list I also tried to remove the RWR export I was trying to make work, and saved the modification but still the option does not appear in DCS again? I am back to one screen 3440x1440 and lost my multi monitor configuration I had yesterday and which was almost working fine This is really beyond my understanding - why every file I modify disappear from the list not to be seen by DCS today? It really makes no sense If anyone has any idea - I'm all ears Thanks

I am in the same boat tried different things and came up dry so far. Any speciofic procedure would help Many thanks

When I enable the kneeboard the first time, it's being displayed in the middle of nowhere in my multimonitor setup. Luckily we can now drag it back to a more suitale position and it will keep that position for the remaining of the flight. But at the next flight, the middle of nowhere location will be active again. It would be great if there was (or maybe there is? ) a way for the user to setup the default location of the kneeboard where suitable in his own multimonitor setup, like for instance being able to decalere a kneeboard viewport and set it up just like the MFDs or the other common viewports ? That woudl be quite useful IMHO Thanks

Same issue, due to the total multimonitor size and decalred resolution, the control indicator i partly hidden for me . It seems to stick at the bottom left of my multiscreen setup, which is lower than my mainview. Hence I do not see the full indicator setup Unlike the kneeboard we cannot drag and replace this one It would be great if we could setup position of this view (maybe there is one I don't know?) through a viewport of something to ensure users could place it where they want it (same with the kneeboard btw)

wouldn't cursor zero work?

I just assigned this axis as an analogue value in my pit, read connected to a potentiometer rather than using keystrokes or mouse to implement this. There is a slight issue with the way it's control is implemented with the potentiometer It works fine with only one little caveat: when you turn it all the way down, the HMCS symbology dims and disappear as expected but when you turn it clockwise again, the symbology doesn't come back immediatelly. You first have to come in cockpit (Cockpit and HUD blanking) and when you go out of the blanked area the HMCS symbology reappears according to the potentiometer position. There's no reason the symbology should reappear only after going in and out of the blanking area Certainly not critical, just a very minor issue

Anyone has any idea what is the purpose of this control do? HDG SET knob - Depress in Instrument panel category it's declared in the F-16 key list but I don't see any effect when I assign and test it Closest guess I can do is the pushbutton we usually find on HDG and CRS encoder for centering the heading bug. That is not a real thing in the non EHSI equipped F-16 (but might be in the EHSI equipped airframe?) but anyway it does not center the heading bug in the latest DCS The CRS Set / Brightness control knob - Depress works as advertized and enable EHSI brightness control Anyone has any clue what the HDG SET knob - Depress does? Thanks