Bestandskraft

Both F-14A and -B AI's break with unswept wings in 2.7.5.10869.

Interesting points, it appears I was wrong. I initially stumbled upon this issue due to the Takeoff Checklist where the pilot confirms that the spoiler module is ON. When performing a maneuver flaps takeoff, the module is then actually OFF during takeoff and switches on with weight-off-wheels. I find it odd that is is neither mentioned as a note to the Takeoff Checklist nor to the section describing a maneuvering takeoff, then again the fact that spoiler effectiveness can be increased during a no-flap/maneuver flap takeoff abort by lowering the flaps is mentioned in the Aborted Takeoff section. In any case, I'm happy and this report may be disregarded.

I cannot categorically prove that this is a bug since the NATOPS flight manuals are not totally clear on this, but I believe the outboard spoiler module should be energized and pressurized (SPOIL ON) when the maneuver flaps are extended. Right now, the module is deenergized with only maneuver flaps extended. Reasoning: The outboard spoilers are driven by the outboard spoiler module. If this is deenergized, the outboard spoilers therefore should not move or at least droop down. In the game, when on the ground with ANTI-SKID/SPOILER BK ON or BOTH, the outboard spoilers will extend with the flaps slightly extended with the flap handle; in this case, the outboard spoiler module energizes (SPOIL ON). When leaving the flaps in UP but moving the maneuver flaps to 10° (i.e. beyond the point where the outboard spoilers deploy when using the flap handle), the outboard spoilers remain retracted and the spoiler module shows OFF (if it was previously ON, there is a short delay before the indication changes). The closest thing to a proof for my position is para 11.9.4. in NATOPS (it seems to be consistently numbered for all publicly available versions) which states that for in-flight refueling in HIGH mode, "[f]laps should be selected to 10° with the maneuver flap thumbwheel, which still functions normally with outboard spoiler module power". IMHO, if the maneuver flaps work normally with outboard spoiler module power, they can do so only because the outboard spoiler module is ON with the maneuver flaps extended.

This post contains several tracks and detailed instructions on how to reproduce the bug.

