Stickler

When selecting the different M61A1 ammunition types in the mission editor, the following ammunition is shot as per Tacview: 20 mm HEI: M56A3_HE_RED 20 mm API: M53_AP_RED 20 mm AP&HE: M56A3_HE_RED 20 mm TP: M55A2_TP_RED Therefore, there doesn't seem to be a difference between the 20 mm HEI and 20 mm AP&HE selections. Furthermore, based on reviewing .trk files with the different ammunition types shot against a specific target, the visual effects of bullet impacts seem to be identical. Especially for TP ammunition I would not have expected too see small impact explosions as with the other bullets. Are differences in bullet effects/ricochet/range actually modelled? Are the apparently identical HEI / AP&HE ammunition types an error in the module or in Tacview?

OK, so I'm 99% sure now that Tacview works correctly. The issue was the weird and prehistoric way the F-14 and Mirage F1 HUDs function (see the post I linked above). Sorry for the additional work.

OK, I think I've figured it out thanks to the first part of your comment. I was departing from the assumption that you could derive target placement and pitch from the HUD ladder simultaneously. Due to how the HUD works, this is incorrect. You can only ever get one or the other with a specific HUD trim. This means that, for example, if you calculate a 30° dive attack with a 33° initial target placement (ITP), provided you fly the geometry perfectly with a default 5° down HUD trim, your apparent ITP at the track point will instead be 28°. Confusingly, you'll now need to set 30° instead of 25° pitch on the HUD to reach bomb range at the planned release altitude. I have not read anything about the rungs not being linear nor can I confirm this by testing. Using the ELEV LEAD knob and MAN mode as a reference, there are 86 to 88 mils between the rungs, mostly 86-87. While this means that the HUD calibration is slightly off (89 mils would be most accurate), IMHO this is close enough for government work. So summing up, the problem is solved on my end. Still a weird HUD for A/G employment, but then again it wasn't designed for that purpose.

While I cannot rule out that the real HUD was in fact not graduated as per NATOPS, I would like to offer the observation that when superimposing the CCIP and the aircraft symbol using the ELEV LEAD knob in MAN mode, approximately -86 mils are obtained. With the maximum ELEV LEAD setting of -263, the difference is 177 mils. Converting this to degrees: 9.95625°, which very closely matches the NATOPS value of (-)10°. Why would it be possible to set the manual sight to approximately -10° if the pipper (center dot) already disappears from view at a setting of 223 mils (= 7.7° from the aircraft symbol)? Bad engineering by Grumman?

It's getting a little bit clearer now, but I have not been able to fully grasp the problem. Consider the following screenshots showing the same situation in-game and Tacview: Both DCS and Tacview correctly show the aircraft's pitch to be -40° (this matches the "raw" pitch shown in the F2 view, screenshot not included). Looking at the math of the situation: F-14 altitude = 1944 ft MSL TGT altitude = 11 ft MSL (not shown) ATL = 1933 ft Slant range F-14 to TGT = 2628 ft Ground range therefore (Pythagoras) = 1780 ft The target position angle (TPA) with reference to the physical horizon is then calculated as: TPA = arctan(1933/1780) = (-) 47.35° This is pretty much exactly the TGT position as shown in Tacview. The F-14's HUD has the target beneath the (approximately) 43° line. Since the HUD shows the pitch correctly as per the F2 view, I'm going to assume the target really is at 43° with reference to the pilot's eye position. If we calculate backwards to find the pilot's eye position altitude (ATL), we can say: ATL = tan(43°) x Ground range = 0.93 x 1780 ft = 1660 ft The pilot's eye position is therefore 273 ft (1933 ft - 1660 ft) below the aircraft considered as a point in space. With the aircraft having a vertical extension of 16 ft total, how is that possible? What am I doing/thinking/calculating wrong?

Thanks for the reply, but I don’t understand what you‘re saying and how exactly this explains what I’m seeing. Could you elaborate?

Additional info on the target placement issue: Contrary to what I expressed above, the problem does seem to be limited to certain aircraft in that it does not occur with the F-16. See below. I still don’t understand what‘s going on.

