Stickler

Some additional information: Observe the attached tracks recorded with a reference aircraft on a standard day, no wind, with four TLADD pull-ups using different AoA and note the pitch and climb angle (pitch minus AoA) at which the horizontal bar starts to move out of view: # Timestamp Pitch AoA Climb Angle 1 38.866 34 0.6 33.4 2 32.072 34 0.4 33.6 3 25.285 36.1 2.5 33.6 4 24.952 39.2 5.3 33.9 This indicates that the criterion for the horizontal bar starting to move is neither pitch nor climb angle hitting 38°. The most consistent value seems to be the climb angle, but this is nowhere near 38°. tladd_1.trk tladd_2.trk tladd_3.trk tladd_4.trk tladd_1.acmi tladd_2.acmi tladd_3.acmi tladd_4.acmi

I can confirm the first part of the report (didn't check the second part). Looks like this bug is back.

TO 1F-4E-34-1-1, p. 1-22, states: "b. TIMED LADD (and TIMED LEVEL) - Operate voltage is applied to the PULLUP timer; then to RELEASE timer at the termination of the PULL UP timer countdown. For the LADD mode, the PULL UP timer must be set on some value to get the ADI pullup schedule; the RELEASE timer must be set to develop a bomb release signal." TO 1F-4C-34-1-1, p. 1-122A (the F-4E part), states: "Voltage is applied only to the pullup timer in the LOFT or TIMED O/S modes. In the TIMED LEVEL and TIMED LADD mode, both timer circuits are energized, providing the pullup timer is not set on zero. In the TIMED LEVEL and TIMED LADD modes, the release timer must be set to obtain the release signal. (The release timer may be set on zero for the LOFT and O/S modes.) Completion of the pullup timer energizes relays which provide the various pullup signals and the pullup flight path program." In the game, you will obtain a TL release with the release timer set to zero; in fact, if the pull-up timer is also zero, the bomb release button acts as a pickle button (instantaneous release). Based on the above extracts, it is unclear whether a release timer > 0 was required to obtain weapons release. This is therefore not a bug report but a recommendation to check your wiring diagrams or ask for SME input.

It‘s a bug. Please reference

As per the title. Conversely, the aircraft spawns airborne, in takeoff position or during hot ground starts with the altimeter properly RESET.

As per the title. This is not a bug, but an inconvenience for multiplayer where crews use UHF to communicate with ATC and AUX for intraflight communications using the COMM CMD switching technique. In that case, it is not possible to monitor both frequencies simultaneously before INS alignment is complete unless manually switching the R/C radio ON. It should be noted that according to the RL checklists available, switching on the communication and navigation equipment is at or near the top of the BEFORE TAXIING (REAR COCKPIT) checklist, specifically before the Radar and WRCS bit checks which potentially take a significant amount of time. I can see no technical reason why RL WSOs would have delayed switching on their radio until after completing INS alignment.

Observe the attached tracks and .acmis starting from the same position and parameters. Track "DT" (Dive Toss): As per the bombing calculator, I enter 1.04 as the CB, subsequently lock a harbour tug in AIR-GND mode, and pickle at the same location while still in active pause. Approaching the target as precisely as possible at the planned parameters, the bomb releases at at plan range of 5117 ft from the target, resulting in a 3783 ft long bomb. Track "DL" (Dive Laydown): As per the bombing calculator, I enter 9216 ft as the release range, subsequently lock a harbour tug in AIR-GND mode and pickle at the same location while still in active pause. Approaching the target as precisely as possible at the planned parameters, the bomb releases at at plan range of 8980 ft from the target (thus 236 ft closer than set). Evaluation: I was able to trace back the "closer than planned" release in DL mode to the range bar not tracking the leading edge of the target return (which is where the actual target is located), but the trailing edge, in this post. This error can be easily overcome by adjusting the release range or setting a release advance. Generally, for DL, the range bar's position seems to be the only relevant factor in determining the range to target entered into the WRCS. As can be seen from the "DT" track, in DT, the range bar's position does not seem to determine, or at least is not the only factor determining, the range entered into the WRCS. I was able to exclude a faulty CB as the reason for the DT miss: When locking the tug from a dive, pickling with the tug underneath the pipper and subsequently levelling off to release at 500 KTAS and 2000 ft, the bombs hit (no track uploaded since this behaviour is as expected). Thus, in DT, having the target under the pipper at pickle and the range bar at the corresponding location ensures a hit even for the Dive Level variant. However, moving the range bar a significant distance away from the main beam clutter, even if the target was under the pipper at pickle (and thus utilizing a grazing angle within the 10° DT limit), will cause the target to be missed. What this "significant distance" is, and by how much the target is missed, is unpredictable (at least I could not identify a clear logic); the actual target hit will neither be the center of the pipper not the place marked by the range bars if the threshold of significance it exceeded. Please reference this post for additional information. Based on even further testing, everything described above is valid for releases from single-stage trigger or from lock-on. Bombing table: dtdl-dl.trk dtdl-dt.trk dl.acmi dt.acmi

For everyone else's benefit, I think I figured it out. IAS: No discrepancy between game and Tacview since IAS is directly imported. The only problem is that IAS is misnamed and should actually be EAS. TAS: For human players, "TS" in-game is equal to "TAS" in Tacview with the caveat that "TS" is an instantaneous value whereas "TAS" is averaged over the last second. Conversely, if winds are present, "TAS" in Tacview/"TS" in the game are unequal to TAS in the cockpit because Tacview's "TAS" and the in-game "TS" are the distance the aircraft has travelled between two 3-dimensional coordinates in DCS's coordinate space divided by the time required to do so, whereas "TAS" in the cockpit is derived from IAS by correcting for pressure and temperature, thereby indirectly obtaining the distance travelled through the air mass in a specific time. In headwind, the aircraft will travel less absolute distance in DCS's coordinate space in the same amount of time than without wind (resulting in a lower calculated "TAS"), whereas the wind has no influence on the distance travelled by the aircraft through the airmass surrounding it. Note that due to this logic, with the same headwind and a 90° dive angle, or with perfect crosswind, cockpit TAS and Tacview TAS/"TS" are virtually the same whereas the difference is at its maximum in straight-and-level flight with perfect head or tailwind. Interestingly, for AI, "TS" is always their actual TAS regardless of wind, but their "TAS" in Tacview will be off in the same manner as for humans. GS: GS in-game is equal to GS in Tacview with the caveat that it is an instantaneous value in-game whereas it is averaged over the last second in Tacview, even though they are obtained in a different way: In-cockpit GS is obtained from TAS by factoring in wind (drift) and dive/climb angle, while Tacview's GS is the distance travelled between two 2-dimensional (X/Y) coordinates in DCS's coordinate space per unit of time. CAS: Tacview's "CAS" will only match cockpit IAS/CAS on a standard day and with the caveat that for DCS, Tacview calculates CAS from TAS. If TAS is incorrect due to winds, so will be CAS. I have no idea why the Tacview values I posted above were so grossly off. I wasn't able to reproduce this issue.

Thanks, I believe that was in fact the error in my thought process. I set 500 in the ME. What threw me off is that the "TS" value shown in the F2 view was "500" in both scenarios, whereas the actual true airspeed (which then translates to KIAS etc.) when entering the game was 500+50 = 550 KTAS with headwind (KTAS increased "automatically" to maintain 500 KGS) and 500+0=500 KTAS without any wind. I find the whole thing terribly confusing. Witness the below screenshots of the exact same situation in the game and in Tacview (note the dive angle of approximately 45°, this is with 50 kts headwind): Summary: TS (F2 view): 499 kts TAS (F-4E): 535 kts TAS (Tacview): 443 kts GS (F-4E): 319 kts GS (Tacview): 284 kts KCAS (F-4E): 390 kts KCAS (Tacview): 315 kts IAS (F2 view, not seen but imported directly by Tacview): 363 kts IAS (Tacview): 363 kts If I were to try, I could probably explain half these discrepancies. I believe the original bug report has resolved itself though.

First of all, this is a general DCS bug. The F-16 was merely used as an example; I can also reproduce it with the F-4E. Observe the below screenshots taken from the exact same .miz upon entering the game and selecting active pause before clicking "Fly". In both cases, the aircraft is set to fly at 500 KTAS at 20000 ft MSL, standard day, no turbulence. Screenshot 1: No wind Screenshot 2: 50 kts headwind Note how the headwind increases CAS (HUD) and IAS (F2 bar), remembering that "IAS" provided in the F2 bar is actually EAS (Equivalent Airspeed). This is physically incorrect. Steady winds aloft do not affect IAS or CAS in real life. Conversely, winds an aircraft experiences while on the ground DO affect IAS/CAS. This effect is (at least qualitatively) modelled correctly in-game. Note also that the usage of active pause is not the cause for the issue; after resuming the game the error persists. It must be stated that this is not merely an aesthetic issue but affects the aerodynamic behaviour of aircraft. For example, when setting maximum tailwinds (206 kts at 1600 ft) at a reasonable TAS (depending on the aircraft, say 300), the aircraft will stall out of the sky due to insufficient IAS/CAS. I've been playing DCS for about 15 years and this is the first time I've come across this bug. Not sure if I've just never noticed it or if it was introduced recently.

I'm reasonable sure the cause for this problem is that 20000 ft scale (and the B-mode ranges) are miscalibrated. Observe the below screenshot which was created by superimposing two screenshots taken at the exact same time in active pause, once in PPI and once in B. The radar shows ships that were placed at exactly 1 through 9 nm slant range from the aircraft. Note how regardless of the radar display mode selected, the radar returns are located at the same spot on the scope. However, whereas the PPI scale perfectly matches the actual distance of the returns, the returns are noticeably short of the B scale at 4 nm and less. Since the optical sight's range bar seems to be calibrated to match the 10 nm B scale, it will show the targets at smaller slant ranges than they actually are. This issue seems to be limited to the 10 nm B scale and greater; the distances are more or less accurate in 5 nm B scale. Note that the optical sight scale is unaffected by which B scale is selected. I do not believe this causes an actual ranging error in DT/DL since at 2 nm, the displayed range error is about 1000 ft whereas the deviation in release range caused by pulse length and block size error reported here is about 200-300 ft and can - from the looks of it - be eliminated by manually adjusting the range bar.

In 2.9.15.9509, shutting down both engines in flight will cause all hydraulic indications to drop to zero psi due to the generators dropping offline. If able to maintain windmilling engine RPM above the generator cut-out speed (53-54%), as stated above, indications will remain available and show that hydraulic pressure is unaffected by the shutdown; PC-1/2 and Utility remain at about 3,000 psi. In any case, the effectiveness of the primary control surfaces is not compromised by the shutdown. Even at very low speed with engine RPM near zero, the aircraft retains full maneuverability, only affected by the handling degradation due to high AoA. This may be related to the issue that even the airflow from the starter generator is currently enough to maintain 3,000 psi without a demand on the flight controls. With full demand (constant stick wipeouts), the starter generator is sufficient to retain approximately 2,000 psi. Bottom line: The current implementation of the hydraulics system during a double-engine failure may or may not be realistic depending on whether the real F-4E's system was able to retain flyable hydraulic pressures at very low engine RPM. Another matter is why the complete shutdown of only one engine (0%) does not cause the affected PC-1/2 system's pressure to drop to zero even with high demands on the control surfaces.

Since the 2.9.15.9509 changelog contains something hydraulic related ("Complete overhaul of pneudraulics system"), I thought I'd repeat the above test. Results Scenario 1: Shutting down the right or left engine after starting hot from the ramp will not cause hydraulic pressures to decrease. Only when shutting both engines down will both hydraulics drop to zero (due to AC power being lost). If external power is connected and the generators are switched to EXT ON prior to engine shutdown, hydraulic pressures remain at 3,000 psi. Proceed as in Scenario 2, step 9. Scenario 2: Start in a cold jet. Connect external power, so AC power is always available to power the hydraulic pressure indicators. Start airflow to left engine. PC-1 and Utility stabilize at 3,000 psi with some oscillations. Start left engine. No change to hydraulics. Connect air to right engine and start airflow. PC-2 rises to approximately 3,000 psi. Shut down left engine. No apparent effect on hydraulics. Shut down right airflow. No apparent effect on hydraulics, except that fluctuations cease. Hydraulics remain at about 3,000 psi indefinitely. Switch off either the left or right generator. All hydraulics indicators will drop to zero. When switching the generator back on, the PC-1/2 indication will return to 3,000 psi, while the Utility indication will indicate less and less psi every time the generator is cycled. If the time with the generator in OFF has been sufficient, psi will remain at or near zero. Move the control surfaces and actuate the flaps. PC-1/2 and utility pressures, respectively, will decrease until the controls cannot be actuated any more. Notes The implementation has improved markedly. However, I still doubt an engine running at 21% (from airflow) can generate the nominal system pressure of 3,000 psi, or, based on further testing, retain pressure at approximately 2,000 psi with full demand on the control surfaces (constant stick wipeouts). Furthermore, I doubt that with both engines at 0% RPM, 3,000 psi can be maintained in either PC-1 or PC-2 indefinitely. Even if we assume this is possible, based on my understanding of the hydraulic system, after failure/shut-off of one engine, at the very least the actuation of the control surfaces should cause the hydraulic pressure of the failed/shut-down engine to drop towards zero. This is currently not the case. It is unclear why the Utility hydraulics indication would decrease every time AC power is removed from and reapplied to the aircraft while PC-1/2 pressures remain unaffected.

Two changes for the worse (IMO) in 2.9.15.9509, with and without the hotfix: Reception of the DME component of VOR/DME transmitters via the appropriate TACAN channel no longer seems to be possible using X channels (Y channels still don't work, either) even though the identifier tone can be received. Reception of bearing and DME of mobile TACAN stations only works if the "Bearing" option is ticked in the ME. Previously, without "Bearing" ticked, it was possible to receive only the DME.

Two sample range sheets added to original post.