Print Page | Close Window

Overcoming a Self-Inflicted Compiler Error

Printed From: Just Flight Forum
Category: Just Flight Products
Forum Name: Traffic X / Traffic / Traffic 2005
Forum Description: Discussion area for Traffic titles
Printed Date: 29 Mar 2020 at 9:23am

Topic: Overcoming a Self-Inflicted Compiler Error
Posted By: Soaranden
Subject: Overcoming a Self-Inflicted Compiler Error
Date Posted: 15 Jun 2016 at 11:21am
Recently, I removed (from FSX) two user aircraft that I had been using for AI aircraft. After removing the aircraft and dutifully updating aircraft from cfgs in the Fleet Database, Traffic X would not compile. After deleting the aircraft from the Traffic X Aircraft.tcc file and from the Traffic X AircraftTypes.tcc file, Traffic X would still not compile. Then, I realized that flight plans for both aircraft remained in the TX_VFR_USA.tcc file. I removed the flight plans for the nonexistent aircraft from the TX_VFR_USA.tcc file. After doing so, Traffic X was able to complete a compile successfully.

Missing data is a typical reason that compiles fail. I had been asking Traffic X to compile flight plans for nonexistent aircraft! That was asking a bit much, wouldn't you say? I was lucky that I didn't have schedules for those two aircraft in multiple flight plan files. If I did, I probably would have used the freeware Notepad++ to search all flight plan files for instances of those two aircraft.


Posted By: RayM
Date Posted: 15 Jun 2016 at 4:42pm
up to now I have never removed any aircraft from FSX - thus affecting the Traffic X installation - but I can see how you got into your 'failure to compile' situation.

If you do this again, there is a facility in AIFP which will give you a list of BGL files that contain a particular aircraft.

A long time FSXA and Traffic X user

Posted By: Soaranden
Date Posted: 15 Jun 2016 at 6:30pm
Originally posted by RayM RayM wrote:

up to now I have never removed any aircraft from FSX - thus affecting the Traffic X installation - but I can see how you got into your 'failure to compile' situation.

If you do this again, there is a facility in AIFP which will give you a list of BGL files that contain a particular aircraft.


Thanks for the information about AI Flight Planner.

To make it clear to everyone, I wouldn't have had a problem with Traffic X compiling were it not for the fact that the user aircraft I removed from FSX had been used as AI aircraft in Traffic X flight plans.

Another reason I'm glad you mentioned AI Flight Planner is that I recently upgraded to a new computer, and I had forgotten to install AIFP on the new machine. I see that, as of 5 Jun 2016, AI Flight Planner general release 3.1.21 is available from" rel="nofollow - Stuff 4FS - AI Flight Planner .

Thanks, again, Ray.


Posted By: RayM
Date Posted: 15 Jun 2016 at 6:42pm
AIFP - I find it a useful tool that can add AI to my airports that will ALWAYS appear because I enter a Density value of 1%. My FSX setting is usually about 66%.

I use Traffic X as the tool to add the majority of my AI traffic that will vary every time I compile due to the 'random' Density values that TX adds to every AI flight.

A long time FSXA and Traffic X user

Posted By: freddy
Date Posted: 18 Jun 2016 at 1:56am
Here's an advanced technique ... (warning: this is not for everybody).

To avoid the issues with the randomly generated traffic density value, I back up the schedules.dat file and airport.dat file before I do the compile. I do my edits, add my planes, etc, in to Traffic X as normal, followed also by a normal compile.

After that's complete, I then go in to "MANUAL MODE" ...

