Stickler

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.

Original post updated.

According to the game manual, timers for ARBCS bombing modes are available for PULL-UP (0 to 60 seconds) and RELEASE (0 to 30 seconds). Both can be set in increments of 0.1 second, with 0.1 second as the minimum setting. This statement is confirmed by all real-life F-4 manuals at my disposal. As seen in the attached track, the pull-up timer can be set to values greater 60 seconds (70 seconds in the track), and the release timer can be set to values greater 30 seconds (40 seconds in the track), each in intervals much smaller than 0.1 seconds. The aircraft will not only permit these values to be set, but actually uses them in bombing: In TL mode, 70 seconds after the bomb release button is pressed, the pull-up light goes out and the steady tone comes on. 40 seconds afterwards, the bombs release. timers.trk

Reference the attached track which shows me deliberately entering the Pave Spike's "idiot mode" by slewing the pod onto an aerial target 1000 ft above me. Upon hitting the first-stage trigger, the pod goes crazy, as expected. The issue is not idiot mode itself, but that in this state, the pod generates visual outputs that are physically impossible, such as looking through itself onto the rack it is attached to, or aft through itself and along the fuselage with the exhaust smoke being visible. My guess would be these are engine problems and hard to fix but maybe you could add the issue to your tracker for when everything else is finished. idiotmode.trk

Yes, I replayed the track and it works. The green XMIT lamps were lit and I re-ran the mission several times to make sure it wasn't a fluke. The mission is set up as an airstart. Please find the track from the perspective of the jamming aircraft in the attachment. ecm-20241219-202328.trk

Observe the attached MP track which shows a head-on pass starting at 75 nm separation between a human-controlled blue coalition F-4E and four aircraft, from left to right: 1x TU-22 (AI, Red coalition) 1x F-4E (human-controlled, jammer manually switched to BOTH shortly after the start of the mission, Blue coalition) 1x F-4E (AI, Blue coalition) 1x F-4E (AI, Red coalition) All F-4Es have an ALQ-131 loaded. All AI aircraft are configured as follows: ACE skill "Nothing" task ECM Using = ALWAYS USE Reaction to Threat = PASSIVE DEFENCE Restrict Air-to-Air Attack = on The only aircraft performing any visible jamming is the TU-22. It is noteworthy that locking the F-4Es does not cause them to start jamming either (not seen in track). server-20241219-202319.trk

According to the RL 34-1-1, the HOLD position of the TGT FIND switch in the back seat prevents the TDS from being integrated with the WRCS and illuminates the WRCS OUT light. In the game, the WRCS OUT light does not illuminate when the TGT find switch is set to HOLD and e.g. WRCS acquisition mode works normally.

According to the RL 34-1-1, in MAP PPI, linear polarization of the antenna beam is automatically selected regardless of the polar switch position (because, if I understand correctly, the antenna does not nutate in MAP-PPI mode, and nutation is a prerequisite for circular polarization). In the game, selecting circular polarization in MAP PPI with all other settings unchanged has an effect on the radar presentation, which should not be the case if polarization remains linear.

If it helps, one or two patches ago, BRT external lights could actually be seen from about 2-3 nm away at default zoom. They would then dim considerably upon approaching the light source, to become more clearly visible again at very close distance. This intermediate non-visibility (which made e.g. night rejoins pretty hazardous because you'd lose your sight references at an inopportune moment) apart, that solution was actually pretty good.