Stickler

While it may be true that the lack of coincidence of the markings is an issue in the real F-4 as well (I don't have a real aircraft immediately available I could use to check), it is certainly not a parallax issue. Regardless of head position, the "zero" elevation mark of the radar symbology is always at the same 1-2° positive elevation scale position. On the contrary, in the rear seat, the misalignment can be eliminated with an appropriate head position.

One might add that with the radar scanning along the horizon (elevation +- 0), the elevation bar is not coincident with the 0° mark on the elevation scale in the front cockpit.

Thanks for the clarification. Returning to the main question at hand, why does AGC gain out the contact in 100 nm and 200 nm range, but not below these settings?

Why does AGC gain out the contact in 100 nm and 200 nm range, but not below these settings? On a related note, I understand AGC to be a feature of track mode (see here). During Manual Search (e.g. when holding the first-stage trigger and not attempting lock-on with the second-stage trigger), we are not in track mode which implies that ACG is not active. I should have mentioned (but this is also visible in the track) that I do not press and hold the first-stage trigger ON the contact, but centered horizontally and vertically on the radar scope with target dead ahead.

The attached track shows a B-52 straight ahead at 45 nm. Note how its radar contact is clearly visible in MAP and BRST modes in the 50, 100 and 200 nm range scales as well as when holding the first-stage trigger in MAP mode in scales up to and including 50 nm. Conversely, the contact is not visible when in MAP mode in a greater scale than 50 nm when holding the first-stage trigger. first_stage.trk

Reference the attached track showing Jester tracking an F-5 at 100 nm range in BRST mode. This works with all aircraft and ranges, even greater than 100 nm. The problem here is that there is no contact showing on the radar at that range. Jester is magically able to track the F-5 anyway. brst_jester.trk

I originally noticed this yesterday during an MP cold-start mission but was able to recreate the issue today in my private LAN with air spawns. Currently, the Air-to-Air TACAN functionality seems to have been lost (it worked in previous versions) between two human-controlled F-4Es. Note the attached tracks, one from the each aircraft involved (the first aircraft acted as the server). With 15Y and 78Y set in the aircraft respectively, I would expect a DME readout to be available. Regardless of T/R or A/A T/R selection with 2x TACAN selected on the navigation control panel, no DME is obtained in either aircraft. I have tried various other channels and the X band with the same result (partially shown in the tracks). This is possibly related to this issue. server-20250721-101432.trkAAT-20250721-101440.trk

Unless there has been an undocumented change since 2.9.13.6818, it should be noted that Jester does not currently dispense countermeasures as set on the F/C panel, but in an apparently random fashion. See here.

Did more research on this and found some extracts from the RL manuals which indicate that the system may not be modelled completely correctly after all. First of all, if the battery could in general power the Main 28V DC Bus, the speed brakes and the aux air doors would be mentioned in the below overview: The reason why speed brakes and aux air doors are NOT in the list is likely because in case of double generator failure, the main DC line relay is deenergized, thereby disconnecting the Main 28 V DC Bus and the Essential 28 V DC Bus: Or, described in a more comprehensive way: Note that "the dc tie control circuit is designed to disconnect the two dc buses during double generator failure so that loads from the main 28 volt dc bus will not discharge the battery". Since the battery is a 24 V type, the disconnect would occur immediately (24 V is less than 24.5 + 0,5 - 0 V in all cases), regardless of why exactly the RH and LH transformer-rectifiers are no longer powered. An additional hint is provided by the below emergency procedure: If the aux air doors could be operated on battery power, the description would most likely not state that the doors are inoperative with double generator failure. It is noteworthy that a double generator failure should illuminate the DC BUS light, indicating that the buses have disconnected. Note below that the manual only speaks of the battery powering the essential dc bus "for a period of time", not of the main 28 V dc bus. If have not been able to generate a DC BUS light in the game. I suppose it should probably illuminate with both engines and/or both generators off. I have not found a definitive source stating where the light itself gets its power. Based on the below extract it may be tied directly to the Battery bus (as the FIRE and OVERHEAT and EJECT lights).

I compiled a list of modes of battle damage by having my aircraft shot at by different weapons while sitting on the ground, and then analysing and aggregating the resulting debriefing .logs with PowerQuery. Every time I run a new test a few entries get added to the list, so the attachment is very likely incomplete, but likely not by much. First of all, kudos wrt the level of damage modelling. Secondly, a few questions: Which system does "Mechanical Failure in Actuator/Actuator" refer to? What is the "Enter No Go Button/Lamp"? Laser Code? Light/DIM Knob, Light/Lamp, Light/PRESS TO TEST Button: Which light is meant? Indicator Failed, Meter/On Off Logic? Which meter? The Meter Switch on the radar panel seems to have its own failures. Power ON Light/Button? Which one is meant? Test Light? Which one is meant? There are quite a few entries for "Broken" circuit breakers. What exactly happens when a circuit breaker "breaks"? Can it no longer be actuated (pulled/reset) or is this "code" or a workaround for the electrical component protected by the circuit breaker no longer working? If the circuit breakers are not "code" as above, it seems that several electrical components do not have their own failure modes. For example, it seems a single generator cannot fail due to battle damage (and not due to ME settings either, as written above). Is this correct or did the generators just happen not to be damaged during my tests? Likewise, it seems that hydraulic failures are not on the list; I was specifically expecting the possibility of hydraulic leaks due to hydraulic lines or reservoirs being hit, more so since fuel and oil leaks seem to be modelled. Are hydraulic leaks modelled? Thirdly, a few possible typos: VHF FM radio total failure: There is not VHF radio in the F-4E. Is the AUX radio meant? AVTR "Door Clicked" and "Tape Clicked". Not sure what that means. "Flare Ligth" "Receiever Pressurised" Damage.pdf

Thanks for your explanation. Could you please provide answers to my three questions above though? With regard to the actual amount of fuel that fits into the tanks depending on density, based on a quick test, the indication shows 12150 lbs in a fully fuelled reference aircraft at sea level both in low density conditions (OAT 50°C, QNH 28.35) and high density conditions (OAT -12.4°C, QNH 31.10 inHg). This seems to contradict your statement and also the manual:

This is at the same time a question and a bug report. According to RL Dash-1, the F-4E had the following fuel capacities: null Given that the following is the fuel quantity indicator of a fully fuelled jet in-game, it appears as if 68-495 and up is intended to be modelled. Then again, the most visible feature of 68-495 was the introduction of a tank depressurization switch which is not modelled: Thus: Which fuel system is intended to be modelled? Could the tank depressurization switch be added or the fuel system be retrograded to 68-494 for consistency? Which fuel levels nominally show on Heatblur's fuel tape and fuel counter when cells 5, 6 and the wings are empty? 5348/5966 or 4862/5408? For the rounded Dash-1 figures see below.

Sample checklist pages from EP section added.

The WSO's throttle still does not move for me when I move the pilot's throttle using an axis in a multiplayer session (did not try keyboard, since this would require me to unbind my throttle axis to prevent interference, which I have no time and interest in doing). The only thing that does seem to work is that the pilot's throttle moves when the WSO moves his, but only when using the keyboard, not when using an axis.

Except for the oscillations no longer being present, no change to the above behaviour in 2.9.16.10973.

The first option is correct.

NAVAIR 01-245FDD-I, 10-14, contains the following question in the NATOPS test question bank: "111. Actuation of the warning lights test switch by the RIO will illuminate the pilot's master caution light. T I F". According to my research, neither NAVAIR 01-245FDD-I nor TO 1F-4E-1 contain a definitive answer whether the above statement is true or false. The statement that comes closest is the following: This would seem to indicate that whenever the front cockpit MASTER CAUTION light illuminates, the rear cockpit light will illuminate as well. It is not clear whether the reverse is also true, but it would appear logical if it were. In the game, actuating the warning lights test switch in the rear cockpit will illuminate the WSO's MASTER CAUTION light, but will not NOT illuminate the pilot's MASTER CAUTION light, and vice versa. Thus, the current implementation is not necessarily incorrect, but as a low priority item it might be worth checking the wiring diagrams.

Some additional information: Observe the attached tracks recorded with a reference aircraft on a standard day, no wind, with four TLADD pull-ups using different AoA and note the pitch and climb angle (pitch minus AoA) at which the horizontal bar starts to move out of view: # Timestamp Pitch AoA Climb Angle 1 38.866 34 0.6 33.4 2 32.072 34 0.4 33.6 3 25.285 36.1 2.5 33.6 4 24.952 39.2 5.3 33.9 This indicates that the criterion for the horizontal bar starting to move is neither pitch nor climb angle hitting 38°. The most consistent value seems to be the climb angle, but this is nowhere near 38°. tladd_1.trk tladd_2.trk tladd_3.trk tladd_4.trk tladd_1.acmi tladd_2.acmi tladd_3.acmi tladd_4.acmi

I can confirm the first part of the report (didn't check the second part). Looks like this bug is back.

TO 1F-4E-34-1-1, p. 1-22, states: "b. TIMED LADD (and TIMED LEVEL) - Operate voltage is applied to the PULLUP timer; then to RELEASE timer at the termination of the PULL UP timer countdown. For the LADD mode, the PULL UP timer must be set on some value to get the ADI pullup schedule; the RELEASE timer must be set to develop a bomb release signal." TO 1F-4C-34-1-1, p. 1-122A (the F-4E part), states: "Voltage is applied only to the pullup timer in the LOFT or TIMED O/S modes. In the TIMED LEVEL and TIMED LADD mode, both timer circuits are energized, providing the pullup timer is not set on zero. In the TIMED LEVEL and TIMED LADD modes, the release timer must be set to obtain the release signal. (The release timer may be set on zero for the LOFT and O/S modes.) Completion of the pullup timer energizes relays which provide the various pullup signals and the pullup flight path program." In the game, you will obtain a TL release with the release timer set to zero; in fact, if the pull-up timer is also zero, the bomb release button acts as a pickle button (instantaneous release). Based on the above extracts, it is unclear whether a release timer > 0 was required to obtain weapons release. This is therefore not a bug report but a recommendation to check your wiring diagrams or ask for SME input.

It‘s a bug. Please reference

As per the title. Conversely, the aircraft spawns airborne, in takeoff position or during hot ground starts with the altimeter properly RESET.

As per the title. This is not a bug, but an inconvenience for multiplayer where crews use UHF to communicate with ATC and AUX for intraflight communications using the COMM CMD switching technique. In that case, it is not possible to monitor both frequencies simultaneously before INS alignment is complete unless manually switching the R/C radio ON. It should be noted that according to the RL checklists available, switching on the communication and navigation equipment is at or near the top of the BEFORE TAXIING (REAR COCKPIT) checklist, specifically before the Radar and WRCS bit checks which potentially take a significant amount of time. I can see no technical reason why RL WSOs would have delayed switching on their radio until after completing INS alignment.

Observe the attached tracks and .acmis starting from the same position and parameters. Track "DT" (Dive Toss): As per the bombing calculator, I enter 1.04 as the CB, subsequently lock a harbour tug in AIR-GND mode, and pickle at the same location while still in active pause. Approaching the target as precisely as possible at the planned parameters, the bomb releases at at plan range of 5117 ft from the target, resulting in a 3783 ft long bomb. Track "DL" (Dive Laydown): As per the bombing calculator, I enter 9216 ft as the release range, subsequently lock a harbour tug in AIR-GND mode and pickle at the same location while still in active pause. Approaching the target as precisely as possible at the planned parameters, the bomb releases at at plan range of 8980 ft from the target (thus 236 ft closer than set). Evaluation: I was able to trace back the "closer than planned" release in DL mode to the range bar not tracking the leading edge of the target return (which is where the actual target is located), but the trailing edge, in this post. This error can be easily overcome by adjusting the release range or setting a release advance. Generally, for DL, the range bar's position seems to be the only relevant factor in determining the range to target entered into the WRCS. As can be seen from the "DT" track, in DT, the range bar's position does not seem to determine, or at least is not the only factor determining, the range entered into the WRCS. I was able to exclude a faulty CB as the reason for the DT miss: When locking the tug from a dive, pickling with the tug underneath the pipper and subsequently levelling off to release at 500 KTAS and 2000 ft, the bombs hit (no track uploaded since this behaviour is as expected). Thus, in DT, having the target under the pipper at pickle and the range bar at the corresponding location ensures a hit even for the Dive Level variant. However, moving the range bar a significant distance away from the main beam clutter, even if the target was under the pipper at pickle (and thus utilizing a grazing angle within the 10° DT limit), will cause the target to be missed. What this "significant distance" is, and by how much the target is missed, is unpredictable (at least I could not identify a clear logic); the actual target hit will neither be the center of the pipper not the place marked by the range bars if the threshold of significance it exceeded. Please reference this post for additional information. Based on even further testing, everything described above is valid for releases from single-stage trigger or from lock-on. Bombing table: dtdl-dl.trk dtdl-dt.trk dl.acmi dt.acmi

For everyone else's benefit, I think I figured it out. IAS: No discrepancy between game and Tacview since IAS is directly imported. The only problem is that IAS is misnamed and should actually be EAS. TAS: For human players, "TS" in-game is equal to "TAS" in Tacview with the caveat that "TS" is an instantaneous value whereas "TAS" is averaged over the last second. Conversely, if winds are present, "TAS" in Tacview/"TS" in the game are unequal to TAS in the cockpit because Tacview's "TAS" and the in-game "TS" are the distance the aircraft has travelled between two 3-dimensional coordinates in DCS's coordinate space divided by the time required to do so, whereas "TAS" in the cockpit is derived from IAS by correcting for pressure and temperature, thereby indirectly obtaining the distance travelled through the air mass in a specific time. In headwind, the aircraft will travel less absolute distance in DCS's coordinate space in the same amount of time than without wind (resulting in a lower calculated "TAS"), whereas the wind has no influence on the distance travelled by the aircraft through the airmass surrounding it. Note that due to this logic, with the same headwind and a 90° dive angle, or with perfect crosswind, cockpit TAS and Tacview TAS/"TS" are virtually the same whereas the difference is at its maximum in straight-and-level flight with perfect head or tailwind. Interestingly, for AI, "TS" is always their actual TAS regardless of wind, but their "TAS" in Tacview will be off in the same manner as for humans. GS: GS in-game is equal to GS in Tacview with the caveat that it is an instantaneous value in-game whereas it is averaged over the last second in Tacview, even though they are obtained in a different way: In-cockpit GS is obtained from TAS by factoring in wind (drift) and dive/climb angle, while Tacview's GS is the distance travelled between two 2-dimensional (X/Y) coordinates in DCS's coordinate space per unit of time. CAS: Tacview's "CAS" will only match cockpit IAS/CAS on a standard day and with the caveat that for DCS, Tacview calculates CAS from TAS. If TAS is incorrect due to winds, so will be CAS. I have no idea why the Tacview values I posted above were so grossly off. I wasn't able to reproduce this issue.