AI Flight Plans

[gsnde]

Originally Posted by jvile

There are very few people that write FP's using the FSX FP compiler and fewer people writting TNG FP's.

Jim,

What other ways you can write true FSX AI flight plans if not by using the FSX compiler?

[DanKH]

OK, I think a Go-around could be categorized as a TNG circuit, as the TNG's doesn't actually T before they G .... my AI turns the pattern way when they have to perform a Go-around. Pure coincidence or use of Pattern...I don't know.

[DanKH]

Originally Posted by gsnde

Jim,

What other ways you can write true FSX AI flight plans if not by using the FSX compiler?

I think Jim refers to the FS9 converter tools also available here. so you compile a genuine FS9 flightplan, and convert it into FSX. but the data beneath is the well known TTools style txt-files and not the .dat files you should make to comply with the SDK.

[gsnde]

I see. What is such a converted flight plan technically - FSX or FS9?

I lived under the impression that using FS9 flight plans in FSX will kill the FSX AI traffic and revert to a FS9 compatibility mode.

For this reason I have abandoned my old Excel flight plan tool and build a new one following the new syntax

[jvile]

OK, I think a Go-around could be categorized as a TNG circuit, as the TNG's doesn't actually T before they G .... my AI turns the pattern way when they have to perform a Go-around. Pure coincidence or use of Pattern...I don't know.

Its not coincidence but more of codes that are used for instructions.

When you say go around, what is going around. Each different type Plane (USER/AI) is controlled by different codes and then factor in VFR vs IFR.

You say the AI turn the pattern way when going missed. Are they IFR or VFR?

If you observe a AI Plane on a VFR FP the approach to downwind is based on direction of arrival heading. The missed approach turn is also part of the dll and can be a left or right turn downwind. You might see one VFR AI turn right and another turn left.

FSX uses hardcode values for USER type planes flying VFR which the Control Tower instructs what to do for the pattern approach. If you are VFR and go around there is no ATC to tell you what to do.

FSX uses another set of instruction rules if you the USER is on a VFR FP and if you go missed Tower tells you to contact ATC departure which makes the decision on which way to turn. That turn is based on the shortest radius of the heading you are flying (in respect to TH of the runway) in most cases or the terrain elevation matrix or the distanced traveled after being told to contact departure, etc., etc., etc. (many varibles).

AI Planes that are on a VFR or IFR FP use another set of instruction rules. Some of these approach/missed approach rules also apply to a USER plane on a IFR FP

When you are VFR other then contact Tower for landing you are the PIC and have to make all the right decisions.

User/AI on FP's are controlled by the ATC decision making and we can write code to change the behavior of both the approach and missed approach along with controlling which way the AI will turn or which way ATC will tell you to turn.

TNG is a AI Plane that has no instructions from anyone. FS9 and FSX gives us some control in how a TNG will behave in the Pattern and Altitude settings but all of that is part of the Runway properties. VFR TNG is not in control of any ATC like a IFR TNG so must use the runway properties for the control of instructions.

[jvile]

What other ways you can write true FSX AI flight plans if not by using the FSX compiler?

Martin

There are none.

Many think that TTools is a substitude for FSX type FP's and it is not. Even when you use some type converter for FP's from FS9 to FSX the FP's do not work 100 percent.

But at present it is better then no FP's at all.