I initially thought this was an aircraft-agnostic Tacview problem (see post below) but now I'm not so sure anymore. Compare the following screenshots and .acmis taken from an attack by an F-14 and an F-16 against the same target. F-14.acmi F-16.acmi In both the F-14 and F-16, the target is on the -25° degree line on the in-game HUD and the pitch of the aircraft is approximately -25° as indicated on the HUD, the F2 view and in Tacview. However, in the F-14.acmi, the target is located on the -30° degree line, while in the F-16.acmi it is located on the -25° line. The same mismatch between the in-game HUD and the Tacview HUD view also occurs in the Mirage F1. I have not tested other aircraft. I am at a total loss how this is even possible. If it was a wrong HUD trim, surely the F-14's pitch as indicated by the aircraft symbol would not be consistent between HUD, F2 view and Tacview. Any ideas?

Sure. Attaching .acmi and corresponding screenshot of my Caucasus test. Tacview-20230404-200825-DCS-maptest.zip.acmi Time is +01:50 into the recording (active pause). Note the target under the -15° line on the screenshot and under the -20° line in the Tacview HUD view.

There seems to be a bug with unit positioning in .acmis in 1.9.0 and DCS Open Beta 2.8.3.38090 MT (not tested in other builds or versions). See the attached screenshots which were taken at the exact same moment in time for the F-14 and the Mirage F1, respectively, using active pause. Comparing the HUD screenshot from in-game and Tacview, it becomes apparent that while for both aircraft the pitch angle is captured accurately, the target is displaced by approximately 5° below its position in the Tacview HUD view compared to the aircraft's HUD. The target is located in PG, N24°35.957 E054°42.910. Since the same problem occurs in two aircraft types I suppose the modules by themselves are not causing the issue. Also tested this in Caucasus against a different target (APC, not tank as in PG) and I get the same result (5° displacement).

According to the -A and -B NATOPS, the A/G HUD has a vertical FOV of 20° centered on the aircraft symbol (10° up, 10° down). The pitch ladder is graduated every 5° up to 30° pitch up and pitch down, then every 10° thereafter. null In the game, the A/G HUD has an asymmetric FOV of 10° pitch up (note the barely visible 10° mark in the picture immediately below) and approximately 8° pitch down (see the second picture below) with reference to the aircraft symbol, and the pitch ladder is uniformly graduated every 5° (see the third picture down).

1. According to NWP 3-22.5-F-14A/B/D, VOL. III, IC10, p. E-4/E-5, the following conditions need to be met in the F-14A/B before any of stations 3, 4, 5, or 6 can receive an air-to-ground release pulse: A. Landing Gear Handle UP B. ACMP: Master Arm: ON C. Stick: Wpn Select: OFF (GUN if mixed) D. PDCP: MODE: A/G E. ACP: WPN TYPE: Store type F. ACP: DLVY OPTNS: QTY: 1 or more G. ACP: STA SEL: 1 or more loaded stations: SEL H. ACP: FUZE: MECH and/or ELEC not SAFE In the game, I have noticed the following deviations from this logic: Bombs can be released with the gear handle down Bombs will release even though both MECH and ELEC fuses are set to SAFE Bombs will release without any store type selected (wheel set to OFF) Bombs cannot be released if WPN select is set to GUN with "Mixed" selected in the back seat Bombs can be released if QTY set to 00 2. According to both NWP 3-22.5-F-14A/B/D and the flight manual, ITERs and ITER-loaded stores cannot be jettisoned. In the game, depending on the WPNS/MER TER selector, both ITERs and ITER-loaded stores can be jettisoned. 3. In the game, fuel tanks can only be jettisoned with WPNS selected, not with MER TER. I have found no indication in the above manuals that an MXU-611 cannot be jettisoned, however I have not found any information that it CAN be, either. Therefore, not sure if this is a bug. 4. The "jettison" sound sometimes occurs even if no stores are actually jettisoned. To reproduce, load stations 3 to 6, select MER/TER, perform a selective jettison of all stores, then repeat. I assume the "clunk" sound is meant to simulate the haptic feedback the pilot receives when a heavy store leaves the jet (as opposed to the jettison cartridges firing which could not be heard from within the cockpit), so when no store actually leaves the jet the "clunk" should not be heard. Even if the sound is intended to simulate the sound of the jettison cartridges they could certainly not be heard twice since they are one-shot.

