Delta134

The update today seems to have brought back a previously known bug in the flight model. During landing any roll input induces exaggerated yaw coupling. I haven't tested it yet for slow flight with gear retracted. This is a critical issue, please fix it as soon as possible, thanks. See the attached track. landing.trk

That’s correct, I was looking at AN/APG-66 documentation. Good to know it is different for the AN/APG-68. @Frederfif you have a publicly available source for this, I suggest you pass it to @BIGNEWY In the end I wouldn't mind it being implemented either way. As long as it is consistent

Do you have a source for this? The documentation I have states TWS uses RWS scan patterns when no targets are designated (1, 2, 3, 4 bar 10°, 30°, 60°)

Hey @Lord Vader The purpose of narrowing the scan limits for a bugged or cursor target is such that the contact is scanned more frequently. In the current implementation these scan limits are kept even if you cancel all targets. Like you said you agree; what is the sense in that? The only compelling argument for the current implementation is documentation explicitly stating it is correct. Even official documentation might not explicitly mention what happens to the scan limits if a target is debugged (it may be regarded as obvious and thus not explicitly mentioned). If you claim you have this explicit documentation, fine. Otherwise, I would request you please refer to common sense.

Hello, a while ago I made the following bug report: I am happy to see this was (partly) fixed on the last major update. Thank you. The following part was fixed: Slewing away from Cursor Target does not restore scan limits. (now slewing away from a Cursor Target, thus making it a System Target, correctly restores previously set scan limits). However, the following issue remains: Once a contact has been upgraded to Bugged Target, upon downgrading the contact to a System Target again, the scan limits are not restored. See the attached track for a demonstration. tws_scan_limits_bug_2.trk

The functioning of the HTS is described on page 285-287 of the manual. Delay between the RWR and HTS can be explained by the Scan Cycle Time. The Scan Cycle Time can be decreased by disabling Threat Classes on the HAD Threat Page as explained on page 292 of the manual.

What's the status on this project? Can we expect the new default F-16 liveries anytime soon?

Thanks for the clarification

I think I may not have stated the issue clearly enough. In order to upgrade a System Target to a Cursor Target, one does not need to press TMS up. One simply hovers the cursor over the System Target. This correctly sets the scan limits to a 3-bar ±25° pattern. However, once moving the cursor away from the Cursor Target (again, no TMS down required) the target should be returned to a System Target and the scan limits should return to the original scan limits. In the track file I demonstrated this is not the case. I agree that in case of a Bugged Target (TMS up on a System Target) the scan volume should stick to the target and the scan limits are reduced. So to clarify: the issue is not the location of the scan volume (this should be centered on the Cursor or Bugged target) but rather the azimuth limits of the scan volume not being returned to the original as soon as the Cursor or Bugged target is returned to a System Target (i.e. the ±25° is not returned to the original) The issue particularly pertains to the following sentence on page 243 in the manual: Disregarding the issue due to the manual being work in progress is too easy. Please seriously look into the issue I am describing.

False targets seem to appear with the RF Switch in Quiet and Silent thus inhibiting the FCR from scanning. To me it seems logical that while the FCR is inhibited from scanning, it is impossible for any targets to appear. Is this intended behaviour? See the attached track file for a demonstration. First I demonstrate false targets appearing while scanning, then I move on to switching the RF Switch to Quiet and Silent. false_targets_without_radar_scan.trk

The changelog for update DCS 2.9.8.1107 mentions the following bug being fixed: However, testing indicates the AG radar image is still sticking to the crosshairs when using a reduced azimuth scan limit. See attached track file. agrdr_sticking_to_cursor_cross.trk

While in TWS mode and hovering the radar cursor over a System Target, it is correctly made a Cursor Target and the scan limits are correctly set to a 3-bar ±25° pattern centered on the target. However, when slewing away from the Cursor Target, scan limits are not restored. The same is true for a Bugged Target. This issue complicated workflow and pilot load in addition to being in conflict with the functionality described on page 243 of the DCS F-16C Early Access Guide by Eagle Dynamics. See the attached track file. tws_scan_limits_bug.trk

