WHOGX5

I think what is clear from this thread is simply that ED should wait longer with pushing new features. You can still output the same amount of content at the same pace, just do it a month or two later and give both your QAs and developers more time to find and fix any bugs. That feels like it should be enough to stop all these bugs, because it feels like every DCS F-16C patch is two steps forward, one step back (at best). I also think ED needs to be more receptive to bug reports. It is very difficult to get bugs reported, and so many threads which are clearly describing incorrect behaviour gets marked as "correct-as-is" and locked to prevent any further discussion or context to be added to the matter. I know both myself, and a lot of my DCS friends, have simply stopped reporting bugs on the forums because it feels like a futile endeavour, when you've spent hours sometimes researching an issue and providing all kinds of information, and still it gets marked as "correct-as-is" and locked. The community is more than willing to help ED make the DCS F-16C the best it can be, we just need to be given the opportunity.

@Tom Kazansky If you look at the real life tanker tracks from Operation Allied Force from the af.mil webiste, and you do some Google Maps measurements and MS Paint forensics, you'll find that the AGIP tanker tracks are about 40x20 nautical miles in total, meaning a 10 nautical mile turn radius and 30 nautical mile legs.

They're always in racetracks, but the speeds and altitudes vary in accordance with real world tanker setups for recieving different airframes. So for the F-16C's for example, optimum altitude and airspeed is at FL300, 315 KIAS.

Currently, tankers decrease their bank angle when an aircraft is refuelling. This often leads to a close to 40 nautical mile turn radius which is absolutely enourmous. This effectively means that a tanker with 20nm legs, with the possibility of initiating refueling on either of the two legs, will occupy an airspace of about 70x60 nautical miles. It would be nice if the mission creator could choose either the desired bank angle and/or turn radius in the mission editor. For communities who try to adhere to real life airspaces it is simply an impossibility to do so when the turns are so incredibly wide.

I agree that it is logical procedure in real life to turn off the station before mounting/dismounting the TGP, but that does not mean the TGP will not turn on when the hardpoint is powered. Obviously you would keep things turned off IRL to minimize the risk of power surges and stuff like that during power cycles, but that kinds of wear-and-tear and failure simulation is a level of detail which is not simulated in the DCS F-16C (but I would warmly welcome that level of failure simulation in the DCS F-16C). Also, another issue in DCS (last I checked) is also that we cannot re-arm individual stations, so any time you hang some new bombs off of your wing, it will remove and replace your TGP whether you want to or not. Most of all, it's worth pointing out that this issue applies at cold starts as well. I've only done one flight since the last patch, and I did my normal startup procedure according to checklists, where I powered up the hardpoint well after the TGP had been mounted and the engine had began supplying power to the aircraft, but when I brought up my TGP once I was airborne, it was still turned off. This also happened to my flight members who flew with me last night.

I don't know why this is set to "not a bug"? If the hardpoint is powered, there should be power to whatever is connected to the hardpoint, right?

It would be nice to know whether this is even a recognized bug and that a fix is on its way? It's really difficult to visually ID A-A targets with the TGP because it's constantly jittering back and forth, and often times it jitters so much that you can't even get a point track on your target.

This is a really old bug which has been reported many times before. The problem is that in the DCS F-16C the EPU does not power all the systems connected to the emergency buses. This is why the INS always looses power when you have a flameout in DCS but not in real life, because in DCS it is simply not powered by the EPU. No word on when this will be fixed.

