Tholozor

Currently, the AACQ legend will overlap with the bullseye-to-cursor readout in the top-left corner of the ATTK display. I found this quite odd, even after seeing documentation showing both in the same area without mentioning any type of swapping/priority logic, so I did a little digging for real-world examples. I found helmet camera footage from the U.S. Hornet East Demo Team (video source) which just so happened to have the ATTK format pulled up. It also has the bullseye-cursor data shifted slightly to the right compared to the position in DCS. Full disclaimer, I am aware the video was taken in 2010, so a later OFP may have changed the position of this data block after the version the DCS version represents. This example was the oldest I could find that had the ATTK format present on a Legacy Bug on video, if anyone has older examples, please feel free to share. Since the DDIs don't display the full raster on a digital recorder, I took various frames and warped them to the same orientation and overlaid them to present a more complete picture of the ATTK format. The out-of-display bullseye symbol can be seen just below the spacing between the bar scan and current bar legends.

Keep in mind that the Caucasus map is roughly representative of the region circa 2008.

Are you able to post a track? Everything works fine on my end.

Check your in-game audio options for what device is set to 'Headphones.' Any audio that would play through the pilot's headset (i.e. radios, cockpit voice alerts, etc.) are played through whatever is set to this device.

These lights only illuminate under specific conditions: RCDR ON should illuminate when the recording system is running (not implemented). DISP should illuminate when the countermeasures are in semi-automatic mode, and ready to dispense with pilot consent. SAM should illuminate when the aircraft is locked by a surface-to-air missile system. AI should illuminate when the aircraft is locked by another aircraft's radar. AAA should illuminate when the aircraft is locked by anti-aircraft artillery (Vulcan, Shilka, etc). CW should illuminate when the aircraft is painted by a radar in continuous wave (usually a type of missile guidance). You can also verify the lights will illuminate with the Lights Test switch.

This is actually a recent correction of an old bug. TACAN channels will now show distance to DME stations on their paired frequency. It just so happens that channel 107X is paired with the VOR frequency 116.00MHz, which just so happens to also be the VOR/DME frequency at Damascus.

The coordinates on the aerodrome data don't correspond to the centerpoint of the runway, they correspond to the approximate foot of the runway (in your example, the foot of runway 25).

The first time GBU-24 is equipped and utilized by the aircraft, it will behave normally (weapon release initiates IN ZONE when the ball intersects the VV, and LTD/R is automatic). After rearming GBU-24s (track uses unlimited ammo to demonstrate, but the issue also manifests when rearming via ground crew), the following will happen: - IN ZONE cue is ignored, and will drop immediately when weapon release is pressed. - LTD/R will not automatically fire. - LAR zone is not displayed on the HSI. GBU-24_second_release.trk

Removed.

If the pilot depresses the RAID/FOV switch prior to entering TWS (and while an L&S exists prior to TWS), the radar will enter SCAN RAID immediately upon entering TWS. SCAN RAID should only able to be engaged if the radar is already operating in TWS with an L&S present. SCAN_RAID_primed.trk

One of the latest updates made TACAN able to receive distance information from paired-frequency stations. Depending on what navigation aid stations are present on the map, some TACAN channels may conflict.

FLIR is an infrared sensor system, which would be immensely helpful looking for people at night.

A thread already exists for this:

Mainly asking as this is new behavior, and wasn't present in previous builds. Looking back though, looks like this was a previously reported issue, so I guess no bug if this was an undocumented change:

When entering TACAN, the HSI is providing DME information to VOR/DME stations of the paired frequency. Examples in tracks attached: - TACAN 73X on Syria will show range info to the VOR/DME station at Beirut (112.6 MHz). - TACAN 83X on Persian Gulf will show range info to the VOR/DME station at Ras al Khaimah (113.6 MHz). TACAN_VORDME_73X_Syria.trk TACAN_VORDME_83X_PG.trk

According to ATP-56(A) NATO UNCLASSIFIED, dated November 2000, the KC-130's fuel transfer rate (equipped with Sargent Fletcher 48-000 pods) should be: - 4080 pounds per minute, with the removeable fuselage fuel tank and two AAR pumps installed. - 2040 pounds per minute, with the removeable fuselage fuel tank and only one AAR pump installed. - 1020 pounds per minute, without the removeable fuselage fuel tank installed. For the S-3B, the fuel transfer rate should be 1370 pounds per minute. For the KC-135: - Boom: over 6000 pounds per minute - MPRS pod: 2680 pounds per minute

I believe the common term for it is 'Bump Acquisition.' It's a method by which (when commanded by the pilot) the radar can reject the current STT trackfile for a period of time in order to acquire another trackfile for STT. The first trackfile will have an exclusion zone around it, preventing it from being locked again for a number of seconds.

In addition, SET is only needed for setting default weapon radar parameters in RWS only. TWS has its own controlling logic behind bar scan and azimuth settings that cannot be altered.

Yea, noticed the Pd, well done on that, that's mainly why I tried to keep testing limited to large RCS contacts within 40nmi to keep Pd as high as possible. Just ran an additional test, and from what I can tell the raw hits are still being display on every sweep, but as you mentioned before, their positionally spaced according to their range bin (my original test was basically doomed from the start, ha!). Re-tested with multiple, large RCS contacts at varying ranges and bearings, which resulted in multiple raw hits positioned at the same range bin position, but at slightly differing angles due to the azimuth of detection, cool stuff! Leaving this here for anyone who might've thought along the same lines I did originally. You can see the faded bricks from prior detections slightly offset from fresh hits.

Thanks for the explanation @Harker, any thoughts on raw hits not being displayed on certain sweeps? I noticed that even on a 1B scan (with elevation adjusted so the contact would firmly fit into the scan volume), a raw hit isn't displayed until after a number of sweeps. Is this also part of the HPRF range bins?

This is correct per IRL payload restrictions. If a weapon is loaded on the centerline (station 6), stations 5 and 7 are not to be used. The opposite is also true, where if anything is loaded on stations 5 or 7, station 6 is not to be used.

Yep, reported thread over here:

Raw hits on contacts detected in HI PRF are not co-located with their respective trackfile, and are not drawn on every detection. PRF_Detection_Brick_Position.trk

I didn't see this in any of the changelogs, but it may be that TWS AUTO finally has centroid tracking, where it automatically biases the scan volume to maintain as many trackfiles as possible (provided the L&S is still within it, and regardless of DT2).