MBot

The P-37 would be a very useful addition as GCI/EWR radar. It is very unfortunate that it has never been set up as a proper unit, considering that it already exists in game as a scenery object with a very detailed 3D model.

Since the other thread has been incorrectly marked as [DCS BUG], I am not sure if it is still being checked by HB. Therefore I am opening a new topic here. On a carrier moving between 26 and 44 kph, a player F-14B with engines running is continuously sliding forward on the deck. Interestingly the Tomcat does not slide when the carrier is moving slower than 26 kph or faster than 44 kph. In my opinion this is a rather severe issue as in various of my missions the player slides over the catapults, crashing into spawning AI before start-up to taxi is complete. Changing carrier speed is no workable solution as carrier speed is dynamically set depending on weather in order to create a fixed wind over the deck. This is an issue related to the F-14B since the Hornet is not sliding in the same circumstances. Tomcat position at spawn. Tomcat position after 10 minutes. Note amount of movement in the time required to align INS. For comparison: Hornet position at spawn. Hornet position after 10 minutes is unchanged.

For me it is quite the opposite. In the pattern the jet now feels very unstable. Previously it was very stable in AOA to the point that I would fly the pattern almost hands off in pitch once trimmed out. If you gave it a moment the jet had a natural tendency to return to on speed AOA with each power change. Now it seems that the jet's natural pitch response with power changes is greatly delayed. Perhaps this is what you mean with increased pitch stability. But in effect this has resulted in a big reduction of stability in AOA. I don't know it this is realistic or not, but the Tomcat became a lot more difficult to fly on speed for me. I used to have mostly green lines in the groove, now it looks like this:

Curious. Is this possible hardware dependent?

The option "Restrict Afterburner" does not have a discernible effect on AI afterburner usage.

AI that is too late to meet a fixed waypoint Time on Target continues to fly route at stall speed. Happens frequently when AI takes off delayed due to extremely poor taxi logic at airfields. This is an old issue first reported in 2016 here. Since this has never been acknowledged I move this to the 2.5 bugs.

There continue to be serious issues with AI radar detection ranges of some aircraft. The following test was conducted with a selection of various AI aircraft to illustrate some of the extreme discrepancies. All test aircraft fly at 4000 m AGL and are approached head-on by a target A-10 at an altitude of 100 m (look-down) or 8000 m (look-up). The distance from the target at which the test aircraft accelerate to engage the target represents when it has detected it. Detection range look-down: MiG-19: 160 km (excessive range, radar not look-down capable) MiG-21: 60 km (excessive range, radar not look-down capable) MiG-23: 75 km MiG-25: 280 km (excessive range, radar not look-down capable) MiG-29: 60 km F-5E-3: 270 km (excessive range, radar not look-down capable) Detection range look-up: MiG-19: 350 km (excessive range) MiG-21: 100 km (excessive range) MiG-23: 120 km MiG-25: 500+ km (excessive range) MiG-29: 75 km F-5E-3: 460 km (excessive range) From this selection, only the MiG-23 and MiG-29 seem reasonable. Feel free to make additional tests of other AI types. Here is an old post on this in 2.0 Alpha bugs section. Since this has not been acknowledged so far I move this to the 2.5 bugs section. AI_DetectionTest.miz

Having a Persian Gulf map without an oil tanker unit is rather ironic, isn't it? For the mission usability of the map I think this should be an AI unit with rather high priority to add.

A Rapier group consisting of a launcher and an optical tracker will not engage targets without adding a Blindfire tracking radar to the group. This is incorrect as the Blindfire was a mid-life addition to the Rapier system and is not required to engage targets in visual conditions. Some months ago this was still working correctly.

AI will not attack radar ground units (for example Hawk SR or TR) with rocket pods (for example S-5 or B-8 ). Attacking the same targets with guns, missiles, bombs and heavy rockets work. AI attacking other ground unit types (for example Hawk launchers) with rocket pods works too.

Any chance this could have been looked at in the mean time? This is still a big obstacles to creating realistic ground controlled intercepts.

Carrier moving with 25 kts, no wind, engines running. Tomcat position at spawn. Tomcat position after 10 minutes. Note amount of movement in the time required to align INS. For comparison: Hornet position at spawn. Hornet position after 10 minutes is unchanged.

I am seeing this too. AI wingman is stuck at the end of catapult 2. Reproduction: Spawn from ramp with a wingman and taxi out of the way to let wingman launch first. Does not happen with Hornet.