The thing is that the DCS F-16C manual is 100% correct, it's just the in-game implementation that's incorrect, and it's due to a slight misunderstanding of the manuals by the DCS F-16C developers. It is 100% correct that the concentric rings correspond to the different lethalities of the detected emitters, where Ring 1 indicates search, Ring 2 indicates tracking, and Ring 3 indicates missile guidance. What this means in real life, is that if an emitter is in Ring 1, your RWR can detect it's emissions, and through threat identification, known max range of that identified threat radar, its detected signal strength, and other factors, your RWR determines that the detected emitter is so far away, that it can't see you, but you can still detect its emissions. When an emitter gets close enough to end up in Ring 2 it is within tracking range. This means that it can now actually pick you up on its radar, but you're still outside of its weapon engagement zone. Finally you have Ring 3, within which you're inside the weapons engagement zone of the detected emitter. As an emitter gets closer or further away from you, it will move gradually between these rings. This is one of the amazing features of the AN/ALR-56M, as it allows you to react extremely quickly to pop-up threats. As soon as a new emitter pops up on his RWR display, the pilot can tell, at a glance, the level of lethality that emitter poses to him. The issue with the current implementation is that every emitter which isn't locked on to you and isn't shooting at you will end up at the center of Ring 1. Its level of lethality doesn't matter, threat type doesn't matter, max track/engagement range doesn't matter, signal strength doesn't matter, it can be 1nm or 1000nm away from you; it will still show up in Ring 1. As soon as it locks on to you, it will teleport to Ring 2. Then as it fires, it will teleport to Ring 3. This makes the current AN/ALR-56M implementation in DCS quite useless as it doesn't give the pilot any useful information except bearing to threat, like an old 70's RWR. All even remotely modern RWR's (including the AN/ALR-56M) already have ways to indicate whether an emitter is locked on to you or guiding a missile towards you using various symbology and sounds, it does not need to put the emitter symbol at a specific location on the RWR to indicate these things. For comparison you can look at the AN/ALR-56C which Razbam implemented into the F-15E. Unlike the M-variant, the C-variant only shows raw distance, where the outer edge of the RWR display corresponds to 60nm. This means that the pilot has to know, in his head, at which distances certain things are lethal to him. His situational awareness from the RWR is therefore much lower because he has to calculate all of these lethality levels himself, rather than having it be supplied by the RWR. For extremely long range threats like SA-5's, S-300/400/500, etc., an F-15E pilot won't even know when he's within range until he gets locked and launched at from >60nm distance. The main development of the AN/ALR-56M is its extreme sensitivity which allows it to detect emitters at incredible distances, and give the pilot increased situational awareness via the RWR. This is why BAE Systems (company who makes the AN/ALR-56C & M), on their own website, say that the M-variant provides "Situational awareness for long-range response strategy/threat avoidance.", which is something they don't say for the C-variant, because you can't do long-range threat avoidance with an AN/ALR-56C because of the aforementioned reasons. This is why the US Air Force chose to equip the F-16CM, their premiere SEAD platform, with the AN/ALR-56M, to allow it to operate in dense high threat environments with greatly increased situational awareness and survivability. As it is in DCS currently, the F-15Es AN/ALR-56C provides the pilot way more situational awareness than the F-16Cs AN/ALR-56M, which is completely backwards of how it is in real life.

As a result of the F-16C being one of the few aircraft with a sidestick, its pilots normally carry two kneeboards; one on each leg. Is there any chance of us getting this in the DCS F-16C with the new pilot model? It'd be extremely helpful rather than needing to have everything from checklists, to charts, to mission data cards in the same kneeboard.

This is not entirely correct, but rather a slight misunderstanding of the manuals. What happens in real life is that when a pilot hops his aircraft he will load different identification requirements from his DTC which specifies what makes a track be classified as friendly or hostile using his onboard sensors. One important thing to note, is that the F-16CM-50 is unable to correlate IFF information to tracks, so any IFF response requirements in the identification requirements will only be taken from interrogations performed by other aircraft on the same target, transmitted via LINK 16. So a hostile ID requirement could be that the target has to be of type MIG-29 and have a negative Mode 4 IFF response. Then you can determine the aircraft type with NCTR using your own radar, and if some other aircraft on your LINK 16 network has interrogated that same target, correlated it to the track, and sent that Mode 4 response back onto the network, then that target will show up as hostile on your FCR. Now, if there is a disagreement between a track identity on the LINK 16 network and the identity which has been determined for that same correlated track by your own aircraft, then the track will mipple (flash) between the two different identities to show the pilot that there is an ambiguity there. Since ID requirements aren't necessarily the same on the LINK 16 network and in your own aircraft, you can have all kinds of ID disagreements even with the exact same information about the track in question. Also, what the manual means when it says that the FCR has no authority to change ROE, they literally mean that what is displayed on your FCR doesn't in any way override the rules-of-engagement which have been set by the commanders and generals leading the war. Just because something has been ID'd as hostile in your aircraft, does not mean that it actually is hostile or that you're cleared to fire at it. In the same way, just because something shows up as an unknown, does not mean it's not hostile or that you're not allowed to fire at it. You can have a situation where you have identified the aircraft type via NCTR, you have performed an Mode 4 interrogation which came back negative but isn't correlated to the track so it still shows as unknown, yet you have still fulfilled theatre ROE requirements and are allowed to fire at the target. So yeah, the main issue in the DCS F-16C regarding this specific aspect of the symbology is that correlated tracks don't mipple back and forth between the different track identities if there is a disagreement in identity between your own onboard sensors and what is supplied via LINK 16.

