Raptor9

The original bug reported in this thread is marked as fixed. Further, I am not able to reproduce it either. Since the original topic appears to have been resolved, I am locking this thread to prevent any further confusion regarding the issue at hand. If anyone has any bugs or wishlist threads to post, please make a unique thread for it.

The "datalink signal" is not a continuous, singular signal; like when your phone indicates signal reception from a cellphone tower. The datalink is composed of discreet radio microbursts of data that are periodically transmitted from various units in the battlespace, which are then processed and displayed in the cockpit based on the data contained within those radio microbursts. There is no indication in the cockpit when the radio signal from Air Traffic Control is lost because there is no continuous signal being broadcast from a single ATC tower. In similar fashion, there is no indication in the cockpit when datalink is lost because there is no continuous datalink radio signal being broadcast from a single unit in the battlespace. If line of sight is lost between your aircraft and a unit transmitting information across the datalink channel, the information received from that particular unit is simply no longer received, just as if you can no longer hear the voice radio transmissions from that unit while still hearing all others on the same frequency.

The AH-64D and OH-58D have never had any sort of ADS-B or TCAS equipment installed, and neither did the F-16C variant modeled in DCS. No idea if modern-day versions of the F-16 do, and I am highly skeptical that the F-14 had any either.

1) Select a different point as a Direct destination. 2) Select a route on the RTE>RTM sub-page. 3) Delete the point that you've set as the Direct destination.

As stated previously many many times, APKWS are not planned for the DCS AH-64D because the AH-64D variant featured in DCS was never equipped with them. Simply repeating the same posts from the other locked thread will not change this fact. Thank you.

From the DCS F-16 Early Access Guide.

Any time George, as the AI CPG, is using the TADS (meaning it is not slaved to fixed forward), he will arm the aircraft which allows him to fire the laser. If you safe the aircraft, this conflicts with his assigned task, which is to use the TADS to acquire and/or engage targets. Therefore he will set the aircraft back to arm so he can continue to perform his assigned task. If you want to safe the aircraft, you must command him to stop using the TADS by pressing Down-Short with the AI interface displayed.

This is correct behavior. Specified on page 95 of the Early Access Guide.

From page 528 of the DCS AH-64D Early Access Guide: "Laser ranging" means someone is measuring the range to your helicopter, like an armored vehicle about to engage you. "Laser designating" means someone is designating your helicopter for measuring range or to guide a semi-active laser-homing munition, like a GBU-12 bomb or AGM-114K missile. "Laser beaming" means someone is guiding a laser beam-riding missile toward you, like the AT-16 Vikhr missile from the Ka-50 or the tank-fired AT-11 Sniper missile. Regardless of which message you are getting, you should interpret this as a hostile attack since someone is clearly intending to engage you imminently or has already fired on you.

Recommend this thread, by a real-life AH-64 instructor pilot.

There is no need to press Up a second time. George will automatically de-slave from your line of sight and begin searching. Pressing Up when the George interface is simply saying "Gunner, Target, Pilot Helmet Sight." Which is a common and standard target handover technique used by real AH-64D crews to cue the gunner to a target the pilot has visually acquired. No, it is not any more complex than any other modern aircraft. It is just designed for a different mission, in a different combat environment, and to fight in a different manner than a fixed-wing aircraft.

The AH-64D is indeed designed to operate during hours of darkness, but it wasn't intended to be operated at low altitudes near terrain or obstacles in an "unaided" manner without the use of the PNVS or TADS FLIR sensors (or night vision goggles as an alternative). And the CPG is certainly not going to be trying to detect targets at night using the unaided eye. If you are intending to fly at night without the use of the PNVS, TADS, or night vision goggles, higher altitudes should be utilized at which terrain or man-made obstructions will not be encountered. If the lowest setting of the IHADSS is still too bright for use, I would recommend removing the IHADSS monocle entirely.

Threads merged. Please refer to the post marked as the Solution above for more information.

@AndrewDCS2005, if you go into your track replay that you provided above and turn the MIDS LVT knob to OFF before performing the same steps, you will see that it takes several moments after initial detection of the aircraft for the FCR to establish radar tracks, which can then be upgraded to radar-derived system tracks using TMS Right, or individually using TMS Forward. The exact same time to bug a TOI in TWS happens regardless of whether TNDL is enabled or not. The only difference is the symbology shown on the MFD. As I stated above, when an aircraft detected by an FCR is correlated with an existing TNDL track, it inherits the datalink information from the offboard datalink track within the system track file to change the symbology, but the datalink information does not make it capable of being engaged if it has not established sufficient radar track information. As I described in my first post yesterday, the symbol characteristics of when this TNDL correlation occurs does not indicate that the track has sufficient radar track data to bug the aircraft as the target of interest for engagement. If the F-16 could utilize offboard datalink information to engage a target, the FCR would not be needed in the first place. So again, there is no demonstrated difference in how long it takes the FCR to establish a radar track in TWS with or without TNDL datalink correlation, the only difference is how the symbology is presented.

