Stickler

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)?

As title. These sounds include crew chief responses via intercom and the RWR.

I am looking at a Phantom piloted by me without a human WSO in the F2 view, standing next to a Phantom controlled by another human pilot without a human WSO. Neither I nor the human pilot of the other F-4E can observe the other aircraft's lights in FLASH, but everyone can observe their own lights in FLASH.

The exterior lights FLASH setting is not visible for other clients in multiplayer. When lights are set to FLASH, they instead appear as STEADY to other players even though they appear as FLASH from the perspective of the player setting FLASH. I have not noticed this behaviour in previous versions of the module, but I haven't specifically looked for it, either.

EDIT: Found the reason for the below. As per Formulas | Tacview Wiki | Fandom, Tacview exports GS/VS/TAS as the rolling average over the last second. The exported values therefore lag the actual value. --- I have noticed what seems to be a discrepancy in speed export. Reference the following data recordings from a drop of a Mk-82 Snakeye in High Drag mode on a standard day, no wind. The following orange table shows data from the telemetry .csv. Note (marked in yellow) that the KTAS exported by Tacview at specific timestamps (Unix time) does not match the TS as indicated in the F2 view at the same time stamps (screenshots and the blue table). As soon as GS and VS are available, I used Pythagoras to calculate KTAS (second column in blue table) to verify that KTAS data export is congruent with other exported data. Note also that ASL export matches the F2 data exactly, so the issue seems to be specific to (true air) speed. The discrepancy seems to be largest around the time when the Snakeye retarder blades deploy (0.2 seconds after release) and the bomb experiences an extreme rate of drag increase. Can anything be done to increase accuracy of the export? EDIT: Could there be an option to set the length of the rolling average period?

According to the RL Dash-1, the drag index of rocket pods depends significantly on whether the tail and/or nose cones are present and whether the pods are empty or full. Based on performance testing, the game currently seems to assume that independently of the presence of the nose/tail cones and load, LAU-3/A pods have a drag index corresponding to their full, no nose/tail cone state (12.2 or 13.5). The drag-independency of the pod configuration can be most easily tested by flying straight and level at military power and determining maximum aircraft speed, then partially firing the rockets. Expected behaviour is a decrease in speed since drag just increased significantly. In the game, no apparent drag change occurs. For in-game LAU-68 pods which do not come with a nose or tail cone, the same non-increase of drag after firing is present, however the pods generally seem to have a larger in-game drag index than the RL pods. A full LAU-68 without nose and tail cone should have a drag index of 5.4, however actual performance data rather matches the 12.2 or 13.5 drag index of a full LAU-3 without nose/tail cone. The fact that e.g. {HB_F4E_LAU-68_MK1_3x}.lua and {HB_F4E_LAU-3_MK1_3x}.lua both have a Cx_pil of 0.00683453125 seems to support the assumption that the LAU-68 drag is currently too high and matches the LAU-3 drag. I'm assuming that rocket pod drag cannot be made load-dependent due to DCS limitations, however I do recommend to decrease LAU-68 drag so game performance matches the books.

I cannot seem to be able to find documentation about what the "γ" (small gamma) variable in Tacview telemetry is, except that the 1.9.1. change log states that "Path α has been renamed to γ to match NASA documentation". It seems to mostly match the aircraft's flight path as indicated by the flight path marker (FPM) in the HUD view, but not always, especially during high-G maneuvers during which γ lags behind the FPM (see post below): So, what exactly is γ and, more importantly, could it be made exportable?

The RL -1 delineates various methods of updating ownship position. Methods b and c in the screenshot below include a direct adjustment of the present position counters. In the game, the present position counters can only be directly and permanently adjusted in Air Data Mode (INS off). When attempting to update them in INS mode either airborne or on the ground (to include in a stationary position), the counters will revert to the aircraft calculated present position as soon as the position update switch is moved out of the SET position. While other text on the same page of the RL manual (which is also replicated in the game manual) seems to imply that updating the present position by rotating the present position counter knobs is only possible in Air Data Mode, it does not seem plausible (and it is not written either) that updating methods b and c above could only be used in Air Data Mode in the real jet. Without being able to prove my interpretation is correct due to a lack of available documentation, I suppose that in INS mode, the present position counters will not continue updating "behind the scenes" while in SET, but position updates will stop entirely until SET is released, then resume. The sentence "Therefore, the switch movement from SET to FIX must be a smooth continuous movement in order to prevent an unwanted interval [emphasis added] of NORMAL operation" (slightly differently worded in the game manual) also seems to indicate that if you accidently leave the switch in NORM for longer than 0.5 seconds, the counters will not completely revert to the aircraft-calculated position, but simply continue updating until the NORM position is left for the FIX position.

When entering the cockpit, having external power connected, switching on the engine master switches, setting generators to EXT ON and switching on the Instrument Ground Power switch, I found three cases of which only case 1 produces the expected result. 1) Without a human WSO in the jet, leave the rear TACAN in OFF and switch the front TACAN to T/R. The NAV CMD light will illuminate in REC and T/R. TACAN warmup will complete in approximately 2 minutes. Subsequently switching the rear TACAN to T/R does not produce any unexpected results. 2) As 1), but instead of switching on the front TACAN, leave it in OFF and switch the rear TACAN to T/R. No NAV CMD light illuminates in the rear (and front) cockpit, neither in REC nor in T/R. TACAN warmup does not take place. Switch the front TACAN to REC (or T/R). Note that the front NAV CMD light illuminates both in REC and T/R. Warmup completes in about 2 minutes. 3) With a human WSO in the jet, switch the front TACAN to T/R. Observe that the front NAV CMD light will illuminate only in REC, not in T/R. Switch the rear TACAN to T/R. The rear NAV CMD light will not illuminate, neither in REC nor in T/R. TACAN warmup does not take place. To initiate warmup, the front TACAN has to be recycled to OFF, then back to REC (or T/R). To avoid the issue altogether, human WSOs have to switch their TACAN to REC (or T/R) before the pilot. Waiting for the completion of warm-up before switching on the front TACAN is not required.