I use a text editor to open the new schedules.dat and airport.dat files created by the Traffic X compile, and I cut-and-paste the new/edited aircraft values and airport details out of those files and in to my two previously backed up files. Place these backed up (and now manually edited) files back in to the Traffic X folder, and then MANUALLY compile these by running the "_compile.bat" file (don't do the compile through Traffic X because that would alter the files again). After the MANUAL compile is complete, rename the "Traffic.bgl" file that's created to "TrafficX.bgl" and place that file in to the \Scenery\World\Scenery folder of FSX. Done.

Yes, it's a bit of work ... and there's often a bit more to it than what I've mentioned here, usually involving manual edits to some of the other files too ... but I find this the BEST way to achieve the results I want. I have full and complete control over the files and what's in them, and that results in the EXACT AI experience that I want.


<Gripe On> I wouldn't need to do this if only Just Flight had included an edit field in the Traffic X screens allowing the user to enter their desired traffic density value for each plane. As a default, this field could still contain a randomly generated value, that's fine, but at least they would have allowed the user to "override" that value to a value of their choosing. And while we're at it, Traffic 2005 included a field where the user could enter the required flight level (altitude) for each aircraft ... why oh why was that ever removed from Traffic X? We had all the candy with Traffic 2005, but Traffic X took all the candy away. <Gripe Off>


By the way, it's good to see a post from Soaranden. Welcome back Dan! And, I suppose, it is just good to see a post in here period, it's a little quiet around this place these days.

Posted By: RayM
Date Posted: 18 Jun 2016 at 9:53am

forgive me if I am not appreciating what your procedure achieves.

Are you manually editing the traffic density value that exists in each schedule listed in schedules.dat? Do you only do the particular ones that you want to definitely appear?

It can be very odd to find a Piper Cub or AirCreation 582 struggling along at 17000ft, it has probably taken a couple of hours to even get to that height! You can set a Max Altitude for each aircraft but TX seems to ignore it.

Just to re-iterate that I am 'happy' that TX will give me a varying set of aircraft at an airfield every time I re-compile - this makes life more interesting for me anyway. If I want particular aircraft to ALWAYS appear then I go over to AIFP where I have easy control over the density value. This way I get a mix of aircraft that I know will always appear and others that will vary every time I compile from TX.
AIFP will also allow me to program several TNG flights from an airfield whereas I have found that TX will stop me setting up (sometimes) more than 2 TNG schedules.

A long time FSXA and Traffic X user

Posted By: freddy
Date Posted: 19 Jun 2016 at 1:57am

(Long response ... sorry.)

To answer your question, yes, I am manually editing the traffic density value that exists for each aircraft listed in schedules.dat. And, yes, I generally only do the ones that I specifically want to appear. My traffic slider in FSX is set to 60% for airliners and 100% (yes, 100%) for GA planes. So I've edited the schedules.dat file with that in mind.

It is worth noting that I have effectively been using the same schedules.dat file for ages, because I back it up each and every time BEFORE I do a new Traffic X compile ... so that means, over time (a long time), I have manually edited that file and moulded it in to my own personal AI masterpiece.

By doing manual edits, I can alter the attributes of any AI plane I choose. For example, altitudes (noting of course that most GA planes rarely fly above 10,000 feet). I don't have Piper Cubs or AirCreation 582s struggling along at 17,000 feet. I've manually edited the files to prevent that. Although, admittedly, it is rare that I alter altitudes. But it can be done. It's really handy to edit them when you have mountainous terrain such as the Rocky Mountains, New Zealand, Papua New Guinea, The Himalayas, etc. On some occasions I've even bothered to set even numbered altitudes for North/South flying aircraft, and odd numbered altitudes for East/West flying aircraft ... in an effort to kind of mimick the real-world semicircular/hemispheric rules that apply in various countries for collision avoidance reasons. As a further example, it's easy to place Cessnas at a lower level than, say, King Airs ... and different jets at different altitudes too ... with a share of my corporate jets flying at 30,000 feet and others at 50,000 feet, whilst the commercial airliners fly between 36,000 and 45,000 feet. Etc etc. By manually editing the files and manually compiling, you can achieve all of this.

Yes, as you say, Traffic X does let you set a Max Altitude for each aircraft, which it then seems to ignore ... like your Piper Cubs and AirCreation 582 example. It has quite a few of those kinds of issues (bugs). But it does do one thing really well... Bugs aside, Traffic X does a fantastic job at creating and sorting the AI files for you. It's second to none in that regard. And it even does the liveries too. It's just brilliant for all of that. So that's what I use it for, creating, sorting, and storing the files for me. I then manually edit those to my liking and manually compile. Voila, AI that works how I want it to work.

Touch and goes ... easy ... add them in Traffic X and then manually edit the files so that they appear, at the times you want them to appear. For example, you could have a military airport flying normal flights during the day, then doing touch and goes (training for the cadets) at dusk, before returning to normal flights in the evenings after dusk.

Yada yada yada.

I do like the idea that Just Flight had with this randomness factor. And you're right, it's never the same twice when you go to an airport which does indeed make it more interesting. I am sure that was their thinking. And it's a good idea. However, whilst all that is fine, it annoys the heck out me when I specifically add a new plane, which I might be adding to mimic a real-world schedule, and then this plane doesn't show up. Further compiles make it appear, but then others that I had specifically placed in this way are now no longer showing up ... and so on and so forth. That really irks me. An example ... I added 787 aircraft for nearly every airline that has these flying. To do this, I downloaded an appropriate model and associated liveries. I then did lots of hours of additional livery work (when an appropriate livery for an airline could not be found online, I had to do the livery myself), followed by aircraft.cfg editing, and real-world schedules research. All of this took about two months to prepare! Imagine how frustrating it would have been for me if I then imported all of this work in to Traffic X, compiled, and only had three-quarters of those planes appearing.

I am sure AIFP will do pretty much all the same things that Traffic X will do (albeit with a few more options than what Traffic X has - and probably without the bugs). I think, for example, that AIFP does let you set altitudes for each individual aircraft. And I think it would also be possible, to also manually edit the files created by AIFP. So you can probably do all the kinds of things I described above, using AIFP. I just happened to get Traffic X before I knew about AIFP. As I have already touched on above, for me, Traffic X is more about creating, sorting, and categorising the files in to country, airline, and aircraft types. And managing the liveries. These things, for me, make it easy to work on the files and keep track of them. Traffic X does a brilliant job at helping me to manage all of that. It creates the files, categorises them, sorts them, and stores them. I just use those files to get the exact AI that I want. I am not sure how AIFP sorts it's files, if at all ...

Posted By: RayM
Date Posted: 01 Jul 2016 at 5:14pm

just to let you know that I did read your latest response - and I was sitting comfortably before I started - but I was on my annual holiday to a Spanish island in the Mediterranean and reading it on my mobile phone. I tried to respond but, as I haven't used my mobile previously to go on this forum, I couldn't log on and couldn't remember my login details! (Probably an age thing).

You seem to have a good methodology going there which obviously suits what you want to see in your flightsim. I will take some time to absorb exactly what you are doing to see if any of your method would benefit me. I have never previously looked at the 'schedules.dat' and I can see that editing this to 'improve' the flight altitudes of AI could be of benefit but, of course, once you go down this path, you clearly have to go back to the backup of this file every time you edit in TrafficX.

We all find our own preferred methods of 'improving' on the programs we use in our flightsim experiences.

Keep up the good work!

A long time FSXA and Traffic X user

Posted By: freddy
Date Posted: 02 Jul 2016 at 2:15am
Originally posted by RayM RayM wrote:

...I was on my annual holiday to a Spanish island in the Mediterranean

Spanish island in the Mediterranean! Lucky you!

Yes, using my method you need to go back to the backup of the Schedules.dat file every time you edit in TrafficX. And, you also need to do additional edits to the Airports.dat file as well ...

... everytime you add a new plane, or improve an AFCAD, and compile, the compiler adds new parking spots in to the Airports.dat file. The problem with this is that you cannot use the one auto-generated by TrafficX because of the random percentage factor. If it randomly sets a plane to NOT appear, then the Airports.dat file gets adjusted according (removing the parking reference for that aircraft). Now if you then go back to your backed up Schedules.dat file that DOES have that plane appearing, then the auto-generated Airports.dat file won't have the parking spots for that plane ... and you end up with compiler ERRORS and a plane that doesn't appear.

Bottom line ... manually editing your Schedules.dat file ALSO REQUIRES that you manually edit your Airports.dat file as well. And, well, there's other files that may need to be edited as well.

So, how do I do it?


1) Before starting, backup the Just Flight "Compiler" folder, in its entirety, on to the desktop. Then add your AI Plane(s), as normal, in to Traffic X.

