Stickler

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.

The WSO's "TACAN Channel (xx0x) - [Inc]" binding will only increase the TACAN channel up to xx5x. If the channel needs to be increased beyond xx5x, the mouse has to be used to click the appropriate button. This problem does not exist in the front cockpit.

Slaved and Zero. Please reference the attached track. The behaviour occurs with the AFDS (which I assume you mean by "FD") on or off. If it is on, the aircraft will (violently) move to follow the induced heading changes. This last part is presumably realistic. heading.trk

The TACAN Channel (xx0x) - [Next] and TACAN Channel (xxx0) - [Dec]/[Inc]/[Next] keybinds are missing both for the pilot and the WSO.

The Antenna Stabilization Mode - [Down] and [Up] keybinds skip the "Nor" position.

When left-clicking on the Set Heading Control Knob with the mouse, a "pushing in" animation is triggered as expected. When keeping the left mouse button depressed, the mouse wheel can then be used to move the knob left and right, with the corresponding change in indicated heading. When releasing the left mouse button, however, the knob instantaneously moves to the 2 o'clock position. This movement to the 2 o'clock position does not coincide with a heading adjustment. Subsequent presses and releases of the left mouse button pop the knob in and out as expected, however the 2 o'clock position is "stored" as indicated by the actual knob position. Using the mouse wheel once more to change the heading with the left mouse button depressed now means that an instantaneous and large amount of heading change to the right is initiated, which must be arrested by quickly moving the mouse wheel. To get rid of the new "default" position, it is necessary to move the mouse wheel one notch left or right without depressing the knob. However, after a subsequent heading adjustment, the button pops back to the 2 o'clock position.

According to the RL flight manual, any interruption in electrical power will cause the auxiliary air doors and the speed brakes (if out) to close violently. In the game, with speed brakes and auxiliary air doors extended/open on the ground, switching the generators to OFF will only cause the auxiliary air doors to close. The speed brakes will remain extended.

According to the RL 34-1-1 the FREEZE and TARGET INSERT buttons illuminate when pressed. In the game, these buttons do not illuminate.

In multiplayer, when the pilot presses the oxygen quantity test button, the needle remains at the initial position for the WSO while it decreases for the pilot. The WSO will, however, get the Master Caution light when the front needle drops below 1 liter. This issue seems to be specific to multiplayer with two people in the jet. As a single player, when in the pilot seat and pressing the test button, then switching to the rear seat, one can observe the needle has decreased in the rear seat as well.

Various places in the game and the manual provide different nomenclature regarding CBU-1, CBU-2 and their respective submunitions, including compared to RL documentation, leading to confusion. Loadout/F6/.acmi Debriefing RL bomblet CBU-1A/A BLU-4B Bomblets BLU-3B x 27, HE BLU-4A/B, BLU-4/B CBU-2/A BLU-3 Bomblets BLU-3B x 19, HE BLU-3/B CBU-2B/A BLU-3B Bomblets BLU-3B x 22, HE BLU-3/B First, I have not found a RL reference indicating that the BLU-3 and BLU-3/B were different bomblets. Second, the game manual (Cluster Bombs - Heatblur F-4E Phantom II) states that the CBU-1, CBU-2 are "Dispensers with 19 tubes each loaded with either 27 BLU-4B, 19 BLU-3 or 22 BLU-3B HE bomblets". RL sources (reference bulletpicker.com/pdf/CBU.pdf and the below screenshots from T.O. 1F-4C-34-1-1, 15 MARCH 1970, CHANGE 9 - 26 JANUARY 1973) seem to indicate that the CBU-1A/A has 19 loaded (of 19) tubes with 509 bomblets, the CBU-2/A has 17 loaded (of 19) tubes with 360 bomblets, while the CBU-2B/A has 19 loaded (of 19 tubes) for 409 bomblets. Looking at dcs-lua-datamine/_G/weapons_table/weapons/bombs at master · Quaggles/dcs-lua-datamine · GitHub, I assume "27, 19 or 22" bomblets refers to the number of bomblets that each tube contains in the game. These numbers, multiplied with 19 tubes, result in the approximate RL bomblets for each dispenser. The reference is probably not meant to be to the exact RL number of bomblets in each tube, because that number differed between tubes. Unless someone has RL sources that indicate otherwise, I therefore suggest: to insert the slash where appropriate (e.g. "BLU-4/B" instead of "BLU-4B"), to rename the BLU-3 to "BLU-3/B", to rename the "BLU-3B" ejected from the CBU-1A/A as per the debriefing screen to "BLU-4A/B" or "BLU-4/B", to make it clear, at least in the manual, that "27, 19 or 22" bomblets refer to the number of bomblets in each tube in the game, whereas that number IRL was not the same for all tubes.

The chute opened in all cases.

For reasons I have not been able to reproduce, LUU-2B paraflares when released from the F-4E sometimes descend at a rate of around 540 ft/min, at other times at a rate of around 30 ft/min. The correct RL descent rate is 8.3 ft/s or 500 ft/min (luu_2c-b.pdf (alliantaction.org)). I have not tried other aircraft. Please find attached a track, an .acmi recording of the actual flight, and an .acmi recording of the track. Note the descent rates as follows: 30 ft/min 540 ft/min 540 ft/min 30 ft/min 540 ft/min 30 ft/min in the live flight, but 540 ft/min in the track, so there seem to be two layers of randomness at play. LUU-2B.trk LUU-2B (live).acmi LUU-2B (track).acmi

Another aspect to add here: The bombing calculator does not at this time seem to take into account the different drag of submunitions compared to their canister. Witness the CBU-87. A calculated release solution for DIRECT bombing - if taking AoA into account as above - will be highly accurate with an airburst altitude of 300 ft, but the submunitions will fall short of the calculated sight setting with an airburst altitude of 3000 ft. Without being able to categorically prove this, I believe this is the case because at 3000 ft to go, a wrong drag coefficient will have a much larger impact on calculations than with only 300 ft worth of "wrong" drag.

Thanks for the clarification regarding RADAR and WRCS BITs. Just tried the Optical Sight Test again and it does not execute from step 14 onwards (no BIT target displayed in step 18). At step 20, no range is displayed and the reticle does not slowly depress. Can you positively confirm these steps work for you? Also, at step 11, the reticle does not jump to the left as described in the text and in the picture, but down and to the left. TACAN test non-functional starting at step 4 b). See the separate thread here: Have not tried the Pave Spike BITs.

Except for the VOR/ILS test and steps 1 through 13 of the Optical Sight Test, none of the BIT checks described in the game manual starting at Built-In-Test Procedures - Heatblur F-4E Phantom II seem to work for me. Since I believe I was rather thorough in going through the checklist, would a confirmation be possible whether these are actually implemented? There is no "under construction" sign in the manual so they should be. TACAN test not working already reported separately since that was the first non-functioning BIT I noticed.

According to the manual (Emergency - Heatblur F-4E Phantom II), WSO pushing his EJECT light causes the pilot's eject light to illuminate. In the game, this does not work. This is correct behaviour as per RL manuals: I suggest to amend the manual accordingly.

Confirmed for the cold start case (did not check hot start or airstart). Regardless of the pilot's throttle movements, the WSO's throttle does not move. Additionally, any throttle movements by the WSO do not cause the physical throttle in the rear cockpit to move, but they do move the pilot's throttle and affect RPM in both cockpits.

Confirming the STBY flag issue which I happened to stumble upon as well. Unfortunately it's not just an aesthetic issue since at night this makes it almost impossible to know if the altimeter is in STBY or RESET (the "STBY" flag shows in both cases, albeit with a slightly different shade).