• 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.

BUG? Missing Flights From Time Table Data Import

OK, Will do I will send you new data since I separated them by the 3 different aircraft and still getting missing FPs with them separated. Please use the Fewest FPs option so we can be both on the same page. I am not using Balanced in this bug test.
 
The reason I asked for your file set/traffic file is so that I can be sure I'm testing the same data as you. The reason I want to know what were the settings across the bottom of the dialog is so that I can see how you generated it. What modes I use for my own testing doesn't matter - once I have your data. Splitting the source file by aircraft serves no purpose since, internally, AIFP handles each aircraft separately.

Don
 
I hope you can work with them split up. I am in the process of sending ya the separated A319 data right now. When I send it to ya please import the data as Fewest FPs as running the import in Balanced and Balanced return priority will create the "Unable to assign one or more legs for aircraft type "319"" error. The Flight Plan File set I am sending ya was ran in Fewest FPs.
 
So long as I get a file set/traffic file that demonstrates the problems you see, the source data from which it was generated and the dialog settings used to generate it, and you tell me which specific flights are missing, I'll have what I need.

Don
 
Ok Don I sent ya the files and what I hope the data you are looking for. Most of the missing flights fell on Sunday. But I had a few missing Sat, Mon, and Tues flights missing.
 
You seem to have put a new element into the equation; that is Priority to Same FN within n minutes. If that field is left blank, I think you'll find most of the missing flights will reappear. The "duration exceeds repeat period messages seem to be caused by a Day-1 problem involving over Saturday midnight flights. The "flight scheduled very close or before' appears to be a legitimate timetable data generation error due to a missing sit time. I'll address these situations ASAP. in the meantime, please see if there are any missing flight plans with the "... Same FN" textbox blank.
 
Done that, but there was absolutely no changes to the FPs at all. I had blanked out the "Same FN within n minutes" box and even put a 0 in it. Both times the FPs are unchanged and the same errors in the same spots. Something is not working there.
 