2) Do the compile (in Traffic X).

3) MOVE the newly created Schedules.dat, Airports.dat, and AircraftTypes.csv files out of the Compiler folder and on to the desktop. Rename these and add the word NEW to their names (eg "NEW Schedules.dat"). I now have a new Schedules.dat, a new Airports.dat, a new AircraftTypes.csv and the previous (original) Compiler folder all on my desktop ... and I've renamed the files adding the word "NEW" to each of them.

4) Delete the Compiler folder and then immediately COPY (do not move) the previous (original) Compiler folder, in its entirety, back from the desktop and in to place. (By copying, and not moving, you are still keeping a backup copy of the previous original folder ... if anything goes wrong, you can refer to this folder, or just copy it back and start over.)

5) Using the files "NEW Schedules.dat", "NEW Airports.dat", and "NEW AircraftTypes.csv" on the desktop for comparison, do your manual edits to the Schedules.dat file and Airports.dat files, using cut-and-paste and adjusting the random density values, altitude values, flight numbers, or whatever you need, accordingly ... obviously saving the files when done. Because we renamed the new files on the desktop and added the word "NEW" to each of them, it is easy to open these files side-by-side with the original files that you are editing, using the word "NEW" in the filename to keep track of which file is the new file and which file is the one you're actually editing.

