Stickler

I believe I found the solution. It seems that binding the [WSO] Antenna Hand Control Slew X/Y axes (either one or both of them, not sure) prevents Jester from locking the ground return, but will instead cause him to lock whatever is underneath the cursors at the time of attempting the lock. I stumbled upon this per accident when I realized that Jester was unable to lock air returns in Boresight as well, instead locking some other point (the one underneath the cursors). Setting a huge deadzone to make sure that no unintentional inputs are made to the axis does not solve the issue. I had to completely unbind the axes. Jester was then able to lock the ground return and I am now getting fairly accurate deliveries. Haven't tested this enough to be able to say with confidence that DT (especially Dive Level) works as intended, but the principal issue I had can be traced back to the bound axis.

I have had the issue of getting the loading bar stuck at "Mission Load Fail" when attempting to replay a multiplayer track from a session with me as WSO in the back seat of a human pilot which was generated from a mission run on a dedicated server for a while. Until now I thought this was related to the complexity and length of the mission somehow corrupting the track, but now I think we are looking at a general problem. Reference the attached .miz which only contains an F-4 and a hostile BTR at a separate airfield. When running the mission on a self-created server and entering the aircraft as a pilot, clicking a few switches and then exiting, the resulting track "without WSO" will playback just fine. When running the mission on a self-created server and entering the aircraft as a pilot, switching to the WSO seat, clicking a few switches, returning to the pilot's seat, clicking a few switches and then exiting, the resulting track "switching" will also playback just fine. If, however, attempting playback of a mission hosted on a self-created server with myself as a human WSO having been present in the same jet on a different computer, both the track recorded by the pilot/server ("Pilot and server track with WSO") and the track recorded by the WSO ("WSO track") will cause the loading bar to hang at "Mission Load Fail". DCS subsequently has to be exited via "CTRL-ALT-DEL". Previous missions I flew on a dedicated server with another human player in the front seat had the issue that the track generated by the pilot was loadable, the track generated by me was not, as above. Any idea what might cause this? Has anyone actually been able to get a working (that is, "loadable") track of themselves in the WSO seat from a mission with another human pilot in the front seat? tracktest.miz server-20240907-115215 (Pilot and server track without WSO).trk server-20240907-120320 (Server track with aircrew on one PC switching between pilot and WSO seat).trk server-20240907-114141 (Pilot and server track with WSO on separate PC).trk tracktest-20240907-114158 (WSO track on separate PC).trk

I can confirm this still happens in 2.9.7.59263 MT. A related issue may be the following: When shutting down the right throttle as part of the Engine Shutdown checks, hydraulic pressures are completely unaffected. Only when the left engine is shut down as well do PC-1/PC-2 and utility pressure drop to zero. Expected behaviour is PC-2 pressure dropping to zero prior to left engine shutdown (which is also a prerequisite for a proper spoiler actuator check). Hydraulic pressure not dropping (except for a quick "jerking" loss of hydraulic pressure in all systems that quickly recovers) can also be observed when shutting down the left engine first. Did some more testing and came up with a rather odd hydraulic-related behaviour that is best explained with the attached track. I am aware that my actions are not as per the checklist. No intentional control surface movement or actuating of any switches occurs except those described below. Started left engine first. PC-1 initially stabilized at above 3,800 psi, Utility at 3,100 psi. Connected air to right engine and started airflow, but never started the engine itself. PC-2 pressure rose to approximately 3,200 psi. Not sure if an RPM of roughly 21% (max 23% later on) would suffice IRL to build up hydraulic pressure above specification. Shut down left engine. All hydraulics initially drop toward zero, then recover. PC-2 [!] rose to 3,100 psi, PC-1 subsequently stagnated at 2,400 psi. Utility stagnated at 3,000 psi. At about 08:04:00, the hydraulic systems experience an upward, then downward pressure jerk, with PC-2 subsequently rising back to 3,100 psi, PC-1 to 1,900 psi, Utility to 3,000 psi. These seemingly random hydraulic fluctuations, quantitatively and qualitatively different, continued at irregular intervals until I had seen enough and ended the recording at 08:07:00. The end state was all hydraulic systems static at 3,800 psi. As it stands, right air alone can therefore currently sustain 3,800 psi in all hydraulic systems, possibly indefinitely. hydraulics.trk

