WHOGX5

To each his own, but that's what I'm planning on doing. The only thing I'm unsure of is that the ECM seems to be implemented in a way so that you can't have radar priority in MAN mode, only ECM priority (radar gets silenced). I've been out of town since the last patch released though so I haven't had the opportunity to try it for myself. The way I have my CMS set up is PRGM 1-4 for regular chaff as well as pre chaff/flare, CMS left for my flare program and slap switch for emergency chaff and flares. However, if I can only use radar priority in SEMI / AUTO, then I'll use SEMI and just set the program to drop zero chaff/flare and drop them manually using PRGM 5-6 instead. Another reason why using SEMI isn't a good idea is that when you're within, as an example, approximately 25 nm of your target you usually want to turn your ECM off as modern missiles can home on jam and there's no point in blasting your ECM within burn-through range of the enemy radar anyways as that just gives your position away. But turning off your ECM with CMS right will also remove consent for the SEMI mode. So your pretty much stuck between choosing between ECM and chaff or no ECM and no chaff. As it seems there's no in-between in the current implementation.

In the DTC teaser images released by ED a couple of years ago there were options to set pretty much every single cockpit switch the way you want it for cold starts. It's been so long since then so who knows if it'll still be a feature or if it has long since been scrapped. And I'm sceptical regarding the current cold start setup being the worldwide standard. Is it standard procedure during preflight to set every single volume knob to the maximum setting and blow out the eardrums of the pilot?

Well, it doesn't make 100% sense as it's currently implemented in DCS. Chaff is most effective near the notch and (IIRC) the ALQ-184 as a +-30° cone fore and aft where it's effective. So when you're in an aspect where you want to drop chaff you wouldn't want to use the jammer and vice versa. I just assume that the SEMI and AUTO modes in the real F-16 are advanced enough to adapt to the aspect of the aircraft to the engaging unit, otherwise it feels like they'd be completely useless, just constantly jamming and dropping countermeasures as long as you're spiked, no matter the situation.

It's not about wanting to silence your radar but rather it's about diverting power from your radar so you can squeeze more power into the ECM pod. So your options are to do some half decent jamming while being able to use your radar/HTS or jamming with the absolute maximum power output available to you but not being able to use the FCR/HTS at the same time.

So I've understood this much like @TEOMOOSE and @GrEaSeLiTeNiN has. What I wonder is if I'm in SEMI or AUTO mode and press CMS up, will I still dispense my manual PRGM 1-4? Becuase at least in the F-16 countermeasures .lua there are three programs in addition to program 1-6 which govern the SEMI and AUTO response to different threats; one is IR SAM, one old radar and one for new radars. This makes me think that we'd actually be able to have 4 different programs on hand at once in SEMI / AUTO; CMS up for PRGM 1-4, CMS Left for PRGM 6, slap switch for PRGM 5 and CMS Down for whichever program is selected by SEMI or AUTO mode. EDIT: Typo

As I understand it he's saying that, in the current DCS implementation, if you turn left with an RWS brick on your FCR, the brick will move right on the FCR page to stay in the same position over the ground, or at the same coordinates, hence it's ground stabilized. However, say that you're really close to a target and you're flying towards it at a high speed, then the brick will remain stationary relative to you distance-wise on the FCR even though you're constantly closing in on it; the RWS bricks real world coordinates will change so that it maintains the same position on the display, hence it is display stabilized. As should be obvious, ground stabilization is preferred as it gives you the correct location of the last hit irregardless of ownship maneuvering while display stabilized only shows you where the contact was relative to you at the last hit; the more your distance or azimuth to the target changes, the higher the deviation between the actual and indicated position of display stabilized returns.

