Stickler

The introductory video at the 0:34 mark says that Heatblur's "vanilla" F-4E is the 45-MC. According to the game manual, the aircraft simulated has a maximum internal fuel of 12896 lbs: Tanks - Heatblur F-4E Phantom II According to TO 1F-4E-1, 1 Feb 1979, p. 1-12 (attached), the maximum usable internal fuel of Block 41+ aircraft is 12058 lbs; the 12896 lbs is correct for Blocks up to 40. Also, the manual mentions 315-gal wing tanks here: Engines & Fuel Systems - Heatblur F-4E Phantom II. I have no record of 315-gal wing tanks being used on the F-4E and I suppose 370-gal is meant here as on the other page of the manual linked above.

526th vTFS is now open for applications.

I've been preparing documentation/doctrine for an F-4E squadron within EU Milsim Battalion – The Art of Warfare (tawdcs.org) since November. Check out the recruitment thread: Key facts: Milsim European Time Zone Squadron based on 526th TFS, Ramstein AB, Germany Based on/using available real-world documentation/procedures as far as possible/practicable

Observe the following screenshots: Note how in the first situation, RWY 31L is indicated whereas the player is located in front of RWY 31R, in the second and third situations, RWY 31L-13R is indicated whereas the player is located in front of RWY 31R-13L.

The screenshot below shows me on a perfect 3° glide path to Tbilisi RWY 13R using the Mirage F1's autopilot. Note how the PAPI left of the runway indicates 4 red. To get 2 red, 2 white at Tbilisi RWY 13R in DCS, one needs to fly a glide path of approximately 5°. According to the RL Georgia AIP, both the PAPI and the ILS glide slope are calibrated to an angle of 3.5°. Haven't checked RWY 31L.

I'm aware that the Mk 20 Rockeye is currently incorrectly simulated as clearly demonstrated by any 34-1-1 of your preference featuring the Mk 20 and by Karon's extensive testing (The Mk-20 Rockeye Cluster Bomb: Observations – FlyAndWire). However, until today I assumed that the incorrect simulation was at least consistent, but alas this assumption seems to be unwarranted. As shown in the attached .acmi featuring two Mk 20 lofts with very similar release parameters and trajectory, the first canister opens while the second does not. No switch settings were changed between the releases. Can anyone explain the logic? Is this problem specific to the F-14 or does it affect DCS in general? rockeye.acmi

Noticed the following discrepancy in 1.9.1 (not sure if it existed before) which is best explained watching the attached .acmi: When the aircraft is in a pull-up, the pitch as indicated by the HUD view aircraft symbol and the "Pitch" value in the Telemetry window seem to match exactly, which is as expected. Conversely, the γ value seems to lag the flight path marker quite a bit. For example, when the flight path marker in the attached .acmi reaches 20° nose up, the γ value is approximately 17,8°. Shouldn't these values be the same? Which is the "correct" indicator for the physical flight path of the aircraft, the γ or the position of the flight path marker? pull-up.acmi

The following observations are from 2.8.4.39313 (MT), not tested in other versions. All values are approximate. RALT bug (ft) - Warning tone/light (ft) 450 - 450 800 - 900 1000 - 1800 2000 - 3000 3000 - 3900 The warning tone/light therefore come on significantly before they should based on the RALT bug setting. Occurs in SP and MP.

Sorry to necro the thread, but in which way are GBUs affected by the EFUZE setting in the game (not asking about RL) other than the fact that setting the EFUZE to SAFE will cause them to dud?

.acmis attached as requested. HEI.zip.acmiAP&HE.zip.acmi

Reporting another issue related to the F-14, but this time it looks as if the problem is really on the Tacview side: When selecting the different F-14 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 According to my post in the F-14 bug forum, everything SHOULD be correct on the F-14 module's side. I'd appreciate if you guys could check your code, maybe there's a simple typo that causes the issue.

Copy, I'll post a bug report in the Tacview thread.

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.