Stickler

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 (one or both), hydraulic pressures remain at 3,000 psi. With both engines shut down, 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.

Standard RL procedure is to switch fighter radars off prior to commencing AAR. As shown in the attached track, after being commanded to set the radar to standby, Jester will automatically switch the radar back on after AAR is complete. The actual trigger seems to be the closing of the AAR door. This has the unwanted side effect of Jester switching the radar back on when recycling the AAR door after unintentionally having fallen off the boom. I recommend to disable this Jester behaviour. Note that manually setting the radar power switch to standby instead of giving Jester the appropriate command yields the same result. EDIT: Just realized this had already been reported here. Apologies for the double post. aar_rdr.trk

Confirmed. Once a human player opens the door, it shows as open for the remainder of the mission from the perspective of other aircraft. Conversely, the door position seems to be correctly synchronized between pilot and WSO flying a single F-4E in MP.

Another issue regarding Force Jester I just noticed yesterday is this: Regardless of whether a navigation route is entered in the .miz or through the route tool prior to an MP mission, the route is only available and displayed in the Jester wheel for the human pilot. The human WSO merely finds the entry "THINKING..." where the route should be. If, however, an aircraft is crewed only by a single crew member (to include in MP), when switching to the back seat the pilot has the entire route available. In Force Jester mode, he can then, for example, select a route point from the Jester wheel in the back seat and see Jester modifying the LAT/LON dials to match the selected waypoint.

Cheers, thanks for the clarification!

After some more tests, this issue affects not only DL, but DT as well. However, I believe I have been successfully able to trace this issue to the fact that after lock-on, the range bar tracks the trailing edge of radar returns while the actual object is at the leading edge. The APQ-120's pulse length error in SHORT PULSE is about 200 ft; Heatblur's pulse length error and block size error combined seem to be about 300 ft. The resulting error can be eliminated by using active pause, manually going half-action, moving the range bar to the leading edge of the return and then pickling. Given that without a human WSO this is impractical, single pilots can solve this issue by manually accounting for the pulse length error by using a longer release range or a release advance.

This report is about the general inability to obtain VOR information by dialling in the Y TACAN channel associated with a specific VOR frequency in-game, not about this not working at specific locations or with specific frequencies. Thanks for bumping the thread though.

I literally just downloaded my own .miz from this bug report and was successfully able to reproduce the bug after four months. While the bug does not reproduce in tracks, can you at least confirm you were able to reproduce the bug in live play, e.g. by following the linked instructions?

Observe the attached tracks and corresponding .acmis of Dive Laydown attacks with a reference aircraft, standard day, no wind, 1000/4000 ft release range settings, pickle ranges of 9000, 12000, 15000 and 18000 ft (SR, slant range) at 15° and 35° dive angle at pickle. Note that the horizontal range from target at which the bombs are released (BR = bomb range) is always between 100 and 200 ft less than the set release range: 1000 ft set release range SR (ft, pickle) SR (ft, rel.) ATL (ft) BR (ft) 18000 9673 9634 868 15000 7605 7557 850 12000 5950 5880 908 9000 4617 4524 923 4000 ft set release range SR (ft, pickle) SR (ft, rel.) ATL (ft) BR (ft) 18000 5996 4546 3909 15000 5701 4217 3837 12000 5172 3415 3884 9000 4632 2460 3925 I have flown several attempts with other parameters in addition to the ones documented here, and the results have always been similar. I was able to falsify the obvious theory of rack delay since the range error is not affected by the aircraft's ground speed at release. Also, there doesn't seem to be any significant rack delay in Laydown mode, either. My only hypotheses right now are either a wrongly calibrated release range dial/window or some kind of radar ranging error, possibly related to this post. DL_9000_15°.trk DL_12000_15°.trk DL_15000_15°.trk DL_18000_15°.trk DL_9000_35°.trk DL_12000_35°.trk DL_15000_35°.trk DL_18000_35°.trk dl_9000_15°.acmi dl_12000_15°.acmi dl_15000_15°.acmi dl_18000_15°.acmi dl_9000_35°.acmi dl_12000_35°.acmi dl_15000_35°.acmi dl_18000_35°.acmi