Awesome, thanks!

With both the "Jester UI Allow Mouse Controls" and "Jester UI Allow Head-Tracking" options disabled, once clicking on a manual coordinates entry field in the Jester wheel, it is impossible to leave/close the wheel. At least I have tried all keybinds I could possibly think of, to no avail. With Mouse Controls enabled, one can simply click on any surrounding field or in the center of the wheel to close it. I cannot exclude operator error, so if there is a way to close the wheel under the above conditions I would appreciate a hint.

I have not been able to figure out in which scenario the "Start alignment" Jester command would be used. After engine start, Jester will automatically ask for alignment; it seems that that "Start alignment" command does not actually do anything before or after Jester has raised the question despite being acknowledged. I supposed that the command might be used to force Jester to start alignment prior to internal power being available but this is not the case. Any suggestions/ideas?

Some updates to the original post.

Did some experimenting with Dive Toss lately and different sources providing different cb settings for specific release parameters have me somewhat confused. Take this example from the kneeboard, which is taken from RL documentation available at F-4E Squadron Weapons Pamphlets (digitalcombatsimulator.com): Assuming these parameters are for a standard day, release speed at 8200 ft MSL corresponding to 500 KCAS is 554 KTAS. Entering these parameters in the bombing calculator, the resulting cb setting is 1.06, whereas the RL table has 1.10. The above source also provides a formula to manually calculate cb. While the letter in which this formula is contained does not explicitly state whether the formula applies to the BDU-33 only or to all munitions, I was able to re-calculate the cd values given on a previous page of the kneeboard for Mk 82 LDGP releases very accurately. This could be because the BDU-33 replicates Mk-82 ballistics IRL, or because the formula is applicable to all munitions. I don't know. In any case, entering the RL parameters above in the formula yields a cb of 1.22. An actual Mk-84 LDGP released in DCS at the above parameters has a bomb range of approximately 6538 ft. This is significantly longer than IRL since DCS free-fall munitions do not have an ejection velocity (it is noteworthy that the above tabulated RL bomb range would be reached in DCS if the Mk-84 had an ejection velocity of 21.2 ft/s, which happens to be a typical RL figure for Mk-82 ejections). Using the above formula to calculate cb for the actual bomb range in DCS yields 0.97. Using the formula with the bomb range from Heatblur's ballistic calculator (30524 ft) yields -0,65. Overview Source cb Heatblur's bombing calculator 1.06 RL table 1.10 RL formula with RL parameters 1.22 RL formula with DCS bomb range 0.97 RL formula with Heatblur's bomb range -0.65 This leads me to first actual question: Which cb value do we use in the game for maximum accuracy? The cb value from Heatblur's bombing calculator even though the calculator outputs a vastly inaccurate bomb range for any dive angle except 0°, the cb value being very sensitive to deviations in said range? The values tabulated in RL sources, even though RL ballistics differ significantly from DCS ballistics, mostly due to a non-simulated ejection velocity? The result of the RL formula, even though we do not know (I think) whether it applies to munitions other than the BDU-33 IRL, and even though we know that it applies strictly only for RL ballistics which do not match DCS ballistics? Any other option I'm not aware of right now. My second question: Has Heatblur elected to use the above formula to calculate cb? If so, would you be willing to release the constants used for particular weapons (since the ones in the RL source obviously do not provide the same results as your calculator for all munitions)? If not, would you be willing to release the formula used to calculate cb instead? P.S. It seems unlikely do me that the calculator's cb values are directly derived from the RL formula, unless the visible bomb range output is not re-used to calculate cb, but cb is based on a different bomb range calculated behind the scenes.

