Stickler

The air refuel receptacle is connected to the Essential 28V DC Bus so it needs at least one engaged Engine Master Switch to be powered by the battery if no external power is available. The receptacle further needs utility hydraulic pressure. In the game, the receptacle can be operated without an engaged Engine Master Switch, without external power and without hydraulic pressure.

As per TO 1F-4E-1, 15 October 1984, Change 10 - 1 April 1990, p. 2-13 (see below), abruptly moving the stick forward or aft should disengage the AFCS on the ground. In the game, the AFCS only disengages upon abrupt stick inputs in the air.

According to T.O. 1F-4C-1, 1 October 1970, p. 2-27 (see below), the AFCS cannot be engaged if INS is in ALIGN. In the game, the AFCS and altitude hold can be engaged if INS is in ALIGN or even OFF. Also, AFCS does not disengage if INS is active and then set to ALIGN or OFF. With the INS in ALIGN or OFF, there is no apparent degradation in AFCS performance. The note in the attachment cannot be found in any other F-4 manual available to me, so it is possible this limitation does not exist in mod states other than the ones the manual applies to, but it would seem logical that the INS is required for the AFCS to function. This is supported by the checklist sequence (same for all F-4 variants I have checked) per which the reference system selector is to be set to PRIM (after the INS is in NAV) prior to checking the AFCS.

When turning the VOR/ILS frequency rotaries in the front seat clockwise, the associated number decreases. When turning them counter-clockwise, the number increases. This is the exact opposite of all other similar rotaries in the F-4E I have tested so far and in other jets generally. I have not found a specific piece of information in RL manuals concerning whether the above is correctly simulated or not, however due to the departure from usual practice I'm flagging this as a possible bug. Track attached. vor_knob.trk

With the release of the module now having been announced for May 21st, 2024, here's your chance to get in right from the start.

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.

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?