As seen in the attached .trks and .acmis, the optical sight slant range of a reference aircraft underreads by around 350-400 ft in 20,000 ft (HEAT/RADAR), AIR-GND mode. Specifically, comparing the slant ranges (SR) indicated on the optical sight in the "air-gnd_ranges.trk" with the corresponding .acmi, the following results are obtained: Time stamp SR (.trk) SR (.acmi) 57,954 18000 18343 61,355 15000 15354 64,752 12000 12352 68,158 9000 9350 71,472 6000 6423 It is unlikely that this is caused by the radar not looking through the center of the the pipper, since in 6667 ft (GUN) mode, the optical sight's range bar is very accurate as shown in the other .trk and .acmi. The below errors are likely measuring errors or caused by range bar inertia. Time stamp SR (.trk) SR (.acmi) 73,644 6000 5925 74,738 5000 4945 75,876 4000 3945 77,014 3000 2933 78,094 2000 1975 It is noteworthy that the (apparently miscalibrated) 20,000 ft mode nevertheless seems to perfectly match the range bar as situated on the 10 nm B scale radar screen. For example, when the optical sight erroneously displays 18000 ft, the range bar is positioned exactly on the 3 nm position. Also of note is that while the 6667 ft (GUN) mode is very accurate relative to the actual position of the aircraft, a target shown at 6000 ft slant range in the optical sight will be noticeably short of the 1 nm range on the radar screen. Lastly, even though the VISIDENT indicator in the back seat should not work in AIR-GND mode, currently its indications seem to very closely match the optical sight's indications in GUN mode (and therefore actual ranges). It would be interesting to know if the miscalibration in 20,000 ft mode is purely cosmetic or if it translates to wrong slant ranges being fed into the WRCS at pickle for DT and DL. The only vague hypothesis I have is that the issue might be related to the difference between a radar mile (6000 ft) and an actual nautical mile (6076.12 ft). This post is loosely related to that one. air-ground_ranges_track.acmi air-ground_ranges_gun_track.acmi air-gnd_ranges.trk air-gnd_ranges_gun.trk

According to the RL 34-1-1 (p. 1-50C, p. 1-86J), in VISIDENT mode, the HOLD ALT, SHOOT and IN RANGE lights are disabled. The HOLD ALT light is additionally disabled in BST mode. This is not implemented in the game. According to the Heatblur manual, the VI indicator does not function in "air to ground modes". What is meant to be said is probably that the VI indicator does not function in AIR-GND radar mode, see the RL 34-1-1, p. 1-50. In the game, the VI indicator works normally even in AIR-GND mode. This last issue was also posted here since it fits under VISIDENT and AIR-GND discrepancies.

The RL F-4E displays the following items on the radar scope in Air-to-Ground mode which is available only in AI ranges (up to 50 nm). The range strobe is limited to a maximum of 20 miles. Upon lock-on, the acquisition symbols disappear, leaving only the range strobe. According to the RL 34-1-1 (p. 1-50C), in AIR-GND mode, the HOLD ALT, SHOOT and IN RANGE lights are disabled. Furthermore, the VI indicator in the back seat is not supposed to function in "air to ground modes" (Heatblur manual, what is probably meant is AIR-GND mode, see the RL 34-1-1, p. 1-50). In the game, in air-to-ground mode, all radar ranges are available up to 200 nm, albeit no locks can be taken in 100 nm and 200 nm, the range strobe is available at any range, the acquisition symbols do not disappear upon lock-on, the radar display features the range rate, an aim dot and Rmin, Rmax symbols depending on the weapon selected, the VI indicator in the back seat works normally, the SHOOT, IN RANGE and HOLD ALT lights are not disabled, the ASE circle is not fixed in size, but changes in size depending on whether RADAR, HEAT or GUN is selected and varies slightly in size even after a lock is taken. The caged "HEAT" size is presumably the correct one. While I do not find the presence of the range rate readout surprising or bothersome, the Dive Toss and Air-to-Ground radar sections of the manual do not mention the presence of a visible range rate readout either so I suppose the above table not mentioning it might be correct in this regard.

