Jump to content

Recommended Posts

Posted

Hey all,

It appears that AI aircraft don't seem to be able to climb to their assigned orbit altitude from a lower altitude. In the attached mission:

  • An Su-27 is flying at 20,000ft and commences a Race-Track orbit when it reaches Wpt 1.
  • The assigned altitude for the Race-Track is 30,000ft.
  • The Flanker commences the orbit and starts climbing, but almost imperceptibly.
  • By the end of of the first leg of the orbit, the Flanker's nose begins bucking up and down like a rocking horse.
    • This oscillation gets very extreme over time with each passing loop. This can be seen really clearly with time acceleration.
  • The Flanker does eventually reach 30,000ft, but it takes nearly 40 MINUTES of orbiting
  • Once the Flanker has eventually reached 30,000ft, it resumes normal flight.

The example in the attached mission just shows the Flanker, but I've repeated this test with a Mig-29A, an Su-30 and the F/A-18 and the same issue occurs with each aircraft.  

This is really problematic for mission scripting if you push an Orbit task as an Advanced Waypoint Action when the aircraft is below the assigned Orbit altitude.

RockingHorseOrbit.miz

i7-7700K @ 4.9Ghz | 16Gb DDR4 @ 3200Mhz | MSI Z270 Gaming M7 | MSI GeForce GTX 1080ti Gaming X | Win 10 Home | Thrustmaster Warthog | MFG Crosswind pedals | Oculus Rift S

Posted (edited)
5 hours ago, Pizzicato said:

Hey all,

It appears that AI aircraft don't seem to be able to climb to their assigned orbit altitude from a lower altitude. In the attached mission:

  • An Su-27 is flying at 20,000ft and commences a Race-Track orbit when it reaches Wpt 1.
  • The assigned altitude for the Race-Track is 30,000ft.
  • The Flanker commences the orbit and starts climbing, but almost imperceptibly.
  • By the end of of the first leg of the orbit, the Flanker's nose begins bucking up and down like a rocking horse.
    • This oscillation gets very extreme over time with each passing loop. This can be seen really clearly with time acceleration.
  • The Flanker does eventually reach 30,000ft, but it takes nearly 40 MINUTES of orbiting
  • Once the Flanker has eventually reached 30,000ft, it resumes normal flight.

The example in the attached mission just shows the Flanker, but I've repeated this test with a Mig-29A, an Su-30 and the F/A-18 and the same issue occurs with each aircraft.  

This is really problematic for mission scripting if you push an Orbit task as an Advanced Waypoint Action when the aircraft is below the assigned Orbit altitude.

RockingHorseOrbit.miz 7.47 kB · 0 downloads

Okay, so I know from scripting that it is possible; there's nothing in DCS that will prevent this. In my Superscript I have complete control over all aircraft at all times. 

I'll d'load this and take a look. 

ETA:

