After I read your answers, though for no reason, I downloaded TTools again and compiled the Qantas, Malaysian, Lufthansa and Air India flightplans through this fresh download of Ttools. Except Air India, all three troubling 2Hr flightplans worked.
Funny, isn't it?
With Air India, The 2Hr plans for RJAA and RKSI aren't working, rest are working. I mean why are some of the 2Hr plans not working while the others are?
It highly depends on :
a) how you defined your flightplans (the three TTools text sources files)
b) in what conditions you were testing your AI flights.
c) the flight dynamics set of your AI aircraft(s)
d) the "mood" of your flight simulator
at the moment ! Yes, FS has some nasty behaviour sometimes...
What you wrote in your flightplans source files :
In the flightplans, whether you were using the "@" symbol before your arrival time, which flight level, IFR or VFR, etc. All those produces different behaviours.
The @ symbol alters the way TTools handles the
cruising speed of your aircraft, no matter what value you specified in your Aircraft_???.txt file. Instead of the value you entered in the FP source, TTools will use a
simulated one based on the departure and arrival time you provided in the flightplan (distance divided by flight duration),
in order to write the specific time and day of the week at which your aircraft will be loaded/activated in a specific sector. If you use the @ symbol, make sure you have departure and arrival times that suits FS taste, otherwise,
your aircraft will not load inflight, but pop in at gate, or not show up at all. That seems tightly related to your problem (and honestly, that's also what I would expect to be the beginning of the problem)
The
flight level alters the altitude at which FlightSim will load your aircraft in scene on approach (related to the sector loading/activating above). Higher FLs means
higher loading altitude on approach. Too high, and your aircraft will NOT be able to land.
IFR and VFR alters the way your AI plane will enter final, and at which altitude.
FDE :
If you happen to use an aircraft with a
poor FDE it may not be able to slow down enough and descend from FL350... (by "poor", I mean
not suitable for AI operations - There is no such poor FDE. It's very hard to get a "perfect" FDE due to the very limited capabilities of the FS AI Engine)
FS Behaviour :
FS sometimes instruct AI aircraft to climb, while it's supposed to enter an approach pattern (descend) When such things occurs right after the plane were loaded into scene, it will climb
up to its cuising level before descending again (at least, some has noticed that) I don't know why this happens (sometimes, but yes, I did notice one aircraft on approach fly over the destination airport at cruising level - at least on FS9)
FS Brain - very basic :
Where is your airport when you look on the map of the 9 active sectors ? (it's a square like a numpad, your aircraft is in the middle, and 8 sectors surrounding your active one. Every AI object within the 9 sectors will be activated and followed by ATC) Sometimes, your airport is located on the corner of the center sector, and arriving AI in the sector next to that corner are loaded in the vinicity of the airport, but too high !
They won't be able to land, even with engines at idle and full spoilers deployed. Furthermore, when instructed to go around, they'll climb too high, and again, they won't be able to land (they'll disappear after a while)
Operations conditions :
Depending on your weather conditions, approach pattern may be lengthened (good, this make room for your AI to slow down and descend) or shortened (Bad ! for opposite reasons)
So, it's not a matter of "
Write flightplans and expect them to work like a charm...". Sum the above and you get tons of possible scenarios you may have to think of, some of them requires a knowledge of the Simulator and its engine. Like where are the "sectors limits" on a lat/lon map ? how does FS calculates activation altitude ? (I don't know) Flightplans BGLs are loaded in alphabetical order, aircraft loaded in the order they were specified (that's why you have more "Airbus" in most flightplans setups than "Boeing", or more "AIA" than "FAIB"... depending on the titling) etc.
Hopefully, most AI flightplans will work next to perfection... but that's because most users applies TTools
average "default settings" : flightplans written without the @ symbol, aren't "tweaked" with lower aircraft speeds, and usually repeat on a
24Hr basis or even WEEK. So I would advice to :
- remove the @ symbol
- specify a realistic aircraft cruising speed in your Aircraft_???.txt file.
- Change your 2Hr repeat period to at least 24Hr !
- Lengthen the turnaround time to at least
one hour !
The result is :
- Correct activation times will be specified for each sector.
- You'll loose the ability to know exactly at what time your aircraft will load in FS. Perhaps, it's ultimately what you don't want, but heh, the question was "why the aircraft isn't landing..?" To maximize its chance to land, give it room to perform it..!
-
You'll loose your airport activity ! (again not what you want)
And can you tell me about this 37 minute rule?
The modification above is
NOT a solution. Most flights would work well (if your aircraft is able to descend from FL400 though...) Depending on what is happening, and which pattern your aircraft will be vectored to, it may take a moment before your aircraft will be able to land, exit runway, then taxi to gate. The goal of the whole blah blah above could be shorten as : "help your plane to ease its landing - no rush, enough time frame".
Having "reseted" your TTools config has probably nothing to do with the "virtually fixed state" of some of your newly compiled FP. I, as a programmer, can't believe the same source file compiled with the same tool will produce two different BGLs. But I did say "probably" because I don't have all the details and, perhaps you used an older version of TTools (from FS2002 era ? - lol !) And as I explained above, what is happenning in your sim may alter the way AI world behaves. Would ATC responsiveness has been delayed by some CPU usage may give a few more seconds for your plane to descend... or on the contrary, a CPU completely open for Flightsim may have been able to load the AI on time, and prevent it from being deleted ? Who knows... But I digress.
A deeper knowledge of the AI engine is required in order to further give room to your plane to enter approach pattern, land, exit runway, dock at a gate,
and prepare for next flight. To have control over
arrival time, you must use the @ symbol. ... I just suggested you to "not use them"... right ? Puzzling isn't it ? You have to make a choice :
- go for simple things and follow FS AI Engine rules...
or
- have control, but learn more about how the FS AI Engine works...
There is no magic wand to have both control and not follow FS rules. The trick is to
fool the AI Engine !
So, the
obsolete way to have both is using the "@" symbol. You specify a realistic/actual/well calculated
arrival time. TTools will use that arrival time to write at what time and day of week the aircraft will be loaded in a sector. If you happen to have a flight at that time and with that sector activated, the AI aircraft will eventually be loaded, either in flight (approach/cruise/departed) or on ground (at gate, obviously). In your case, you expect the aircraft to be loaded on approach when you load your scene a few minutes before the specified landing time, or if you wait enough for the aircraft. Hopefully it will be activated around FS250/300 on descend.
Meanwhile, the AI Engine will calculate
another time at which it expects the aircraft to be loaded in sector, which uses the
specified cruising speed instead. Then it calculates the difference between the loaded time from the departure/arrival calculation (because you used the "@" symbol), and this reference time from the departure/cruising speed calculation. If the former exceed the later by 20-22 minutes, the AI aircraft
is not loaded on decend/approach ! Plus the 15mn standard duration of an approach/landing sequence, this equates 35-37 minutes, 37 being the critical maximum time frame, that's why it's called the
37 minute problem.
What you should understand here is : the 37 minute problem is
not the cause of an AI loaded but not able to land. It's just explaining why an AI
is not loaded in the air,
but just pop in at gate (if enough turnaround time frame - which you don't even have in your flightplans) But that behaviour is the consequence of a wrong use of either the cruising speed, or the "@" symbol, or both. You can't use the "@" symbol, and use whatever cruising speed you want. Those two are tightly related. That's what jvile tried to tell you above, but not every one has time to go deep in explanations.
However, because you used a so tight flight duration with the "@" symbol, FS assumes your aircraft flies at the speed of the International Space Station. The good point is, it would be loaded very early compared to the estimated time of activation calculated from the cruising speed (around 494Kts according to your aircraft config entry) and will not be discarded !
Or it will ! The culprit is your
2Hr repeat period. We don't know at what time you loaded your simulator to wait for the planes to come in, whether you were on the correct schedule with daylight saving time status checked... When you say "it's not working", we don't know whether the aircraft has been loaded but unable to land, or if it wasn't even loaded... (mostly) The 37mn problem only applies to the later, but the 2Hr repeat period really doesn't help to know for sure what's the problem.
I said the "@" symbol was the
"obsolete" way to deal with arrival times. Of course, that's not really true, your situation is the proof. But most users won't even try to make their aircraft cruise at Mach 36 ! It's pretty the opposite. In the real world, aircraft doesn't fly from A to B at 494Kts. Flight sequences has variying speed, and average rarely exceet 380Kts for medium haul flights and 420/440 for long haul.
There is an alternative to the "@" symbol for "average" users :
reduce the specified cruising speed. This will induce a longer flight duration for the AI engine calculated from the departure time and the cruising speed. That way, the AI will always be loaded earlier (we hope..) and the 37 minute problem doesn't occur. That's how AIFP works by default.
These are the speeds, whichever is of concern(cruise speed I guess).
[Reference Speeds]
flaps_up_stall_speed = 150.0 //Knots True (KTAS)
full_flaps_stall_speed = 120.0 //Knots True (KTAS)
cruise_speed = 494.0 //Knots True (KTAS)
max_mach = 0.85
max_indicated_speed = 330 //Red line (KIAS)
The only one that is related to your concerns is the cruise_speed = 494.0, but at a
very low level. This information in your Aircraft.cfg has nothing to do with AI flightplans. However,
some tools out there
can recover a cruising speed to use for your AI aircraft by reading that cruise_speed specified in the Aircraft.cfg, and use it for your flightplans source files. But the relation ends there. In order to use that entry, you have to do it manually or instruct those tools to do so.
The only cuising speed that matters in AI flightplans is the one specified in your Aircraft_???.txt source file in the form of :
AC#1000,
477,"Boeing 747-400 Qantas" // Illustration purpose only !
That "477" is the value used by AI Engine to calculate the estimated time of activation.
There's a huge difference between 477 Kts and 19750 Kts. From the start, you made it very difficult to point out where the problem is... With the 2H repeat period, it's even harder...
I like it that whenever I land in Guwahati, there should be a few planes arriving and departing from and to some particular destinations. Creating that scenario in a realistic way would take years. Hence, the 2Hr flighplans.
Good you enjoy it that way. But if it was supposed to work well whatever you do, it's pretty non sense to try hard to gather all required informations for a given airline, try hard to understand how the AI engine works, and spend hours of beta testings to make the flight fit well in the given time frame. Contributors doesn't do accurate flightplans because they can. They do it because it doesn't work as expected, people are complaining and if no one were to dig deeper, none of us will enjoy the sim as we do at the time. Yes, that take years, it's not easy. Over the years, AI rules has been discovered or undisclosed and very valuable tools has been created and made public.
Of course, all that is still obscure to the average simmer and a learning curve is required to get used to only one of those tools. No it's not easy, but if there were an easier way, this topic wouldn't even exist... It just not take years for you to get activity on Guwahati by downloading and installing complete sets of flightplans and repaints for the airlines, general aviation and military operating at that airport. It also took years for contributors out there to make those repaints and arrange those flightplans in order to avoid the very problem you're encountering here.
I don't know. You decide.
PS : when I said above
"TTools tries to compile whatever you ask it to", I didn't meant it to be a "low level tool". It has many check implemented and is a "must have" in flightplan editing; it's user guide is one of the most complete and user friendly
ever (for a non english tongue like me, I did understood
everything the first time I read it), and it serves the community for - I don't know - how many years/decades by now. It's a wonderful compiler, much handy than the one provided with the FS SDK. And one wonderful ability of the tool is the control we have over the way the flightplans are compiled.
What I really meant was
"you have to know what you're compiling using it, and when you're unsure of the results, there are other tools you should use that add constrains on what you may do wrong". AIFP for instance doesn't allow you to make your aircraft rocket at Mach 36 unless you choose "Raw compile". Other GREAT tools has similar or other capabilities, but I don't know much about, not using them on a regular basis. Tools are great when you don't know the bits and ends. But when you do, you rarely need them unless you have a problem you don't understand.
