Jump to content

[REPORTED] GBU-38 and Mavericks broken in latest OpenBeta


Peaches

Recommended Posts

Since OB 2.5.4.26368, the flight path of the AGM-65D has been changed, which causes the weapon to no longer be suitable for low-level, stand-off attacks, which is a key mission for the DCS A-10.

 

 

Attached are two track files with the same set-up and execution of a pop-up attack on an SA-6 radar near sea level.

 

 

The first track file is from OB 2.5.3.24984, where the missile is launched at 800 feet MSL and 6.5 NM away from the target. The missile climbs to an apex of 3,200 feet MSL by 2.4 NM away from the target and then dives in and kills the vehicle; its flight path is straight towards the target the whole flight. This behavior has been consistent for the AGM-65D for years, perhaps since the inception of DCS: A-10C.

 

 

The second track file is the same execution but on OB 2.5.4.26368. In this case, the missile, launched at 800 feet MSL and 6.5 NM away from the target immediately starts veering left, performs a slight climb to 1,100 feet MSL (apex at 5.7 NM away from target) and then gradually descends, going below 150 feet MSL while still 2.7 NM from the target and inevitably trashing itself in the trees.

 

 

Please take the time to look into this change and correct the flight path back to its former profile, so that the Hawg can regain its key mission of pop-up attacks in high-threat environments. Thanks!

 

 

EDIT: with TacView files in post #3. Sometimes the track files don't play back correctly when recorded on different versions of DCSW.

 

 

EDIT 2: it looks like the flight profile was changed in OB 2.5.4.25729 on 20 Dec 2018, as the version notes included: "AGM-65. Search and lock ranges was increased based on launch altitude." In giving the missile potentially a little bit longer range at altitude, the change took away the low-level, pop-up ability, which is a poor trade. It also does not explain the left veer tendency introduced.

OB 2-5-3-24984 AGM65 success.trk

OB 2-5-4-26368 AGM65 fail.trk


Edited by Peaches
Link to comment
Share on other sites

I'm not buying anything new since a few months, I'm waiting to see a-10c fixed. I'm not so much concerned with newer textures, but I'd like to see cdu pages and some other 2.5 issues fixed. But above all I'd like not to see newer bugs passed to stable and added to the already existing ones.

Link to comment
Share on other sites

TL;DR:

 

Comparing your .trk and .acmi files to AGM-65F flight profiles, it looks like the new FM (while better) needs further refinement as the missile is under performing.

 

Detail:

 

The first track file is from OB 2.5.3.24984, where the missile is launched at 800 feet MSL and 6.5 NM away from the target. The missile climbs to an apex of 3,200 feet MSL by 2.4 NM away from the target and then dives in and kills the vehicle; its flight path is straight towards the target the whole flight. This behavior has been consistent for the AGM-65D for years, perhaps since the inception of DCS: A-10C.

The loft profile in 2.5.3, while spectacular, looked unrealistic when compared to the AGM-65F profile found in the AV-8B Tactical Manual Vol 2. Not only was the apex too high but, having burnt off all it's speed to climb, the missile was now slow and took too long to reach it's target i.e. I would see +2 min flight times (at range/altitude in 2.5.3.24436), when max should be 1m45s

 

The second track file is the same execution but on OB 2.5.4.26368. In this case, the missile, launched at 800 feet MSL and 6.5 NM away from the target immediately starts veering left, performs a slight climb to 1,100 feet MSL (apex at 5.7 NM away from target) and then gradually descends, going below 150 feet MSL while still 2.7 NM from the target and inevitably trashing itself in the trees.

The current AGM-65D performance is less than that found reading the AGM-65F charts in the AV-8B Tactical Manual Vol 2 (interpolating between Mach 0.3 and 0.5 charts for 0.4).

 

Using the AV-8B AGM-65F charts, range might be 34,000 ft (5.6 NM) @ 1000-500 ft/ M0.4, so a launch from 6.5 NM looks optimistic (unless in a faster aircraft).

 

Looking at your track and tacview files -

 

• Apex at 1,100 ft is perhaps 700 ft low

• Time of flight at 25 sec, was 15 sec short of an expected 40 sec.

• Distance covered was 3.8 NM (6.5-2.7) = 23,000 ft in 25 sec. The expected travel time was about 24 sec, so the DCS missile is very close but a little slower.

 