Under certain circumstances FSX will load double AI Planes (duplicate FP's) into the visual airborne zone (not on the ground) when using TTool FP's. This is turn drops the FPS on a good computer to a very low value. The only way to see this is happening in the airborne Visual Zone is with TrafficLook.dll or TrafficToolBox.dll. You must restart AI Traffic to rid the visual zone of these duplicate flights.

What we have to understand is TTools is a FS2002 FP program. That's right a FS2002 FP program.

When we copied over the FS2002 FP's to FS2004 we had problems. Many of the AI Planes stopped showing up same now with FSX.

Lee Swordy never updated TTools for FS2004 but open sourced the code so any one with code knowledge could rewrite TTools for FS2004. Several Payware FP Co's did change some coding for their FP's but not all of it.

MS changed the address where Lee had written the code for the @ symbol and used it for TNG. MS liked Lee's @ back timed 15 minute arrival rule so much they hard coded it into all FS2004 FP's. This caused such a timing issue into the arrival zone we had to change the FP compiled aircraft.txt speed to half the IAS so most AI Planes would start to show up at the Visual zone sector.

Now start to factor in the problems going from FS2002 to FS2004 and now up to FSX. Its a wonder anything shows up with a TTool FP but like you say it knocks out the FSX FP's partially.

So we now have FP's by TTools that

@ symbol is corrupting FSX default arrival timing into the visual zone
IAS speeds in the compiled Aircraft.txt that still need a half value if @ is present
TNG in both FS9/FSX is addressed where @ was located in FS2002
Scaler factors that FSX uses for FP compiling and in the APX Airport Header is not understood by TTools
TTools is its own compiler and does not play by the same rules that FS9/FSX plays by
45 mimute turn around not honored which could also be why AI Planes will not come out of Pre Clearence mode due to timing issues
In some cases on startup AI Planes are spawning in duplicates within the visual airborne zone sectors
etc
etc

[DanKH]

Hm... maybe it's time to brush off Ye Olde Visual Studio 2005 and "reinvent" a GUI that can make/compile genuine Flightplans....

I'll see if it's something for me.....

Meanwhile I too use ole FS flightplans and indeed ai-aircraft fro my AI, an using Peters AIFPC to convert them into "FSX" plans. at least flightplans converted with his tool doesn't eliminate the default AI traffic in FSX.

[jvile]

Dan

I am using Peters program also to get the airport ICAO codes correct and the days of the week.

If you came up with a FSX FP compiler it would probably be the first beside the way FSX wants it done.

[scruffyduck]

Originally Posted by DanKH

Hm... maybe it's time to brush off Ye Olde Visual Studio 2005 ....

Hmmm I never thought of it quite like that Dan

[gsnde]

Originally Posted by jvile

Martin

There are none.

Jim,

I am making flight plans according to the descriptions in the FSX Traffic Toolsbox SDK, compiling them with TrafficDatabaseBuilder.exe.

The flight plans are in this format:

C182-0,G-ASDF,33,ONE_WEEK,VFR
{
61901,KSLE,65,,62000
62000,KEUG,55
}

Do I get it right that you are telling me that this is still not an FSX flight plan ?

[DanKH]

Originally Posted by gsnde

Jim,

I am making flight plans according to the descriptions in the FSX Traffic Toolsbox SDK, compiling them with TrafficDatabaseBuilder.exe.

The flight plans are in this format:

C182-0,G-ASDF,33,ONE_WEEK,VFR
{
61901,KSLE,65,,62000
62000,KEUG,55
}

Do I get it right that you are telling me that this is still not an FSX flight plan ?

Nope, that is a genuine FSX flightplan, nothing more and nothing less ;-)

[gsnde]

Gosh, I am glad I shorty felt like Arthur Dent.

The new format is much better readable compared to the FS9 version, that is why I like it.

What I still don't understand is what those converted FS9 flight plans are in technical terms. I know that some converters correct the day shift and the changed icao codes. Fine. And it seems that FSX does not fall back into the FS9 compatibility mode when using such converted flight plans. OK. That would mean they are no longer in FS9 format (otherwise FSX would fallback to compatibility mode, right?).

But neither they are true FSX format files. Because extracting the flight plan data from such a converted flight plans is producing the TTools format.

I can hardly believe that the difference between FS9 and FSX is a different header and a different start of week.

[Mace]

Originally Posted by gsnde

I see. What is such a converted flight plan technically - FSX or FS9?

If it is compiled using FSX's TDBB then it's an FSX flight plan and will work 100% in FSX. Unlike FS9 ai bgl files.