This problem seems to have been only partially fixed in 2.9.7.58923. Witness the attached track recorded in 2.9.7.59263 MT. With both engines started but the jet remaining on external power only, having external power disconnected will cause neither the auxiliary air doors nor the speed brakes to close. Only when moving the generator switches to OFF from EXT ON does this occur. I suppose that if either the speed brakes or the auxiliary air doors were able to operate on battery power without external (or internal generator) power, there would be no need for the -1 warning. I therefore assume that the two mentioned devices should retract without external (or internal generator) power available; the generator switches being in the OFF position should not be a requirement for retraction. retraction.trk

As per the Heatblur and RL flight manual, during an engine start using external airflow, one should signal the crew chief to stop flow at 45% RPM. The reason for this figure is not provided in any Air Force manual I'm aware of, but the RF-4B NATOPS manual (NAVAIR 01-245FDC-1) suggests that 45% is usually self-sustaining RPM. Witness the attached track. When starting the right engine, I order the crew chief to stop airflow immediately after ignition, which is acknowledged prior to the engine reaching 15% RPM. The engine starts without issues. When starting the left engine, I order the crew chief to switch external air from the left to the right engine, which is acknowledged at 15% RPM and executed prior to the engine reaching 25% RPM. The engine starts without issues. I am by no means an expert in the J79 and I cannot prove my position, but it seems implausible that the engine would be able to reach self-sustaining RPM even though airflow is interrupted 20% or more RPM below the relevant threshold. airflow.trk

Understood and fair point. In this case, the bug is rather that neither the Select tank to refuel switch nor the Toggle [Flare] Ripple Release switch (nor the INS Align Mode - Heading Memory switch, which is the last of the three switches of this type) will automatically open the associated cover. It is noteworthy that the INS Align Mode - Heading Memory switch behaves the same way as the Toggle [Flare] Ripple Release switch: If the cover is down, the switch will not move. So we have 2 out of the 3 switches of this type following the "restrictive" mode, and one following the "non-restrictive" mode, with neither of the three automatically opening the cover.

The "Select tank to refuel switch" can be moved using a key bind (I only tried "Toggle") even when the associated cover is closed. Although this might be a design choice, the WSO's "Toggle [Flare] Ripple Release" switch can NOT be actuated with a key bind when the cover is down, which leads me to believe that the "Select tank" switch is affected by a bug.

This problem still occurs in 2.9.7.59263 MT.

The Comm Frequency (...) - [Next] key bindings, both when bound with a keyboard key and with a DirectX HOTAS key, sometimes skip digits. This probably happens for the [Prev] bindings as well, but I haven't checked. The [Dec] and [Inc] bindings as well as mouse interaction do(es) not seem to be affected. I have identified the following specific cases where this occurs. I haven't checked the first three digits of the WSO's UHF radio since I'm using [Dec] and [Inc] bindings for those, but I strongly suppose examples 2) and 3) occur in the rear cockpit as well. 1) Pilot/WSO UHF: Set 388.300 in the manual frequency. Press the Comm Frequency (xxx.0xx) - [Next] button The aircraft will show 388.400. SRS will interpret 388.500. Press the button again. Both the aircraft and SRS show/interpret 388.600. 2) Pilot UHF: Set 260.000 in the manual frequency. Press the Comm Frequency (x0x.xxx) - [Next] button. Both the radio and SRS will show/interpret 280.000. 3) Pilot UHF: Set 293.000 in the manual frequency. Press the Comm Frequency (xx0.xxx) - [Next] button. The aircraft will show 294.000. SRS will interpret 295.000. Press the button again. Both the aircraft and SRS show/interpret 296.000.

Figured out the reason for the problem, and it can actually be seen in both tracks: Jester does not lock the ground beneath the pipper, but the ground much further downrange. You can easily see the ground return that Jester is supposed to lock (quite lengthy in the first track, but quite well gained out in the second), but the range gate after lock is nowhere near the return. Compare the attached track where I lock the target myself from the WSO seat. Bomb accuracy is subsequently very high; the error can be attributed to imprecise parameters at release. This raises the question why there isn't a significantly higher number of people reporting problems with DT since Jester not locking affects all release sub-types of DT, not just Dive Level. dttest4.trk