Just a slight correction: PDLT is set via the HSD (via TMS right on a datalink track if I'm not mistaken). As far as I know it's not possible to set PDLT via the FCR but it was a long time since I read about it.

The short answer is no. You can enter the time for each steerpoint by pressing 4 on the ICP, but none of the systems around it or actual calculations have been implemented yet by ED. So the closest you'll get is using the time-to-target countdown in the bottom right of the HUD and adding that, using your brain, to the current time which gives you an ETA that you can then compare with the actual time-on-station that you've set for the steerpoint. A real pain in der poopenschaft if you ask me.

Ah ok, I wasn't sure about that one. In either case, shouldn't the angular velocity of the radar dish still be constant? Because as it is right now, if I set my radar to either EXP, DBS1 or DBS2 and cycle through A1, A3 and A6, the time required for a full scan will increase and decrease, hence the angular velocity of the radar dish, even though it's covering the same area.

I had the same issue with the 97's. Didn't have any issues with the 87's though.

Trackfile. As you can see, everything works as it should in NORM. It's in EXP, DBS1 and DBS2 that issues start to arise. A-G Radar - Angular Velocity.trk

PM sent.

Do I really have to start scouring through manuals to prove that such a basic thing as being able to point the radar in any direction within gimbals limits is something that's actually possible in real life. Why on earth would any radar in the world have a +-10° azimuth setting if you can't slew it around? It functions just like the A-A radar does. If you move the cursor, you move the scan volume.

Yes, I will concede that you managed to correct it and I no longer stand by this being an irreparable issue. Also, since it said I was in MAN mode, I assumed I was in manual mode. It seems like the MAN and AUTO range labels are reversed, hence why I couldn't change the range manually. However, the issue still stands as it is functioning incorrectly. This is not "correct as-is".

As per the title. Trackfile included. A-G Radar - Azimuth DBS2.trk

Yes, I'm aware of that. But if the area you've selected is near the edge of your scan volume, it will irreparably break the A-G Radar. This is not correct.

When slewing the cursor around while in A3 and A1 azimuth setting in NORM, the scan volume does not move with the cursor. Trackfile included. A-G Radar - Scan Volume.trk

It didn't help. I found some weird things though that might shed a little bit of light. If the cursor is near the edge of the FCR and you go EXP/DBS, you'll get the aforementioned issue. If you do the same with the cursor somewhere away from the edges of the display, you wont. It also seems like it's possible to move the cursor outside of the scan volume limits in EXP/DBS. It doesn't stop at the edge of the screen like it does in NORM.

I just went in and out of EXP and DBS back to NORM and somehow my scan volume ended up outside of the MFD. I was also unable to change range. Didn't touch any controls except the EXP/DBS OSB. Trying to change modes or go into snowplow doesn't help. Trackfile attached. A-G Radar.trk

Patch is available for download.

Patch notes: https://www.digitalcombatsimulator.com/en/news/changelog/openbeta/2.7.7.14727/

In the GM radar video posted by Wags (linked below with timestamp), when he enters DBS mode the angular velocity of the radar dish changes depending on the azimuth setting. Or alternatively, the time required to perform a full scan is correct, but it's not proportional to the angular velocity in DBS. It seems like the radar is moving relative to the zoom level of the FCR, rather than the actual azimuth setting. If you're in DBS A6, the angular velocity of the radar dish should be the same as in DBS A1, but the time it takes for a full scan should take longer as you're scanning a wider area. Therefore, in DBS A6 you should only see your radar image update during the very short time the radar dish passes the area you're looking at, and then you'd have to wait for the radar dish to rotate all the way to the gimbal before coming back and updating the area you're looking at again. As you can see, when Wags enters DBS with the A6 setting, it takes the same amount of time for a full scan as it does in NORM A6, but instead of moving left to right +-60 degrees, it moves relative to the borders of the zoomed DBS mode, roughly +-10 degrees, yet a full scan takes the same amount of time as +-60. Thus it has a lower angular velocity compared to NORM. Then when Wags enters A3 you see the angular velocity increase, which it shouldn't, while the time required for a full scan decreases, which it should. Finally, as he enters A1 it speeds up even more to roughly the correct angular velocity. EDIT: Also, I just noticed that the same issue applies when he decreases the range in DBS 2. The edges of the scan is still relative to the display even though the FOV narrows down, rather than being relative to the azimuth setting. Timestamp at 7:26.

You're arguing as if I said that a .lua would be the end all solution. It would be a stopgap measure. Like you said, we have nothing that is satisfactory, but having a .lua would alleviate a lot of the problems we face. And regarding the threat circles, they can be enabled/disabled for individual units in the mission editor so if things are visible that shouldn't be, that's on the mission creator. I can't speak for every airframe as I pretty much solely fly the F-16, but the reason that threat circles can't be added or removed in the F-16 is that they haven't been properly implemented threat yet. Every threat circle should be tied to a steerpoint, but as it is right now, they just magically appear. Would it be far more painful than waiting for a DTC for an entire decade, ever since the release of the A-10C, before DCS World even existed? Going in to the sub menus every single flight to setup the exact same settings for years on end? Because that's what a lot of us have been doing. It's not like creating a .lua, that changes values in other .luas that already exist, would take thousands of man hours to implement. It would be an incredibly bare bones, temporary solution that'd give third-parties something to work with, and I'd be surprised if it took more than a couple of weeks for all the DTC options to be implemented into something like CombatFlite. And I don't agree with your opinion that implementing a stopgap like this would decrease the likelihood or increase the difficulty of implementing a proper solution. Lately it has become quite apparent that ED wants to implement something akin to the Joint Mission Planning System. That's great, but it's gonna take a long time to make. A few years ago ED released pictures of an entire DTC menu covering pretty much every setting you could possibly want to set in an aircraft, even switch state when starting cold. That system could've been rolled out ages ago if it weren't for the JMPS. At least that's my analysis of the current situation. The reason a JMPS system would take such a long time to implement, is that it covers all things related to mission planning and is way beyond a DTC in scope. If they pull it off, the JMPS should cover everything from simply placing steerpoints to providing fuel and drag calculations, climb profiles, calculating weapon delivery profiles, etc; pretty much anything that relates to the mission planning process. All these things would have to be worked out for each air frame in the sim That's why some sort of stopgap measure, like a .lua, would be a great interim solution. Even in a controlled environment like a DCS community there is so much time that has to be spent and so many hoops that have to be jumped through in preparation for each mission, simply because we're 100% reliant upon the .miz file. Every single thing you want to set, from steerpoints to radio presets to laser codes, has to be set in the mission file itself unless you want to input everything manually and drastically increase the risk of something being input incorrectly. And that doesn't even cover the things you can't set in the mission editor, like countermeasures, MFD setup, etc. So a JMPS would be better than a .lua, but a .lua would be infinitely better than having nothing at all for the foreseeable future.

You have to enter elevation manually. You can find the elevation using the mission editor, F10 view, CombatFlite, etc.

I think the real missed opportunity would be to model a two-seat F-16. Simply making an F-16D Block 50 or even an export variant with a PW engine like the F-16D Block 52+ would take much less effort than making something like an F-16A or early F-16C, yet add a whole slew of new capabilities, especially an F-16D 52+: AN-APG-68(V9), internal ECM, CFT, WSO, LANTIRN, etc. This would also be the first combat capable "trainer" in DCS. The only other two-seat fighter we have is the F-14, and it's not very well suited for teaching new pilots how to fly or taking people along for incentive rides since you can't really fly the F-14 as a single seater. A two-seat F-16 would allow new pilots to practice everything from takeoff and landing to A-A and SEAD together with someone experienced. Not to mention taking potential DCS customers along for an actual mission where you're not merely watching a youtube video, but you're actually there. You get to experience everything first hand and feel what it's actually like.