I've investigated this a bit more. Contrary to my initial statement, you do not need a lock to get a release tone. Instead, just depressing the first-stage trigger, thus displaying the range strobe, will enable a release. This is correct as per the RL 34-1-1. However, the advantage of pressing the second-stage trigger is that the range strobe will "snap" or adhere (with some lag) to the strongest radar return in the vicinity of the strobe when the lock is taken. This strongest return happens to be at the center of your pipper. As others have indicated, "locking" does not actually lock a specific point on the ground but commands the radar to track/follow/adhere to the strongest return within its beam. I am not sure whether this is realistic, but it might be. If you watch the range strobe closely after lock-on (it's easier to see in active pause), the strobe will actually oscillate slightly trying to find the strongest return hit by the radar beam. If there is no good return, this oscillation will be stronger. If you pitch the aircraft up and down while maintaining some clutter on the scope, the strobe - after taking a lock - will follow the clutter with some lag but still attempt to mark the strongest return even if Jester is disabled. If you don't take a lock, the range strobe does not do that. If you pitch the aircraft too quickly or too much, the range strobe is unable to "catch up" with the returns and will get stuck. At lower grazing angles, the ground returns have an insufficient gradient/contrast to cause the range strobe to move in a specific direction. I suppose this is why it is important to stabilize you aim prior to pickling (IRL). If Jester is enabled, he will move the acquisition symbols onto the strongest part of the main beam clutter even before you have him take a lock. After lock-on, the range strobe's behaviour is the same with enabled and disabled Jester. As opposed to my first post, the position of the range strobe at pickle does seem to have an effect on the range entered into the WRCS under some conditions which I have not been able to perfectly reproduce. As described in the previous post, when taking manual control of the range strobe, moving it from the center of the main beam clutter and either locking or first-stage-triggering a different discrete return, the bomb will still hit where the pipper is placed at pickle. Conversely, the attached track shows different results. I'm flying level at 500 KTAS, 4000 ft ATL, towards the harbour tug with Jester disabled. CB 1.06 set as per the calculator. As soon as the tug appears on (Air-to-Ground) radar, I manually move the acquisition symbols over the return and lock-on. The return subsequently tracks perfectly down the scope; comparing the distance shown on the label and the radar scope shows that the distance returned by the radar is correct. Pressing and holding the bomb release button at 5 nm from the target, the bombs release late to impact about 0.8 nm long of the tug. At pickle, the sight is several miles (not just one mile) long of the target. The same or a similar result occurs when the bomb is released from first-stage trigger. Running this test again, placing the acquisition symbols at 4 nm, command a lock and pickling with the tug at 5 nm, the bombs impact 0.4 nm short. With the symbols locked at 3 nm at pickle, the bombs impact 1.4 nm short. Therefore, pickling in this instance obviously enters a distance into the WRCS which is neither the distance to the ground beneath the pipper nor the distance indicated by the range strobe; instead, the position of the range strobe seems to affect, but not determine the WRCS range. Granted this particular release is outside the Dive Toss design limits both in terms of distance to target and dive angle at pickle, I would still be interested where the (incorrect, but not super incorrect) range used for the release comes from. If this is simple inaccuracy introduced into the system for realism that'd be fine, but the miss distance seems to follow some logic. A related question may be why pointing to the tug blanks out the entire B-sweep at standard gain. The only theory I have right now that would explain the observations in the previous post and this one is that: pickling on a target at the centre the main beam clutter with a good "lock" (range rate display not significantly oscillating) or first-stage track on the target causes a hit, even if "lock" mode was initially engaged over a different part of the main beam clutter (i.e., the range bar likely moved to the centre of the main beam clutter between entering "lock" mode and pickling), a "bad" lock on (range rate display significantly oscillating), or merely first-stage tracking, a position that is not the target causes bombs to likely miss even with the pipper on target at pickle, a "good" lock on a target outside the main beam clutter, for example on a ship (range rate display not or very little oscillating), will cause the bomb to hit the place superimposed by the pipper at pickle provided that place is at the centre of the main beam clutter. This is a bug or missing feature because in the real jet, the slant range inserted into the WRCS depended solely upon the position of the range bar at pickle (no ground return necessary). If the target is not in the centre of the main beam clutter (for example due to an insufficient grazing angle), the bomb will likely miss. lock_dt_manual.trk