Made a track that satisfies most of your requirements. Intended release parameters were 300 KTAS at 1000 ATL with a coefficient of 1.02 (the default). Waited about 1 second after hearing the beep. Made sure I was in a release position before the aircraft intercepted the radar line at pickle and before reaching bomb range: I rounded out 6000 ft slant range from the target, with the radar line at release intersecting the flight path at around 2900 ft slant range, so plenty of buffer. I undershot my target of 1000 ft ATL by about 200 ft, but the bomb range at the actual 800 ft ATL is calculated at 3500 ft plan range, so bomb release prior to target overflight was physically possible. The result was qualitatively the same: A release about 2.3 nm beyond the target. A 800 ft ATL release would have required a coefficient of 1.03, but this - as you said - should not cause a miss of such magnitude. I am a bit confused about your instructions for debugging though, hoping for a clarification to enhance my understanding of how DT works (or how Heatblur has chosen to implement it). This is the relevant part of the DT description from TO 1F-4E-34-1-1: What I take from this description is that the main function of the pipper (the other being to assist in compensating for lateral wind drift) is to aim the radar so the WSO can achieve lockon at the correct point on the ground. Why would walking the pipper onto the target and not holding it steady improve accuracy, especially given the instructions state to stabilize the pipper on the target? I also understand that the only function of the bomb release button is to cause the radar measured slant range to be entered into the WCRS at the moment of pickle. Thus, as long as there is a valid lock, and disregarding lateral guidance by the roll tabs, where the pipper is in relation to the target when the bomb release button is pressed should be irrelevant. How would waiting 1 second after pickle improve DT accuracy? Why must the radar line at pickle not be passed prior to reaching bomb range if lockon is not required to be maintained after pickle? dttest2trk.trk