What I am saying is that current implementation is correct according to ED's manual and does not prevent you from properly utilizing TWS mode once you filter out datalink symbology. Indeed, this means you might want to toggle them on or off every couple of seconds. That's why there's a control for it on the HOTAS in order to easily use it. So that it really isn't a big deal. Why do you think this is a workaround? Where in the manual does it say you can deduce your TWS target state from datalink symbology? I can tell you it doesn't. I think you are frustrated by the 'inconvenience' of having to toggle symbology. You think it should be easier. I don't think it has to be easier and current implementation is correct according to ED's manual. If you have any documentation confirming this isn't correct, I suggest you send this to ED privately. Your question regarding the hollow yellow brick doesn't really make sense. Are you trying to force that to come up? If so, why? A scenario in which this symbol would show up on your FCR is when an AWACS or other fighter provides you with the track and the DCS ROE decides it is a 'suspect' and the contact is not correlated with onboard sensors. As far as I understand, DCS currently doesn't do this. It only gives you hostile or friendly tracks. However, this ROE implementation is a separate issue from the one pertaining to radar symbology. One of the ED community managers has already confirmed it needs work but is correct as is for now.

To give you a quick answer to your question: In order to visually confirm through symbology if you have upgraded a target from 'Track Target' to 'System Target' you need to filter out any datalink symbology (page 267 of the manual). If you don't, any datalink symbology will override your radar symbology. This is regardless of any color. Color only denotes target classification (hostile, unknown, suspect, friendly). It has no impact on the state of your TWS target. TWS small brick: search target TWS large filled in brick: track target TWS large hollow brick: system target TWS large hollow brick with circle: bugged target As I stated before, you need to mentally separate radar symbology and datalink symbology. They are different things. So to reiterate: To properly display your TWS radar symbology, filter out any datalink symbology!

For some of the mission, 154.000 MHz is assigned as the tactical frequency on COMM 2 or AUX. This is frequency actually lies outside the range of frequencies the F-16's ARC-222 VHF radio can use. It can transmit and receive between 116.000 - 151.975 and 30.000 and 87.975 as can be read on page 194 of the F-16's manual by ED. This mean you cannot manually enter the frequency to tune into the tactical frequency. The workaround is to enter the preset, which somehow allows you to access 154.000. However, this shouldn't be allowed and is probably a bug which may be resolved by ED in the future. That would break some of the missions in the Gamblers campaign.

Yeah there's a separate thread for the ROE classification. ED affirmed that is needs some work but for it is modeled as intended. The issue in this thread is about distinguishing between the various states of targets in TWS as far as I understand. What the TWS sub-mode symbology means can be read on page 241 of the ED F-16 manual. What the datalink symbology means can be read on page 264 of the ED F-16 manual (which section also goes into the radar filtering)

This symbology is correct according to the manual. To me it also seems logical the way it is implemented. Datalink targets will always have a large box for an unknown or suspect contact (regardless of the TWS track). It becomes filled in once the contact is correlated with onboard sensors. Indeed it is correct that to properly display the TWS track or system target is to filter out the datalink symbology. That's why the HOTAS command is there, so you can quickly and easily request your required/preferred symbology. So you need to view the FCR symbology and datalink symbology as separate from each other. It becomes clear if you read it the way it is described in the manual.

I experienced the same you did. The warping must surely be an ED issue outside of BD's control. Indeed it is hard to stay in formation with AI performing erratic maneuvers. I just take some space and try not to be bothered to much when I am out of position from time to time. The issue with 3 and 4 leaving towards the west, I would assume to be a mission bug though. I did two more circles on my anchor before deciding to land. The trigger detecting final approach on runway 10 picked up from there. It was quite confusing though. Nonetheless, I also congratulate BD and his team with the launch of this longly awaited release. I played the FIWOS campaign by Ground Pounder and was very impressed. Now after having finished the first two mission of the Gamblers campaign I can say I am excited to finish the rest of the missions. The briefings are very enjoyable to read with the humor included without it getting to cheesy. Immersion is great (I would say better than the FIWOS campaign which was already very good). I am also happy to see AAR be more prominent. After a full playthrough I think I will write a review.

