Gday Paul
Yes AiSort is looking for the Aircraft.cfg files
I just done a search on my system and I came up with a load of sim.cfg files all associated with animals Boats & Ground Vehicles But all the Stock aircraft have aircraft.cfg.
I think what FsX is doing is loading other scenery traffic before the aircraft.
Regards Frank
Yes, I'm aware that all those "other" objects have "sim.cfg"
files in lieu of "aircraft'cfg", but I did confirm that when it
searches each aircrafts folder, it first looks for "sim.cfg" and
after not finding it, it will then search fof the "aircraft.cfg"
file. So it's a matter of some hard-wired, misplaced logic
in FSX's coding that causes it to do these pointless searches.
It also looks for alot of other file types that should not
normally exist, such as files with .CAB extensions on
file types that have never used that extension such as
FSX.CAB, texture.CAB, Addon Scenery.CAB, model.CAB,
soundai.CAB and on and on and on. FSX is really quite
inefficient when it comes to file management, IMO.
In any case, that's the reason I renamed all my aircraft.cfg files
and I no longer have those hundreds of "File not found"
occurances.
Another question. Does aisort use the "SimObjectPaths.x"
statements in the fsx.CFG file to locate the folders to search?
The reason I ask is that all my AI aircraft are contained
in "SimObjectPaths.6=SimObjects\AI Aircraft".
To work around the "sim.cfg" issue, I could temporarily redirect that statement to:
"SimObjectPaths.6=SimObjects\I:\Microsoft Games\FS9\Aircraft"
where I have copies of most of my FS9 AI aircraft that I
have imported into FSX. Unfortunately, I have four instances
of FS9 on my system. Each tweaked for different purposes
and/or regions of the world. None the less, the above re-direct
would pick up most of them.
I know others that are pointing their fsx.CFG simobjects
statements to their FS9 installation to prevent having
to have alot duplicate entries. So it would be prudent to
use the fsx.CFG "SimObjectPaths.x=" statements to
search for the AI aircraft.
Paul
EDIT:
Frank, I am in the process of converting a VERY large file at the moment. All seems to be going well.
here's what I found I had to do to overcome the "sim.cfg" issue.
First, I changed the pointer in FSX.CFG Simobjets to include my FS9 Aircraft directory. No luck
there as aisort didn't appear to look there.
Next, I created a temp folder and put all my FS9 AI aircraft folders into that. I renamed my
FSX "AI Aircraft" folder and then renamed the temp folder to "AI Aircraft". Again, aisort did
not use this folder ( which contains aircraft folders with aircraft.cfg files ).
I then renamed my FSX "Airplanes" folder and renamed the temp folder to "Airplanes".
aisort now used this folder and created an AircraftTypes.txt file.
So, it appears that aisort is only looking for aircraft.cfg files in the FSX "Airplanes" folder.
This will cause alot of confusion with those, like myself, who prefer to keep all addon and
AI aircraft in different folders. Something the FSX structure allows through the use of
the FSX.CFG file "SimObjects.x=" entries.
Something else I noticed is that the "minimum parking radius" parameter appears to
have a 7.0 M absolute minimum. There also seems to be some additional factor, in the
range of 1-2 meters added to the 1/2 wingspan data as read from the aircraft.cfg file.
I noted that my Mig-15's and Mig-17's all have a 7.0M parking radius setting in the
AircraftTypes.txt file while the Mig-19's were set at 9.0M.
What is your experience with the TDBB requirements in this regard?
When converting a plan by hand using these aircraft I used the
actual wingspan/2, rounded up, to create the plan. That resulted in 5.0M and 6.0M
radii for those two aircraft. I increased those values by 1.0 M.
I then modified the airport parking for the airports that the Mig-15/17/19's use, to allocate
specific parking of 6.0, 7.0 and 8.0 meters for those planes.
When compiling, I noticed that TDDB kept giving me ALOT of "can't find parking"
errors. I had to do numerous itterations of chaning destinations and times until I
finally got an error-free compilation. This occured even though I had allocated far
more parking spaces than expected planes at any given field.
After starting FSX I noticed that at the fields I used, using the traffictoolbox listing, that
they were far fewer planes than available parking but more importantly, it appeared
that FSX was assigning the planes to larger spots than necessary. And in several
instances, assigned Il-18's ( normally 18.0M ) to 20.0M spots while assigning
Tu-95's ( 20.0M ) to 18.0M spots!
So, my conclusion is that TDBB and FSX are doing alot of things that certainly
are not spelled out in the SDK ( I've always found the FS SDK's to be lacking )
and even those items that are addressed are not sufficiently documented.
Your statement "I have found that “TrafficDatabaseBuilder” is VERY fussy about plans
It accepts do fly" is a understatement to be sure. it's a nightmare!
Paul