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

Based on further testing, I would like to add that when flying in an F-16 against a human-controlled F-4E with its ECM on, I can observe the symbol indicating jamming on the F-16's radar. When flying in an F-4E, as described above, no jamming is visible.

If an additional source that might shed light on the correct implementation is needed, I just realized that the checklist sequence for executing a Dive Toss/Dive Laydown mission (p. 2-94/2-95 of the document depicted here, reproduced in the game manual here) does not include a reference to setting the pinky switch to any specific position. This would indicate that full DT/DL functionality is available independently of said position. Given that several of the DT-related ballistic tables in T.O. 1F-4C-34-1-1 are grouped by pickle slant range (mostly 10000, 15000 or 20000 ft), it is likely the RL authors expected the pilot to pickle at these "even" ranges because they would be easy to read off of the sight range bar. If the sight range bar only unwound starting at 6700 ft slant range, this presumed expectation would have been unfounded.

Note the following extract from 347 TFW DOW NIP #24, p. 67: In the game, when pressing and holding the bomb release button in TGT FIND with the Pave Spike in track mode with the laser firing, then moving the cursor away from (long of) the target/aircraft while keeping the bomb release button depressed, the TTG cue's position relative to the T0 cue will not be affected, and bomb release will occur as it would have if the cursors had not been moved. If the bomb release button is pressed and let go repeatedly while the cursor is moved, the TTG cue will adjust every time the bomb release button is pressed. This strongly indicates that the SR to the TGT is in fact inserted into the computer at every pickle, and NOT continuously updated. The reference base describing this functionality is rather thin though, the above extract from the NIP being the only source I have found that describes this expected behaviour. The RL 34-1-1 does not seem to contain any explicit information regarding this particular issue.

Zabuzard, the way I read your statement is that the bomb release button causing a TGT insert signal to be sent is correctly modelled according to your research. That particular fact/issue, however, was a rather minor tangent in my report, which is mainly about the fact that no steering information is available in Pave Spike WRCS acquisition and track modes. Am I to interpret Silhou's changing the title to "NO BUG" as the developers being of the opinion that the entire logic/behaviour I am describing in my above post is correctly modelled? If so, how do you explain the apparent contradictions between the 347 TFW DOW NIP #24 I quoted and the game/your sources/SME's input? If not, which is the correct interpretation of Silhou's changing the title to "NO BUG"?

Same issue here, and unable to to pinpoint a reason either. Not sure with which version of the module this started but it wasn't always the case. What helps for me is to run an instant action mission in the same game session and on the same map prior to running a custom mission or connecting to a server. Does not happen with other modules (tested F-16 and F/A-18).

While trying to find a workaround for this issue I was able to reproduce what the underlying problem actually is: The along track cursor uses a zero azimuth reference that is neither the aircraft's track nor the aircraft's heading. For example, with the aircraft flying a true course of 360° at 500 KTAS in a crosswind from 270° true at 97 knots, the required wind correction angle (WCA, or crab angle) is -11°, which translates into a heading of 349° true to stay on course. In TGT FIND, to make the Pave Spike look directly at the target in WRCS ACQ, the radar cursors need to be placed 11° RIGHT of the target, which equals the WCA with an inverse sign. Alternatively, you can use rudder (trim) to take out the crab while moving/freezing the cursors ON the target, but this will of course screw up your track. In the above example, this doesn't work though since the required correction exceeds rudder authority. If you manage to actually point the radar at the target using this workaround, the TGT FIND/OFFSET steering will accurately guide you to it or any offset you entered. If you start with the cursors zeroed/reset and press the along track wheel to move the cursor straight up on the radar scope, the point the pod is looking at moves away from the aircraft along the 338° true bearing in the above example. I would expect either the 349° true bearing if the cursor zero azimuth is the aircraft's heading or 360° true bearing if the cursor zero azimuth is the aircraft's track. Even if the design choice is made not to model drift stabilization, I cannot see the logic in the zero azimuth reference of the radar SCREEN being the aircraft's heading and the zero azimuth reference of the radar CURSORS being the aircrafts heading plus the WCA (or the aircraft's track plus the WCA times two), so I strongly suspect we are looking at a bug (possibly a sign error in the code).

VOR DME can be received by setting the appropriate TACAN channels (cf. e.g. AC00-31a.pdf, p. 60 ff.). This currently works in the F-4E for X channels only (or VOR frequencies ending in .X0), but not for Y channels (or VOR frequencies ending in .X5). Given the F-4E generally has Y channel capability and I have not found anything in the RL manuals indicating otherwise, I would imagine that .X5 VOR frequencies should be able to be received via the F-4E's TACAN. I do not know if this is a problem specific to the F-4E or a general ED issue.

Observe the attached screenshot: It can be seen that the aircraft is established on the localizer and GS for an ILS approach into OISS. Not seen (but inferable from the ASI and VSI, scenario has no wind) is that the aircraft is also stable without a marked trend to go below or above the GS. Note that the flight director commands an unwarranted climb to above the GS. This is likely related to the below issue which also features a horizontal FD bar above where it should be: It is possible that this is an (undocumented?) feature since the FD vertical commands seem to improve in accuracy as AoA is increased to the 19.2 units optimum, that is, the horizontal bar MIGHT take into account AoA by design, or this might be totally coincidental. I tend to assume the latter since the FD command would then be incorrect during approaches intentionally flown at different AoA, such as no-flap or formation approaches.