What is the status of this issue? With a carrier moving at 25 kts, the F-14 slides a good 10 m forward (and into other jets) even before start-up is completed. Switching the aircraft in the mission to the Hornet, it slides noting at all. Considering the Hornet is fine, I am not sure this qualifies as "DCS BUG".

Making a ramp-start with more than one AI wingman on the Stennis always leads to a taxi collision between 2-3. I somewhat doubt that ED is going to change the spawning on the Stennis anytime soon, so a fully Tomcat compatible Forrestal cannot come soon enough.

Giving this some thought considering size vs. complexity, different scenario options and geo-strategic relevancy, I think the South China Sea is a likely contender. The map could include Hainan for the Chinese "mainland" (even though it is an island), a strip of Luzon in the Pilippines (including Clark Air Base, NAS Cubi Point and Subic Bay Naval Base, but exluding the large city of Manila) a small strip of coastline for South Vietnam (including Cam Ranh Bay) and obviously the contested islands. The theater would be of considerable playable size, with multiple airbases arranged in the center and around 3 sides of the map and offering a sizable ocean area for large scale naval operations. Yet the land mass to be modeled in the detailed area would be comparatively small, easing the production of the map. Basically only Hainan, the islands and small chunks of the South Vietnam and Luzon would be required. The map would be attractive because it accommodates 3 major powers: China, the Soviet/Russian air and naval base at Cam Ranh Bay in Vietnam and the US air and naval bases in the Philippines. Thus allowing for a variety of historic, semi-historic and near-future scenarios. As a free map intended to be a new signature map for DCS World, the fact that it would also target the Chinese marked might also be important.

I can only get an AI Tu-22M3 to cruise for a maximum of about 1700 NM until running out of fuel (1 Kh-22 payload, 26'000 ft, 480 KTAS). This is considerably short of the ferry range found around the internet (usually around 3600 NM). Perhaps combat radius and range were confused when the aircraft was configured for DCS. I know it is a rather minor thing but it would be appreciate if the Backfire's range could be looked at (it has some relevance related to Tomcat missions).

I noticed that while an E-2 will detect a bomber at over 300 NM and make respective radio calls, it will only submit it via data link once the target is about 150 NM from itself (target distance from AWACS, not Tomcat). Is there a reason why farther out targets are not received via DL?

I also noticed that the AI F-14B will not engage multiple targets with AIM-54 simultaneously, something that the old AI F-14A does very well. Engaging fighters with a single missile at a time seems appropriate, but when intercepting bomber formations the lack of multi-target engagements is apparent.

I would like to know this too.

There certainly is something off with AIM-54 guidance. I just tried some supersonic Backfire intercepts at 30'000+ ft, closure 1800 kts, launched in the heart of the envelope at 70-80 NM, both in TWS and PDSTT. Each time the missile lofts too high and about 10 NM from targets snaps down hard, burning all its energy and subsequently falling down vertically behind the target. Pk for long range shot against non-maneuvering supersonic target: 0.

Thank you very much, I think I got it now. It seems to me to be a rather un-intuitive way to display things though. If we have the MLC filter enabled/auto and just the blue target appears on screen, the only real useful information that I can take away from it is azimuth. Closure rate really is just "yes, but just a wild guess how much". Why not just display absolute closure rate and be able to compare targets at different azimuth with a scale that works everywhere?

Sorry for being slow to comprehend, but I would really like to understand how this display works. In the example above, do I understand it correctly that both the red and the blue target would have the same 600 kts closure rate in relationship to the ground beneath them? Therefore the rate scale at the left side is only valid for 0 azimuth targets. For all other azimuth you would have to guess the closure rate against the ground by judging the distance from the MLC trace. And since the MLC trace is not displayed with the MLC filter enabled and since the MLC trace changes form depending on your own airspeed, for targets with an azimuth >0 you effectively have no reliable way to determine their actual closure rate in relation to the ground. Consequently you also cannot accurately see on the display when a target is approaching the notch at azimuth >0. Correct?

I still don't quite understand. Does this mean that the closure rate scale is only accurate at an azimuth of zero? Let's say in the image above there would be a target at azimuth of -60 with a closure rate of zero (center tick mark on the left scale). At this azimuth the MLC trace in the image displays at a closure rate of -600 knots. Is the target in the clutter or not?

According to the manual, the DDI in pulse doppler modes is displaying closure range against the ground: What I don't understand is why the mainlobe clutter trace is showing as an arch: I would understand this form if the display would show absolute closure range, in which case the closure of the ground relative to your aircraft us lower at higher azimuth. But since the display shows target closure range against the ground (with 0 meaning the target having the same closure as the ground and thus it being in the ground clutter), shouldn't the trace be a straight horizontal line?