Okay, you might want to read the manual again. This is a misunderstanding of how Race Tracks work (it's not obvious) + a possible M.E. Gotcha.

When you designate a waypoint as the orbit point for a CIRCULAR orbit, it will orbit THAT WAYPOINT in a circle, flying over it each lap. 

When you designate a waypoint as a RACE TRACK orbit, that is the 'A' point of the race track, the direction and distance for the loop back point - the 'B' point - is the NEXT WAYPOINT you have specified. In this case it was your 'END' waypoint. So you needed at least one more waypoint between the A point and the END.

The M.E. Gotcha is that when you specify an altitude and speed for an orbit, make sure that it matches the altitude and speed for the waypoint; so waypoint alt / spd == orbit task alt/spd. 

 

If you want your ship to be at alt before the orbit takes place, then you need an intermediate waypoint, same for the descent when leaving. If you don't and it arrives at the orbit point before reaching the altitude, then it will increase whilst it's orbiting. 

Otherwise it just interpolates between where it is and what it needs to be AT the next waypoint. 

Also, in your example the distances between everything were too small for the AI to cope with well. 

 

Attached is a fixed version with a timer that stops the orbit. If you view it on the F10 map and increase time compression you can watch it fly to your race track, orbit a few times and then go to the end and arrive at 20k as you wanted.  

 

Hope that helps. 

PS - This isn't a bug. 😉

FixedRockingHorseOrbit.miz

Edited by TEMPEST.114
Posted
6 hours ago, TEMPEST.114 said:

Okay, so I know from scripting that it is possible; there's nothing in DCS that will prevent this. In my Superscript I have complete control over all aircraft at all times. 

I'll d'load this and take a look. 

ETA:

Okay, you might want to read the manual again. This is a misunderstanding of how Race Tracks work (it's not obvious) + a possible M.E. Gotcha.

When you designate a waypoint as the orbit point for a CIRCULAR orbit, it will orbit THAT WAYPOINT in a circle, flying over it each lap. 

When you designate a waypoint as a RACE TRACK orbit, that is the 'A' point of the race track, the direction and distance for the loop back point - the 'B' point - is the NEXT WAYPOINT you have specified. In this case it was your 'END' waypoint. So you needed at least one more waypoint between the A point and the END.

The M.E. Gotcha is that when you specify an altitude and speed for an orbit, make sure that it matches the altitude and speed for the waypoint; so waypoint alt / spd == orbit task alt/spd. 

 

If you want your ship to be at alt before the orbit takes place, then you need an intermediate waypoint, same for the descent when leaving. If you don't and it arrives at the orbit point before reaching the altitude, then it will increase whilst it's orbiting. 

Otherwise it just interpolates between where it is and what it needs to be AT the next waypoint. 

Also, in your example the distances between everything were too small for the AI to cope with well. 

 

Attached is a fixed version with a timer that stops the orbit. If you view it on the F10 map and increase time compression you can watch it fly to your race track, orbit a few times and then go to the end and arrive at 20k as you wanted.  

 

Hope that helps. 

PS - This isn't a bug. 😉

FixedRockingHorseOrbit.miz 8.96 kB · 0 downloads

 

Thanks for taking the time to look into this and supply a solution and explanation, Tempest. I really appreciate the time you put into this. 

I'm not convinced that this isn't a bug, though, and that the altitude change is too much for the AI to cope with. The Flanker in the mission had 10nm to gain 10,000 ft which is pretty trivial. I ran the mission again with a 500 ft delta instead of 10,000ft, and it still struggled. Similarly, the ability to set a discrete altitude and speed for the orbit is surely intended as an override for the waypoint parameters - not a redundant set of fields that need to be arbitrarily matched by the mission designer.

The Hoggit page reinforces this (although Hoggit is obviously inferred documentation, not official): https://wiki.hoggitworld.com/view/DCS_task_orbit

Quote

speed: Speed in meters per second the AI will orbit at. If no speed is defined then the AI will orbit at 1.5 their stall speed.

altitude: Altitude in meters the AI will orbit at. If not defined the altitude of their current waypoint will be used.

It's also clear that this functions perfectly if the group's starting point is above the assigned orbit altitude. If you start at 40,000ft and ask the AI to orbit at 30,000ft it behaves beautifully. It only has an issue if it has to climb - even if that's only a few hundred feet. That's a bug from my perspective, not a misunderstanding.

Regardless - there are two specific use cases that I want to accomplish through scripting but without dynamic spawning (because I hate how DCS only supplies random GUIDs in the mission debrief for dynamically spawned groups).

1. I want to randomise the orbit position, altitude and speed of CAP groups that are already in flight at the start of the mission. I can make this work by setting their start altitude at 50,000ft and having them descend to their orbit altitude, but that's a workaround to the issue above.

2. I want to have delayed start CAPs taking off from the ground that have similarly randomised CAP orbits. I haven't figured out a functional workaround for this yet, though. I'm definitely open to ideas, though.

Again - I really appreciate your time and input, but I disagree that this isn't a bug. I have no issue with the AI needed to climb to orbit altitude over the course of several loops of the orbit, but they should be able to do it at more than 10 ft per nautical mile.

i7-7700K @ 4.9Ghz | 16Gb DDR4 @ 3200Mhz | MSI Z270 Gaming M7 | MSI GeForce GTX 1080ti Gaming X | Win 10 Home | Thrustmaster Warthog | MFG Crosswind pedals | Oculus Rift S

Posted

Thanks for the pointer, @buur - that definitely helped. It also confirmed that there is something problematic going on under the hood. I was only able to get the Flanker to cleanly climb from 20,000ft to 30,000ft by setting its speed to 800 kts / Mach 1.29 in the editor. I'm no aeronautical engineer, but I'm pretty sure that the Flanker shouldn't need to be travelling at 1.3x the speed to sound to make it to 30,000ft and stay there. That's also suicidal from a fuel consumption standpoint, as it requires the Flanker to stay in full burner for the entire orbit. 

I tested it, and the same Flanker can take off from Maykop (effectively sea level) and climb to 30,000ft at just 500 kts / Mach 0.8 over a shorter distance with no problems. It's only when climbing out with the Orbit task that it struggles.

In terms of the 20,000ft to 30,000 test over a 35nm leg using Orbit, I tried the following:

  • 500 kts / M0.8 - The Flanker can't climb at all.
  • 600 kts / M0.97 - The Flanker climbs to 28,000ft then stops climbing.  
  • 700 kts / M1.13 - Weirdly the exact same as above. It maxes out at 28,000 ft and then stops climbing.
  • 800 kts / M1.3 - Perfect climb with no issues.

There are very clearly shenanigans going on here.

i7-7700K @ 4.9Ghz | 16Gb DDR4 @ 3200Mhz | MSI Z270 Gaming M7 | MSI GeForce GTX 1080ti Gaming X | Win 10 Home | Thrustmaster Warthog | MFG Crosswind pedals | Oculus Rift S

Posted (edited)
4 hours ago, Pizzicato said:

I'm not convinced that this isn't a bug, though, and that the altitude change is too much for the AI to cope with. The Flanker in the mission had 10nm to gain 10,000 ft which is pretty trivial.

Remember that the AI is generic and not clever, in fact its really quite dumb. So whilst the ship and a human could make those changes, the AI can't/won't, unless you micro-manager the crap out of it with excessive waypoints / stepped climbs / or excessive params - just as you've found out. 

Like i said, it will always try and interpolate an action from the previous waypoint to the next waypoint, but it will not max out the performance of the aircraft because the AI isn't really that specific. You can see this with the way vehicles drive; it doesn't matter what vehicles you have in the convoy or leading the convoy, they will always drive the same way. 

Same for aircraft too. 

If you want to argue that it's crap and should be a lot better, and you can micro-manage it to get what you want, but it's a huge pita to do so, then I can whole-heartedly get behind that. Like most things in DCS it's half-baked at best. But I don't agree it's a bug with orbiting or even waypoints; it's just highlighting how poor the AI systems are, but I'm glad you're getting what you need from it now. 

🙂

Edited by TEMPEST.114
  • Like 1
Posted

@PizzicatoI've also tested the behavior in a straight line and you are absolutely right. The Flanker can fly with 500 kts ground speed at 30.000 feet. It seems that there are some wrong values in the orbit flight model. Best is we ask @Flappie if he could shift this thread to the ai-bugs. This is a better place for this thread. 

  • Like 1
Posted (edited)
45 minutes ago, buur said:

@PizzicatoI've also tested the behavior in a straight line and you are absolutely right. The Flanker can fly with 500 kts ground speed at 30.000 feet. It seems that there are some wrong values in the orbit flight model. Best is we ask @Flappie if he could shift this thread to the ai-bugs. This is a better place for this thread. 

I admit I never use Russian aircraft unless they're targets, but does this 'bug' apply to blue aircraft? If it does then I agree it's more likely an AI bug, but if you use the waypoints and micro-manage it a little more - just as I did in the 'fix' example, then I don't see any problems. 

 

What am I missing?

Edited by TEMPEST.114
Posted

The AI switches the flight model entering an orbit. For example there is no wind effect during an orbit on the planes. But also the simplified should follow the values a plane can fly. Maybe there is a table where all these values stored.  And maybe ED has to update it.

  • Like 1
Posted
1 hour ago, TEMPEST.114 said:

I admit I never use Russian aircraft unless they're targets, but does this 'bug' apply to blue aircraft? If it does then I agree it's more likely an AI bug, but if you use the waypoints and micro-manage it a little more - just as I did in the 'fix' example, then I don't see any problems.

What am I missing?

Yes, the bug extends to the blue aircraft.

Your fix is a workaround, but it doesn't address the underlying problem which is that the AI can't deal with an Orbit task that asks them to climb above their current altitude unless they're travelling at absurd, fuel-draining speeds. That being the case, you can't push an AI Orbit Task that has a randomised altitude unless you ensure that the aircraft has already attained an altitude above that. If you want to set a randomised orbit altitude between 50,000 ft and 20,000 ft, as an example, you've first got to send the aircraft up to 50,000 ft just to be sure that it'll be capable of reaching whatever altitude the randomised value lands on. 

The edge case here is that the ascent gets interrupted by the AI having to intercept an enemy aircraft, after which it struggles to climb back to the altitude in question.

1 hour ago, buur said:

@PizzicatoI've also tested the behavior in a straight line and you are absolutely right. The Flanker can fly with 500 kts ground speed at 30.000 feet. It seems that there are some wrong values in the orbit flight model. Best is we ask @Flappie if he could shift this thread to the ai-bugs. This is a better place for this thread. 

Yep. That makes sense. Thanks Buur.

i7-7700K @ 4.9Ghz | 16Gb DDR4 @ 3200Mhz | MSI Z270 Gaming M7 | MSI GeForce GTX 1080ti Gaming X | Win 10 Home | Thrustmaster Warthog | MFG Crosswind pedals | Oculus Rift S

Posted (edited)
11 minutes ago, Pizzicato said:

Yes, the bug extends to the blue aircraft.

Your fix is a workaround, but it doesn't address the underlying problem which is that the AI can't deal with an Orbit task that asks them to climb above their current altitude unless they're travelling at absurd, fuel-draining speeds. That being the case, you can't push an AI Orbit Task that has a randomised altitude unless you ensure that the aircraft has already attained an altitude above that. If you want to set a randomised orbit altitude between 50,000 ft and 20,000 ft, as an example, you've first got to send the aircraft up to 50,000 ft just to be sure that it'll be capable of reaching whatever altitude the randomised value lands on. 

The edge case here is that the ascent gets interrupted by the AI having to intercept an enemy aircraft, after which it struggles to climb back to the altitude in question.

Yep. That makes sense. Thanks Buur.

Okay, so just so you know, when I was editing your mission to fix it, I was able to have the aircraft climb WHILST orbiting, still at the same speed (450 I thinkt put in an intermediate waypoint because of how the AI interpolates it's manoeuvres. 

So I'm either confused about the problem or I'm not seeing it as you are. 

I had your Flanker climb from 20000ft to 30000ft at 450 knots whilst doing a racetrack orbit between point A and point B. 

I'm not seeing or understanding the bug. Sorry.

ETA:

The reason is climbs SLOWER in the orbit is because the orbit, I believe, makes the assumption that it's either being a refueller or loitering so it's being more gentle in it's manoeuvres. 

I'm not trying to seem like I'm being contrary; I'm just not seeing the 'bug' per se, other than a more global 'wouldn't it be nice if the AI was smarter' thing. The intermediary waypoints are kind of required because a) programming a GENERAL AI that can interpret context for any situation  is VERY, VERY hard and b) At the end of the day, it will always be an interpolation between fixed known points. 

 

Edited by TEMPEST.114
Posted
12 minutes ago, TEMPEST.114 said:

I had your Flanker climb from 20000ft to 30000ft at 450 knots whilst doing a racetrack orbit between point A and point B.

That's not what your fix is doing as far as I can tell. nullThe aircraft starts at 20,000 ft at WP0/Spawn. You then get it to perform a climb to 30,000ft from WP0 to WP1. It then flies to WP2 where it commences its orbit which is conducted entirely at 30,000ft. There's no climbing at all during the orbit.

Did you upload the wrong version of the file?

image.png

image.png

i7-7700K @ 4.9Ghz | 16Gb DDR4 @ 3200Mhz | MSI Z270 Gaming M7 | MSI GeForce GTX 1080ti Gaming X | Win 10 Home | Thrustmaster Warthog | MFG Crosswind pedals | Oculus Rift S

Posted
1 hour ago, Pizzicato said:

That's not what your fix is doing as far as I can tell. nullThe aircraft starts at 20,000 ft at WP0/Spawn. You then get it to perform a climb to 30,000ft from WP0 to WP1. It then flies to WP2 where it commences its orbit which is conducted entirely at 30,000ft. There's no climbing at all during the orbit.

Did you upload the wrong version of the file?

image.png

image.png

No.. The file I gave you had the intermediate waypoint to get the climb completed BEFORE the orbit.

I'm saying that if you go back to your original one, and fix the issue of the missing RaceTrack point B waypoint, from the START to the original point A point, there isn't enough time to climb so when it gets to Point A it will then begin the orbit and slowly climb UNTIL it hits 30000ft then it levels off. 

So my point was that if you set up the orbit properly but it doesn't reach the target alt before the orbit starts, it will slowly climb until it does - at a rate that *if it was a tanker* wouldn't throw the chicks off. 

 

1 hour ago, TEMPEST.114 said:

kay, so just so you know, when I was editing your mission to fix it, I was able to have the aircraft climb WHILST orbiting, still at the same speed (450 I thinkt put in an intermediate waypoint because of how the AI interpolates it's manoeuvres. 

This is the sentence you missed off from your quote. This is the context where I had it climbing in the orbit. 

Posted

So we're obviously talking at completely cross purposes. There's no missing point B in my initial file. There's a start point for the orbit, and there's an end point for the orbit. The aircraft does what its supposed to do according to the documentation - it starts the racetrack at the waypoint labelled Start and completes the loop at the waypoint labelled End. That's how the race-track has worked ever since DCS's inception and beyond. It also works just fine in the mission and in every other mission I've ever made. The only issue is the inability to climb.

The suggestion that there isn't enough time to climb doesn't make any sense to me either. It can do this just fine (with nautical miles to spare) outside of the Orbit. It can also do it just fine within the Orbit if you set the speed a little higher. The weirdness is that the climb behaviour goes from 2ft per minute to 3,000ft per minute if you just set it to go 100kts faster. That's not a feature. That's not user-error or PEBKAC. It's just a clear behavioural bug. If you can provide an file demonstrating a reasonable climb during - not prior to - an orbit task being given then I'm happy to be proven wrong, but until then it's a Class B bug as far as I'm concerned. 

With regard to your underlined sentence, are you saying that you had the aircraft climb while orbiting while you were editing my mission but then didn't provide that version? I'm really confused.

Anyway, this discussion is getting neither of us anywhere. I genuinely don't understand what point you're trying to make and why you're trying so hard to explain away a demonstrable problem. Ironically, we're both just wasting daylight going around and around in circles without gaining any conversational altitude, so I'm going to leave it here.  

i7-7700K @ 4.9Ghz | 16Gb DDR4 @ 3200Mhz | MSI Z270 Gaming M7 | MSI GeForce GTX 1080ti Gaming X | Win 10 Home | Thrustmaster Warthog | MFG Crosswind pedals | Oculus Rift S

Posted
On 5/19/2024 at 3:27 AM, Pizzicato said:

So we're obviously talking at completely cross purposes. There's no missing point B in my initial file. There's a start point for the orbit, and there's an end point for the orbit. The aircraft does what its supposed to do according to the documentation - it starts the racetrack at the waypoint labelled Start and completes the loop at the waypoint labelled End. That's how the race-track has worked ever since DCS's inception and beyond. It also works just fine in the mission and in every other mission I've ever made. The only issue is the inability to climb.

The suggestion that there isn't enough time to climb doesn't make any sense to me either. It can do this just fine (with nautical miles to spare) outside of the Orbit. It can also do it just fine within the Orbit if you set the speed a little higher. The weirdness is that the climb behaviour goes from 2ft per minute to 3,000ft per minute if you just set it to go 100kts faster. That's not a feature. That's not user-error or PEBKAC. It's just a clear behavioural bug. If you can provide an file demonstrating a reasonable climb during - not prior to - an orbit task being given then I'm happy to be proven wrong, but until then it's a Class B bug as far as I'm concerned. 

With regard to your underlined sentence, are you saying that you had the aircraft climb while orbiting while you were editing my mission but then didn't provide that version? I'm really confused.

Anyway, this discussion is getting neither of us anywhere. I genuinely don't understand what point you're trying to make and why you're trying so hard to explain away a demonstrable problem. Ironically, we're both just wasting daylight going around and around in circles without gaining any conversational altitude, so I'm going to leave it here.  

It seems that in trying to be brief things have become confused.

If you want to talk about the mission I uploaded and where your confusion what what I've said is, here's an invite to my personal discord server. Hope to hear from you: https://discord.gg/zcH3jeVA

I tried to DM you but you have that turned off. 

  • Recently Browsing   0 members

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