I have seen the OP's question being asked several times on Discord and these forums, as well as Zabuzard's corresponding and consistent answer. Based on testing, exemplified by the attached track and screenshots, I can confirm that in Heatblur's F-4E module it is currently not strictly necessary to initially lock the target or the ground close to the target when flying nominal parameters. All that is needed is a lock itself (or a first-stage track, see next post) so that a release tone is generated once you press the bomb release button (no lock/track, no tone). Under said nominal conditions, the slant range inserted into the WRCS is apparently the one projected through the pipper onto the target the moment you press the bomb release button, because usually the range bar will be at the location superimposed by the pipper. Reference the screenshots: 1) Locked the water an estimated few thousand feet short of the target (white speck, Harbor Tug). 2) Sight picture at pickle 3) Hit where the pipper was at pickle, not the originally locked ground return Correct CB for the release (Level, 580 KTAS, 15300 ft ATL) would have been 1.17; actual setting was 1.15, so no significant difference. Note that the acquisition symbols / range bar do not actually remain on the originally locked target but move along with the pipper until pickle. Conversely, further testing (my recorded tracks unfortunately do not show what really happens, but see below screenshot) shows that when placing the pipper on a feature and pickling, the bomb will hit said feature (with the proper CB) even though the acquisition symbols / range bar had been manually moved to and locked on a discrete target beyond or short of the feature beneath the pipper prior to pickle. Screenshot taken in active pause: Bomb will hit where the pipper is (center of main beam clutter), not the Harbor Tug locked with the acquisition symbols. lock_dt.trk

After some more investigation, I came to the (for me) surprising conclusion that at least 50% of the light issue (for far LODs) actually depends on the moon phase. Compare the following screenshots of an F-4E with fully bright/flashing lights at 2.0 nm and note that the visible light intensity decreases as the moon illumination decreases as well. At New Moon, the aircraft is virtually invisible. Comparison with the same settings and an overcast cloud layer obscuring the moon yields the same (!) visibility (no screenshots). Comparison with an F-16 shows that visibility for the F-16 at 2.0 nm is worse, but somewhat better at intermediate ranges (no screenshots). So the problem seems to be caused partially by ED's idea that a higher moon illumination makes exterior lights MORE instead of LESS visible, and partially by Heatblur's light intensity calibration at intermediate/closer ranges. I realize the first issue would have to be fixed by ED; merely putting it here if anyone else stumbles upon it. I do not have a master solution for the second issue, either. Full Moon, 60° elevation: 3rd Quarter Moon, 30° elevation: Waning Crescent, 10° elevation: Full Moon, 10° elevation: New Moon:

Based on further testing, the "Force Jester" option seems to work in singleplayer or with a single crewmember in multiplayer (if you occupy the rear seat, you can fly while Jester operates the radar, and Jester will call out Bandits), but not, as described above, in multiplayer with two human players in the cockpit. For example, with Jester set to "Auto" and both cockpits occupied by a human player, the WSO can operate the radar normally. As soon as the pilot sets Jester to "Force", Jester will be unable to e.g. track a radar return even though the WSO has his hand controller disabled with a modifier, as described above. Neither will Jester call out Bandits. With the exact same controller setup, no interference occurs between a single human in the backseat and Jester in "Force" mode when operating the radar.

Observe the attached track of me spawning in an SA-8 engagement envelope and being engaged several times in active pause. Note that the configuration of the countermeasures dispensed by Jester does not match the settings introduced into the front seat programmer. Furthermore, the actual configuration of dispensed countermeasures changes every time the track is replayed. There may be a lose relation to the front seat settings but I have not been able to figure out the logic. As far as I can tell, when releasing a countermeasure programme manually, the release configuration matches the settings (not recorded). It is noteworthy that when watching the mission in the back seat in "Force" Jester mode, Jester does not actually press the dispense button but seems to more or less randomly operate the chaff and flare rotaries and the countermeasure count decreases by a random amount each release sequence. jester_dispense.trk