Thanks, hopefully at some point the issue will be addressed by ED. From what I can see from the previous reports you linked, ED never affirmed the issue. Hopefully in my post I have demonstrated the problem a bit more clearly and shown that: Current implementation doesn't match how it is described in the manual. Current implementation is inconsistent within the game across enemy and friendly contacts. Current implementation prevents the pilot from effectively operating the FCR and contradicts how one would logically expect the system to function. I would also like to add that during missions I have observed more inconsistencies in the way datalink tracks are displayed: PPLI track displayed on own position on HSD, team members not showing up as such on HSD (instead they're displayed as donor) despite proper setup in the mission editor/DLINK pages, friendly contacts not being displayed at all or at irregular intervals. I just have not been able to reproduce these issues on a short track yet. Perhaps at a later time. But it goes to show that some work is required.

In the manual the datalink is still referred to as L16, however I'll refer to it as TNDL as this is how it is currently represented in the game. Problem: Whenever TNDL tracks are displayed on the FCR, they replace the FCR's own target symbols. The TNDL tracks become solid to indicate correlation with onboard sensors. Meaning the track is received both as TNDL track as well as picked up by the onboard FCR. This becomes problematic when I want to confirm the 'state' of the target while in TWS mode; whether it is a Search Target, Track Target or System Target. To solve this problem, I press IFF outboard short on the TQS in order to remove all datalink tracks from the FCR. While in TWS mode I would then expect the FCR to display the 'state' of the target as there are no datalink tracks overlapping the target, i.e. I would expect targets to be displayed according to the ways described in page 235 of the manual on air-to-air radar modes. This seems to be true for contacts of the enemy faction. However, contacts of the friendly faction are removed from the FCR entirely in any CRM mode (RWS, TWS, VSR). This leaves me unable to view the target 'state' of friendly contacts in TWS mode. The same goes for filtering options using IFF inboard short. Strangely enough I am still able to bug these friendly contacts while hovering the cursor over their supposed position and pressing TMS up. Even though no contact is displayed. This behavior is inconsistent with the manual and inconsistent with in-game functionality with regards the contacts of the enemy faction. Observed behavior: Radar Display Filtering causes friendly targets to be removed from the FCR page entirely. Expected behavior: Radar Display Filtering allows the pilot to remove datalink tracks, leaving the raw FCR targets to be displayed. To demonstrate I have attached a track where the player F16 has 6 planes on the nose. Three at 20 nm and three at 40 nm. Each group of three contains an enemy contact, a TNDL team member and a friendly contact. In some cases the FCR filtering would behave correctly whenever the player F16 had no team members set on the TNDL page in the mission editor. However, I was not able to reproduce this after testing but thought I would mention it anyway. tndl_filtering_behavior.trk

As you already confirmed yourself visually, you didn't engage afterburner. You were in military power and didn't go past the afterburner detent. As can be seen from your throttle position, fuel flow and nozzle position indicator. Still, even with afterburner, thrust will decrease with altitude and the plane won't climb indefinitely.

The steering line disappeared because you don't have any of the bombs left for the weapon you have selected on your SMS page (since you dropped both of your GBU-12s). On the SMS page, press OSB 6 to switch to your GBU-10s. Make sure CCRP is selected using OSB 2. Now you should have the steering line again and you can drop your two remaining bombs.

Some terrible product support being displayed by OnReTech here. This completely destroys customer trust. OnReTech should be aware this is very damaging to them and their product. They'll have to show some serious change and improvement. I hope Eagle Dynamics also plays a role in making them aware of this. Ultimately it is their brand.

It appears it is possible to overwhelm the RWR by placing multiple SAM sites (ground radars). This causes the RWR to not display air threats. In the attached track file there are numerous enemy and friendly SAMs, AWACS and fighters. There's three enemy MIG29 flights approaching from various directions starting around 50 nm out. No RWR indication of the 29s, except when enabling search mode with the search button on the threat warning auxiliary control panel. Upon disabling search mode, the 29 indications disappear again. The RWR will not display the 29 indication even when they are actively locking and guiding semi active radar missiles (as is apparent from the track). When enabling search mode, the 29 indications and missile warnings appear. Please watch the track until the player aircraft is destroyed. The RWR behavior seems very strange. I find it hard to believe this is functioning as intended. The case could perhaps be made for ground radars overwhelming air threats at long range. But not to the point where there are no RWR indications when enemy air threats are actively locking and guiding radar missiles. Is this functioning as intended? Can anyone reproduce the issue? rwr_threat_display_not_functioning.trk Tacview-20231113-230209-DCS-rwr_threat_display_not_functioning.trk.zip.acmi