The FCR symbology in the DCS F-16C is not functioning properly at all, and unfortunately there is no other answer than that it is a complete guessing game. As it stands currently you cannot see which targets are buggable or not in any of the FCR A-A modes. For this reason I personally don't use TWS unless I absolutely, absolutely have to, as the issues you mention make it extremely labour intensive and unreliable. You will have the same issue in RWS when using the SAM and DTT modes, but at least there they are easy to fix by simply pressing TMS UP again.

After doing some tests where I fly in a straight line towards an SA-5, I have come to a few conclusions about ECM performance in regards to the DCS AN/ALQ-184. I have attached 5 different track files from the 5 tests. I did every test twice, and the results were identical indicating that ECM in DCS is very likely to be deterministic, so I've only attached one set of tracks. During the tests I was flying at approximately FL250 at a speed of about M0.8. Test 1 - No ECM, Result: Stable lock at 75 nautical miles. Test 2 - ECM in Mode 1, Result: Stable lock at 72 nautical miles. Test 3 - ECM in Mode 2, Result: Stable lock at 72 nautical miles. Test 4 - ECM in Mode 3, Result: Stable lock at 31 nautical miles. Test 5 - ECM in Mode 3, but I only turn it on after being locked by the SA-5 and turn it off again after a lock has been broken, Result: Stable lock at 72 nautical miles. As you can see, there are a few take aways from these tests. Firstly, as most of you probably know, the difference between Mode 1 and Mode 2 is that Mode 2 will silence your radar in order to increase ECM performance, but according to these tests, it makes no difference whatsoever performance wise. Therefore there is no reason to ever use Mode 2, as it is objectively worse than Mode 1. On a similar note, in Test 5 where the Mode 3 barrage jam is manually activated in order to emulate Mode 2, you can see that it has the exact same performance as both Mode 1 and Mode 2. Lastly, there is no real reason to use Mode 1 or Mode 2 at all, as they only shorten the max range for an SA-5 to acquire a stable l ock by ~4% in exchange of decreasing the performance of, or even inhibiting, your radar. The only really effective jamming tactic is Mode 3 barrage jamming before being locked up by the enemy emitter. As soon as you've been locked, you may as well turn off your ECM to prevent home-on-jam shots as your ECM will not be able to break the lock again until you've reached a distance of within ~4% of max lock range, at which point you're pretty much out of harms way anyways. I obviously don't have any real life data on AN/ALQ-184 effectiveness against an SA-5, and since ED does not specify which variant of the Spoon Rest track radar they've simulated for the DCS SA-5 it's hard to even make an uneducated guess, but based on this test my personal opinion is that the effectiveness of barrage jamming seems to at least be within the confines of reason, whilst Mode 1 and Mode 2 break lock techniques are completely ineffective. The effectiveness of Mode 1 and Mode 2 should be increased with Mode 2 being closer in performance to Mode 3, whilst Mode 1 should have a slight decrease in performance compared to Mode 2 as a result of not silencing the radar. My guess is also that Mode 1 would have a much bigger decrease in performance against emitters with a similar frequency to the F-16CM-50s AN/APG-68V(5) radar (around 10-26 GHz according to public sources), but remain near equally effective against emitters using other radar bands as Mode 2. SA-5_TEST_Mode_2.trk SA-5_TEST_Mode_3.trk SA-5_TEST_Mode_3_Break_Lock.trk SA-5_TEST_No_ECM.trk SA-5_TEST_Mode_1.trk

Geographic lines are most often used for borders and boundaries like you say, but you can really use it for whatever you want, it's just a matter of placing the steerpoints and dashed lines will be drawn between them. Geographic lines are not yet available in the DCS F-16C though. The only steerpoint types that really exist in DCS so far is navigational points and markpoints. Allegedly, other steerpoint types will be introduced with the DTC, and when the DTC releases is still unknown.

