Bug in NAV point timing causing AI aircraft to travel at full burner

[Starfire13]

Affected versions

Development build

Build information

DCS Liberation 9.0.0 Build 5372 Git revision f9f2c79aeb4db51d74e61f4b0125b22b9313757f

Description

This bug has been bugging me for a while (pun intended) so I decided to track down the cause.

In the example file, the JOIN waypoint time is actually 1 minute earlier than the previous waypoint timing (2: NAV). But it's not really the JOIN waypoint timing that's the problem.

For reference, here are the timings: 1: NAV 16:24 2: NAV 16:29 JOIN: 16:28 INGRESS: 16:39

What I found was that the ground speeds for 1: NAV and 2: NAV were set at 320 knots (which works out to 230 knots IAS at their altitude). This means the Hornet flight travels all the way to 2: NAV at about 230 knots IAS (which is way slower than they ought to be flying), and hit their timings for 1: NAV and 2: NAV perfectly.

But once they do, the next waypoint is actually a minute in the past, so they go to full burner and accelerate from 230 knots to 440 knots (600 knots ground speed). But even on full burner all the way to their ingress point, they still can't make up for lost time, reaching their ingress point almost 2 minutes after the intended time (they arrive a couple seconds short of 16:41).

If I manually bump the NAV ground speed values from 320 to 520 in the mission editor, the problem goes away. They fly the entire way to ingress without having to use burner. Essentially, it's the NAV point ground speeds settings that are messing things up.

Note that I'm not saying 520 knots is the perfect number. I just bumped it up to see if there was in fact enough time between the JOIN and INGRESS timings for them to hit INGRESS on time if they weren't already running late.

The attached save file has 2 separate packages, one with auto-generated waypoint positions and one that has been manually tweaked in Liberation. I wanted to determine if moving waypoints had any impact on this problem. The same issue occurs regardless if the waypoints are moved.

Save game and other files (save game required, bugs without saves will be closed)

NAV Ground Speed Bug Example.liberation.zip

[Starfire13]

By the way, even though Fast Forward is turned on in the example file, I did also try it with Fast Forward disabled to make sure that wasn't the culprit. It isn't. The AI flights will take off and circle HOLD at around 520 knots ground speed, then slow down to 320 knots ground speed once they have to head for 1: NAV.

[DanAlbert]

Excellent, thanks! I think I saw the same thing recently but only saw it once and assumed it was probably just the usual pathologically bad climb to hold point issue or whatever. Knowing that it's nav point related gives me a pretty good hint of where the problem is though (I expect we just don't handle timing on waypoints at all, so the AI takes some arbitrary pace to to nav points and then has to make up for lost time very quickly afterward). I think I'll have some time to look at bugs tonight.

[DanAlbert]

It's exactly that. We don't assign TOTs for nav points, and pydcs apparently defaults all waypoint speeds to 600kph, which is really quite slow.

[DanAlbert]

Give https://github.com/dcs-liberation/dcs_liberation/pull/3117 a try? It's not the best fix but it's the easy one and most of the code near this is going to be heavily altered soon anyway...

[Starfire13]

Will give it a try tonight. 🙂

[Starfire13]

This is working well!

[DanAlbert]

Great, merged, thanks for confirming. Also thanks for the investigation. Fixing this was almost trivial since you did the hard part :)