The current FM needs further refinement as the missile is under performing.

 

Please take the time to look into this change and correct the flight path back to its former profile, so that the Hawg can regain its key mission of pop-up attacks in high-threat environments.

Reverting the flight model to another incorrect flight model for 'gameplay' reasons is not the correct method, providing real world data (where available) and improving the new flight model to reflect real capability is.

 

EDIT 2: it looks like the flight profile was changed in OB 2.5.4.25729 on 20 Dec 2018, as the version notes included: "AGM-65. Search and lock ranges was increased based on launch altitude." In giving the missile potentially a little bit longer range at altitude, the change took away the low-level, pop-up ability, which is a poor trade.

I wasn't using the A-10C at the time but FM changes to the AV-8B's AGM-65G occurred in DCS 2.5.3.24984, reducing it's excessive loft, perhaps 2.5.4 reduced it further.

 

It also does not explain the left veer tendency introduced.

The A-10C's missiles

 

• veer to the left when fired off the right wing

• veer right when fired off the left.

 

The magnitude is about 5° before the missile tracks back towards the target (if it was directly ahead). It appears to be the same on the NTTR map, so doesn't look to be MagVar/True North related and decreases with range to target.

 

Tested A-10C in DCS Open Beta 2.5.4.26552, Caucasus and NTTR maps at 5000-500 ft AGL.


Edited by Ramsay
Checked when Tacview showed AV-8B AGM-65G reduced loft

i9 9900K @4.7GHz, 64GB DDR4, RTX4070 12GB, 1+2TB NVMe, 6+4TB HD, 4+1TB SSD, Winwing Orion 2 F-15EX Throttle + F-16EX Stick, TPR Pedals, TIR5, Win 10 Pro x64, 1920X1080

Link to comment
Share on other sites

When you noted that the missiles veer left/right depending on station, were the missiles loaded on the single-rail LAU-117s or on the triple-rail LAU-88s?

I had LAU 88 with 2*AGM-65D on Stations 3 and 9 (4 missiles total).

 

When tested at Tonopah in NTTR, I of course expected to see the missiles veer left as they do in Peaches track.

 

However the first AGM-65D came off the left wing and veered right.

 

Checking the missile's HUD in Tacview, highlights the issue - some of the missiles on the LAU-88 are mounted sideways, I guess the missiles are trying to loft but instead fly sideways :lol:

 

attachment.php?attachmentid=203181&stc=1&d=1548557946

 

Note: Some of the missiles on the LAU-88 are "right-side up" and don't veer to the side.

 

Tested in DCS Open Beta 2.5.4.26552

804807954_A-10CLAU88AGM-65DTonopahTestTacview2_5_4_26552.JPG.90e7a75881217bffad608718f2be96d6.JPG


Edited by Ramsay

i9 9900K @4.7GHz, 64GB DDR4, RTX4070 12GB, 1+2TB NVMe, 6+4TB HD, 4+1TB SSD, Winwing Orion 2 F-15EX Throttle + F-16EX Stick, TPR Pedals, TIR5, Win 10 Pro x64, 1920X1080

Link to comment
Share on other sites

Yeah, that's why was asking. The shoulder stations on the LAU-88s are canted. On older model Mavericks (A-G), the GCS actually had to be physically rotated on the missile to account for that. Modern variants (H/K) can account for the rotation in the internal software.

 

At the moment missile track is commanded, the missile sets the current roll attitude as the local vertical reference. The vertical reference is used by the autopilot to perform the g-bias (loft) maneuver. This is the reason for the 30/30/30 rule.

 

I speculate that ED updated the missile autopilot, but failed to account for LAU-88 shoulder station rotation. Hence the oblique loft trajectory. It's the same as if you locked up a target in a 30 degree left bank, then rolled to wings-level and pickled: the missile would actually roll 30 degrees left before lofting.

 

H/K models shouldn't suffer any issues due to station orientation, although the 30/30/30 rule still applies.


Edited by DirtySanchez
Link to comment
Share on other sites

Interesting find, Ramsay. I guess that explains why my first 65 fired from the 88 flew into the trees, miles short of the target, but the second one went all the way and killed that target. I'll have to see which missile comes off the rail first. I've never looked.