Regarding your second issue, I know I have personally reported that as a bug several years ago at this point, but I honestly cannot be bothered to go that far back into my post history to find that thread. Suffice to say, the issue is that the bore ellipse in the JHMCS should follow true line-of-sight of your radar (this is true for the HUD bore cross as well), however, at the moment in the DCS F-16C the ellipse is simply drawn in the center of the JHMCS irregardless of where the radar is actually pointing. When you TMS UP to slew the radar to your JHMCS, it moves the radar from pointing straight forward to pointing where your head is looking, even though this isn't shown by the ellipse, resulting a lock on whatever is inbetween that path of travel. In the video below you can see the JHMCS in action at 3:29. As you can see, if you step through the video frame by frame using the "." and "," keys, you can see the ellipse instantaneously appear from one frame to the next where the head is looking, indicating that it initially won't lock anything while moving from looking straight in the direction of your aircraft to looking in the direction of your head, and once it's slewed to your head, it follows your head movements as good as it can (you can see how imperfect and laggy the FCR movements are). You can also see the ellipse "stick" to the target aircraft while it attempts to get a lock, and then it transitions to a square once a steady lock has been aquired. In the second video which shows the HUD symbology, right at the very start of the clip, you can see the "NO RAD" disappear right as he slews his radar to his JHMCS. A couple of frames later, the bore cross instantanously appears in the top left of the HUD, indicating the exact same thing as the first video, that the radar will not lock anything while transitioning from pointing in the direction of the aircraft, to pointing in the direction of the JHMCS. After this, the bore cross on the HUD will follow radar line-of-sight from this point onwards, just like the ellipse will follow radar line-of-sight in the JHMCS. As you've probably noticed, neither of these behaviours are present in DCS. If you turn off HUD blanking and look towards your HUD with the JHMCS in dogfight mode with the radar on, the HUD bore cross and JHMCS ellipse should be perfectly overlayed and following each others movements, which currently isn't the case in DCS. Instead, with their current implementation, the HUD bore cross will always point in the direction of your aircraft irregardless of where the radar is actually pointing, and the JHMCS ellipse will always point in the direction of your head, irregardless of where the radar is actually pointing. Also, the radar will lock anything in its path when slewing itself towards your JHMCS LOS, which shouldn't be the case as it makes the radar close to useless in a furball if it just arbritrarily locks anything it may come across, rather than what the pilot actually wants to lock up.

The issue you mention regarding inputting the opposing teams IFF codes is a non-issue, as it is fully realistic. No pilot should be flying with Mode 1, 2, 3/C or any other unencrypted transponder mode when entering combat. That's why Mode 4 and similar systems were developed who give encrypted responses and only respond if provided with the correct key, to avoid responding to hostile interrogations. Simply give both teams different encryption keys and the problem is solved. However, Mode 1, 2 and 3/C is still used by the military and it is impossible to fly according to real world procedures and tactics without these modes, hence why they should really be implemented into DCS Core, and not just for certain third-party aircraft.

Well, I think that the thread that you yourself created in the past (linked below) where you found flashcards regarding the AN/ALR-56M is very solid proof, even though it's only based on a document and not the document itself. There is such a large amount information in those flashcards that are verifiably correct, that I think it's safe to say, beyond any reasonable doubt, that all of the information in those flashcards is correct, including the part which states that the AN/ALR-56M uses navigation data to update emitter symbol positioning during maneuvering.

CTRL+Z

+1, I've had the same experience as those before me, I didn't get a track file or anything that I can upload.

It's also worth noting that this error does not apply to all airframes. I've flown the F-16C in formation with F-15E's in DCS, with the same barometric pressure set on our altimeters, and we had somewhere between 500-1000 feet of difference between our indicated barometric altitude at FL200-ish while flying wingtip.

This is incorrect. Firstly, you are indeed correct in the fact that the KC-10 is a special case which has the ability to provide both DME and bearing information via TACAN, but other aircraft can only provide DME via A/A TACAN, not bearing. That's the reason why the NATO brevity for A/A TACAN is "YARDSTICK", because you measure distance with it. Secondly, as has been reported many times in the past since a DCS patch broke this well over a year back, tankers in DCS can currently only be received with TACAN using either REC or T/R modes in DCS, which is obviously incorrect as these modes are meant to be used for ground stations. With your TACAN set to A/A mode you cannot recieve neither DME nor bearing from a tanker, but in REC you can receive bearing and in T/R you can recieve both bearing and range, irregardless of whether the tanker has this capability in real life, and irregardless of weather you've ticked the "Bearing" option in the advanced options for the tanker.

I mean... It'd be pretty dope to have the actual AVTR implemented. The ability to record HUD/HMD as well as both MFDs for both BDA and debriefing using the switches in the cockpit. That'd be extremely useful.

You don't have to accept anything, it will just magically appear in your aircraft as the steerpoint indicated on your HUD. One thing you can do though is to press the WARN RESET switch on the ICP to get rid of that message if you think it gets in the way.

The Sufa is so incredibly classified and has so many domestically produced Israeli systems that there is a 0% chance of it being developed for DCS unfortunately. The Greek F-16C/D 50/52+ variants have a lot of publicly available information however, so that might be a more viable alternative. Personally I'd really like an F-16D or a Block 40 with LANTIRN (or both).

They are indeed ground units. We had some guys in our community perform DEAD on an entire SA-2 battery with AIM-120's using A-A radar. Great success!