I can contribute the following to this discussion. All data was collected in 2.9.7.59263. Referencing the ballistics data in GAF T.O. 1F-4F-34-1, p. 1-162, shooting from the M61A1 and the SUU-23/A gun pod at 30° dive angle, 450 KCAS, 48.000 lbs gross weight, 4000 ft ATL with a target elevation of 0 ft MSL requires a sight setting of 59 mil. The real F-4F would have had an AoA of 22.4 mil at these parameters according to the following chart (which is identical in all manuals I'm aware of): Subtracting 22.4 mil from 59 mil makes a sight depression from flight path of 36.6 mil. When recreating the above scenario in the game as precisely as possible, Heatblur's F-4E exhibits an AoA of -1.1° = -19.195 mil. 36.6 mil + (- 19.195 mil) = 17.4 mil, which I what I entered in the sight for the following tests. Observe the result of the test firings: SUU-23/A on the wings (direct hit) SUU-23/A on the centerline (short) M61A1 (even shorter) I will not reproduce the screenshots here to preserve everyone's bandwidth (they are available on request though), but depressing the sight further by 1 degree to 34.8 mil causes a direct hit by the centerline pod, and depressing the sight by another 1° to 52.3 causes a direct hit with the nose gun. IMO, what we can deduce from this is that Heatblur's wing pods are rigged at X°, the centerline pod at X-1°, and the nose gun at X-2°. The question is: What is X? To answer that question, it is noteworthy that NAVAIR 01-245FDB-1T contains two sets of sight angle charts for the Mk 4 gun pod (the Navy's equivalent to the SUU-16/23), one for a gun bore line at FRL and one for a gun bore line 2 degrees below FRL. When extracting the required sight setting X for similar flight conditions as above from the "2 degrees below" chart (only difference is a release speed of 450 KTAS, not 450 KCAS, normalization for gross weight was of course accomplished), the results are qualitatively the same: Direct hit with the wing pods at setting X°, direct hit with the centerline pod at X-1°, direct hit with the nose gun at X-2°. The data from the "at FRL" chart does not provide results observable in the game. Under the assumption that DCS's ballistic model very closely approximates RL data, from this I deduce that Heatblur's rigging is as follows: Wing pods: 2° below FRL Centerline pods: 3° below FRL Nose gun: 4° below FRL The question then remains if this is realistic. Unfortunately, I have not been able to find a clear answer for this. On the one hand, the fact that there is only one chart for the M61A1 and the SUU-23/A gun pod in GAF T.O. 1F-4F-34-1, and that T.O. 1F-4C-34-1-1, p. 5-10, in a section applicable to all covered F-4 variants, states that "the gun firing tables are applicable to the SUU-16/A, -23/A gun pods and the F-4E nose gun" strongly suggests that the real F-4E had the same rigging for pods and the nose gun. This is also what would make the most sense tactically. However, "being applicable for" does not imply "being identical", since one could argue that a difference of max. 2° in rigging was not though of as warranting producing different charts, and that using a single chart was "good enough for government work". On the other hand, T.O. 1F-4C-34-1-1, albeit in the section applicable to the F-4D at 1-62, also states the following: In a section applicable to the F-4E, it states that: This would indicate that the nose gun was rigged 2° below FRL, and the gun pods were rigged along FRL. However, it seems that the bore line of the nose gun was adjustable e.g. based on the mission flown. See the following extract from the Navy Tactical Manual: My conclusion is therefore that Heatblur's current design choice is not categorically unrealistic, however I do find it odd that the in-game maintenance crews would elect to rig all three gun choices differently. My recommendation would be to rig all guns 2° below FRL since that would be the rigging most players presumably expect, since it has the advantage mentioned in the above extract, and it is the rigging for which we have at least two RL sources containing valid sight settings. This might also help to alleviate the problem reported at where it is found that the A/A gun solution does not provide sufficient lead for the nose gun, possibly because the sight computations assume a 2° depression whereas the nose gun is actually depressed 4° from FRL (speculating here).

Please reference the attached track. My intent is to release a pair of Mk-82 LDGP bombs on a sea level target using the Dive-Level Maneuver with a release at 450 KTAS and 3000 ft MSL (= 3000 ft ATL). According to the in-game bombing calculator, the required ballistic coefficient is 1.04, which I input manually into the appropriate window in the back seat. As should be apparent from the track, I am achieving lockon and the desired release parameters quite accurately before hitting the nominal release point at 10152 feet (1.67 nm) from the target. However, the bomb releases slightly beyond the target to impact 1.7 nm further downrange (that is, the calculated bomb range itself is accurate). I am aware that I am slightly outside the 25,000 ft range limit for Dive Toss at pickle, however I repeated the test with a pickle at 3 nm with the same approximate results. If it seems advantageous to merge this thread with the following, feel free to do so, however in that thread a similar issue was traced back to operator issue which in my case I cannot seem to find (do not hesitate to call out any errors on my part though). dttest.trk

In the RL F-4E, in Dive Toss mode and with radar lockon, the optical sight range bar indicated present slant range to the locked target. In the game, the range bar shows a fixed range after lockon regardless of actual range. This is apparently not an issue specific to the present version since it can be observed in at least two popular online tutorials that were created using previous versions of the module:

Thanks. I was operating under the implicit assumption that unlimited fuel meant that whatever fuel you set in the ME is the fuel you initially have. Good to have Heatblur's solution documented here for future reference.

As requested. AoA test 40000_2.miz

Please reference the below screenshots for clarification of the issue: [Screenshots removed due to exceeding my 200 MB quota]

When setting an internal fuel weight below 2640 lbs for a clean aircraft in the mission editor, the aircraft will still spawn with 2640 lbs of fuel. Only settings higher than 2640 lbs in the mission editor will increase the spawn fuel of the aircraft to the selected value.

That would be appreciated. Even with your mil figures I wasn't able to find a reference to these numbers in the sources available to me or on Google. BREAK BREAK Did some extensive testing using my own bombing calculator (the in-game calculator not providing usable results) and my hypothesis is that Heatblur's F-4E gun sight automatically compensates for parallax error. Reference the attached track. With a release speed of 472 KTAS, 27° dive angle, 1917 ft ATL release altitude, -0.9° AoA and 0.9 G (expected G for a 27° dive angle is 0.89), calculated bomb range is 3121 ft with a sight angle of 66 mil (1° = 17.45 mil). Note that the actually required sight depression to superimpose the sight over the target (as shown by the left crater position after impact) is 61 mil, thus the calculated setting (which includes parallax correction) minus the correction itself. One might assume that this is due to inaccuracies in my calculator's ballistic model, but in this case it's not. Compare the data points visible in the .trk (need to activate the frame counter) with the values from my calculator: Time index KTAS/ALT (F2) KTAS/ALT (calc) 261.414 (release) 472/1932 472/1932 262.414 479/1556 479/1544 263.414 486/1149 485/1137 264.414 493/712 493/700 265.414 501/245 501/234 265.785 (impact) 505/25 504/14 Note that the lowest altitude shown in the F2 view prior to (and at) impact is 25 ft even though terrain elevation is 16 ft. I therefore assume that at impact, the bomb's actual altitude is 16 ft and the "25" is a measuring error due to an insufficient update rate of the F2 view. In conclusion, I'm assuming that the bombing calculator is correct since it provides speed and altitude results observable in the game. What I find very strange, then, is that the parallax correction must be factored OUT of the calculated sight setting to obtain the correct setting. It is as if the sight in the game "knows" the parallax correction required and automatically applies it, and if you then apply the parallax correction manually, it will have been applied twice. This is not immediately plausible for a sight which to my knowledge does not receive input from the INS in DIRECT and A/G mode. Alternatively, the above may be explained by a virtual co-pilot situated among the bombs (or at the logical location of the aircraft considered as a point in space, which seems to coincide mostly with the bombs' location) looking at the target through another sight. What this virtual pilot sees through the virtual sight is then transmitted to the cockpit for the actual pilot to view. I have noticed the same discrepancy (calculated sight setting WITHOUT parallax correction is the one that provides the correct results, not the setting WITH parallax correction) with other release parameters, but the above example was deliberately constructed to showcase the issue. I'm not necessarily asking that this issue be fixed (although that would IMO improve realism), but a confirmation that we have a sight that internally and automatically compensates for parallax (or which does not need to be compensated for parallax due to the "virtual pilot" construct above) would be helpful to preserve my sanity. parallax.trk

Issue 1 All RL 34-1 available on the internet state that the gunsight can be depressed up to 245 mils below the FRL. This is confirmed by the game manual at LCOSS - Heatblur F-4E Phantom II. In the game, while the knob can be turned so the mil depression setting shows 245, the gunsight actually only depresses up to 225 mil. Any more depression in the window will not cause the sight to depress further. Issue 2 Compare the following screenshots: Sight setting Cockpit view Tacview 90 225 (close) 225 (far) 179 In the "90" case, I would expect Tacview to show a depression of 90 / 17.45 = 5.2° or 90 / 17.78 = 5.1°. Tacview shows 5.0°. In the "225 (close)" case, I would expect Tacview to show a depression of 225 / 17.45 = 12.7° or 225 / 17.78 = 12.9. Tacview shows 12.0. In the "225 (far)" case, I would expect Tacview to show a depression of 225 / 17.45 = 12.7° or 225 / 17.78 = 12.9. Tacview shows 13.0. I am going to assume that the second discrepancy is due to parallax. These results seem to indicate that Heatblur's F-4E uses 1° = 17.78 mil, therefore adopting the NATO-mil definition. This is supported by \DCS World OpenBeta\Mods\aircraft\F-4E\UI\BombingTable\main.js, which contains "const FACTOR_DEGREE_TO_NATO_MILS = 17.777778". However, in the "179" case, Tacview shows a depression of 10.3°. 10.3 x 17.78 = 183, which is not the sight setting that will put the BTR under the sight. That setting is 178 or 179. Incidentally, calculating 10.3 x 17.45 = 180, which is not exact, but at least closer than 183. This makes me wonder whether the chosen factor is actually 1° = 17.45 mil after all. This would make sense since all RL 34-1 available on the internet assume that 1° = 17.45 mil, which seems to indicate that the RL F-4E's gun sight was also calibrated using this definition. What is Heatblur's intended degree/mil ratio? Is the gun sight calibrated to that setting throughout its entire range? Could the above slight discrepancies be related to the first issue (225 vs 245 max depression)?