Thanks @Noctrach, looks like I'm not crazy after all. I think the loss of lock/track due to roll and the loss of track due to ATA and pitch might be closely interrelated but they need not necessarily be the same issue. I can hold an STT-generated TID track all day long with 90° or even 180° AoB provided my ATA remains close to 0°. So the "antenna elevation + azimuth + roll > 55°" relation is probably not really additive (at least with regard to roll); if it was, you'd certainly lose the track at 90° AoB. I incidentally found that if you set 40° ATA, then roll inverted and then push the stick forward, the track will be lost when reaching around +15° antenna elevation as well. In any case, no need to debug this further on our end since this has been reported twice now. @WarthogOsl I'd say it's dropping STT-generated TID tracks when it shouldn't. Since I do not have access to the original aircraft's AWG-9 manual I cannot prove my point but I can hardly imagine the real radar couldn't maintain an STT-generated track at 40° ATA, 15° pitch and 0° roll when the radar's limits are ±65° in azimuth and -76°/+54° in elevation, especially since the lock itself can be maintained at these parameters. In other words, why should it be able to maintain the lock but not the track?

EDIT: This post was originally about a loss of PD-STT lock. Through more testing I found the actual problem is a loss of the TID track obtained from an STT lock, not the loss of the lock itself. Text and title changed accordingly. 2.8.1.34667 Start parameters: F-14B, 25000 ft, M 0.8, human Su-30, 25000 ft, M 1.0, AI, programmed to maintain pure pursuit on F-14B and not to use chaff or ECM Split range 55 nm, head-on Steps: F-14B establishes a valid PD-STT lock. TID track file visible F-14B cranks to 40° ATA, 3-4 G F-14B maintains new heading, TID track file remains visible F-14B bunts over, 0.5 G Loss of track (X) occurs at about 15° nose low with a radar elevation of around +10.0 ° (indicated by flares in .acmi). Track file is deleted shortly thereafter. Track file data readouts (bearing, track altitude etc.) are lost. The STT lock, WEZ symbology, HUD radar cross are maintained throughout. When re-establishing pure pursuit, the TID track and the corresponding track file data readouts re-generate automatically. This has been 100% reproducible for me. Happens both with a human RIO and Jester, also in PULSE STT and/or against A-50 (this one is slower than 1.0 M of course). It it likely this has something to do with TID track generation capacity based on radar elevation/azimuth in STT, since the test can be varied as follows: When crank is 50° instead of 40°, loss of TID track occurs at around 5-10° nose low. Without crank (maintaining 180° aspect), the TID track is maintained during bunt-over until the vertical limit of the radar elevation is reached (lock breaks around 54° indicated antenna elevation). In general, the loss of TID track occurs at a smaller nose-down angle the greater the crank. The track file is maintained throughout when using TWS. Is anyone able to explain why the loss of track occurs at parameters which should be able to support it (at least I am not aware of a track production limit based on azimuth/elevation when in STT)? Not posting this as a bug since it is possible I'm overlooking something obvious or things are working as intended. loss_of_lock.acmi

This being the last post I could find related to the TGTS switch, I'm reporting that as of 2.8.1.34667, the AIM-54C (at least the Mk60 variant) IS affected by the TGTS switch just like the AIM-54A. This is based on test firing both AIM-54A-Mk60s and AIM-54C-Mk60s with different TGTS settings against a non-maneuvering F-14 manned by a human. Comparing the time stamp at which the time-to-impact counter starts blinking with the range between the missile and the target at that moment, it becomes evident that the active range of both -A and -C models is dependent on the TGTS setting (SMALL - 6 nm, NORM - 10 nm, LARGE - 13 nm) as described in the game manual. I would like a word if this is - taking reality as a reference - an improvement or a regression. Additionally, when taking note of the time at which the target human-crewed F-14 receives RWR indications of the inbound active AIM-54, these were the results I obtained: AIM-54A (SMALL): around 5 nm AIM-54A (NORM): around 7,7 nm AIM-54A (LARGE): around 7,4 nm AIM-54C (SMALL): around 8 nm AIM-54C (NORM): around 7,7 nm AIM-54 C (LARGE): around 7,4 nm These results are unexpected in three ways (if anyone can explain I'd appreciate it): 1) RWR indications are received a significant amount of time AFTER the missile goes active, especially in LARGE mode, for which I do not have an explanation except some kind of RWR processing delay or a delay between the AWG-9 sending a "go active" signal to the missile and it actually going active. 2) RWR indications are received at a slightly longer distance between missile and target when the missile was fired in NORM mode compared to LARGE mode, which IMHO should be the other way around. 3) The AIM-54C produces emissions detectable by another F-14's RWR before it goes active, but only in SMALL mode. Note this is for human players only. Due to what I understand is a DCS limitation, AI aircraft will start threat reacting against an inbound AIM-54 at exactly 10 nm regardless of the TGTs setting.

