Stickler

Observe the illumination of an F-4E with fully bright external lights in 2.9.10.4160. Standard day, clear skies, new moon, Gamma 2, Volumetric Lights on. Note how it is essentially impossible to spot the lights of the jet without labels unless flying immediately next to it. This issue is not limited to viewing one's own aircraft in F2 view but occurs in the same way when approaching another human-controlled F-4E with bright lighting. 1.0 nm 0.5 nm 0.1 nm Close

Please find attached a working track (if no time acceleration is selected) that showcases the crew chief not reporting "flaps up" immediately after the FC check. Reference time 08:04:24 when the flaps switch is moved to the "up" position and 08:05:18 when the crew chief elects to report the flaps up. Incidentally, the track also contains Jester asking for the requested type of alignment twice at 08:00:28 and 08:00:34 even though this bug was reported as fixed. noflapsup.trk

Run the attached mission created fresh in 2.9.10.4160 in single-player. Upon spawn, the navigation points set in the mission editor will not be present in the Jester wheel ("No points in flight plan"). I cannot seem to recall this issue in any previous versions of the module. jesterrepeat.miz

I was finally able to consistently reproduce the bug five times following the below steps. The problem is, as Volator already reported, that the issue does NOT occur in the associated track(s). Put the Caucasus.lua into the C:\Users\XXX\Saved Games\DCS.openbeta\Config\RouteToolPresets\ folder, overwriting the old file, if present. Load the attached .miz in the ME. "Launch Multiplayer Server" from the "Flight" menu. Take the F-4E slot on the Blue side and load the "Jester_Repeat" preset. Spawn Go to the back seat and set the pull-up and release timers to 300 (30.0) seconds. Return to the front seat, select A/G sight, stations 2 and 8, "BOMBS", Master Arm HOT, and TL mode. Steer straight ahead to the railroad bridge (VIP) at 500 KTAS. When directly over the bridge, hold the bomb release button to start the pullup timer. Do not wait for Jester to report the fix. Once Jester is done with his "INS updated" call, the speed callout loop starts. Caucasus.lua server-20241215-204029.trk jesterrepeat.miz

Upon further reading, the pullup light is actually supposed to illuminate during all weapon release modes as long as a weapon release signal is generated. In DIRECT mode, this would be while the bomb release button is depressed. In modes with an automatic release, this would be from the moment the system generates the release signal until the bomb release button is released. The light not illuminating in LAYDOWN is therefore after all not a problem with LAYDOWN implementation which would be reasonable to have demonstrated with a track, but a lack of implementation in all modes, which is most likely a design choice or oversight instead of a bug.

For Laydown, the aircraft's weight should not affect the sight setting at all since the reticle image is pitch stabilized with reference to the horizontal plane of the inertial platform. AoA, which is dependent on the aircraft's weight, therefore has no effect on the correct sight setting. This is correctly implemented in the game but incorrectly implemented in the bombing calculator.

Observe the attached track and .acmi of an RIP OFFSET attack against a harbor tug with a significant crosswind from the right. With the aircraft more or less on track towards the target, upon precise RIP target insert, the roll tabs (and ADI flight director, not visible in track but I checked afterwards) command a turn into the wind, causing a significant miss since the amount of turn commanded significantly exceeds the required wind correction. No offset distance is set. On the other hand, the PPI azimuth seems to remain unaffected by the erroneous shift and can be zeroed to overfly the target, as expected (not shown in track, tested afterwards). [EDIT: This might not actually be the case, see the thread linked below]. This does not seem to occur with zero wind. VIP offset with actual distances set is apparently unaffected [EDIT: VIP offset is affected after all, see the thread linked below], however the system will erroneously steer you to a point upwind of the target when using an RIP different from the target. The same issue occurs in TGT FIND and all LABS/WRCS and DIRECT/WRCS modes (using the TGT FIND/Activate switches in the back seat) with an RIP. I have found no indications in the RL 34-1-1 or Heatblur's manual that would explain why the ADI and roll tabs command a turn away from the target and into the wind. This issue is likely related to the following: offsetwindmiss.trk Tacview-20241130-205127-DCS-offsetwindmiss.trk.zip.acmi

According to the RL -34-1-1, in Laydown mode, the pullup light will illuminate to indicate bomb release and will go out when the bomb button is released. In the game, the pullup light does not illuminate.

Affirm, without Jester, all hand-dialed in the back seat.

Reference the attached track of a Loft release (non-WRCS). I manually set the Low Angle to 30° and the pull-up timer to 12 seconds. The actual release occurs at about 25° flight path angle.* This is entirely repeatable according to my tests: Simply "take control" after the parameters are set and attempt a refly. The release consistently occurs about 5° lower than planned. Note that this is with a reference aircraft. I had noticed this behaviour very rarely before but I was never able to capture a track. While 100% reproducible once you have a track, I have not found a way to reproduce the bug itself. *Note that Heatblur have made the design choice to have the weapons nominally release at a specific climb instead of pitch angle, whereas the RL 34-1-1 seems to indicate that the release angle settings in the back seat refer to pitch and not release angle. I did consider reporting this as a separate bug, however having a climb angle as the release criterion does simplify ballistic calculations considering - to my knowledge - only a limited amount of RL gyro settings including AoA are available and these do not match in-game performance. wrongangle.trk

