Stickler

Reference the below screenshot from the RL Dash-1. In the game, regardless of the position of the armament safety override button, both selective and emergency jettison can be accomplished after the emergency extension gear handle in the rear cockpit has been pulled.

Simple question: Does the condition and wear and tear of the aircraft have any influence on the amount of INS drift accumulated during a specific period of time given identical aircraft movement and external conditions? Or put another way, do different non-reference aircraft accumulate INS drift at a different rate?

The safety pin which is visibly installed to secure the arresting hook when the crew removes their helmets does not prevent the arresting hook from being lowered.

Impressive. Working as intended then.

Title says it all.

In the attached track, the aircraft's "Initial Point" as shown on the kneeboard is 36° 59' N, 35° 24' E, whereas the actual position of the aircraft at spawn is N37°00.352 E035°26.307. This actual position is also the position initially set in the aircraft position dials. If one were to use the kneeboard-provided coordinates for alignment, an error would be introduced into the INS. I have not checked if this error occurs always or only under specific conditions. If this discrepancy is not intentional, I recommend to have the kneeboard-provided coordinates match the actual coordinates to prevent confusion. kneeboardcoords.trk

Idea: Would it be possible to repurpose this command to force Jester the start the alignment routine (what alignment do you want, etc.)? Three use cases come to mind: In-flight alignment. You want Jester to start alignment before the Jet is on internal power (possibly with the intent to realign on internal power later on). You want Jester to realign the INS in the last chance as was apparently common practice IRL.

Sounds like a plan. I of course wrote carelessly: It is not about "getting" a radar contact, but about "seeing" it to maintain positional SA on your preceding flight members. A smaller radar display range will simply help with that, since not everyone will be mushed together at the bottom of the screen. Managed to fly a pretty good radar trail departure by disabling Jester, see the attached track. It is noteworthy that when re-enabling Jester at 12:06:25 with a crystal clear radar picture of just my flight lead ahead and hardly any clutter, Jester immediately switches to the 50 nm scale, losing the contact. He subsequently only spots the traffic visually, but not on the radar until the end of the track. The method shown is, of course, only a workaround. If one were able to use focus for SA (implying that Jester somehow "knows" what your intentions are and sets the radar so he at least has a chance to get contacts on your flight members quickly), I would much prefer this over the current need for micromanagement. The other option being boresight which seems to work quite well, but which will only allow you to maintain SA on your immediate predecessor. radartrail.trk

There are keybinds for "Target Latitude - [Dec]/[Inc]" and "Target Longitude - [Dec]/[Inc]". There are no keybinds for "Set Position (N/S Lat) (push to turn)" and "Set Position (E/W Long) (push to turn)", the knobs forward of the Target Lat/Long knobs.

Would it be possible to add keybinds for modifying the aircraft's present position, such as already exist for TGT1?

While the F-4 as simulated by Heatblur does not have a parking brake and the Emergency Wheel Brake will not stop the drift, your input did cause me to do some more investigating. I am pretty sure the problem has to do with the slope of the surface one is standing on. The last chance in the track has such a slope. I tested this by reversing the parking position. Even with 30 knots of tailwind, wheel chocks applied, full military power and a gross weight above limit, the aircraft will very slowly roll downslope, in this case, backward. The funny thing is: In this scenario, setting the wheel chocks will actually ACCELERATE the backward drift. The only way I have found to completely stop the drift is to hold the regular wheel brakes depressed. If one does not want to do that, a workaround is to bind a toggle switch to the wheel brakes keyboard command or a custom joystick button.

As stated, I would like to use the 5 or 10 nm ranges for radar trail procedures. For example, during a radar trail departure, Jester does not build SA on preceding aircraft quickly enough to use the focus feature (by the time the friendly aircraft show up on the wheel, you are most likely already out of the weather). If an option to manually set 5 or 10 nm were available, one would have a much better chance of actually getting a radar contact. This is also a factor during radar trail recoveries where you will initially be too close to your flight lead for him to show up on your radar. Upon flight split, it would again take too long for the radar contact to become available in the Jester wheel to effectively use the focus feature. Currently, to fly radar trails without a human WSO, one has to manually set 5 or 10 nm in the back seat and disable Jester to prevent him from reverting back to 25/50 nm.

Currently, there are keybinds and Jester wheel commands to set radar range to 50 and 25 nm. For radar trail procedures, these settings are too high. I therefore recommend to add additional keybinds and Jester wheel commands for 10 and 5 nm.

Found a workaround. If you assign a modifier to the axis commands in question - for example a joystick button configured as a switch - that causes the axis to only be active if the switch is ON, Jester will lock the ground just fine.

Neat, thanks!

It is well documented and implemented in the game that the F-4E exhibits a significant amount of INS drift even under optimum conditions, both when flying with a human WSO and when flying with Jester. With a human WSO, there are several options available to fix the INS. What is the recommended practice to fix the INS without a human WSO, given that there is no way to command Jester to fix the INS, there are no keybinds for updating the present position dials to the coordinates of the fix point, and the pilot is not even able to see said dials? The only method I have found is to hop into the back seat and fix the INS from there, which under anything but peacetime single-ship conditions is extremely uncomfortable, not to say unfeasible.

In the attached track, note how I taxi into the last chance area and attempt to come to a complete stop. It's only that the aircraft does not stop, but continues to drift forward even at idle power. If not installing wheel chocks, the aircraft will drift forward indefinitely. Even having wheel chocks installed will only cause the aircraft to come to a complete stop after approximately 3 minutes. The mission has 15 knots of tailwind in the last chance. However, the effect occurs also without any wind. The only difference seems to be that the stronger the wind is, the longer it takes for the aircraft to stop after installing chocks. Using time acceleration during playback is strongly recommended to more easily see the problem. This would be merely an aesthetic one if it didn't prevent realignment/break the INS when attempting to realign in the last chance without chocks installed, or forces one to wait up to several minutes until the aircraft is REALLY stationary before starting the realignment, wasting valuable time. chocks.trk

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.