Reasons for planes not taking off

[pb321]

I'd like some help in listing the reasons why planes may not take off from a runway, which leads to clogging on the runway. I've experimented with 1-, 3- and 4- nodes on the runway, marked as such. If I understand it, the 1- or 4-node methods work, the 3-node method doesn't usually work. I've also read that some have found that 3- or 4-nodes may be placed on the runway, but only the last node (end of turn onto runway) is marked as "on runway". However, I believe I read that logic may be added to Flightgear Airports to require all the nodes be marked as "on runway" (true?). Note: I don't understand yet how FG Airports knows where the runway is.

Sometimes it seems a pushback made incorrectly (less than 90-100 degree angle between segments) can cause planes not to take off.
Are these basic principles correct? What are other reasons planes may get stuck on the runway and not take off, clogging the runway?

[wkitty42]

FGA knows where the runways are because it reads it out of the apt.dat file...

i was also wrong in telling you to have only the last node on the runway marked as such... all nodes on the runway need to be marked... as i understand it, the lines drawn on the image depict certain areas of the airport... one of those is the runways' thresholds which we now see as the "threshold layer"... since we know where the thresholds are and the direction of the runway, we also know where the center line is and how wide it is... that gives us a boundary box to look within to see if there are any nodes in there not marked as "on runway"...

as far as AI getting stuck, one reason has been disconnected nodes but the most common one i've seen is basically confusion... the craft is waiting on another craft to go... maybe one got in line faster than another that should go sooner... sometimes i can boot the one that is stuck and everything carries on normally... sometimes i have to boot several of them until the one they were waiting for is finally gone and then all the rest work normally... i made kind of a game of it... had to write a script that would tell me which record in the property tree was the craft i was looking at... once i know the craft's record, i can open it and set its velocity value manually to give it a push and get it moving... it can be ""fun"" at an airport with 50+ craft all stuck waiting on one to go...

[pb321]

Thank you, @wkitty42. Makes sense that FGA uses the apt.dat, threshold and width to "find" the runway.
I've read about the "boot" method of declogging the runway and have not yet tried it.
I have been working on four groundnets, all of which experience a clog, and, if I'm correct, all of them have one plane each that seems to stop on the runway and refuses to take off. I suppose setting the time to "dawn" instead of "morning", for example, might avoid this clog or at least postpone it (it has seemed to work this way before), but there may still be a clog. When does one decide enough has been done to avoid the clog and upload the file?

[wkitty42]

ahhh... one thing to remember about the AI is that the entire schedule is loaded into memory for all craft... when first starting FG, there will be AI instantiated that have a flight two days from now... some maybe a week from now... it takes time for them to all fly out and normalize... one can trigger this by jumping the time forward a few hours at the time so those craft will leave... then you can move the time back to clock time... but don't be in a rush... bump the clock forward and wait like maybe five minutes for craft to do their clearance and taxi movements...

i mention this because it may be what you are seeing... i saw it badly when i stripped my AI flight plans to be only all flights into and out of one airport... there were only like 20 parking places... they all filled with flights for today, tomorrow, next day, etc, all the way around until no more parking was available... the first seven parking taken were all the same flight but on each day upcoming since it was a 24hr scheduled route flight... there should have been only 8 or 10 craft instantiated in total instead of all of the ones in one schedule and then the next and so on until parking ran out

i think that a flight should not be instantiated if

1. the callsign already exists (prevent dupes flying)
2. the flight doesn't leave for X period of time (TBD)

at least those two reasons... i mean, if i have one flight a day that uses the same callsign every day, why should there ever be more than one of them instantiated?

[portreekid]

Thank you, @wkitty42. Makes sense that FGA uses the apt.dat, threshold and width to "find" the runway.
I've read about the "boot" method of declogging the runway and have not yet tried it.
I have been working on four groundnets, all of which experience a clog, and, if I'm correct, all of them have one plane each that seems to stop on the runway and refuses to take off. I suppose setting the time to "dawn" instead of "morning", for example, might avoid this clog or at least postpone it (it has seemed to work this way before), but there may still be a clog. When does one decide enough has been done to avoid the clog and upload the file?

Sorry about the bug with all "your" Airports using an ancient APT.dat (715). Hope FGA 0.0.23 fixes that.

[pb321]

Maybe @portreekid..I'll upgrade and give it a try. Info from @wkitty42 is helpful, too. Now I understand why some airports are loaded completely with traffic.