Unfortunately, the bug still exists in 2.5.6.59626. Good news is that I have finally been able to reproduce it. As far as I can tell, the bug occurs: only in multiplayer, only as a client, definitely on the carrier, and possibly on airfields (didn't test the latter), only when spawning from ramp. Steps to reproduce: create a mission where spawn time is after mission start time, fresh start DCS on server and client, start server, connect as client and join into the first F-14, click "Briefing" and "Fly" before spawn time (spawn time is 45 seconds after mission start time in the attached example), observe the "Your Flight is Delayed to Start" message (the bug also occurs when a different aircraft is preventing your spawn temporarily, setting spawn time after mission start time just is the easiest way to reproduce the bug), hit "ESC", "Select Role", select the second F-14, hit "Briefing" and "Fly", wait for the spawn, do an automatic startup (the bug occurs with a manual startup as well, however with an automatic startup we exclude non-standardized player input), release the parking brake, advance throttles, note that it takes approximately 92% RPM (95% RPM in the F2 view) to break free of your parking position (without the bug it only takes approximately 80% RPM (85% in the F2 view)) to start rolling, taxi to the CAT and launch, note an AoA spike to approximately 27° (25° in F2) during launch (without the bug, max AoA is 15° (14° in the F2 view)), probably indicating an out-of-limits aft CG location, note a sluggish acceleration to 300 KIAS. I have attached 4 tracks to illustrate the problem; 2 server tracks and 2 client tracks. The bugged client track immediately desyncs after brake release since during replay the aircraft is non-bugged, therefore the excessive power setting necessary to break free of the parking position translates to the aircraft running over the edge of the deck. Note that the spawn delay by itself it not the cause of the problem, since when simply waiting until your aircraft spawns without selecting a different slot, the bug does not occur. server-20210127-131858_without_bug.trk overweightbug-20210127-131809_without_bug.trk server-20210127-102604_with_bug.trk overweightbug-20210127-102511_with_bug.trk

When using triggers to generate map markers to make e.g. navigation fixes defined as trigger zones selectable in the Jester wheel, not all programmed map markers will show in the wheel. I have tried for several hours to reverse engineer the exact logic behind which markers show up on the wheel and which don't, to no avail. From the attached screenshot it appears that every other marker is not displayed, but my tests have shown that the problem is more complicated than that (e.g., there are exceptions to this rule depending on which "Value" a marker gets assigned and in which order the markers are positioned in the trigger actions list. Conversely, ALL the programmed markers will show on the F10 map without issues. When manually adding the markers on the F10 map after mission start, all of them will be present in the wheel as well.

On a complete unrelated topic, I tried intensively to get bookmark injection to work and here's what I found: On a German keyboard with a German keyboard layout selected in Windows, the only key that actually causes a bookmark to be set is "`" (the key to the right of "L", on a U.S. keyboard this is below the ESC key). Neither the "2" (key to the right of "`" on a German keyboard) nor RALT+B have any effect. What's more, using the Thrustmaster TARGET software, I have been unable to program a key to produce the "`" character so it is recognized by Tacview with a German layout selected (the character is recognized just fine by the DCS Options/Controls menu, i.e. when I press the joystick button, the key "`" is produced in the assignment panel). When software-switching to a U.S. layout, a HOTAS-programmed "`" works just fine. To avoid these problems or generally problems with international keyboards, would it be possible to either include a key option that has no special characters (such as "c", "u" etc.) or include an option to use a DX button or make it possible to configure the desired hotkey by modifying a .cfg file or similar? Cheers.

Hey Vyrtuoz, the following 100% repeatable problem occurs for me with Tacview 1.8.5. Advanced (Windows 10 Pro, RTX 3080, latest drivers): I have two monitors, one main monitor (Display Port, 3440x1440, 100 Mhz) and one secondary monitor (1920x1200, 60 Hz). As long as Tacview is closed while displayed on the main monitor, everything works fine. However, once the program is closed while displayed on the secondary monitor, during the next start attempt, Tacview will freeze while loading the map, regardless of whether a mission is loaded or just the basic program. When HKEY_CURRENT_USER\SOFTWARE\Raia Software Inc. is deleted, everything is back to normal until the program is again positioned on the second monitor and closed. EDIT: Reason was the Nahimic service as described in your FAQ. For others affected by this issue, here's how to disable that service: How to disable the Nahimic Service | Eng - YouTube

Hey DArt, small question. I have created the following code for an overlay circle: { "author": "Bestandskraft", "brushStyle": 1, "center_x": 56.3508333333333, "center_y": 25.1, "color": "#ff000000", "colorBg": "#33000000", "id": "{ff29daa9-7fd7-4f8f-b0a8-48eee8bb9cae}", "lineWidth": 1, "name": "TEST", "radius": 12345, "shared": false, "timestamp": "", "type": "circle" }, Which radius do I have to enter so that it is exactly 20 nm? In other word, which unit do you use for the radius? It is not meters, because the circle is much too small when entering 37040. I initially though it might be yards, but even with 40507.4365704287 the circle seems to be a little bit too small.

Good news, 2.0.6 seems to have fixed the PAR azimuth error for airfields. Good work DArt! :thumbup: Unfortunately, for carriers the deviation is still present. I have attached a comparison between a carrier approach in Caucasus (little deviation) and Persian Gulf (big deviation). Hopefully it helps you track down the issue.

According to NAVAIR 01-F14AAP-1, 1 August 2001, Change 4 - 01 September 2004, p. 20-42, and NAVAIR 01-F14AAA-1, 15 May 1995, Change 1 - 1 February 1997, p. 20-31, in the A-A AN/ARN-84 TACAN mode, only range is received because the aircraft antenna complement is not configured to receive or transmit bearing information. That means that even though a tanker TACAN might be sending bearing information, the F-14 could not receive it. In the game, bearing information is displayed when tuned to a tanker TACAN. According to this post by Super Grover, the AN/ARN-84 is the TACAN equipment modelled in the game.

Hey DArt, just did some further testing. In the Caucasus map, the PAR azimuth is PERFECT! Even for CV approaches, the azimuth is close enough to be usable. However, in Nevada, the aircraft is displayed LEFT of centerline when perfectly aligned, so it's the opposite from Persian Gulf. So it seems it must be a problem not generally with differences in earth model, but with a PAR view incompatibility between LotATC and the Nevada and Persian Gulf theaters. Could it be that the LotATC PAR scope is using the magnetic variation in Caucasus also for Nevada and Persian Gulf? This seems likely because magnetic variation is about 1.5 E for Persian Gulf, 7.0 E for Caucasus, and 12.0 E for Nevada, so Caucasus is right in the "middle". By the way, there seems to be no discrepancy with coordinates generally: In the airport view in Persian Gulf, I can see aircraft taxiing at the correct locations, so the problem only seems to affect the PAR view.

With 2.5.6.50793, selecting "Remove Pylon" for ANY of the stations 3 through 6 in the loadout screen will remove the weapons rail from ALL of them. That includes stations with a legally loaded store.

Hey DArt, both problems persist in build 717f0013. To help you narrow down the issue, the "aircraft displayed right off centerline" does not only affect the PAR view, but also the normal tactical view when the range circles and the green runway extension line are enabled. Cheers.

Hey DArt, I recently bought a licence for LotATC and so far I'm loving it. However, I did notice two issues: 1) The course indicator on the PAR display seems to be off. When an aircraft is exactly on centerline, it is still displayed a bit to the right off course. I tested this with Al Dhafra, Al-Bateen and Abu Dhabi. Interestingly, you are displayed right off course if you fly an approach to RWY 31R, but also right off course if you fly an approach to the reciprocal RWY 13L. 2) A similar problem occurs with PAR approaches to carriers (I am not sure if this is the same problem as above), where you are also indicated to be right off course when in fact you are on the final bearing. I have attached some screenshots to illustrate the problem. This was in a no-wind situation.

Naquaii state here that the Heatblur F-14B is based on the NATOPS flight manual of 15 May 1995, Change 1 – 1 February 1997. While I do not have this manual available to me, I do have its equivalent (same date) for the F-14A. Of all the various NAVAIR 01-F14AAX-1 for the respective F-14 variants floating around on the internet, the A-1 from 15 May 1995 is the only one I have seen which explains in any detail the functioning of the Inboard and Outboard Spoiler Failure Override Switches (INBD and OUTBD SPOILER FLR ORIDE). Specifically, the normal procedures section states that the INBD and OUTBD SPOILER FLR ORIDE switches are left in ORIDE during/after the Poststart checks. The switches, however, are not mentioned in the Heatblur poststart checklist (presumably because, while movable, they are not implemented). During the RL Takeoff Checklist, the pilot will then confirm to the RIO that the INBD and OUTBD SPOILER FLR ORIDE switches are indeed set to ORIDE. Except for a general reference in the FCF checklist that the INBD and OUTBD SPOILER FLR ORIDE switches should normally be in NORM to provide spoiler asymmetry protection, the flight manual does not mention when/if the switches are set back to NORM after takeoff. Following the logic established by the RL checklist, the switches should therefore remain in ORIDE during the entire flight and through shutdown. From the description of the switches in the RL manual, I am unable to infer why they should be in ORIDE throughout the flight, or at least which advantage would be gained by having them in ORIDE for takeoff. I would appreciate any insights you guys may have regarding this apparent discrepancy.

Already mentioned here, but this was outside the bug section and might therefore not have been noticed. The time-to-go indication on the TID exhibits some behaviour which I highly doubt is modelled correctly. NATOPS and the game manual, p. 281, both state that "[t]he time-to-go assumes the aircraft is flown at its present groundspeed along the great circle heading to the selected point", but do not go into more detail. In the game, when hooking a waypoint, then selecting SPD on the CAP, one can see that the GS is displayed not as the aircraft's actual speed over the ground, but as the rate of approach to the waypoint. That is, if flying perpendicular to the point, it is zero, when flying away from the point, it is negative. While this by itself might be correct (I doubt it), apparently the game uses this groundspeed to calculate the time-to-go. This means that a correct TTG is only displayed when flying exactly to or away from the waypoint. If flying perpendicular or almost perpendicular, no TTG is displayed (presumably due a DIV/0 error). This makes the TTG indication completely useless e.g. when holding / flying a trombone to push on time, when it is most important.

I already mentioned this here but since this was not in the bug section it might be overlooked. The game manual, p. 178 (supported by NATOPS) states that the hydraulic transfer pump "can supply either system from the other and will maintain a pressure between 2,400 and 2,600 psi if the driving system is at around 3,000 psi." In the game, if one main hydraulic pump fails, this side's hydraulic pressure will instead remain at 3,000 psi if the hydraulic transfer pump is working. This means you cannot know which side has failed, thus cannot apply the appropriate checklist procedures (see NATOPS), which differentiate between four main cases (both combined and flight pressure zero, combined pressure approximately 2,400 to 2,600 psi, combined pressure zero, and flight pressure approximately 2,400 to 2,600 psi).

Regarding how to perform a VIS FIX, page 275 of the game manual states: […] […] Overfly the selected prestored point and when over the point, depress the VIS FIX button on the cap. If the delta is not satisfactory, press VIS FIX again to clear the delta and repeat from step 1. If a satisfactory delta is displayed, depress the FIX ENABLE button; this causes the delta correction of own aircraft position to be inserted into the computer. In my interpretation, this implies that the delta displayed when hitting the VIS FIX button is the delta at the moment of the button press, which then continues to be displayed until you either enter it into the system with the FIX ENABLE button or discard it using the VIS FIX button another time. In the game (2.5.6.45915), pressing the VIS FIX button displays your continuously updated LAT/LONG deviation from the selected fix point (tested with WP1 and only in multiplayer). The fix point is moved to your aircraft's present position (not the one you were at when hitting the VIS FIX button) when you hit the FIX ENABLE button.

2.5.6.45317: When flying at about 90° perpendicular to a waypoint, the TTG indication vanishes. I have not found any information in the NATOPS manuals that corroborates this; the only relevant paragraph seems to be the following (precise source not quoted intentionally): "The time-to-go assumes the aircraft is flown at its present groundspeed along the great circle heading to the selected point."

Thanks, that was indeed the problem! Minor thing though, in the note to step 14 it says that the hydraulic transfer pump "[w]ill operate from flight side to maintain combined side at between 2400-2600 psi." In the game, when switching to NORMAL after returning the engine crank switch to neutral, the pressure in the combined side stays at 3000 psi instead of dropping to 2400-2600 psi.

I am not exactly sure if this is the same problem, but: Game manual, p. 348. After step 13. ENG CRANK switch to L (Left engine), pressure having reached 3000 psi, and setting the ENG CRANK switch back to off: When executing step 14: HYD TRANSFER PUMP switch to NORMAL, combined side hydraulic pressure is supposed to be maintained at between 2400-2600 psi. With 2.5.6.45317, the pressure drops to 0 psi instead.

As per title. While one can change the VHF/UHF ARC-182 Volume in the RIO cockpit just fine using the mouse, binding a key or a DX button to the respective commands has no effect in the game.

Page 243 of the game manual states that "sliding [the two way slider] aft and holding allows for focus control. […] In focus control [right four-way hat] up/down increases and decreases focus." During my tests, while it seems I was able to get into focus control mode, I was not able to apply any changes to focus using the above procedure.

1) Page 243 of the game manual states that "Sliding [the two way slider] forwards allows for selection of manual gain while releasing and sliding it forwards again reselects automatic gain. Change of the manual gain with manual gain already selected can be done by sliding the switch forwards and holding it for 2 seconds." In the game, sliding the switch forwards and holding it for 2 seconds does nothing. Instead, manual gain settings can be changed by toggling through AGC, MGC and MGC blinking by repeatedly pressing the two way slider forwards. 2) Any changes made to manual gain are not saved, i.e. when changing from manual gain back to automatic gain and then to manual gain again, the default gain is restored.