@AndrewDCS2005, I took control of your track and indeed the targets cannot be bugged when they are initially illuminated by the ownship FCR. However, when I narrowed the scan volume in azimuth and bars, I was able to bug the targets sooner. Further, if I deliberately slewed the FCR scan volume away from the incoming aircraft until the radar tracks were dropped, and then slewed it back, as distance to the aircraft was reduced, I was able to bug the targets more rapidly after initial detection on each attempt. This corresponds with the implemented radar limitations of distance, target size, and number of actual detections against a given aircraft (probability of detection). Let me emphasize one of my final statements from my previous post: "If the pilot wished to bug the far right target for an engagement, it must be one of the 10 system tracks that have been established from a radar track. Once the cursor is slewed to that datalink track to steer the FCR scan volume to re-detect the target, it will still take a few moments before the target can be bugged as TOI, so that the FCR can establish that track as one of the 10 system tracks based on reliable radar track information." The point being, is that the system track file may contain both radar tracks as well as offboard datalink tracks. However, only system tracks with sufficient radar track data can be bugged as a TOI for engagement. When an FCR detects an aircraft that is correlated with a datalink track within the system track file, it may not yet have sufficient radar track information for an engagement. This isn't related to TWS mechanization in itself but rather how the changes in the DCS F-16's radar physics have altered how the radar detects and processes targets under various conditions. There have been changes this past year in the DCS F-16 and DCS F/A-18 radar simulations to improve their functionality with regards to radar aspect, probability of detection, false target rate, etc. You were using MiG-27's in this example. If using a larger target, such as an Il-76, the radar tracks in my tests were achieved faster, even at a greater range, allowing a relatively rapid TOI designation following initial detection.

I've tested using the HTS and TGP to target a radar that is shutdown using all three of the following methods after an AGM-88 is fired upon it: Evasion of ARM advanced waypoint action. Unit Emission Off triggered action. Group AI Off triggered action. In all three of these methods, I was still able to use the HTS and TGP as expected, such as designating/un-designating the radar on the HAD MFD format and slewing the TGP after the HTS put the TGP line-of-sight in the vicinity of the radar's location. This included combinations of the following actions: Designating the radar on HAD prior to the radar emissions ceasing. Designating the radar on HAD after the radar emissions ceasing. Designating the radar on HAD after radar began emitting again. With any remaining onboard AGM-88's powered. With any remaining onboard AGM-88's powered off. Switching to a different SMS profile entirely, such as Mk82 in CCRP. In all of these tests, I never had the HTS nor TGP fail to perform as expected. I have seen instances on multiplayer servers in which custom scripts were being used to simulate such behavior with air defense radars. In these instances, my first clue that something was amiss was the fact that as the radar emissions were switched off, the corresponding symbol on the HAD MFD format was also disappearing immediately. The expected behavior of the HTS pod is that when a radar emission ceases, the corresponding symbol on the HAD MFD format will remain static for 4 minutes in memory (2 minutes after which it will turn green), which still allows the radar to be designated and/or attacked. The fact that the symbol was being removed immediately is a sign that there was game logic being broken somehow, and afterward I too was having trouble designating, or un-designating, symbols on the HAD MFD format. But when tested in a mission without custom scripts inserted, I was unable to replicate the behavior.

Hello @MrReynolds, this bug has already been reported internally, but thank you for the report.