Then you and I seem to be getting very different results from the same data. BTW, putting 0 there is not necessarily the same as leaving it blank. Also, with that field (which you'll notice is initialized at startup) to be sure the blank is fully effective, you need to blank the entry, exit that dialog and AIFP and then restart AIFP. That field should them come-up blank.
In any case, I will attempt to isolate and fix the error caused by that entry and fix the other two issues I have identified. Should I see something else that might explain what's happening, I'll take care of that as well. But, I'm not hopeful.

Don
 
I have now found and fixed the issue responsible for the occasional overlapping flights. While doing so, I confirmed that, on my system at least, all legs in the timetable data are generated and displayed both in Balanced and Fewest FP modes. So, the only explanation I can give you to account for the difference in results is that, while you downloaded 3.1.12, it did not install properly. Does the Main Panel title bar say 3.1.12? If not, that your problem.

Don
 
OK. I have reverted to the "brute force" approach. I have manually counted the number of legs in the source data (1126).

The Balanced mode generates 1126 legs. Unfortunately, it "forgets" when it has closed a flight plan and sometimes adds another leg to it - which opens it again, destroying the circularity. The timetable displays the data exactly as generated, giving the impression of missing flights.

On the other hand, the Fewest FP mode generates only 1103 legs (for me). This appears to be some sort of initialization problem, since the missing legs on my system are not the same ones as on yours. In every case, the legs you reported missing were included in the set I generated - leading to the extended discussion.

So, there appear to be two unrelated problems. Now that I've got an objective way to view the issue, it shouldn't be too hard to find - but still may take a while. I'll re-release when I have a solution

Don
 
I am gonna send ya a copy of my AIFP settings. Maybe you can see something in there I don't and it's causing the issue. Can you send me a copy of the FP file set that you made from my data so I can have a look at it. I wanna double check if it is indeed working on your end there.
 
At this point, I don't need any further information from you. As for "double checking" if it is indeed working on my end here, I've already described two issues which will be resolved. So, clearly, its not working on my end now, but I'm quite confident that, having identified these two issues I can determine with some certainty when it is.

Don
 
The trouble with "digging into" complex code that one developed years before, is that you sometimes forget the assumptions on which the code is based and you start finding problems that aren't there. In this instance, it turns out the missing legs are easily explained.

When operating in Fewest FPs mode, AIFP repeatedly cycles though the timetable data looking for the longest sequence of legs it can find, saves that sequence as a flight plan, excludes those legs from further searches and repeats the process until no further flight plans can be created. An underlying problem with this approach is that there may be a few legs left over that can't be connected in the usual manner. (This is very unlikely to happen with Balanced mode.) When I initially developed this feature, those leftover legs were of no concern to the users I was working with, so they were left unhandled.

The last data you sent me contains 1126 legs. The Fewest FPs mode connects 1107 of those legs, leaving 19 unaccounted for. The next version of AIFP you see will list those 19 legs individually. Of course, if you check "Deadhead Closure'' the number of legs generated will be increased by the number of deadhead legs - buit it will have no effect on those 19. Those unassigned legs could, of course, be linked with deadhead legs. But, this could result in several aircraft wandering around the world in an illogical fashion. So, since that particular issue can be avoided by using Balanced Mode, I chose to do nothing (other than, now, to document them.)

At the risk of repeating an earlier caution, if you do not enable deadheads, the timetable will display what appear to be erroneous legs and an equal number of legs will be missing. This is because every flight plan commences at the destination of its final leg. If a deadhead leg to bring the aircraft back to the originating airport is not added when needed, then the final destination of the flightplan will not be the intended start point and neither the timetable nor the flight plans will fully reflect the original timetable data.

While investigating this issue, I noticed a few "rough edges" in the user interface that I have smoothed out. Other than that and highlighting the unassigned legs, the next release will be virtually identical to what previously existed. Please monitor the sticky at the top of this forum for notice of the release.

I suspect you will not be particularly satisfied with this response. But, I would point out airlines spend millions of dollars for their aircraft scheduling software. You spent considerably less for AIFP.

Don
 
The trouble with "digging into" complex code that one developed years before, is that you sometimes forget the assumptions on which the code is based and you start finding problems that aren't there. In this instance, it turns out the missing legs are easily explained.

When operating in Fewest FPs mode, AIFP repeatedly cycles though the timetable data looking for the longest sequence of legs it can find, saves that sequence as a flight plan, excludes those legs from further searches and repeats the process until no further flight plans can be created. An underlying problem with this approach is that there may be a few legs left over that can't be connected in the usual manner. (This is very unlikely to happen with Balanced mode.) When I initially developed this feature, those leftover legs were of no concern to the users I was working with, so they were left unhandled.

The last data you sent me contains 1126 legs. The Fewest FPs mode connects 1107 of those legs, leaving 19 unaccounted for. The next version of AIFP you see will list those 19 legs individually. Of course, if you check "Deadhead Closure'' the number of legs generated will be increased by the number of deadhead legs - buit it will have no effect on those 19. Those unassigned legs could, of course, be linked with deadhead legs. But, this could result in several aircraft wandering around the world in an illogical fashion. So, since that particular issue can be avoided by using Balanced Mode, I chose to do nothing (other than, now, to document them.)

Yea, it's a very very helpful feature. I can now write a 2nd timetable data file for the missing flights and a 3rd if necessary and then merge them. Can you add the arrival times on the box also to go with the departure times where it would show "KSAN-KDFW FN: 108 Dep: 6/17:24 Ari: 6/21:59" instead of "KSAN-KDFW FN: 108 Dep: 6/17:24" it would help me out on writing the 2nd time table for the Missing Flights to merge.

However I think you should also add a "Optional" feature to have it go through the skipped FPs and assign them by re looping them until all FPs have been assigned. I am sure it would provide fewer FPs than Balanced. This feature if implemented should be a selectable option in the "Create Flight Plans from Time Table Data Window" That may should the void of the missing flights.

For now if you could at least implement the Arrival time in "The following legs could not be assigned" section that would help me a megaton for working around this! TY

At the risk of repeating an earlier caution, if you do not enable deadheads, the timetable will display what appear to be erroneous legs and an equal number of legs will be missing. This is because every flight plan commences at the destination of its final leg. If a deadhead leg to bring the aircraft back to the originating airport is not added when needed, then the final destination of the flightplan will not be the intended start point and neither the timetable nor the flight plans will fully reflect the original timetable data.

While investigating this issue, I noticed a few "rough edges" in the user interface that I have smoothed out. Other than that and highlighting the unassigned legs, the next release will be virtually identical to what previously existed. Please monitor the sticky at the top of this forum for notice of the release.

I suspect you will not be particularly satisfied with this response. But, I would point out airlines spend millions of dollars for their aircraft scheduling software. You spent considerably less for AIFP.

Don

Who knows how much they spend on their software. All I know is that they're not limited to assigning just 7 days in a continuous circular loop in which Flight Sim limits us to. They have the luxury of and infinite calender to play with. 7 days is very hard to loop FPs as it is an odd number of days. If Flight Sim was design with a 2 (14 day) week FP window it would be less of an issue as it would be an even number of days. It a huge limitation in Flight Sim for creating AI traffic.
 
The trouble with "digging into" complex code that one developed years before, is that you sometimes forget the assumptions on which the code is based and you start finding problems that aren't there. In this instance, it turns out the missing legs are easily explained.

When operating in Fewest FPs mode, AIFP repeatedly cycles though the timetable data looking for the longest sequence of legs it can find, saves that sequence as a flight plan, excludes those legs from further searches and repeats the process until no further flight plans can be created. An underlying problem with this approach is that there may be a few legs left over that can't be connected in the usual manner. (This is very unlikely to happen with Balanced mode.) When I initially developed this feature, those leftover legs were of no concern to the users I was working with, so they were left unhandled.

The last data you sent me contains 1126 legs. The Fewest FPs mode connects 1107 of those legs, leaving 19 unaccounted for. The next version of AIFP you see will list those 19 legs individually. Of course, if you check "Deadhead Closure'' the number of legs generated will be increased by the number of deadhead legs - buit it will have no effect on those 19. Those unassigned legs could, of course, be linked with deadhead legs. But, this could result in several aircraft wandering around the world in an illogical fashion. So, since that particular issue can be avoided by using Balanced Mode, I chose to do nothing (other than, now, to document them.)

Yea, it's a very very helpful feature. I can now write a 2nd timetable data file for the missing flights and a 3rd if necessary and then merge them. Can you add the arrival times on the box also to go with the departure times along with plane type where it would show "KSAN-KDFW FN: 108 Dep: 6/17:24 Ari: 6/21:59 Aircraft:319" instead of "KSAN-KDFW FN: 108 Dep: 6/17:24" it would help me out on writing the 2nd time table for the Missing Flights to merge.

However I think you should also add a "Optional" feature to have it go through the skipped FPs and assign them by re looping them until all FPs have been assigned. I am sure it would provide fewer FPs than Balanced. This feature if implemented should be a selectable option in the "Create Flight Plans from Time Table Data Window" That may should the void of the missing flights.

For now if you could at least implement the Arrival time in "The following legs could not be assigned" section that would help me a megaton for working around this! TY

At the risk of repeating an earlier caution, if you do not enable deadheads, the timetable will display what appear to be erroneous legs and an equal number of legs will be missing. This is because every flight plan commences at the destination of its final leg. If a deadhead leg to bring the aircraft back to the originating airport is not added when needed, then the final destination of the flightplan will not be the intended start point and neither the timetable nor the flight plans will fully reflect the original timetable data.

While investigating this issue, I noticed a few "rough edges" in the user interface that I have smoothed out. Other than that and highlighting the unassigned legs, the next release will be virtually identical to what previously existed. Please monitor the sticky at the top of this forum for notice of the release.

I suspect you will not be particularly satisfied with this response. But, I would point out airlines spend millions of dollars for their aircraft scheduling software. You spent considerably less for AIFP.

Don

Who knows how much they spend on their software. All I know is that they're not limited to assigning just 7 days in a continuous circular loop in which Flight Sim limits us to. They have the luxury of and infinite calender to play with. 7 days is very hard to loop FPs as it is an odd number of days. If Flight Sim was design with a 2 (14 day) week FP window it would be less of an issue as it would be an even number of days. It a huge limitation in Flight Sim for creating AI traffic.
 
For now if you could at least implement the Arrival time in "The following legs could not be assigned" section
In Development Release 3.1.12(b), the confirmation report includes both arrival time and aircraft type - as you requested.

However I think you should also add a "Optional" feature to have it go through the skipped FPs and assign them
Even adding a deadhead leg between two unassigned legs on the basis simply that the second departs after the deadhead leg arrives is relatively complex and does not guarantee that all legs can be assigned. If done, the most likely result is a bunch of 2- or 3-legs (+deadheads) fps that bear little relationship to the original data. The creation of flight plans from those legs is best left to humans. You can dump the report to Notepad, which should facilitate entry of your solution. Note that the Balanced mode avoids unassigned legs and Return Priority seems to offer a reasonable compromise between the other two modes.

If Flight Sim was design with a 2 (14 day) week FP window it would be less of an issue as it would be an even number of days. It a huge limitation in Flight Sim for creating AI traffic
You should probably discuss that with MS or LM.

Don
 
Yea just tried it out. I have to go to balanced mode to fill the missing FPs on the 2nd go around.

However I think I spotted a bug in the Deadhead Leg FN which now shows as -1. Is that a legal FN for Flight Sim? I know the deadheads had shown as 0 as before.

When I run the time tables with the single aircraft type, I am not getting any missing FPs when I do run either Balanced Modes. But I am missing a bunch of FPs when I run time tables with multiple aircraft types on it when you say it shouldn't be missing those. Also when running multiple Aircraft Types in the Time Table I am getting the ole "Departure scheduled before or very close to arrival time of previous leg" and "The total duration of this flight plan exceeds the selected repeat period" Errors quite a bit. None of this happens when I keep each of my Aircraft types in seperate time tables so for some reason the program is handling the multiple aircraft types in the same time table data differently. So what data will you be needing to figure out this one?

Edit: I am also getting a few "Departure scheduled before or very close to arrival time of previous leg" and "The total duration of this flight plan exceeds the selected repeat period" errors on the 320 side of my Time Table data when I run any mode including both balanced modes. Those appear to be being caused by the deadhead route additions. But still no missing FPs when I run a single aircraft type in the FPs. They are missing when I run multiple aircraft types in both Balanced modes.

Edit 2: I remade my full time table with just 1 AC type and it does not have any missing flights when I run both balanced modes. But it still creates "Departure scheduled before or very close to arrival time of previous leg" and "The total duration of this flight plan exceeds the selected repeat period" errors when the deadhead legs are added. So it confirms that the missing balanced mode flights are occurring when I have multiple AC Types in the Time Table Data.
 
Last edited:
I have to go to balanced mode to fill the missing FPs on the 2nd go around.
Don't know what you mean by "2ng go around". But, as I explained, Fewest FP's is likely to have a few missing legs.

However I think I spotted a bug in the Deadhead Leg FN which now shows as -1. Is that a legal FN for Flight Sim? I know the deadheads had shown as 0 as before
Not a bug. It's intentional - to help identify deadhead legs. I changed it from 0 - which displays in the timetable as a blank - to make it stand out from legs in which the flight number simply was not assigned. ATC is directed to use the registration number on default legs, so it should not encounter those -1s. In any case, I'm not aware that it causes any difficulty

I am missing a bunch of FPs when I run time tables with multiple aircraft types
Actually, you're not. If you check the Flight Plan List or Timetable, you'll see all the legs have, in fact, been generated. But, the error report - erroneously - tells you they are missing.

This was due to me checking for unassigned legs too soon. All the legs assigned to a given aircraft are created sequentially, with each aircraft being treated in turn. I was checking for unassigned legs following each aircraft so, when the first aircraft was complete, it reported all the legs for the second and third aircraft as unassigned (which they were at the time). Then, following the second aircraft, another check was made and it reported all the legs for the third aircraft as unassigned. And that's the report you saw. As you can see, this logic is fine if only one aircraft is involved.

Development release 3.1.12(c) is now available at http://stuff4fs.com. It checks for missing legs only after all aircraft have been processed and, on your 3-aircraft timetable, doesn't report any legs unassigned.

Thanks for reporting that.
Don
 
Everything seems to be working now except for one thing.

The Sit-Time box in the "Create Flight Plans from Time Table Data" will not work if I put a number in there from a blank. On my Time Tables I put the Sit-Time variable in the 8th section. But the program still thinks there is not setting there so it will not process the Sit-Time part when I run "Create Flight Plans from Time Table Data" function. However If I restart AIFP, it does read the Sit-Time when I rerun it after restarting the program. So something is not right there. Do you need any data for you to test this on?

Edit: OK I got the Sit-Time bug to happen again. This time I put 240 in the Same FN Priority Box and then again with 60. I ran them and it acts like it's ignoring the Sit-Time value if I put a Same FN Priority value in. I realized that was going on when I restarted the program and forgot to put a value in the Same FN Priority and it paid attention to the Sit-Times then. So it seems like the bug has something to do with me putting a value in the Same FN Priority Box.
 
Last edited:
Back
Top