• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Traffic File Matters

Bert
I do agree with George's statement.I am rather fustrated with all the info here and at other forums; to me it seems all mixed up (Mace, Reggie eg).
Also the SDK is not that big help...no good examples.
A clear tutorial "How to make a AI-Traffic-file for FSX" should be of great help for a lot of us.
Click to expand...

It's my intent that AI Flight Planner automatically take care of all these idiosyncrasies so that you don't have to, and that there will be no difference between creating flight plans for FS9 and FSX other than specifying the day encoding system (if you care) and the target system at compile time.

Don
 
So Don,

Are you saying there isn't a problem mixing FS9 and FSX traffic files :confused:

George
 
Are you saying there isn't a problem mixing FS9 and FSX traffic files
Click to expand...
George, there are (at least) two problems being discussed in this thread, so it depends on what you mean by FS9 and FSX traffic files.

1. If you attempt to mix traffic files compiled for FS9 (using TTools or AIFPC) with traffic files compiled for FSX (whether the default files, others made with TDBB or made with AIFPC) in FSX, the compiled-for-FSX traffic may be suppressed. (If I interpret Jim's input correctly, this only happens if the "@" symbol is used.) So long as the FS9 flight plan file is (re)compiled for FSX (using AIFPC, since the TTools flight plan file format is not compatible with TDBB) there's no such problem. AI Flight Planner (which uses the AIFPC compiler) requires you specify the target system (FS9/FSX) at compile time, and, if you wish, has the compiler add a "_FS9" or _FSX" suffix to the traffic file name to help avoid confusion. But, if someone insists on installing the traffic file in the wrong folder ...:banghead:)

2. If you specify (using the "@" symbol) a flight plan leg arrival time that is more than 37 minutes later than the arrival time calculated by the sim (distance divided by a/c cruising speed), the AI will not appear for landing. Instead, it will spawn in a parking spot a short while before it is due to take-off again. This is most likely to occur when simulating scheduled airline long-haul operations and is the issue that's led to the claim that TASs in the aircraft file should not be reduced. It happens in both FS9 and FSX and is discussed in excruciating detail earlier in this thread and others. (I gather - but have never checked - that files compiled with TDBB - don't exhibit this behaviour.) It's the issue Jim and I are wrestling with at the moment to see if we can find a way for AI Flight Planner to make it transparent. I'm confident we'll find a way but, if we don't, I'll at least make AIFP "smart enough" to detect the potential situation and advise the user how to avoid it.

I hope this clarifies the situation re AI Flight Planner.

Don
 
gadgets said:
Bert

It's my intent that AI Flight Planner automatically take care of all these idiosyncrasies so that you don't have to, and that there will be no difference between creating flight plans for FS9 and FSX other than specifying the day encoding system (if you care) and the target system at compile time.

Don
Click to expand...

Thanks Don for both; your reply and version 0.73
Regards
Bert
 
Perhaps I misinterpreted your earlier information. The proposal was:
1. calculate ETA in every case it's not specified by the user - dist/speed + 15 min - except in the case of short-haul where it's departure time that matters,
2. place "@" in front of every arrival time, and
3. halve the aircraft speed given to the compiler (which can be reconstructed upon decompile).
Click to expand...

Don

Regardless of my words that may cause misinterpretations you have captured the correct process and your proposal is accurate.

In fact, I'm beginning to question the need for "@" in AI Flight Planner. Seems to me I could always set the arrival time to the AIFP-generated ETA and let the user override it if as necessary. Anyone have any thoughts on that?
Click to expand...

That would work

If you specify (using the "@" symbol) a flight plan leg arrival time that is more than 37 minutes later than the arrival time calculated by the sim (distance divided by a/c cruising speed), the AI will not appear for landing. Instead, it will spawn in a parking spot a short while before it is due to take-off again.
Click to expand...

That is correct and the AI plane can spawn in a parking spot a few minutes after it's original fixed time and sit until the next scheduled departure.

This is most likely to occur when simulating scheduled airline long-haul operations and is the issue that's led to the claim that TASs in the aircraft file should not be reduced. It happens in both FS9 and FSX and is discussed in excruciating detail earlier in this thread and others.
Click to expand...