A lot to unpack in this thread, but I'll do my best to explain it in the clearest but briefest of terms. First, when using TWS it takes several moments to build a radar track (large, solid square) from a raw radar return, or "search target" (small solid square). The longer the scan time, the longer it takes to build a radar track. For example, if using a 1-bar scan with a narrow azimuth, the radar track can be built faster since the target aircraft is scanned multiple times in a smaller time frame, allowing the radar to establish the track. This is especially important when building a track against maneuvering targets. In the first image below, several radar tracks have been established. In the second image below, other aircraft have been detected by the radar enough times to build additional radar tracks, which is an automatic process. Once a radar track is established, it can then be upgraded to a system track within the system track file. Once a system track is established, it will appear as a large, hollow square if not correlated with any offboard datalink information. If no system tracks have been established from radar tracks, TMS Right will command up to 10 radar tracks to be upgraded to system tracks within the system track file, since a maximum of 10 tracks within the system track file can be derived from radar tracks, and will bug the closest as the highest priority target, or Target Of Interest (TOI) with a circle. (The remaining solid white square on the FCR MFD below was established as a radar track after already upgrading the other 9 to system tracks.) Once any system track is bugged as TOI, this will also command the radar to a +/-25 degree azimuth scan centered on the TOI, which may cause some existing tracks to be dropped if they remain outside the FCR scan volume for several moments. In the image below, TMS Right was used to step the TOI through several tracks. Several moments of the state shown in the image below will cause the three tracks on the left to be dropped. When TNDL is incorporated, datalink tracks are contributed from offboard sources and are contained within the F-16's system track file like the radar tracks that have been upgraded to system tracks. However, if a target aircraft is being tracked by the F-16's FCR and is also present within the system track file from an offboard datalink track, the two tracks will be correlated and the track information from the offboard datalink source will be added to the system track sourced from the onboard FCR. Under these conditions, the radar track is essentially upgraded to a system track automatically by the fact it is being correlated with information from an existing system track. Pressing TMS Right will immediately bug the closest target as the TOI since the radar tracks are already upgraded to system tracks, and since they have inherited the datalink information from the contributing offboard source within the system track file, the target symbol reflects this added information. In the image below, since a target has been bugged, the FCR scan volume is reduced to a +/-25 degree azimuth scan as before, dropping one of the radar tracks, which reverts to a surveillance air track being received from a nearby E-3 AWACS aircraft. If the pilot wished to bug the far right target for an engagement, it must be one of the 10 system tracks that have been established from a radar track. Once the cursor is slewed to that datalink track to steer the FCR scan volume to re-detect the target, it will still take a few moments before the target can be bugged as TOI, so that the FCR can establish that track as one of the 10 system tracks based on reliable radar track information. However, as can be seen, other tracks will be dropped to only offboard tracks as they lose their radar track information. __________________________________________________ Now, having said all of that, before the posts start appearing regarding radar tracks that have been correlated with offboard surveillance tracks and leading to differences between the colors and shapes when they become correlated/uncorrelated, it is a known issue that will hopefully be resolved in the near future.

@Spartan111sqn, there seems to be some confusion as to how the JFS works. The Jet Fuel Starter is not discharged and recharged, the JFS/brake accumulators are discharged to start the JFS itself. And the JFS, being mechanically linked to the engine, subsequently spools the engine so it can be started. Please review my second comment in the thread. If you have a flameout in flight, that means that the F-16's engine was successfully started to get the aircraft airborne in the first place; and if the engine was successfully started, then the JFS/brake accumulators will have been recharged. If the JFS/brake accumulators have been recharged, the JFS can be used for an in-flight restart. The premise of your questions is not logical. If the JFS/brake accumulators are discharged during the engine start sequence and never recharged, then the F-16 would never have any wheel brakes upon landing. Further, if the JFS/brake accumulators were, for whatever reason, not correctly recharged during the start-up sequence, the pilot would discover this when initiating taxi from parking when testing the nosewheel steering and brakes to ensure proper functionality, and abort taxi and the flight altogether.

There is no bug. Heading Hold is enabled in the AH-64D when below 40 knots ground speed, regardless of whether Attitude Hold is enabled, subject to specific engagement/disengagement criteria. Please refer to the DCS Early Access Guide in the FMC section for more specific explanation of the criteria.

Let me clarify. When I say it "was hardly, if ever, used", I am not saying that the real AH-64D pilots simply chose not to use it, I am saying that FFD wasn't even loaded into the real AH-64D map databases, and was not even available to use from within the cockpit, even if the aircrews wanted to. It was in fact not present as you are claiming. I'm sure there was at least one unit out there that probably used it at least once, whether it was training or operational testing, which is why I avoided saying "never" because there are always the occasional exception to absolute statements. However, there are much more important features that are still in development for the DCS AH-64D that were actually available for use by aircrews at large.

Multiple wishlist threads have been merged. FFD was a feature that was hardly, if ever, used in the real AH-64D. As such, this feature is not planned and efforts are focused on other aspects and features of the DCS AH-64D.

As the thread is titled, the transponder is a system that has not been implemented. The attitude is not necessary.

@SpecterDC13, the OP of the thread was inquiring about the inconsistency between the Category loading description in the DCS F-16 manual and the position of the STORES CONFIG switch in the game for a given loadout. The thread topic is what @Lord Vader was responding to with his comment. If you wish to report another behavior you believe is a bug, please start a new thread to avoid generating confusion.

@BFQ Using the 4-way trim hat will only physically move the cyclic in the pitch axis when a forward/aft input is applied. When applying left/right inputs, the cyclic will not move. The trim positions can be thought of as such: Forward/Aft: Airspeed trim/adjustment Left/Right: Bank angle trim/adjustment