It is not YOUR flight plan however, since you didn't write the plans. You simply converted them. That's why it would be the right thing to do, to ask permission from the original author, if you were thinking of uploading.

We had a thread on this a while back, "The ethics of FSX flight plan conversions".

I have created the following AI packages for myself:
American
Continental
TACA
Copa
Icelandair
Aeromexico/Aerolitoral
Mexicana/Click!
Northwest
Delta
Aeroperlas
Air Jamaica
Jet Blue
Avianca
Frontier

...all of them converted flight plans.

And none of them uploaded.

I only have permission to upload from 1 author, and that is Carlos Augusto Narvaez-Diaz. I have not attempted to ask Brian Wheatley or any of the other FP authors whose plans that I used.

I lived under the impression that using FS9 flight plans in FSX will kill the FSX AI traffic and revert to a FS9 compatibility mode.

that is correct to the extent of my testing.

For this reason I have abandoned my old Excel flight plan tool and build a new one following the new syntax

You are writing something to convert? or prepare? If you do, then keep in mind the date differences between FS2004 and FSX:

This is a change most converters ignore, and it can mess up all of the flight plans:

FS2004:
0 = Sunday/Sonntag
1 = Mon/Donnerstag
2 = Tues/etc
3 = Wed
4 = Thur
5 = Fri
6 = Sat

FSX:
0 = Monday
1 = Tues
2 = Wed
3 = Thur
4 = Fri
5 = Sat
6 = Sun

Sheesh my german is rusty, can't remember all the days anymore.

[jvile]

Martin

You ask me

What other ways you can write true FSX AI flight plans if not by using the FSX compiler?

I said "there are none." That means based on your question that the only true way to write FSX FP's is using the FSX SDK TDBB Utility until someone produces a FP builder that is more friendly.

That also means you are using the only true way that is compatible for now with how FSX processes the FP's.

[Mace]

Originally Posted by gsnde

What I still don't understand is what those converted FS9 flight plans are in technical terms. I know that some converters correct the day shift and the changed icao codes. Fine. And it seems that FSX does not fall back into the FS9 compatibility mode when using such converted flight plans. OK. That would mean they are no longer in FS9 format (otherwise FSX would fallback to compatibility mode, right?).

I think when you talk of "flight plans" you are really talking about bgl files. In this case they are traffic bgl files. They are a type of scenery file and they are binary in format.

If you are talking purely of "flight plans" then they are simply text files, and they can be in either FS9 or FSX format depending on which compiler you want to run them through.

Basically

If the plan is compiled using TDBB, then it's an FSX traffic bgl.

If the plan is compiled using TTools, then it's a FS9 traffic bgl.

But neither they are true FSX format files. Because extracting the flight plan data from such a converted flight plans is producing the TTools format.

If you use a program that is designed to pull data out of the bgl and put it into TTools format, you have effectively converted it BACK to FS9 standards, because TDBB won't accept txt files in TTools format. That is why we have all of the converters available.

Take for example my traffic_cmp.bgl. (FSX ai traffic bgl for Copa Airlines).
The bgl itself is an FSX ai traffic bgl because i compiled it using TDBB.

However, I could easily take one of the many converter/manipulator programs available, and extract the flight plans from my bgl, and they could be extracted into TTools format.

My bgl is still an FSX bgl. It's all a matter of conversions.

I can hardly believe that the difference between FS9 and FSX is a different header and a different start of week.

There are more differences than that. The date format itself has changed inside the bgl. I think it is 32-bit in FSX. I can't remember, and I am not that knowlegable about the traffic bgl's beyond that. Someone like Jens Rabmund posted on that once and explained all of the differences they discovered. That was early in the FSX days, like Oktober/November.

[gsnde]

Originally Posted by Mace

It is not YOUR flight plan however, since you didn't write the plans. You simply converted them. That's why it would be the right thing to do, to ask permission from the original author, if you were thinking of uploading.

Very true.

Originally Posted by Mace

Sheesh my german is rusty, can't remember all the days anymore.