EVGA Z690 Classified, Intel i9 12900KS Alder Lake processor, MSI MAG Core Liquid 360R V2 AIO Liquid CPU Cooler, G.SKILL Trident Z5 RGB Series 64GB DDR5 6400 memory, EVGA RTX3090 FTW3 Ultra 24GB video card, Samsung 980PRO 1TB M2.2280 SSD for Windows 10 64-bit OS, Samsung 980PRO 2TB M2.2280 SSD for program files, LG WH14NS40 Blu-Ray burner. HOTAS Warthog, Saitek Pedals, HP Reverb G2. Partridge and pear tree pending. :pilotfly:

Link to comment
Share on other sites

Good to see that NineLine acknowledged the issue on a related post (https://forums.eagle.ru/showthread.php?t=231171).

 

 

The lofting maneuver has been confused by rail position on the LAU 88, meaning inboard and outboard stations are "lofting" sideways, making them useless for pop-up attacks. Thanks to Ramsay for uncovering the root problem.

 

 

Track file attached showing the errant behavior. Launch sequence is Station 9: outboard, bottom, inboard, Station 3: outboard, bottom, inboard.

LAU 88 AGM 65D salvo.trk

Link to comment
Share on other sites

Haha. You're welcome, since I'm the one who figured it out.

Sorry I must have missed your post where you looked at Peaches .trk and .acmi files and did the independent testing.

 

Your input was useful and if you'd tested and comeback with a post saying "yes, it's because ..." you could claim credit, as it is - you came back saying "which are you using ?" i.e. a question.

 

However, as I'm feeling generous, I'll give you joint accreditation for finding a bug in DCS :lol:

i9 9900K @4.7GHz, 64GB DDR4, RTX4070 12GB, 1+2TB NVMe, 6+4TB HD, 4+1TB SSD, Winwing Orion 2 F-15EX Throttle + F-16EX Stick, TPR Pedals, TIR5, Win 10 Pro x64, 1920X1080

Link to comment
Share on other sites

Yeah, because you pulled it out of the depths of your vast AGM-65 systems knowledge all on your own? I "asked" which launcher not because I wasnt sure, but because it follows logically that using the LAU-88 would cause the problem being described. I was merely confirming that fact.

 

But whatever. I guess it's too difficult to just say thank you.

Link to comment
Share on other sites

  • 4 weeks later...
  • 1 month later...

[REPORTED] GBU-38 and Mavericks broken in latest OpenBeta

 

Latest OpenBeta version 2.5.4.29585

 

GBU-38s do not track coordinates. They behave like free-fall bombs.

 

Maverick track files will follow shortly.

 

EDIT1

See also: https://forums.eagle.ru/showthread.php?t=238668

 

EDIT2

Mavericks sometimes do not hit targets. They "loft" in the wrong direction.

A-10C GBU-38.trk

A-10C GBU-38 test.miz

A-10C AGM-65D.trk

Tacview-20190412-143010-DCS-A-10C AGM-65D.zip


Edited by prof_laser
fetch?filedataid=261737&type=full
Link to comment
Share on other sites

I see the same.

 

I also see that the GAU-8 misses. When the pipper is over target the bullets hit long.

 

Can it be that the elevation data is somewhat corrupted (maybe too high)? To me it appears as if the GBU-38s do steer towards the target, but that the ground is reached at a later time than calculated. The bomb usually misses long.

Link to comment
Share on other sites

  • ED Team

Mavericks are already reported, they loft wrong when used a 3 missile mount, the ones mounted sideways loft funny. GBU issue is related to all GBU issues currently, not really an A-10C issue, but a weapon issue.

 

Thanks for the reports.

64Sig.png
Forum RulesMy YouTube • My Discord - NineLine#0440• **How to Report a Bug**

1146563203_makefg(6).png.82dab0a01be3a361522f3fff75916ba4.png  80141746_makefg(1).png.6fa028f2fe35222644e87c786da1fabb.png  28661714_makefg(2).png.b3816386a8f83b0cceab6cb43ae2477e.png  389390805_makefg(3).png.bca83a238dd2aaf235ea3ce2873b55bc.png  216757889_makefg(4).png.35cb826069cdae5c1a164a94deaff377.png  1359338181_makefg(5).png.e6135dea01fa097e5d841ee5fb3c2dc5.png

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...