Stickler

Based on several videos on YouTube (not linking them individually because there are quite a few, see here), the F-4's fuselage lights do not actually seem to cast any significant amount of light onto the ground beneath the aircraft. Specifically, in none of the videos, even those from night flying, can any such casting be observed. In the game, ground lighting by the fuselage lights is easily visible even during broad daylight. Secondly, the red anti-collision light on the tail does seem to have a significant self-illuminating effect. See, for example, the following video (link is time-indexed): This video also shows that the fuselage lights illuminate an opened front gear door, which is currently not the case in the game. I have found that flying night close formation in the F-4E in a moonless night is almost impossible because neither one's anti-collision light nor the wing tip lights illuminate the other aircraft, and the other aircraft's anti-collision light does not illuminate its own jet. With regard to the wing tip lights, none of the videos shows that they were strong enough to illuminate another jet as they are in some other jets and I have not found anything in RL documentation that would indicate they were, but in case your SMEs were to confirm the contrary, said brightness might be increased as well. Otherwise, my suggestion would be to keep them as they are.

I have attempted a WRCS/LABS delivery as per the manual, specifically the LADD variant as depicted in the schematic at Lofting & Tossing - Heatblur F-4E Phantom II. While things mostly work as advertised, as per the manual, one would expect the activate tone (0.38 sec beep) to sound at Release Range, followed by (in my mission) a 3 second pullup timer accompanied by the pullup light, followed by the pullup light extinguishing at T1 = 0 and the steady tone coming on. In the game (see the attached track), there is no 0.38 sec activate tone. Everything else functions as described above. I have successfully accomplished a WRCS/LABS (LOFT) delivery as well, and there is no 0.38 sec tone either. loft_T.trk

Thanks for the explanation! To make sure I'm getting this correctly: In the ME's fault list there are currently no electrical failures (e.g. single generator failure with bus tie open) or hydraulical failures (e.g., utility system failure). I understand that setting "random system failures" will therefore never cause these failures. However, is it currently possible that battle damage or extreme mishandling of the jet might cause them?

The mission editor provides the option to set up various system failures. When random system failures are enabled in the game options or due to aircraft damage, are the possible resulting failures a) limited to the failures that might also be set in the mission editor, or could b) additional failures possibly occur? If b), are these additional failures limited in any way (if so, could the developers share a list of these additional possible failures?), or, especially given the F-4's component-based system modelling, do these failures cover all systems/components modelled in the jet?

In all loft sub-modes that feature a level portion (T1), the flight director does not keep the aircraft level but commands a 2 G climb. To be sure, this is NOT after pull-up timer expiration and during the pull-up phase (T2), but before.

I am not sure if this issue was introduced in 2.9.8.1214, however I haven't noticed it before: When doing a stored heading or BATH alignment and switching the INS power knob to ALIGN while the HEAT light is still illuminated, a later INS refinement/realignment on the ground fails in the sense that any accumulated drift as indicated by the GROUND SPEED dial showing a value > 0 when the aircraft is stationary is NOT reset. The erroneous GROUND SPEED value will instead persist during and after realignment. In stored heading, the INS align lamp will blink after a short period in ALIGN even though the ground speed is not reset to zero. In BATH and ALIGN, the INS align lamp will never reach the blinking state but remain steady only (tested with a 15 minute realignment period). This does not occur with a gyrocompass alignment or if waiting for the HEAT light to extinguish before switching to ALIGN in case of a stored heading alignment. This is especially problematic with Jester and when doing a stored heading alignment since he will report a successful refinement even though the ground speed indication (and probably the entire INS) is still erroneous. This issue also causes (non-heated) stored heading and BATH alignments to lose a lot of their operational value since a later refinement (say in the last chance) is not possible.

Would it be possible to harmonize the AVTR minutes counter and UHF repeater brightness in the rear seat? At the moment, with brightness fully down, the repeater is not legible while the minutes counter is easily readable; increasing the brightness to maximum makes the repeater readable while the minutes counter subjectively barely increases in brightness. Of course, if the current implementation is realistic by all means leave it as it is.

The RL emergency procedure for a hard-over rudder describes a deployment of the drag chute on short final as the recommended procedure in case an approach-end arresting gear is not available. Specifically, the included table and the procedure imply that the aircraft remains flyable at approximately 90% RPM with gear down, full flaps, and 178 KIAS at a gross weight of 35,000 pounds when deploying the drag chute 1.5 nm from touchdown. In the game, when deploying the drag chute at the above parameters, the aircraft requires full back stick, full back trim and full afterburner to keep flying and not nose-dive into the ground. Maintaining 178 KIAS is not possible. I realize that adjusting chute drag/dynamics to cater for this emergency that (according to the ME's fault list) cannot occur in the game may have unintended side effects for the 99.999% of cases where the drag chute is deployed either to get out of a spin or after landing, however if an easy fix is possible this would further increase realism.

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