Stickler

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.

Observe the attached tracks and .acmis of the same mission, once from the pilot's and once from the WSO's perspective. Note that in the pilot's track/.acmi, the LGB released by the human/human crew hits its intended target, while on the WSO's track/.acmi, it never acquires the laser, flies ballistically and lands beyond the target. This was a mission created specifically to reproduce the issue. Not seen is that from the perspective of human third parties, the bomb will NOT hit (noted during a different multiplayer event, tracks not working). .miz attached in case anyone wants to reproduce the issue on their own. This problem does not occur when flying as a pilot in MP and switching to the back seat to lase the bomb. pilot.acmi pilot.trk wso.acmi wso.trk mp_lgb.miz

First issue According to the RL F-4E 34-1-1, in MAP PPI mode, the offset cursor is displayed in the 10 and 25 mile ranges (and 50 mile on DSCG). In the game, the offset cursor is also displayed in the 100 and 200 mile ranges. Second issue According to the RL F-4E 34-1-1, the range cursor becomes a bombing range strobe when the delivery mode knob is in any position except OFFSET or TGT FIND and the MAP PPI or BEACON PPI (NAR or WIDE) radar mode is selected. If I interpret the 3TFW Radar Bombing and Navigation Guide correctly, this bombing range strobe can be used during "Bomb Strobe Deliveries". In the game, no bombing range strobe as defined above exists. Since the bombing range strobe is not mentioned in the 34-1-1 of 15 March 1970, Change 9 - 26 January 1973, it is possible this was a more recent feature that didn't exist in all blocks of the F-4E. Third issue According to the game manual and the RL F-4E 34-1-1, the maximum navigation range for TGT INSERT is 180,000 ft or 30 nm. There is no information in these manuals on what happens if that range is exceeded. The 3TFW Radar Bombing and Navigation Guide, however, states the following: In the game, the limit of the navigation range of the WRCS is 1999 nm and steering seems to be accurate up to that range. It is of course possible that the 30 nm limit was removed after 1981 when the Guide was written, however the fact that Change 20 of the 34-1-1 from 15 December 1986 still mentions the 30 nm and 180,000 ft seems to indicate that the limit still existed at that time. That being said, the Guide contains the following information: This behaviour cannot be seen in the game. The fact that the offset cursor was only displayed until the 50 mile setting of the DSCG corroborates the 30 nm limit; there is hardly a need for the offset cursor in any higher scale than 50 nm if the along track cursor cannot be moved past 25 nm and cannot register a value greater than 30 nm. Fourth issue According to the RL F-4E 34-1-1, the along track cursors must be moved first to enable cross track cursor movement. In the game, either wheel may be moved first.

Entirely possible that the logic was changed between blocks, even wrt to the technical wiring. Please find below a similar chart that is less ambiguous. If what makes more sense operationally is any indication, the 20000 ft hypothesis is stronger since 6700 ft would be close to or even less than the bomb/slant range of conventional low drag munitions at usual delivery parameters for Dive Toss, rendering the range bar practically useless.

Thanks for the fix. Unfortunately, the range bar is now limited to a 6700 ft max range in DT with the pinky switch set to GUNS whereas, at least if I understand this chart correctly, the 20000 ft max range scale should be used in DT with the Sight Mode Selector Knob in A/G regardless of the pinky switch position. To obtain the 20000 ft scale in 2.9.11.4686, selecting HEAT or RADAR is required.

I have noticed another issue which is possibly related. Observe the attached tracks and associated .acmis. The mission consists of two carriers positioned exactly on a north-south bearing, 4.993 nm apart. This results in a 303 South offset which I enter into the appropriate dial. The first run of the mission has zero wind, with successive iterations having more and more crosswind from the left in flight direction. Note the following: No matter the crosswind, the physical points of space at which both carriers are overflown are (within the limits of random inaccuracy) the same in the first four iterations. However, selection of FREEZE and TGT INSERT results in the pod slewing to a target point in space more and more to the right (west) the stronger the crosswind from the left (east). If I decide to actually follow the steering provided by the roll tabs (last file "steering"), the system accurately flies me over the wrong point, which means the system really does think that the target is at a different point in space depending on the wind drift at FREEZE/TGT INSERT. The issue occurs in OFFSET as well, but has been recorded in TGT FIND due to the ability to visualize the problem. While this doesn't appear like a big deal at first glance, in the "very strong wind" scenario the error reaches approximately 200 ft which precludes accurate bomb delivery. If this behaviour is realistic by all means do not change it, but it doesn't seem immediately plausible to me that the wind drift the aircraft is experiencing should have any effect on WRCS offset handling. Tacview-20241227-175424-DCS-vip_offset_wind.trk.zip.acmi Tacview-20241227-175257-DCS-vip_offset_no_wind.trk.zip.acmi Tacview-20241227-180032-DCS-vip_offset_very_strong_wind.trk.zip.acmi Tacview-20241227-175635-DCS-vip_offset_strong_wind.trk.zip.acmi Tacview-20241227-180520-DCS-vip_offset_very_strong_wind_steering.trk.zip.acmi vip_offset_no_wind.trk vip_offset_very_strong_wind.trk vip_offset_very_strong_wind_steering.trk vip_offset_wind.trk vip_offset_strong_wind.trk