• Montag
• Dienstag
• Mittwoch
• Donnerstag
• Freitag
• Samstag
• Sonntag

... if you really wanna know

Originally Posted by Mace

You are writing something to convert? or prepare? If you do, then keep in mind the date differences between FS2004 and FSX:

I find it annoying to write flight plan sources from free hand. Therefore I have made an Excel workbook, where I can build my flight plan and which then produces the aircraft and flightplan source files for compiling. Since I have made a completely new one for FSX, everything is according to the SDK.

Originally Posted by jvile

I said "there are none." That means based on your question that the only true way to write FSX FP's is using the FSX SDK TDBB Utility until someone produces a FP builder that is more friendly.

Jim, today your answer makes perfect sense. Yesterday the meaning was not coming through. Probably a bad case of spasm in the English Interpreter part of my brain.

Originally Posted by Mace

I think when you talk of "flight plans" you are really talking about bgl files.

Yes, Rhett, exactly that I was doing, which probably have added to the confusion.

Thanks everybody for your explanations !

[samcaine]

I know that this getting well off topic, although it is quite closely linked to creating airfields. But is there an easy to understand guide or forum thread anywhere about creating/converting flightplans for FSX?

[gsnde]

As for creating flight plans: I found the description in the SDK very well written. The compiler is a bit harsh in terms of parking requirements. It is checking the parking spot definitions of all airports touched by your flight plans against the FSX default.

Say you want to create military traffic, where Microsoft has provided only a runway in most cases, you have to create your own airport definition file providing enough parking spots only to compile the flight plan.

You better have the appropriate "AFCADs" in the simulator as well, otherwise you will see your planes vanish at the places which are not providing enough parking.

I have build the traffic for my airport. Right now I have only made the AFCAD for my own airport, most of the others ones I am sending my aircrafts to are only runways. My airport definition file is so to say a "fake", only allowing me to compile the plan. But on my airport all planes are starting and landing as supposed to.

This means you can start without populating 150 other airports with parking spots beforehand.

As for converting flight plans: there is not much to say, just select old FS9 and convert, e.g. with this tool here.

[Mace]

Originally Posted by samcaine

I know that this getting well off topic, although it is quite closely linked to creating airfields. But is there an easy to understand guide or forum thread anywhere about creating/converting flightplans for FSX?

I use a program by Jens Rabmund to convert. If you search the File Library at AVSIM for his name, you'll find his converter.

Here is my method for American Airlines (AAL), for example, step-by-step:
1) gather all info I can on the airline--download all liveries, aircraft, flight plans
2) create an aal_airports.dat file. Look at the SDK-supplied fs10airports.dat file to use as a template. Only put in airports that AAL flies too, of course.
3) create an aal_aircraft.csv file. Look at the SDK-supplied .csv file to use as a template. Only put in aircraft that AAL actually uses...
4) your downloaded flightplan is probably in TTools format. Here you run the TTools file thru Jens Rabmund's converter...and you have an FSX flight plan file.
5) run it all through TrafficDatabaseBuilder.exe.

That's it.

[rfields]

One thing which I don't see here is a description of what is in the traffic.bgl.

TrafficTools creates traffic files based on the FS2002 parameters which the developer worked out - to allow people to use a reduced set of input files with less data than the MS flight plan compiler. As Jim noted TTools was only tweaked to avoid a couple major issues for FS2004 - it was never rewritten to FS2004 standards.

Microsoft's TrafficDatabaseBuilder has two separate functions.

The first is a qualifier where it checks the input files to see if the flights are valid.

These include aircraft range, is the runway appropriate and long enough for the aircraft, does the airport have parking for the aircraft, can the aircraft fly over enroute terrrain, minimum turnaround time, etc. You would not believe the number of 'high quality' and '100% accurate' flightplans from the best known names in the AI community - which will not meet those criteria. They seem to be immune to actually checking to see if the airport identification program they use is accurate, if the aircraft can actually make the flight on range - many airlines have technical fuel stops for long routes - but the stops don't appear on schedules. Many schedules have 1,000 nm flights in less than 1 hour, etc.