NOTE: The AircraftTypes.csv file contains the ACxxx number (aircraft number) for each AI plane. Using Traffic X to do the compile will shuffle these numbers and create a new AircraftTypes.csv file. Because you are doing manual edits to YOUR Schedules.dat file, you must also use YOUR AircraftTypes.csv file (which you backed up when you copied the entire Compiler folder to the desktop). This ensures that you are entering the CORRECT aircraft ACxxx numbers in to your Schedules.dat file as you do your manual edits.

6) When done, manually run the "_compile.bat" batch file.

7) Wait for the compile to finish ... Press any key when prompted (ie, it is finished).

8) Open the LOG.TXT file and search for the word ERROR.

9) If the LOG.TXT file shows ERRORS where you do not want errors (ie, a plane you've have added or something similar) ... then investigate and fix, before manually running "_compile.bat" again.

10) Repeat the investigation and fixing process, and subsequent running of "_compile.bat", until you're satisfied with the LOG.TXT file report.

11) You have just created a new "Traffic.bgl" file in this folder. Copy this "Traffic.bgl" file to the desktop.

12) Rename this "Traffic.bgl" file (the one on the desktop) to "TrafficX.bgl"

13) Move this "TrafficX.bgl" file from the desktop and in to the Simulator's \Scenery\World\Scenery folder, overwriting the old "TrafficX.bgl" file.

14) Run the Simulator and check to see if your plane is there.

15) Repeat and apply fixes if needed. Once fully satisfied, you can delete all the file and folder backups that are on the desktop.

16) Keep a PERMANENT backup copy of the Just Flight "Compiler" folder, in its entirety, in a different folder, far from all of this. This is done just in case things don't go to plan during the above process. Once you are satisfied that your changes are working in the sim, overwrite this permanent backup copy with the NEWLY created Compiler folder, as your new permanent backup.


Now, to be honest, there's usually even more to it than what I've listed above ... for example when I add a new aircraft, livery, or airport. In these cases one would need to manually edit other applicable files depending on what one has added. For example, the "Aircraft.tcc" and "AircraftTypes.csv" files in the \data\Aircraft folder would need to be edited if I add a new livery or new plane.

The method I list here will indeed get you the EXACT results that you want ... but, as you can see, it is not a method I would recommend to the average person unless they have a good grasp about how all the files tie in together and what their purpose is.

Further to that, the steps above do make this all seem very involved and a lot of work. But, trust me, it really isn't. Once you get the hang of this, it becomes second nature and, I think, very easy. However, that said, when using this method you do need to be careful, and VERY METHODICAL. I have gotten it down to a step-by-step routine that I now perform without even thinking. It's second nature to me. Even so, I often find that it is best to work on only on ONE AI PLANE at a time, otherwise confusion can set in. Doing it one plane at a time can be time-consuming, but you do avoid mistakes ... and that results in the expected outcome the FIRST time, EVERY time!