Noticed some consistent Pave Spike behaviour which is likely related to the above but the logic of which I cannot really explain based on available documentation. In the attached track (memory_mode.trk), notice me initially picking up a radar contact in PPI and WRCS ACQ, hitting FREEZE, then switching to TV mode. The pod is initially perfectly pointed at the target, as expected. While remaining in PPI, I enter track mode and move the cursor to the right for a short distance (which shouldn't be possible as established above). When subsequently entering Memory mode by switching back to RDR, the radar cursors have moved to a seemingly random location nowhere near the carrier. I then reestablish the radar track and switch back to TV; the carrier is again visible. Before entering track mode again, I switch the display to B WIDE, hoping that this would prevent the above random cursor/pod drift. However, I notice that in B WIDE, I can actually move the TV picture using the ALONG TRACK and CROSS TRACK controls, which I am not sure would realistically work in that mode since there are no cursors in B WIDE (or B NAR or VI, for that matter). Upon entering track mode and subsequently slewing the TV picture a bit to the right as before, I would expect to thereby move the to-be-memorized position only slightly. However, when switching back to PPI, it can be seen that the cursors have actually moved a substantial distance and are nowhere near the carrier, as before. --- In a branch of the above scenario (see memory_mode_2.trk), I initially establish a radar fix on the target using FREEZE and TGT INSERT. I then switch to TV mode and to B WIDE. I subsequently command track mode and move the reticle over the target. Upon hitting TGT INSERT, which I expect would trigger memory mode, the pod instead moves aggressively away from the target. Verifying its position in PPI, the cursors now seem to be centered in azimuth and on a point about 5 miles ahead of the aircraft. Note that hitting FREEZE before selecting TGT INSERT a second time or having a valid laser lock on the target does not lead to a different behaviour (no separate tracks made). The only workaround I have found to avoid these unexpected movements is to initially establish the radar fix as above, then refine the pod's viewpoint in TV mode not in track mode, but using the ALONG TRACK and CROSS TRACK wheels (which likely wouldn't have worked IRL in B WIDE, as above), and then enter track mode and hold the bomb release button depressed shortly prior to the estimated release point to create a "pseudo" TGT INSERT (compare here). --- In the track of a further branch (memory_mode_3.trk), it can be seen that while the system is in the above "pseudo" TGT INSERT mode, one can actually move the TV picture with the antenna hand controller while simultaneously moving the point the WRCS is looking at with the ALONG TRACK and CROSS TRACK wheels (reference the changing values in range and azimuth on the BDHI) while the bomb release button is held depressed. This works both in a B mode as well as in PPI. Due to a lack of pertinent documentation I cannot prove that this is incorrectly modelled but it "feels" like a bug. memory_mode.trk memory_mode_2.trk memory_mode_3.trk

Compare the attached tracks showing an F-4E at 20,000 ft true altitude passing north to south by a carrier offset about 15 nm east from track. In no-wind conditions, to get a precise fix on the carrier (confirmed with Pave Spike) in TGT FIND, the center of mass of the radar return has to be aimed at. After pushing FREEZE, the radar cursors (and the pod slaved to them) perfectly track the carrier. In strong crosswind conditions from the left in flight direction (90 kts), to even get a precise fix on the carrier, the radar cursors need to be placed on the right edge of the return. After pushing FREEZE, the cursors drift away from the target in downward-right direction. The issue occurs in the same way in OFFSET, but visualization is not as nice due to the missing pod integration. I don't know exactly what "drift stabilized" means in the context of MAP-PPI, but I see no obvious reason why the radar shouldn't be able to compensate for the aircraft's drift in a constant-speed, constant altitude situation. This issue is likely related to the following: radar_drift_tgt_find_crosswind.trk radar_drift_tgt_find_no_wind.trk

Update: The RL formula posted above yields the same results as the bombing tool if the 7.5 ft/s ejection velocity is replaced with the 0.0 ft/s used in DCS. Deviations from RL tables are likely due to slightly different ballistics in-game vs. IRL, tabulation inaccuracies and - especially - different ejection velocities. Reference the thread below for more relevant info.

Through some trial and error I finally found an easy workaround for two of the biggest issues currently affecting the in-game bombing calculator. In the DIRECT and DT tabs, setting, for example, a "dive angle" of 10° provides a bomb range and TOF that actually corresponds to a 10° Loft. Since the tool will not accept a "-10" entry, it is not normally possible to calculate the bomb range and TOF for actual dive releases. Workaround: Copy and paste a "-10" from outside the game into the tool to obtain the correct values. Conversely, in the DT tab, for a 10° dive, "10" needs to be entered to obtain the correct drag coefficient, for a 10° loft, "-10" needs to be entered to obtain the correct drag coefficient. Looks like simple sign errors to me which are probably easy to fix.

First of all, this report is based on the assumption that the developers' intention was to model Pave Spike implementation as it is described in 347 TFW DOW NIP #24. Since there are a few differences between that NIP (from June 1980) and the RL 34-1-1 of 15 April 1979, Change 20, 15 December 1986, or rather since the 34-1-1 is rather terse/unspecific about certain functions, it is entirely possible that the information contained in the NIP was subsequently superseded. However, since the game manual contains quotes from the NIP (compare here and p. 69), the manual references details concerning memory mode which are not included in the 34-1-1 but in the NIP, the Pave Spike features described in the NIP are "better"/more comprehensive than the features described in the 34-1-1 and it is unlikely the Pave Spike implementation was "downgraded" in later F-4Es (or 1980 vs. 1986), I suppose the above assumption is valid. That being said, the NIP contains comprehensive information on how the Pave Spike worked, with the following table summarizing the functions relevant for this report: In the game, the WRCS acquisition and track modes provide neither steering nor DME to a target superimposed with the radar cursors or manually tracked with the TV display, respectively. Steering and DME will become available only once TGT INSERT is pressed, or in other words, once Memory Mode is entered. It is noteworthy that pressing the bomb release button in-game either in the front or the rear seat actually causes the TGT INSERT light to illuminate even though the button is not depressed (MASTER ARM must be HOT, nothing happens with MASTER ARM OFF). While the bomb release button is held, the system acts as if it was in Memory Mode in that steering and range to the tracked target are displayed. That fact that pressing the bomb release button causes Memory Mode to be entered in the currently game implementation is strongly supported by the fact that moving the pod to its gimbal limits causes the same illumination of the TGT INSERT light. I have found no indication in any RL source that pressing the bomb release button would imply a TARGET INSERT or the entering of Memory Mode. This would be rather impractical either since in Memory Mode, inter alia, the laser is shut off. In the game, when pressing the bomb release button, the laser is NOT shut off. The are a few issues connected to the above which I could report, but I'd first like to ask for clarification by the devs if the current implementation is a design choice (presumably for simplification), if it reflects an F-4E mod state for which I have no documentation or if we are looking at a bug/bugs.

According to the RL 34-1-1 and the 347 TFW DOW NIP #24, during all TDS acquisition modes and WRCS IN, the optical sight is caged 35 mils below FRL and at zero azimuth. In WRCS OUT, or once track mode is entered in A/G sight mode, the sight is uncaged and moves to the selected sight depression. In the game, the sight does not uncage in WRCS OUT or once track mode is entered. From the above 34-1-1 extracts, it appears as if the automatic caging occurs in DIRECT mode as well, and this interpretation might actually be correct based on the following source: Since "delivering dumb bombs" might just as well be done in DIRECT, it is possible that the WRCS "knows" that a pod is installed on the jet as soon as the pod is unstowed, which would then potentially cause DIRECT mode to be affected by the auto-caging. That interpretation, however, involves some speculation on my part.

According to the RL 34-1-1, in WRCS auto mode, the optical sight range bar and ADI pitch steering bar move in conjunction with Pave Spike TTg and T0 cues on the TV reticle display. In the game, neither the range bar nor the vertical ADI pitch steering bar are displayed during attacks in WRCS auto mode.

According to the RL 34-1-1 and the 347 TFW DOW NIP #24, antenna hand control operation is not possible in Pave Spike track mode when a PPI radar display is selected. In the game, antenna hand hand control operation is possible in Pave Spike track mode despite selection of a PPI radar display. I do not claim to understand WHY a deselection of PPI is necessary since the cross track and along track cursor are moved by the respective wheels and not the antenna hand controller. Based on the above sources it is not entirely clear either whether an absolute requirement exists to select B WIDE or if any mode except PPI WIDE/NAR is possible. A possible reason why B NAR could cause conflicts is because in that mode the antenna hand controller is used to position the 45° B-sweep scan sector. Since that sector does not exist in VI, I cannot see how VI would conflict with track mode.