But that's another subject/ discussion.

But just like TTools, TDBB works from a set of text based input files - it does not check the FS data files during this process. It does not check the aircraft.cfg and .AIR files to see if the data you entered is right. It does not check the airports data files to see if the data is correct. It only uses the input files and data you enter, you can manipulate.

If TDBB says the airport has no parking, you do not have to add parking to the airport, you can add spots to the airports data file.

In contrast TTools only checks it's formatting - not any performance parameters.

The big reason for TTools to exist and the big difference with TDBB is the fixed arrival time. People who want 'real world schedules' quickly realized that using the aircraft speed to calculate flight times would not work. Real world schedules are based on many factors and not every leg has the same average speed. Also some airlines base their entire operational concept on quick turnarounds - much shorter than the 45 minutes in TDBB.

The problem with a fixed arrival time is that it messes up the traffic .BGL file.

A flight plan is NOT takeoff from ABCD at 1215 and land at DEFG at 1615 to FS.

It is something like this:

Takeoff 1215 - TTools/ TDBB cruise speed 470 KTAS
Grid #1 1215-1244
Grid #2 1245-1314
Grid #3 1315-1344
Grid #4 1345-1414
Grid #5 1415-1444
Grid #6 1445-1514
Grid #7 1515-1544
Grid #8 1545-1614
Land 1615

When you load FS and your aircraft is in Grid #5 and the time is between 1415 and 1444 - then that AI aircraft should be passing overhead during that time.

FS depends upon the grid location of your aircraft, the time and which aircraft belong in the grid and adjacent active grids at that time.

Now if we change the TrafficTools cruise speed to 235 KTS to prevent popups caused by corrupted traffic .BGL files - the flight gets written to the traffic file as:

Takeoff 1215 - TTools/ TDBB cruise speed 235 KTAS
Grid #1 1215-1314
Grid #2 1315-1414
Grid #3 1415-1514
Grid #4 1515-1614
Grid #5 1615-1714
Grid #6 1715-1814
Grid #7 1815-1914
Grid #8 1515-1614
Land 1615

As you can see the aircraft is scheduled to be in Grid #4 and Grid #8 at the same time - two different places at once.

Now let's say the next takeoff is scheduled for 2200.

When the arrival airport is active at 1600, the aircraft is initialized in Grid #8 and makes a very steep descent and landing. Because it will not be initialized in the adjacent Grid #7 until 1815 - where it should be initialized to make a proper descent.

This creates/ increases the flocking many people in FS.
This causes double aircraft to appear in the air.
The double aircraft is much worse in the far east when AI aircraft flightplans begins one day in Europe and end the next day in Asia.

If you are flying along with the AI aircraft and it crosses a grid line - way too early - it can disappear, and reappear later in the flight.

All of which drives FS nuts because it expects the flight to be a smooth transition timewise from grid to grid - at a time/ speed which matches closely with the aircraft flight dynamics.

But even without the @ symbol - TrafficTools does not write fully compliant traffic files.

To summarize the basic points

The input file format is just that - input data which must be internally consistent. TTools was created to eliminate checks for invalid flight plans. TDBB does check more qualifications.

The key is the traffic file itself which is a collection of location grids and which aircraft should be in which grid at which time(s).

Do I use TTools flight plans? Of course, even some in FSX, most real world airlines have not been done in TDBB format, and many cannot be done that way.

Do I get upset about the failures, problems and errors caused by them? No I accept that there will be major problems with any TTools created traffic .BGL file - FS2002, FS2004 and especially FSX.

Peter's conversion tool and new compiler for FSX for Traffic Files using TTools input files will do a better job than TrafficTools when he gets it worked out.

But any traffic .BGL file which was created using set arrival times is highly likely to be internally inconsistent. This is especially true if the reduced cruise speed 'band aid' is used.