Since (I believe) 2.8, only when two humans are in the same jet, transmitting on a radio will, after approximately 1 to 3 transmissions, increment the respective SRS frequency as seen in the SRS overlay by .005 Mhz while the frequency displayed in the cockpit remains the same. This essentially makes SRS (and therefore multi-crew using SRS) unusable/impractical at the moment. Ciribob writes in his SRS Discord support channel that this is either DCS or F-14-related and that SRS cannot work around it. EDIT: Sorry, this is already discussed at but under a different title.

In 2.8.0.32235 (did not notice/check before), when entering a cold and dark jet and applying external power, the fire lights illuminate even though the MASTER TEST switch is set to OFF. The fire lights can be switched off by starting and unstarting the FIRE DET/EXT MASTER TEST. I have not found any indications in the RL manuals which would indicate this behavior is correct.

According to NAVAIR 01-F14AAA-1, 15 May 1995, Change 1 - 1 February 1997, p. 2-155 (and the appropriate pages in other versions of the RL flight manual as well as the Heatblur F-14 manual), the AoA indexer lights come on in certain AoA ranges. In 2.8.0.32235 (did not notice/test before), the AoA tape left of the HUD does not match these ranges. Indexer Should come on (units AoA) Really comes on (units AOA) Green 16.0 - 30.0 15.0 - 30.0 Green/Yellow 15.5 - 16.0 14.7 - 15.0 Yellow 14.5 - 15.5 13.8 - 14.7 Yellow/Red 14.0 - 14.5 13.1 - 13.8 Red 0.0 - 14.0 0.0 - 13.1 I believe the indexer lights work correctly but the AoA tape is wrongly calibrated since the AoA shown in the F2 view seems to be consistent with the indexer but not with the tape, taking into account the conversion formula of Angle = (Units - 3.715) / 1.089 This is supported by the fact that with the APC on, the aircraft seems to hold 14 instead of 15 units AoA. Other than making flying precise approaches difficult, this also makes AI LSO grading (both DCS default and Airboss) somewhat unpredictable since both seem to be using actual (not tape-indicated) AoA as a reference.

Sorry, this seems to have been previously reported at and Then again, it's been almost a year and the issue persists so...

In 2.8.0.32235 (I did not check/notice in previous versions), only the green chevron, not the other indexer lights including a combination of a green chevron and a yellow donut, is shown on the AoA indexer (depending on AoA) when the indexer lights intensity is set to 4 or lower. When it is set to 5 or higher, all indexer lights are shown depending on AoA.

Confirmed.

I was just about to write a bug report when I saw that somebody beat me to it. Some additional info to help track down the problem: 1) It happens regardless of whether the pilot is the host, the RIO is a client, the other way round or whether both crew members are clients. 2) If the pilot respawn happens quickly after sending a radio call, in the new jet (at least when starting hot) one can actually hear the reply to the call made in the old jet.

Based on testing against AI targets in 2.7.17.29493, the PH ACT behaviour has deteriorated since I made the original post since as of now the missile seems acquire the target (to include producing RWR indications) at exactly 10 nm regardless of the position of the TGTS and PH ACT switches. Previously only the LARGE setting would have no effect due to the 10 nm limitation, but SMALL would cause AI threat reactions to start only at 6 nm.

I can confirm that Iceman seems to be completely broken since he neither flies the headings nor the altitude I'm commanding him to fly.

If this is the way ED has modelled it then we obviously have to live with it. However, strictly talking real-life, shouldn't the RWR of any aircraft located within an active missile's radar cone or even side lobes be able to receive and indicate the missile's radar emissions from much farther out than 10 nm, even if the missile itself cannot acquire/lock on to its target due to insufficient RCS?