According to the game manual (which reflects the RL 34-1-1), during ARBCS weapons deliveries, at pull-up timer completion, the reticle light turns OFF, as release pitch angle is attained, the pull-up light and the reticle light turn ON. In the game, neither of the above occur. In some versions of the 34-1-1, it is not clear what the "reticle light" actually is, but it becomes clear that the sight reticle is meant based on the following extract: The RL 34-1-1 also contains the below note, which expands on the above: In the game, releasing the bomb button before bomb release does not energize any lockout. Instead, the T1 timer can be restarted immediately without any further action by pressing the bomb button once more. Letting go of the bomb button should also energize the reticle flasher relay: In the game, reticle flashing does not occur in case b. above. I haven't tested, but I strongly suspect it does not occur in either of the above cases.

According to Lofting & Tossing - Heatblur F-4E Phantom II, in TLADD mode, at timeout of the pull-up timer, the horizontal ADI needle will transition into show [sic] deviation from the intended 3.5 G pitch angle, and then stabilize once 45 degrees nose up pitch is attained. According to all RL 34-1-1 I have found, the following is true: In the game, the horizontal needle will initially provide a 3.5G pull-up in 1.5 seconds to 37° pitch (which is approximately 38° pitch, so far so good), but then, instead of stabilizing at 45° (or 38°, or any other angle) command a 6.0 G pull-up until the release timer runs out. Based on the extract I posted above, it would seem logical that the horizontal bar is removed from view or remains static when pitch angle hits 38°, even though the manual does not explicitly state this (the "maintain pullup acceleration", however, seems to imply that the system would stop rather than increase commanded pullup acceleration at 38°). Neither did I find any mention of the needle stabilizing at 45° IRL, other than several accounts (also of other aircraft of the time) relating that a LADD was performed at 45° of pitch. A possible reason for 38° instead of 45° being the final commanded pitch angle is that at the expected (high) TLADD release altitudes and (low) speeds, a 38° pitch angle at release might yield a higher bomb range than 45°. A final pitch of 45° is possible, however, since this should still result in a flight path angle of less (and therefore better for range) than 45° IRL. Looking at the schematic at the above URL, it is not entirely clear whether a commanded change from 3.5 G to 6.0 G occured during pull-up, however if it did occur, I cannot think of a possible reason. The depicted aircraft also has a flight path angle of 60° instead of 45° at bomb release. The latter is not entirely implausible since the closer the flight path angle to 90° at release at a given speed, the longer the TOF, which would be of interest to get maximum separation until detonation. TLDR: Several conflicting sources. Is there a bug in TLADD flight director implementation?

Observe the attached screenshots and tracks. With the following loadout (1), the maximum KTAS at approximately sea level on a standard day in military power is 538. Conversely, the following loadout (2) yields a maximum KTAS of 563, which implies it has significantly less drag than loadout (1) in the game. This cannot be correct since loadout (1) IRL has a drag index of 61, while loadout (2) has a drag index of 94.6. Loadout (2) having more drag is also visually obvious. Note that the loadouts are identical except that the BDU-33 in loadout (1) have been replaced with a smaller number of CBU-52 in loadout (2), and that loadout (2) has a TER attached to the SWA on stations 2 and 8. This leads me to believe that the culprit must be the BDU-33, CBU-52 or TER, with each or a specific combination of them having incorrectly modelled drag indices. I would tend to surmise that loadout (1) has too much drag in-game rather than loadout (2) having too little since the RL T.O. 1F-4C-34-1-1 features ballistic tables for 8-bomb CBU-52 ripple releases with 500, 550 and 600 KTAS run-in speeds, which indicates that reaching 563 KTAS with 8 CBU-52s in military power was probably possible. cbu-52.trk bdu-33.trk

Thanks for checking. IIRC, the course arrow and ADI needles are working correctly. The bug report is about the heading marker not pointing to the target. The difference may be more easily visible with a WRCS target not along the same bearing as the nav computer target and/or with a strong crosswind.

I just repeated the test without any peripherals except the keyboard and mouse connected to the pilot's computer (no peripherals except an integrated keyboard and a mouse were connected to the WSO's computer/laptop to begin with), and the result was the same as shown in the above tracks.

According to this post, the option to force-activate Jester while a human WSO is in the plane is meant to be used for WSOs to sit by and watch while Jester does the job. Currently, this option does not work correctly, or at least having a human WSO in the plane causes Jester not to be able to perform all his usual functions. Reference the attached tracks of the same mission, one from the pilot's and one from the WSO's perspective. Without a human WSO, I can have Jester select different waypoints and have him automatically select the appropriate radar mode for DT. After I have joined on my other PC, and despite the "Force" Jester option being selected by the pilot, Jester no longer changes waypoints even though acknowledging that he did. Neither does Jester select the appropriate radar mode for DT. One can instead observe him moving the cursors up and down aimlessly in the default radar mode. The issue also occurs if the WSO selects the "Force" option as well. Note that I have not bound any axes on the WSO's PC and all keyboard bindings are default, so there can be no input interference. No intentional inputs were being made in the WSO's cockpit during recording. pilot.trk wso.trk

According to the RL -34-1-1, in OFFSET and TGT FIND, the Heading Marker indicates the magnetic heading to the target as computed by the nav computer and controlled by NS/EW target distance counter after TGT INSERT is pressed, the HSI TGT Mode Light illuminates when the TGT INSERT button is pushed on (if the instrument lights are ON). In the game, after TGT INSERT is pressed, the Heading Marker continues to point toward the target selected on the navigation computer, the HSI TGT Mode Light does not illuminate.

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.