Posted By: RayM
Date Posted: 05 Jul 2016 at 1:13pm
have started looking into your procedures and probably won't go down your working path but it has got me looking at the files you are manipulating.

"... everytime you add a new plane, or improve an AFCAD, and compile, the compiler adds new parking spots in to the Airports.dat file"

Cannot see (as yet) why TX does this.
Looked at airport 00M in my "airports.dat" and found over 4000 listed RAMPS whereas it only has 2 R10.0 plus 1 R16.0 FUEL in ADE. Then I found that, in TX_VFR_USA.tcc, there are over 500 schedules that operate in and out of 00M!!! A TX curiousity there?

Then I looked at 2M2 which only has 1 R10.0 RAMP and has only 1 scheduled flight (an AirCreation Trike) in the tcc file. The "airports.dat" file lists 6 R6.0 RAMPS. Added another 'reverse' flight into the tcc file and recompiled. The "airports.dat" file now lists 12 R6.0 RAMPS ? One flight (out and back) has 'added' 6 RAMPS ?

I am intrigued if you can come up with a logical explanation of this situation based upon your experiences.

Another thing which I have now noticed is to do with the flight levels for each type of aircraft. For example, in TX I have set the max flight level for AirCreation Trike to be 85 (8500'). Now as I have previously said, I see Trikes at much higher levels than this on a regular basis. If I look at the "schedules.dat" file and find any Trike entry, the flight level bit states '85'. So something else is going on here that TX does not handle properly.

Further to the above - have done a test.

In TX I have my AirCreation Trike set to a custom Max Alt of 85 (8500'). Have created a tcc file containing about 15 Trike schedules. Now I compile this, on its own, to a BGL file.
I note that this creates new files in the 'Compiler' folder. When I inspect the 'schedules.dat' file, all flight levels are set to "85", which is what I would hope for.
BUT, if I now inspect the BGL file in AIFP, I see that there are FL's, for the Trikes, ranging from 85 to 205, i.e. changed from the 'schedules.dat' file.
Now, I have carried this out using the TX interface.
Freddy, are you suggesting that carrying out this small test 'outside of TX' would produce a different result?

A long time FSXA and Traffic X user

Posted By: freddy
Date Posted: 06 Jul 2016 at 2:58am

OK, you've got two separate questions there.  One about Airports.dat and the number of RAMPS it has it it for your AI planes, when compared with the actual AFCAD etc.  And the other about flight levels of AI planes.


Let's say I have an airport with only ONE parking spot (a GATE parking spot).  We will call it airport A.  Let's also say that I set an AI plane to fly to this airport from airport B.  The AI plane goes from B to A, and then back again from A to B, parking at airport A and airport B respectively, as any other AI plane in any of your schedules would normally do.  It repeats this journey three times.  So, (B-to-A, A-to-B), (B-to-A, A-to-B), (B-to-A, A-to-B).  How many times did it land and need to park at the GATE at airport A?  Three times.  So there will be three GATE entries in the Airports.dat file for airport A.  One for each and every time the plane needs to park.  Each of those GATE entries also shows the applicable parking spot size next to it.  Similarly, there will be three GATE entries at airport B for this aircraft ... one for each and every time the plane needs to park there ... and each of those also shows the parking spot size next to it.

In other words, every single time an AI plane lands at an airport and needs an available spot to park, there will be a single entry for that in the Airports.dat file.

Now picture 4 additional planes flying to airport A, all from other different airports (there's only one GATE at airport A, so we will assume you are really good at making sure their landing times do not clash).  The first plane makes 2 return journeys, the second plane makes 5 return journeys, the third plane makes 4 return journeys, and the fourth plane makes 3 return journeys.  You now have FIVE planes going to airport A and each of them is making a different number of return journeys, probably based on distance and fuel requirements etc.  In your Airports.dat file, you would now have 3 (our original plane) plus 2 plus 5 plus 4 plus 3 GATE entries in your Airports.dat file.  That's a total of 17 GATE entries in the Airports.dat file ... with each of those showing the applicable parking spot size next to it.

So you see, even for a small airport, with only one GATE parking spot, the data for this airport in the Airports.dat file can get quite large.

Disclaimer: Hmmm, I am not sure if 3 return journeys actually means SIX entries in the Airports.dat file - one for each time the plane needs to park, and one for each reciprocal takeoff/return.  It doesn't make sense that it would need to do that, but I just can't remember right now.

Why does it add all of these entries?  To be honest I am not really sure.  Suffice to say, if I manually delete one of those entries, then I will get compiler errors "Unable to find available parking for B737_Test at airport A".

Not knowing why it adds these entries is not really a big deal.  What is a big deal though, is knowing that you can manually EDIT these entries or even add more in.  For example, alter the value for the parking spot size to get planes with larger wingpan sizes than what's in the AFCAD to still be able to park at the airport, or change the word GATE to RAMP (or CARGO) even though the AFCAD only has a GATE spot thus allowing a plane with only RAMP (or CARGO) set in its aircraft.cfg file to now park at this airport.  With carefully planned and thoughtful editing of the airports.dat file, either changing parking spot types or tweaking the parking size values ... and subsequently matching or modifying the corresponding settings in a plane's aircraft.cfg file ... it is possible to have a plane flying to and parking at the airport that wouldn't normally have parked there had you merely done a routine Traffic X compile.


You are right about the altitudes.  The Schedules.dat file will correctly show "85" next to your Trike plane.  But if you look in the LOG.TXT, after a Traffic X compile, you will see a line at the very end which says something like "Adjusted altitudes for 2,435 aircraft".  Don't ask me how the magic works, because I don't know, but I get the feeling it adjusts the altitudes for SOME of the AI planes based on airport elevations and other factors.  I doubt that it knows about flight routes that go over mountainous terrain ... meaning I doubt it is adjusting the altitudes for that ... but, heck, I am not really sure.

So, even though you set 85 for ALL of your Trikes in ALL of your schedules, it is not inconceivable that SOME of them will not be set to fly at 8,500'.  Most will, but some won't.  It frustrates me that I set 100 for small GA aircraft, and then encounter them at 15,000'.  That's unrealistic.  But, having said that, this usually occurs when there are hills and mountains in the area.  Why or how this magic works, I have no idea.  Note that it seems to do this EVEN IF YOU MANUALLY EDIT THE ALTITUDE VALUES IN YOUR FILES AND MANUALLY COMPILE.  So it appears to be something (magic) to do with the compile process.  However, despite that, one can and should still bother to adjust the altitude values in the Schedules.dat file as they want ... because the planes will still fly at different altitudes from each other, all relative to the values that you manually set in the file, rather than all flying at the exact same standard altitudes as each other had you merely done a routine Traffic X compile.

You ask if I am suggesting that carrying out these small tests "outside of Traffic X" would produce different results?  I'll say "Yes, that is what I am saying".  With a knowledge of how the various Traffic X files all work, what each of them is for, and how to tweak them accordingly, you can categorically get your AI to work 100% the way that you want, EVERY TIME ... and thus produce AI results that a routine Traffic X compile simply wouldn't have (or won't) produce.

And Schedules.dat and Airports.dat are only really the tip of the iceberg.  There's plenty more you can do when you know how to work the other files such as "AircraftTypes.csv" and "aircraft.tcc", as well.
HANDY TIP:  You can rename .tcc files to .xls which will mean you can now open them in Excel ... in neat columns etc that you can sort and search and stuff.  Remember to rename them back to .tcc when done.

Posted By: RayM
Date Posted: 06 Jul 2016 at 9:55am
The way parking spots get added here does seem very odd but I can see from your explanation that the compiler has to do it or the "Unable to find available parking for ....." message will appear. I have always found, when doing an 'all-tcc-files' compile from TX, that I get a few of these error messages. They are generally about 4 or 5 airliners at varying airports. Other times it might be a slightly different group of airliners but it is always 4 or 5 from a group of about 10 in all.

I had forgotten about the "Adjusted altitudes for ..." message. This has to be what is changing the altitudes. "Magic" is the word!

I don't bother to change .tcc files to .xls as I right-click on the file and select "Open with .. " and choose Excel. I do my edits and Save. Excel will save it back as a .tcc if that is what was opened.

I have noticed that the format of the entries in this file do not seem to match the format as shown in the SDK.
typeKey,Title,Cruise,minAlt,maxAlt,minRange,maxRange,minRwyLen,runwayTypes, radius,parkingTypes,IFR%,AutoRoute?,TouchAndGo?

example -
AC3     Beech Baron 58     180     40     450     74     661     4000     HARD|SOFT     6     RAMP     50     no     no

Not sure how TX manages without conforming to the SDK.

As always I appreciate your knowledge and suggestions.

A long time FSXA and Traffic X user

Posted By: freddy
Date Posted: 07 Jul 2016 at 12:40am
Before I begin with a response to those questions, it is worth noting that one does not necessarily need to use Traffic X to create AI files that can be manually edited.  It should also be possible to manually edit any AI files produced from any other AI program (for example, AIFP, Traffic 360, MyTrafficX, etc).  All of those programs will use the same AI traffic compiler from the FSX SDK to produce their AI files, and, therefore, they should all be producing files that adhere to the same rules, syntax and comma separated formats that the AI compiler requires.  I can provide details on how to manually edit the files used by Traffic X purely because I am familiar with the way Traffic X produces, stores, and sorts it's files. But the same or similar kinds of edits should be possible with files produced by other AI programs as well.

Anyway, I digress ...

"Airports.dat" ... If you do get the "Unable to find available parking for..." message when doing an 'all-tcc-files' compile from Traffic X, then it is usually possible to open the Airports.dat file, locate the airport in question, and manually edit the details it contains to correct the errors.  However, in doing so, you are now "locked in" to forever more using this manually edited file.  This is because the next time you use Traffic X to do the compile, it will create a brand new Airports.dat file and your manual edits will be lost.  So you would need to keep a backup copy of your manually edited file, let Traffic X do its thing and create a brand new Airport.dat file each time you want to make AI changes, copy and rename the newly created Airports.dat file to "NEW Airports.dat" on your desktop, put YOUR backed up Airports.dat file in it's place, use the "NEW Airports.dat" file on your desktop as a comparison to add in just the NEW stuff that was created when Traffic X did it's compile, and then, once you have updated YOUR Airports.dat file with the new stuff, do a MANUAL compile. All of this, of course, only if you want to eliminate those "Unable to find available parking for..." messages once and for all, or if you do decide to make "other" manual edits to the Airports.dat file as per my earlier emails.

Ah, yes, of course you can open the .tcc using the right click "Open With..." option in Windows.  That'll work too.

"AircraftTypes.csv" ... Like the Schedules.dat file and it's "magic" changing altitudes, Traffic X also does some other "magic" stuff with other files that I cannot explain.  Yes, the Traffic X "AircraftTypes.csv" file does not seem to conform to the FSX SDK format.  It has the correct number of values, but the values seem off for some of the parameters.  I mean maxAlt = 450 for a Beech Baron 58?  Whether that's interpreted as 4,500' or 45,000', I don't know, but, regardless, surely not.  I have noticed that if you manually change RAMP to GATE for that Baron 58, it will still park in RAMP parking spots, seemingly IGNORING the values in this file.  However, that does make sense to me as I think the parameters in this file are only relevant if you are using the compiler in a special mode which randomly generates IFR and VFR schedules for you - which is one of the (advanced) functions that the compiler can perform. For us, doing our manual edits, the only value that is relevant in this AircraftTypes.csv file is the ACxxx number (aircraft number).  That number is used in the Schedules.dat file to identify which aircraft to use.  But, as for why the values are not correct as supplied by Just Flight, I have no idea (I've never really experimented all that much with this file).  Suffice to say, I do occasionally manually add new planes in to this file (and the aircraft.tcc file) whenever I add a new livery or download a new model, and even though some of Just Flight's values appear to be incorrect, I do think it is important for ME to get the values right.  If you are editing this file, either use IMPORT to let Traffic X fill in the values for you, from the aircraft.cfg file, and then leave the (imported) values as is ... or, for manually entering a new livery, just cut-and-paste the values from the exact same aircraft type that's already in the file.

Posted By: RayM
Date Posted: 07 Jul 2016 at 2:58pm
One last test before I happily close this subject (from my point of view that is).

As before my Trike Max Alt is set at 85.
Set up some flights between 2 airports with NO intervening high ground.
Compiled in TX. NO error message about "Adjusted altitudes for ..." .
Look at BGL in AIFP - all FL's listed at 85.

Another load of flights but with mountains in vicinity.
Compiled in TX. Error message includes "Adjusted altitudes for ..." .
Look at BGL in AIFP - FL's listed at 185 and 205.

So TX (and presumably T360) adjusts the flight levels as it sees fit if it thinks there is high ground on the flight path - very clever! Just odd to see Trikes, Piper Cubs, etc. flying at 20,000ft!

Will be sticking with what I am doing for now but have got a greater understanding of what is going on.

A long time FSXA and Traffic X user

Posted By: freddy
Date Posted: 08 Jul 2016 at 2:05am
Interesting.  So you've kind of confirmed what I have suspected ... hills and mountainous terrain somehow affect the (compiled) flight altitudes.

But, I'd love to know HOW the compiler knows what the terrain is going to be between airport A and airport B.  The SDK guides and instructions confirm that the compiler uses three pieces of information to compile the traffic BGL ... aircraft types, airport parking spot/runways information, and the actual schedules data.  Using Traffic X filenames, those are AircraftTypes.csv, Airports.dat, and Schedules.dat.  And none of those files contain TERRAIN information.  So how the heck it knows on which specific routes it needs to increase the altitudes, I have no idea.

However, having said that, one needs to acknowledge that if it didn't somehow adjust for hills and mountains, then you would always have your Trikes flying in to the sides of mountains whilst enroute (or, actually, in FSX, they'd probably be flying "through" the mountains and out the other side).  So I marvel at the common-sense and cleverness of the Microsoft team to consider this and build in some compiler "magic" that adjusts the altitudes accordingly (and, thus, makes it more realistic to some degree - realistic in that planes that are enroute don't fly in to the sides of mountains [even if the tradeoff is UNrealistic in that this means Trikes, for example, can be seen flying at ridiculously high altitudes.])

Anyway, yes, it's probably time to put this topic to bed.  Everything that I learnt about AI files and how they work (and, specifically everything I learnt about Traffic X's AI files and how they work), I learnt from experimentation ... take backups of the files first, open them, dive in without fear (because you have backups), make edits and tweaks, compile, and see what results you get.  Ray, I can see from these questions and posts that you're already well on your way ...
May your AI skies be filled with Trikes ...

... at FL 205.  LOL


I just did a quick Google and found this sentence in a post on another forum ...

"The SDK does say that it sets a 'safe altitude' for all the airplanes. It does this by way of a course grid and if it cannot obtain that safe altitude then it will correct for it or abort it."

So off to the SDK I go, where I find this:

"All routes between airports are direct. This limitation applies to both random and manually created routes. To minimize the chance of AI aircraft flying into terrain, the TrafficDatabaseBuilder uses a course grid of minimum safe altitudes. Routes whose altitudes are found to be below the minimum safe altitude are adjusted upwards as necessary. If an aircraft is unable to fly at the minimum safe altitude for a route, that aircraft/route combination is rejected."

A course grid eh?  That does make sense.  OK, so now I (we) know.

Posted By: RayM
Date Posted: 08 Jul 2016 at 8:50am

"A course grid eh? That does make sense. OK, so now I (we) know."

Well found Freddy, I didn't spot this when I was looking thro the SDK.

A long time FSXA and Traffic X user

Posted By: freddy
Date Posted: 09 Jul 2016 at 1:08am
... and for all the reading of this SDK documentation I have ever done, which is quite a bit, neither did I.

There's a wealth of information in the SDK documentation and it is easy to miss things if you are not specifically looking for them.

Print Page | Close Window