[Fixed] Stated Loadout Altitude overrides Designed Flight Path's Altitude

[DWReese]

This seems to occur with every plane in every situation.

Example: Israeli F-15I is loaded with 8 GBU-39 glide bombs.

The Weapon Loadout indicates that the plane flies at 36k feet, attacks at 36k feet, and returns at 36k feet. (Hi-Hi-Hi)

The weapon itself indicates that it must be dropped at a minimum of 10k.

I set up a recent test using the Flight Path. I instructed the plane to make an approach at 3k feet; rise to 16k feet for a distance; launch at 16k, and return at 3k once again, as this is hostile territory.

The attack portion works fine. All of the weapons were fired, and it was time to return home.

Unfortunately, after the attack, and despite the Flight Path design, the plane rises up to 36k feet, and continues that posture all the way home. Of course, this puts the plane in harm's way.

Note: You can manually change the altitude, and it works fine.

The attack distance (my base to the enemy base was only 400 miles, and the plane barely used much fuel at all, so it was not trying to save fuel by flying at a higher altitude.

It doesn't matter which plane, or ordinance is involved. If the Loadout says to Hi-Hi-Hi, and the cruise altitude is 36k feet, that is what it will fly at.

In summary, after an attack, and when the plane starts to fly home, it appears to be designed to use the stated Loadout parameters (i.e. 36k feet, or Hi), regardless of what was Designed Flight Path Altitude was set at.


Hopefully, this should be easy enough to check to see if it is programmed that way, since it is occurring with all planes in similar circumstances.

[DWReese]

Sorry, I forgot the saves.

In the first, the plane refuses to climb to 16k, which is needed to fire the weapons. If you manually change it, then it will climb, and fire as expected.

Path Egress Altitude Issue 1.zip

(78.67 KiB) Downloaded 2 times

In the second, after firing, the plane remains at 16k feet, and will not drop down to the designed altitude of 3k feet. If you manually change it, it will drop down as desired.

Path Egress Altitude Issue 2.zip

(80.89 KiB) Downloaded 1 time

[DWReese]

(Note: The first file is actually an Ingress, not an Egress, as it is labeled.)

If an error occurs on the Ingress, it is almost always associated with the addition of a Waypoint to the AI's original path. Additional Waypoints always seem to throw things off, even if they are properly named. If you allow AI to create the path, then you can alter it, as long as you don't add Waypoints. For standard attacks this is fine. For complicated ones, refueling, those involving turns, and/or altitude changes, this can be a problem,

The Egress is a always problem, with or without the additional Waypoints. After firing their ordinance, the plane always wants to climb to 36k feet for its journey home. This will often get him killed. Again, fuel is NOT an issue, so that is not why it's climbing.

That's as much as I can provide.

[Raptorx7_slith]

Thanks, logged as 0016610

[DWReese]

After firing their ordinance, the plane always wants to climb to 36k feet for its journey home. This will often get him killed. Again, fuel is NOT an issue, so that is not why it's climbing.

As you can see with this save, the plane headed DIRECTLY for its base after conducting the attack. What's interesting here is the path home goes directly through a No Nav Zone.

New Battle (what no nav zone).zip

(81.31 KiB) Downloaded 3 times

Also interesting, immediately after firing its weapon, the plane realized that there was a no nav zone, and you could BRIEFLY see a dotted line (intended path) which was similar to its ingress), which went AROUND the No Nav Zone. But, seconds later, instead of following that path, the plane did a 360 and headed directly home through the No Nav Zone, as you can see in the save.

I hope that this helps.

[DWReese]

FYI, this was not fixed. Perhaps it wasn't slated to be.

In any case, the striking plane continues to ignore the No Nav Zone on the flight home. Fuel is not an issue, and the dotted path can clearly be seen that the plane "intended" to fly on the path that it came and what was expected.

About one minute into the flight home, however, it abandons the intended path, and flies straight toward the base, which takes it through the No Nav Zone.

[blu3s]

The issue regarding RTB altitude it's fixed for next build. I can't check the altitude of the FP Ingress leg since AC it's already airborne

[blu3s]

The issue with the Non Nav zone and RTB it's also fixed, checking other issues with the Non Nav zone.

[DWReese]

Hi, great work on everything.

If you are saying that the plane that has finished its mission will NOT enter a No Nav Zone on the way home (if it's in its way) and has been fixed, then I believe that you are wrong as I am looking at it do so. The game's AI drew the original path around the No Nav Zone, and it did it perfectly. Upon dropping its ordinance, the plane appeared to be on the exact same course in reverse, but suddenly turns left and heads through the No Nav Zone. Fuel is not an issue, and no altitude changes are made. The original path was drawn by the game's AI. The return is merely the shortest distance between two points.

[blu3s]

I just regenerate the FP with another AC, the FP creates the Ingress and Egress leg avoiding the NFZ, and the AC respect the Egress Leg and does not directly RTB through the NFZ.

I'm on B1467 so if you're seeing this on 1465, this was probably fixed after 1465, so it will be on the next update