100 percent correct. If the Airliner FP designer had stayed with the calculated compiler time there would be no reason to reduce the TAS because the fixed time would never be 37 minutes more then the calculated arrival time. At that point, adding the @ in front of calculated arrival time would be doing exactly what Lee intended it to do and that is add +15 to the entrance of the visual zone.

I gather - but have never checked - that files compiled with TDBB - don't exhibit this behaviour
Click to expand...

That is correct with both the FS9 and FSX TDBB compiler

It's the issue Jim and I are wrestling with at the moment to see if we can find a way for AI Flight Planner to make it transparent.
Click to expand...

I have good faith that you can do that.

I'm confident we'll find a way but, if we don't, I'll at least make AIFP "smart enough" to detect the potential situation and advise the user how to avoid it.
Click to expand...

You already know what to do and how to flag a warning for the user even with the transparent in place (warn if greater then 37).

AIFP is really cooking now !! :D

When Jon finished with automating my X-wind runway technique and made it all transparent in ADE that was a huge step forward after waiting 4 years. Making AIFP transparent in certain code behavior so it addresses every type FP designed is another huge step forward for all novice and expert designers.
 
Thanks, Jim. I guess we can "tell the world" that the "37-minute problem" is no longer an issue with the special version of AI Flight Planner I provided to you earlier today.

I plan to rework the handling of arrival times in the editor to get rid of the "@" symbol and to handle TNG with a checkbox. This will allow arrival time to be just HH:MM in all cases. The system will default to system calculated arrival times which the user may override (so the "Use ETA" button will disappear as well.) Thus, the Leg List will always show arrival time - in bold or a different color if the user overrides the system-caluclated time. Once that's done, (with a little luck, by tomorrow evening) I'll make a hopefully-final beta release in anticipation of general release early next week.

So, if you.ve been holding back on bug reports, please forward them ASAP.

Have a great weekend, all,
Don
 
jvile said:
Why do most users including others on forums feel they have to convert TTool compiled FP's up to a FSX compatible TDBB compliant Flight Plan?
Click to expand...

I believe - just a guess - that the disappearance of the GA aircraft causes many people to realize their might be a compatability issue. Like most of my experience - people don't want to understand the issue - they just want a one size fits all "fix".

That's easily solvable with TTools compiled files for GA traffic.

As John notes - the ships are an issue which TTools cannot resolve.

Now, I have seen TTools BGL file AI aircraft and FSX TDBB AI aircraft all operating in FSX at the same time.

So there is something more than "the files are incompatible" which is causing the problems.

One specific instance was when working with KORH - Worcester, MA.

I had WoA traffic files with AI traffic in Boston active while I was at the airport. AAL was the main one, but I also think I had Delta running.

I created a misc group of AI flightplans with TDBB for the KORH airport. The aircraft were a mix of default and AI designed aircraft.

One thing I figured out was that as long as the TDBB flight plans / traffic file had no common airports with the TTools flight plans / traffic files - both would be present.

I did not specifical look for surface ship traffic.

In later testing I increased the number and level of AI traffic with TTools flight plans - and hit a point where the TDBB traffic would not be displayed.

This was with the SDK RTM version - I haven't repeated it with the FSX SP2 SDK version.
 
rfields said:
IOne thing I figured out was that as long as the TDBB flight plans / traffic file had no common airports with the TTools flight plans / traffic files - both would be present.
Click to expand...

If that's the case, the default traffic file would really screw things up, it includes most of the airports in the world.

George
 
Yes, exactly that was the first thought to cross my mind, George. This would in fact make both versions incompatible with each other.

Jim, Reggie, can you shed some light? :confused:
 
Wouldn't recompiling the default traffic file with AIFP/AIFPC take care of this issue?

Don
 
gadgets said:
Wouldn't recompiling the default traffic file with AIFP/AIFPC take care of this issue?

Don
Click to expand...

I have converted the default traffic file to FS9 format using AIFPC, but I was under the impression that Jim knew of a way to make the two formats co-exist.

George
 
You must log in or register to reply here.
Back
Top