Search the Community

Hi everyone, The 5" mounts on the Essex appear to track aircraft but, in the majority of tests I've run, only actually engage below 2500 ft. In the tracks below I have a single Ju 88 A-4 at various altitudes that should be well within the engagement envelope of the guns. The only track where the guns engage reliably is the 2.4k ft track. The other thing is the range at which the guns start firing - according to the linked trajectory chart, the upper-limit of the range should be around 15000 yards (~13.7 km) for a target flying at 10,000 ft and around 16000-17000 yards (~14.5-15.5 km) maximum for a target at 2500 ft. In DCS however, the guns first start firing at around 1.5 nautical miles (or about 3000 yards or about 2.8 km) and only get a single salvo off (and even then, not all the mounts engage) before the carrier is overflown. Each gun should be able to fire at a rate of 15-22 rounds per minute (or 30-44 rounds per Mk 32 mount, as used on the Essex). Part of the range issue may be down to the directors (Mk 37 GFCS), whose radar ranges (for the Mark 12) are half of what they should be (they also are defined with the wrong frequency range). In Essex_Class_Carrier_1944.lua, the director's "distanceMax" is set to 25 km. The Mark 12 radar (the rectangular antenna on top of the director, mark 22 is the elliptical antenna beside it) should be able to track bomber-sized targets out to ~41 km [source] Suffice to say, these issues drastically limit the effectiveness of these guns. Essex_5-inch38_Engage_2.4kft.trk Essex_5-inch38_NoEngage_2.5kft.trk Essex_5-inch38_NoEngage_5kft.trk Essex_5-inch38_NoEngage_10kft.trk

Hi everyone, Currently the AGM-84A Harpoon Block 1A pops up to about 1100-1200 ft. According to designation systems however, the missile performs a steep climb to ~5,900 ft before diving on the target: http://www.designation-systems.net/dusrm/m-84.html I'm unsure if this also applies to other Harpoon variants (namely the xGM-84D Harpoon Block IC) as designation systems specifically references the xGM-84A. AGM-84A_popup_alt.trk

Hi, I've been having issues where AI aircrafts do not fly at the altitude I gave them through the task mission in scripting. I have a mission with two fighter groups (Rafale C), an AWACS (E-3A) and a Tanker (KC-135MPRS). At first, I make them start from parking. I then give them this task : local on_the_way = { id = 'Mission', params = { airborne = true, route = { points = { [1] = { type = "Turning Point", action = "Fly Over Point", x = coordinates_plane.x, y = coordinates_plane.y, alt = args.altitude, alt_type = "RADIO", }, [2] = { type = "Turning Point", action = "Fly Over Point", x = coordinates_racetrack_start.x, y = coordinates_racetrack_start.y, alt = args.altitude, alt_type = "RADIO", } } }, } } local orbit = { id = 'Orbit', params = { pattern = "Race-Track", point = coordinates_racetrack_start, point2 = convertCoords(args.point2), speed = args.speed, altitude = args.altitude, } } local controller = Group.getByName(args.group_name):getController() controller:resetTask() controller:pushTask(on_the_way) controller:pushTask(orbit) The aircrafts all go to their zones and perform their race track orbit so I know that it works. The issue I have is that my AWACS flies close to ground level despite the altitude of 20000 feet I give them (I checked this altitude by printing it). When I change the AWACS plane to any other plane it then works and the AWACS flies at the right level. Things get weirder with the fighters, when starting from parking, my Rafales fly at the right level. But when they start from the runway, they fly at ground level as well. And when I change their type to Mirage 2000C, they work again and fly at the right level, even when starting on the runway. So what I thought to be a plane issue seems to also be an issue with their starting zone. But I tried changing the start of the AWACS and none of my changes made it work. I'm also thinking the issue could come from mission scripting as the altitude works when I set the planes routes from the mission editor and not from scripting. I was wondering if anyone had encountered the same issue in the past. And if so, is there a solution to these issues. Thanks a lot for your help.

Been wondering about this behavior. Like, should you keep advancing throttle to keep power up until supercharger kicks in while climbing? Ok, the MP jump on supercharger kick in, that's how it worked. http://www.aviation-history.com/engines/merlin.htm

When I am in the CPG seat and use 5 short up clicks to get the Pilot to come up to 50 feet, he does that ... then he sinks to the ground, then he goes up again, then comes down, up, down, up down ... I shot a video of it. Can anyone tell me if there is something I need to do in the Pilot seat itself before switching to CPG seat to make this work? My Bouncing Apache!

To save multiple duplications of conditions all with an OR (for each unit in each group), two new CONDITIONS for GROUP HEIGHT checks would be much simpler and quicker. ALSO, in the back-end, these GROUP checks, MUST test ALL of the units in the specified group(s) for busting an altitude (High or Low) before the CONDITION is true - it must NOT require that ALL of entire group(s) units collectively bust the altitude limits!

This makes it very difficult and unnecessarily challenging when using AI units for PLAYERS to FOLLOW in close formation. Some option for specifying the MAX RATE of the turns at waypoints AND MAX FPM for change in altitude at waypoints would massively alleviate this problem. So too for change of speed, although this is less of an issue with good formation flying techniques. Thanks