Stickler

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. 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. This 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 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: