Sign in to follow this  
Guest Bob Z

AI Cruise Speeds

Recommended Posts

I've read quite a few posts about ai flight time issues andhave a fairly good understanding of the @ / non @ aspects.I've read and reread the lengthy discussions on PAI.Up till this point I have used Jim Vile's suggestion tosubtract 200 from the cruise_speed and that gave somewhatbetter ai spacing than the fixed 200. Speeds between 100and 390 were changed at my discretion, if at all. My aiworld is all freeware.However, in the past week I have converted some FP's from@ to non @ using the following procedure:Remove fixed ETA with AITMCompile and decompile the FP with TToolsFix up any schedule anomolies with AITMI gave them at least a 45 minute minimum layover between flightsThey have an arrival time calculated by TTools, not the 00:00:00This discussion concerns non @ symbol FP's.For instance:PAI B742PWmodel paiB742pwv61aircraft.cfg v6.1cruise_speed=530AIA B747-200model aia_747_200ACM v2.3cruise_speed=477Microsoft stockb747_400cruise_speed=505In the MS stock aircraft.txt the cruise speed is set to505 and I understand that the cruise speed in both theaircraft.txt and cfg should be the same, and in the MSstock case it is. I also understand that some FP developersuse a somewhat smaller value in the aircraft.txt. I hearthat UT does so also but I can't confirm this. This is at the heart of my questions. More on this later.I followed 1 each of the PAI and AIA ai's mentioned abovefrombefore leaving the gate to somewhat after they reachedcruise altitude. I used top-down view in slew mode to dothis and used MS Traffic Map to get the following actualspeeds. FS9 was set to normal speed.PAIaircraft.cfg cruise_speed=530aircraft.txt cruise speed = 530Actual maximum speed reached was 494 ground speed. Cruise wasabout 480.AIAaircraft.cfg cruise_speed=477aircraft.txt cruise speed = 477Maximum speed reached was 454 ground speed. Cruise wasabout 447.I did not follow the MS one.I understand that TTools uses the speed in the aircraft.txt to determine the arrival time. The following are from AITM:Same two models as above.PAI modelRJAA to RCTPdepart 02:47:21arrive 05:15:211177nmthis calculates to an average speed of 477AIA modelRKSI to VTSPdepart 00:14:46arrive 05:22:462331nmgives an average speed of 454These calculated average speeds are different from theaircraft.txt speeds of 530 and 477 but are remarkably closeto the actual cruise speeds observed. But clearly an ac doesn't maintain a constant cruise speed from gate to gate. DoesTTools think that the ai will actaully cruise at the speedin the aircraft.txt and adjust it's calculation downwards for climb and descent differences? The ones Iobserved didn't cruise at the reference speed.Is this why some FP developers and maybe UT think thatthis is not enough of a decrease and further compensateby lowering the aircraft.txt speed to have TTools computea later arrival time?If climb and descent speeds are taken into account, I wouldthink so also. But the MS stock aircraft.cfg and aircraft.txtentries use an identical speed value, there is no adjustment!Which is correct? Or are they both correct and some otheraspect has an influence?When I convert the FPs from @ to non @, the traffic BGLincreases in size slightly. One assumption is that the FPcompiler is placing ai in more sectors, possibly flyoversectors, as a result of the above mentioned non @, letTTools compute the arrival time, process.How does TTools and FS9 handle the in-between flyover sectors?The reason for this is that I really got tired of "the swarm"and I might even learn something in the process. I know,get FSX, but that's another discussion.Finally, am I doing this right?All the departure ai that I have looked at departed when theywere scheduled to. I have not tracked as many arrivals butthe ones that I have tracked do arrive, but somewhat afterthe scheduled arrival time but within the 45 minute cushion. Whew!

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Long post - lots of questions1. AITM difference / discrepancy - that is because AITM does not look at the aircraft.txt cruise speed but the cruise speed set for that model in the AITM_AC.CFG file.2. Difference between aircraft.cfg cruise speed and the observed in game cruise speed - that is because the ingame speed is impacted by weather and aircraft weight. When AI aircraft are generated - the flightplan timing for the current leg is no longer used and the AI aircraft flies according to it's flight dynamics and the weather.3. Climb and descent - to my knowledge neither TrafficTools nor TrafficDatabaseBuilder account for climb and descent. FS2004 does include a borrowed idea from Lee Swordy.When Traffic Tools calculates a fixed arrival time (@) - the actual time written to the traffic file is 15 minutes earlier than the time by the @ symbol. This is because Lee observed that AI aircraft were generated at the time in the traffic file - he had to back-time the file to allow for descent and landing.In FS2004 MS uses that concept - expect on the fly - by doing the 15 min back timing in realtime. Flight plans with the @ symbol actually have the AI aircraft created 30 minutes before arrival - but for jets with the expanded AI zone - this actually works out well.This is also the reason for your late arrivals - the aircraft is generated 15 minutes before the arrival time - but it is probably not enough time to descend and land by the arrival time.Actually the entire concept of arrival time in FS AI flight plans is an artificial concept.The proper term would be "initialization time" - the time the AI aircraft is created - the arrival time is subject to/ variable because of the flight dynamics and weather.For example - I've seen AI aircraft on a KDFW-KABQ flight generated at the same time and spot whether the landing was on Rwy 26 or Rwy 8 - but there is about a 12 minute longer arrival time at the gate for aircraft landing on Rwy 8.4. Aircraft.txt cruise speed vs compiled flight plan speed - I think, and this is just a guess, that TrafficTools calculates GRIDS not MILES.5. The Microsoft default aircraft are what the program is designed to utilize properly. But they are designed to be used in flight plans created by TrafficDatabaseBuilder - not Traffic Tools.My personal view is that one should have a solid, verifiable reason to go away from the default standard.I know many flight dynamics are set to be more "realistic" than the default AI aircraft.Frankly the best thing you can do to minimize the flocking and approach overruns is to replace all your AI aircraft Flight Dynamics with default FS2004 flight dynamics - most of my AI aircraft use the default B734, and a few the B747 - including my B-52's.That really, really helps.Flight plans compiled with TrafficDatabaseBuilder also appear to be less subject to the flocking and approach crowding issues. I don't know why, expect that Traffic Tools ir probably missing something. Lee had to do so much work and make so many assumptions without any help / documentation from Microsoft.But to summarize, Jim frequently describes timing errors in FS2004 - and those will impact traffic despite our best efforts and strictest compilance with the SDK's.

Share this post


Link to post
Share on other sites

Thanks for responding, Reggie.Sorry about the spacing in the last post, but I knew I wouldn't be able to compose that in one sitting so I did it in Notepad and then pasted it. It didn't come out the way I thought it would.I believe that you stated in another post that you use only 3 FDs; small, medium and large. Could you elaborate, please?Small ?Medium B734?Large B747?I replaced the PAI B734 aircraft.cfg with the MS stock b737-400 aircraft.cfg and ran a few tests. It appears to be OK. I'll look at it more later.By the way, your suggestion to 'don't take the first vectors offered by ATC but ask for another approach' broke the mental log jam I had about approaches. That, in fact, cleared up any questions I had about approaches.EDIT:I made a mistake in the first rendition of this post concerning the @ symbol and edited it out.

Share this post


Link to post
Share on other sites

In the previuos post I edited out some comments on the arrival time. After looking at it again, maybe I was right.I compiled and decompiled an FP using both the @ and non @. The arrival times were about a minute or so apart. Does this mean that if you use the @, TTools subtracts the 15 minutes in the traffic.bgl, but then adds it back in to the arrival time in the flightplans.txt file when decompiling? Is this what I'm missing?

Share this post


Link to post
Share on other sites

Yes, TTools does reset the @ symbol arrival time by 15 min on a decompile.TTools stores a marker - and "on" bit vs a standard "off" bit in TTools created traffic files which tell TTools that the lef of the flight plan has forced arrival times with the @ symbol.MS used the same bit to indicate "Patterns" - TNG in FS2004.So Lee had to chose another one for FS2004. That was the main change in FS2002 and FS2004 traffic file structure from Traffic Tools.But also remember this - AI cruise speeds are only designed to calculate a grid for aircraft appearance. MS/ FS doesn't expect to fly an AI aircraft more than about 200nm if it is transiting overhead, or about 100nm if it is landing or taking off near your aircraft.So a couple minutes either way isnt' a bit deal.I get the impression that following an AI aircraft from takeoff to landing is not something which MS anticipated we would do - especially on long flights.

Share this post


Link to post
Share on other sites

Good, I'm making some progress. Now I think I have a grip on the departure and landing sector mechanics.Flyover sectors:I hear some people say that they pass the same ai flight multiple times on a long distance flight. I fly almost exclusively bush so I have never seen this, but I have no reason to believe that it is not true. If so, would that be a result of using the 200 speed @ settings in the aircraft.txt and the real airline schedule arrival time? The time and placement that TTools would use to fill in the flyover sectors in the traffic.bgl would be based on a speed of 200. And what happens when TTools exhausts the flight time available for that leg. Does it just not fill in some flyover sectors? Or is the ai placement within each sector truncated. Or prematurely spawned in each sector?ie:In the following example I just made the numbers up so that they are easily divisible.The schedule used is a real world schedule which has a flighttime of 5 hours and an ai with an average speed of 400 giving 2000nm.2000nm flight at aircraft.txt speed of 200 gives 10 hours.A sector is 106 or so, I believe. Let's say 100; it's easier. I'll ask about the 200nm you mentioned later in the post.That gives 20 sectors for TTools to fill.At a speed of 200 the ai would transit a sector in one half hour.That gives TTools ten hours to fillBut it doesn't have 10 hours till the arrival time, only 5. So the ai must:1. Fly only part of each sector.2. Not fly some sectors, possibly toward the end of the leg.3. The ai get spawned in each sector at a time corresponding to the realtion between the arrival time and 200 speed, thus giving the multiple overtake phenomenon. This is what I suspect.4. Something else.If any of the first 3 are the case, then it would seem that making the aircraft.txt speed equal to the aircraft.cfg speed and letting TTools calculate the arrival time would negate, or at least limit, this occurrance. And is that why my non @ compiled bgl's are a bit larger than the @ ones?You mentioned:'AI cruise speeds are only designed to calculate a grid for aircraft appearance. MS/ FS doesn't expect to fly an AI aircraft more than about 200nm if it is transiting overhead, or about 100nm if it is landing or taking off near your aircraft'I thought that the sector was about 106nm. I don't understand the 200. That's the first time I've heard that number. 200 doesn't fit with the above example, but using 200 instead would merely change the numbers. TTools would still have twice the schedule time to fill.Edit:Ok, I understand the 200. 200 across the sector, 100 or so from the point of the user ac. The example would then be 10 sectors to fill at an hour a sector with the same result.

Share this post


Link to post
Share on other sites

Did you copy a post of mine from about three years ago? :-)You've got the basics right. The active AI zone and the grid settings do not appear to be totally in sync - and one of the major improvements in FS2004 was the ability to have aircraft in different grids flying at the same time.The 200nm is just approx the areas from the user aircraft.Some Active AI zones are much smaller than 100nm from the user aircraft. The English Channel appears to have a pretty narrow AI zone which will show aircraft on both sides. Most of the time you get only one side of the Channel AI.There are several other areas of the world - national boundaries and geographical boundaries appear to come into play.One issue with LOWI is that AI aircraft directed out to the northwest by ATC cross an AI boundary and disappear if there is too much traffic - about 35nm out. So they popup at the gate.KSAN has an issue with AI aircraft from the east only being created about 40nm from the airport.The 200 ktas cruise speed is focused on having the most accurate timing in a flight plan at the arrival point.Not caring about realistic timing enroute.Other simmers are concerned with balancing the two.No matter what speeds are used in the flight plan - enroute AI aircraft are going to come and go, appear/ disappear, etc.Part of that is the way they fly - and part of your aircraft crossing major boundaries.I usually see AI aircraft on the same route as me cross the AI zone to the north and west above the equator - their great circle routing. But as I make turns they come back again.Now remember on your 10 grid example - that the AI aircraft never flies the entire 10 grids unless the user aircraft stays close enough to it throughout the entire flight.Most of the time the AI aircraft will appear in the first five grids - and never appear in the next four grids - it will appear 30 minutes before arrival in the final grid.When you fly with AI aircraft for an entire flight - you mess up the grid / flight plan system.I've flown flights following an AI aircraft where the AI aircraft arrived 2 hours early at the destination - because of favorable winds / weather. The real world schedule for this flight from Europe to Dallas has about 2 1/2 hours of slack built in.Keeping the same session running, never reloading the AI, I left the AI aircraft on the ground at KDFW and flew my aircraft out to KTUL. Sure enough the AI aircraft appears over KTUL on schedule and I was able to chase it again and watch it land at KDFW on time - the second landing within three hours for the same AI flight.Why did this happen?When I left KDFW for KTUL - as soon as I crossed far enough to take KDFW out of the Active AI zone - the airport was wiped clean of AI traffic - and it only reloaded when I got back close to the airport - and of course it reloaded the AI traffic fresh from the traffic file times - not for the times which had been true three hours previously.When we start flying with AI aircraft more than one trip across the current AI zone - we really start messing with the program capabilities.Many of these issues would not occur if FS was designed for real time AI all the time worldwide.But nobody has a computer capable of running that kind of traffic - so what we have is a "slice of time" look at AI traffic - and that can have it's own weirdness.

Share this post


Link to post
Share on other sites

No, I don't believe I read that post although I have read plenty of others and they are always worth the time. Jim Vile, also. Does it still exist? I started with fs9, and I remember that about 3 years ago I was still at the point where I spent an entire day trying to figure out the PAI MD8x texture naming.Trying to get a mental picture of the 'time slice' is really quite anti-intuitive and I won't even get into the Time Zone issues unless you want to.-----------'I usually see AI aircraft on the same route as me cross the AI zone to the north and west above the equator - their great circle routing. But as I make turns they come back again.'-----------I believe I've seen this also.I've heard it stated 'if you use the @ be sure to use the 200 speed'. Shouldn't there be another factor attached to this?'if you use real time schedules'.In my estimation, if you use real time schedules and unless the aircraft.txt speed/placement value is 200 or so and even with the @, a number of the FP turnaround times are too short for the ai to arrive before the departure time, thus causing the ai to disappear. Some are too short anyway.But would that be the case with computed arrivals?That is:1. Use the same speed from the aircraft.cfg in the aircraft.txt2. Let TTools compute the arrival time3. 45 Minute minimum turnaround4. Fix up any schedule anomolies4. Reattach the @5. Recompile the traffic bglThis would give an extra 15 minutes in the arrival zone. I know, I could always just make the minimum an hour, but just for discussion, would the above cause any unwanted anomolies.My guess is that there would be a 15 minute discrepancy between what TTools calculated for the landing sector and the adjacent sector.The ai FD replacement:Do you mean replace the .air file with the MS stock but do not replace the aircraft.cfg?

Share this post


Link to post
Share on other sites

No need to look at the old post - you followed the same through process I did.TimeZones are easy to fix in FS - download FSRealtime and do the install - it will install Dennis Thompson's modified scenery files with much more realistic time zones. I don't use FSRealtime while flying - but the install of Dennis files is much easier that way.Also, make sure that every month you run the update so the timezone changes occur around the world.I use the @ symbol in the majority of my flight plans and use the cruise speed close to the aircraft.cfg speed.The PAI A340 series aircraft are the only one on my main computer where I must use a lower AI speed.But 200kts for all AI aircraft increases the flocking effect. I just cut the aircraft speed down to something below 300 ktas.However I have another computer where the same files - aircraft and traffic - produce different reeults.We would all be better off to use TrafficDatabaseBuilder - but many airline flight schedules will not work without a lot of extra aircraft due to the 45 minute minumum turnaround time.For common flight dynamics - I replace both the .AIR file and all entries in the aircraft.cfg file except the lights, contact points and fltsim.x sections with a default aircraft set.

Share this post


Link to post
Share on other sites

I have TZ30 installed.About the different computer producing different results, it could be the manner in which FS9 interfaces with the different PC's internal clock. Different PC's clocks may have different characteristics. That's the only variable I can think of.I've read the TrafficDatabaseBuilder docs also and yes, we do break just about all of the rules. Actually, TDB works from available parking spots backwards to build the FPs and most of us do it the other way around!So, what I'm about to do looks about the same as you have it and if I go to FSX I'll have more knowledge from the start. I'm going to wait a bit on that. I guess that about closes it out for now unless there's something else or you have any questions for me. Many thanks for your help; now and for the many helpful posts in the past and future.

Share this post


Link to post
Share on other sites

Hi Bob,I took a look at the Lee Swordy's traffic tools source code to find an answer to your question about traveling 2000nm in 5 hours.It looks to me that if you specify a cruise speed with no arrival time, then the sector crossing are calculated using the applied cruise speed. However, if you supply an arrival time, then the supplied cruise speed is ignored and the cruise speed used to calculate sector crossings is based on (arrival time - departure time) / distance.Here is the comment in the source just before the call to calculate the actual cruise speed... //---- if this leg uses a fixed arrival time then calculate the cruise speed // we need in order to arrive at the specified arrival time. // otherwise we will use the given cruise speed for calculationsHope this helps....Lee Steffensen

Share this post


Link to post
Share on other sites

Hi Lee.The TTools docs state:----------------9. What the traffiic file DOESN'T controlAI performance: You cannot alter the cruising speeds or the climb and descent profiles of the AI aircraft. The cruising speeds are defined in the aircraft.cfg files. Manoeuvring behaviour is hard-coded in the FS software----------------So it seems that there could be a discrepancy between what TTools calculates for flight time positioning and what actually occurs when FS9 is running.That:1. The (arrival time - departure time) / distance or aircraft.txt speed is used by TTools, depending on the flightplans.txt.2. Aircraft.cfg speed and model characteristics are used by FS9 in game.That if 1 and 2 above do not correspond, the ai will have a tendency to be more active in the arrival sector at the expense of flyover sectors to a greater or lesser degree depending on the relationship of 1 and 2. Given the example that I used, Reggie states that the ai will simply not fly some of them.The same flight plan compiled with and without the @ gives a different size bgl. The one without the @ is larger. What contributes to this I have not, as yet, determined. Use one of the larger carriers FP's to try it.I set up a simple 1 leg traffic.bgl and looked at it with a hex editor. The layout looks fairly uncomplicated; a header or two followed by a string of coordinates and then the airport info.Deciphering the values and their relationships would take much more doing and I would tend to think that Lee Swordy put a great deal of thought into this and there wouldn't be much improvement to bemade, if any, by changing it.That being said, I presume TTools is open source and that it is C because C string functions would handle the flightplans.txt quite nicely.Where would the code be available for download, or you could email it if you're one of those generous people.Thanks

Share this post


Link to post
Share on other sites

See below for my replies....>Hi Lee.>>The TTools docs state:>---------------->9. What the traffiic file DOESN'T control>AI performance: You cannot alter the cruising speeds or the>climb and descent profiles of the AI aircraft. The cruising>speeds are defined in the aircraft.cfg files. Manoeuvring>behaviour is hard-coded in the FS software>---------------->>So it seems that there could be a discrepancy between what>TTools calculates for flight time positioning and what>actually occurs when FS9 is running.>>That:>1. The (arrival time - departure time) / distance or>aircraft.txt speed is used by TTools, depending on the>flightplans.txt.>>2. Aircraft.cfg speed and model characteristics are used by>FS9 in game.>>That if 1 and 2 above do not correspond, the ai will have a>tendency to be more active in the arrival sector at the>expense of flyover sectors to a greater or lesser degree>depending on the relationship of 1 and 2. Given the example>that I used, Reggie states that the ai will simply not fly>some of them.I totally agree with this. The cruise speed specified in the flightplan is only used to determine when the aircraft shows up in the appropriate AI sector. Once the plane is there, the aircraft.cfg file (and it's .air file) determines how the plane will fly, including how fast it flies. So if the cruise speed in the aircraft.cfg file does not match the cruise speed in the flight plan, then a discrepency will exist.Now with all of that being said, does it matter? Not really. If you look at the discrepency, what is really happening here. The plane appears at some point in time in an adjacent sector to your aircraft or it takes off in your sector or an adjacent sector. When this occurs is based on the cruise speed in the flight plan or the departure time in the flight plan. It then flys it's route (in a manner based on the .cfg and .air files) until one of two events occur. It lands, or it leaves the adjacent sector of your aircraft's sector. In both cases, if the cruise speed in the aircraft.cfg file is higher then the cruise speed in the flight plan, this occurs earlier then expected by the flight plan. But who cares, if you look at it from your aircraft's point of reference, the AI plane no longer exists or is on the ground. Though I won't say the same if I'm at an airport watching the planes come in.>>The same flight plan compiled with and without the @ gives a>different size bgl. The one without the @ is larger. What>contributes to this I have not, as yet, determined. Use one of>the larger carriers FP's to try it.That's very interesting. I believe the file structure is static given the same legs in the flight plan. When I find some free time I'll have to look into it. >>I set up a simple 1 leg traffic.bgl and looked at it with a>hex editor. The layout looks fairly uncomplicated; a header or>two followed by a string of coordinates and then the airport>info.The flight plan file is actually comprised of four internal databases. Airports, Airplanes, Routes, and Sector boundry crossings.>Deciphering the values and their relationships would take much>more doing and I would tend to think that Lee Swordy put a>great deal of thought into this and there wouldn't be much>improvement to be>made, if any, by changing it.>He did. His code is quite comprehensive.>That being said, I presume TTools is open source and that it>is C because C string functions would handle the>flightplans.txt quite nicely.>His code is in C. It handles not only the parsing of the text files easily, but it also handles the binary bgl files in a simple matter. I can say that my implementation in C# is not as elegant.>Where would the code be available for download, or you could>email it if you're one of those generous people.>You can download the source code for the FS2002 version right here on Avsim. Lee open sourced it. I asked him directly for the FS2004 code. Comparison between the two is minimal. Some of the differences were discussed by Reggie such as AI planes doing patterns. In any case, the FS2002 code will give you a real good understanding on how the bgl files are formatted. Lee did a good job documenting the files structures.I would like to provide you the FS2004 version source, but Lee didn't give me permission to distribute it and I would like to not rock the boat. I've already gotten lashed about continuing his work. :(Great discussion!!!Lee Steffensen

Share this post


Link to post
Share on other sites

LeeOK, I see it. It's the 'Traffic Tools Source Code v1.3.3' item. That's OK about the FS2004 code because I didn't plan on changing anything. It's just that this aspect of FS9 has intrigued me for quite some time.I see what you and Reggie mean by the 'slice of time' aspect and at least to me, it is quite twilight zone-ish and it's probably that way to most people. Someone posted that 'It's amazing that Flight Sim does the things it does' and that is very true.I haven't done any flying in the last three days, so the next flight should be quite enjoyable.

Share this post


Link to post
Share on other sites

LeeI was under the impression that the speed value in the aircraft.txt was used for calculations in all circumstances.However, what it looks like is:1. If the @ is used, the speed in the aircraft.txt is used for calculation only when the gate to gate time <= 30 min.2. Otherwise it is overriden by the calculated speed.3. If no @, then the aircraft.txt speed is used.The resulting value from 1, 2 or 3 is then used to calculate the sector placement.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this