Stickler

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.

While it is still not entirely clear to me whether the AFCS could be engaged with the INS in ALIGN in later mod states of the F-4E, I stumbled upon two references that indicate that the AFCS might in fact operate independently of the INS, but that also indicates that AFCS dependencies are incorrectly modelled in another regard: In the game, the AFCS can be engaged and remains engaged regardless of the position of the reference system selector switch or the compass controller switch. The only aspect of relevant in-game behaviour that corresponds to the above logic is that the AFCS does in fact not disengage when the mode selector is switched from SLAVED to DG. In this context, it is noteworthy that it is currently not possible to switch from SLAVED to DG directly using the mouse, since a left click will switch to COMP (and successively to DG), while a right click will switch to SYNC.

Not sure if the following issue is related to or was caused by fixing the one reported in this thread, but as of 2.9.11.4686, both ECM switches are in STBY when the aircraft spawns. The checklist calls for the ECM to be switched OFF during the After Landing Checks, and I do not see a reason why maintenance personnel would place the switch to STBY prior to the crew entering the jet. If the switch needs to be in STBY on spawn to prevent the no-warmup bug, it might be left as is, otherwise I recommend the OFF position as default.

In the RL 34-1-1, the following WARNING can be found in the OFFSET RADAR IP section: There is also this depiction of an OFFSET/TGT FIND attack reproduced in the game manual that is slightly less specific: This strongly indicates that in LABS/WRCS modes, the AJB-7 pull-up command will be triggered when the aircraft is at a range from the inserted target position that is equal to, but not greater or less than the value set in the Release Range window. Various other paragraphs in the 34-1-1 also speak of a release signal being trigged AT a specific range instead of "at or above/below". This leads me to believe that when executing a Timed O/S WRCS attack without offset ranges set and subsequently FREEZING and TGT INSERTING directly over the target, the pull-up command should occur when the aircraft reaches a distance BEYOND the target which is equal to the distance set in the Release Range window. As the attached track shows, however, in the game this is currently not the case. Instead, upon TGT INSERT the AJB-7 pull-up command is triggered immediately, presumably because the distance between the aircraft and the target is LESS than the Release Range. tladd_rr.trk

Based on limited further testing, the above problem occurs with the laser code set to 1511 (as in the .miz/.trk) and 1512, but NOT with the laser code set to 1688. I will not test all possible laser codes, but I would imagine that 1688 is the ONLY laser code that does not exhibit this problem. Note that in the .trk, 1511 was set both in the "Aircraft Additional Properties" and the bomb settings in the mission editor and not changed during the mission.