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

New AI Flight Planning Tool

Status
Not open for further replies.
Found it! I was using a comma as a separator in a text string which included a number with a decimal point. With German localization selected, the string contained one more comma than I anticipated. The problem (should) only occur if you are using local [EDIT] standard [/EDIT] time coupled with germanic localization.

Martin, have you found anything else? If not, do you think I should delay release any longer?

Don
 
Last edited:
Given that local time is a major "selling point" for AIFP, I thought I should re-release with that bug fixed. I have also completed the user manual and updated the timezone database. New version here.

Unless someone finds a problem with this version, I will release it in the next few days.

Don
 
Don,

The error is partly corrected. I say partly because I have found another one :o, which is most likely related somehow

This is what I do:

I start like last time and select the flight from EDTG to ETAR, beginning at 10:00 and ETA gives me the right value now. I save the leg data.

I add a new leg. This time going from ETAR to KLAX. Starting at 12:00. The distance and duration is correctly displayed (at least the numbers make sense). But the Arrival Time is "00:50+1".

A bit of testing indicates the problem is due to the fact that the flight is taking longer than 12 hours. This happens on XP as well as on Vista.
 
Last edited:
Martin, I'm not sure what you see as the problem. If the "+1", it is intentional, indicating that the flght arrives the following day. The "+1" will not be transcribed to the Flight Plan List - unless you're using weekly frequency in which case it will be reflected as the day of departure plus one - as it should be. Using local times, that suffic could also be -1 (crossing the date line eastbound) or +2 (crossing the dateline westbound on a flight that departs North America for, say, Singapore shortly before midnight.

Since I suspect arrival times will be of concern primarily with airline traffic, I'm trying to emulate airline schedules which often use such flags.

Don
 
So much the better, Don.
For me it was looking like an invalid time code, because I did not know this notation.
 
Don,

I liked your explanation very much, but not so your program :D

If I try to save the leg data with a string like "01:20+1" in arrival time (like in above example), I get an exception error saying error during conversion to a double data type.

Have you tried to reproduce my script?
 
Last edited:
Sorry about that. It was a misplaced parenthesis ")". But, there is another bug "lurking behind it". I'll clean it up and re-release later today.
Don
 
I hope this is the last one, guys. Beta version 0.63 available here.

The most significant change is that the "Start-at" airport is gone. Please pay close attention to the airport AI Flight Planner identifies as the originating airport. The other changes are largely cosmetic. Please read the Notes to Beta Testers.

Have fun,
Don
 
Don,

Maybe I am doing something wrong. I have loaded an aircraft file and started a flight plan from scratch.

I could enter Repeat Period, select an aircraft, enter the tail number and the activity level.

But I can't continue from here on, because all other fields are disabled. When I toggle the 'Use Local Time' checkbox, I am told that data has been changed and am asked if I want to save it. If I say yes then it tells me that a departure time must be provided - logical, but I can't do it.

This is with XP.
 
Last edited:
No, you weren't doing anything wrong. Yesterday, while I was adjusting the positioning of the controls to accommodate the removal of the "starts-up" airport, for some unknown reason the FP Type group box got disabled. v064 uploaded.

Sorry,
Don
 
Don,

I have another error now. What I do is plan a flight from scratch from EDTG to ETAR at 10:00. I use the ETA button and save the leg. OK so far.

Then I add a new leg at 12:00 to KLAX.When I click save leg I get an index out of array error.

After I confirm the error with continue, the line of the first leg in the leg list box is empty (though still there).

This time it is on Vista.
 
Hi Don,

OK, this last bug is ferret out.

Question: Do I see that you don't add the +1 to the arrival time when you make a flight that leads into a new day?

Suggestion: I have caught me again while testing this time that I opened up firefox to search for the ICAO of Mather AFB. For those like me who can not easily remember ICAOs it would be more than helpful to have a small button beside the airport from and to filed, which on click opens a search mask for either ICAO or airport name.

Bug:

This is what I did. I only give you the relevant parts so that you can reproduce it.

  • Start tool, start flight plan from scratch
  • First leg: EDTG departure time 10:00 to ETAR (use ETA button)
  • Second leg: ETAR departure time 11:00 to KLAX (use ETA button)
  • Third leg: KLAX departure time 15:00 to KMHR (use ETA button)
  • Fourth leg: KMHR departure time 09:00 to CYYR (use ETA button)

As soon as I press 'Save edited leg data' this last leg is shifted to first position. It looks like the leg are sorted by the departure time. To confirm I add the next leg at 9:30 and then one at 07:00, which I expect to go on second and first place.

  • Fifth leg: departure time 09:30 to KBIF (use ETA button)
  • Sixth leg: departure time 07:00 to EDTG (use ETA button)

==> It looks like every leg is sorted in the list according to the departure time. Therefore the flight plan shuffles completely.
==> surprisingly for the last two legs I suddenly had the +values in the arrival time again. So why were they missing for leg 2?
 
Thanks for the report, Martin.

First, the good news. The ICAO lookup capability is already there - in two places. First, the top item in the Airports menu and second, if you type a question mark (?) into any airport field.

The "+1" suffix should be there in every case of arrival on a different calendar day from departure. But, it is there only in the editor and the Leg List. You should not see it back in the flight plan list.

Yes, the Leg List is sorted by time. This is a recent change. (I assume) Legs must be sorted by time for the flight plan to be valid in the sim. Is this sorting a problem for you?

That's an interesting flight plan - four trans-Atlantic crossings in the same day plus a couple of local flights? If you had created the same flight plan without the legs being sorted and compiled it with TTools or AIFPC, would all legs have operated in the sim? Have you discovered a way to spawn simultaneous AI flights from a single flight plan? If so, I need to make AI Flight Planner a little "smarter". (Had you attempted to save this flight plan back into the Flight Plan List, you would/should have received several "departure before arrival" error messages.)

When you add a leg, the departure airport set by the system is the destination of the last leg in the Leg List. When you insert a leg, the departure airport is set as the destination of the leg immediately previous to the insertion point.) The departure airport is used to calculate ETA. (Incidentally, there's nothing special about an arrival time set using the ETA button. Once entered, there's no record that it wasn't typed by the user.) For the last two flights entered, since you added them, the departure airport would be KMHR. Given the 8hr time difference, the 0700 departure to EDTG would have arrived after midnight (local or GMT); hence the "+1". I can't explain the "+1" suffix on the 0930 departure to KBIF. Were you using local times? If not, what time zone was set, please?

Finally, you said
I add the next leg at 9:30 and then one at 07:00, which I expect to go on second and first place.
Click to expand...
I hope that is where they actually were placed.

The really good news is that you didn't encounter any other difficulties. Unless the sorting of the Leg list creates some difficulty with the sim, perhaps we're finally "there".

Don
 
Don,

It's a Habu I’m flying :D

The route is not realistic and the main purpose of it is not to go there but find possible errors. And for that purpose it was quite good over the last weeks.

Logical evaluation
I guess we are running into problems if a flight is taking longer than the repeat period is adjusted to. I have expected this is checked and handled automatically. I think the user should be warned in such a case. Even better would be to clear the repeat period selection so that he is forced to actually re-adjust this setting.

Let us find out what is happening. I start a flight plan with a short trip from EDTG to ETAR and then head of to KLAX. Depending on my departure time (12:00 or 14:00) I will arrive at KLAX on the same or the next day.

What should happen from my point of view is this: when I am on a daily repeat modus (1h-24h) and my flight plan is exceeding the respective time circuit, this should not be allowed, because it will not lead to a usable flight in FS.

The same is true for the weekly schedule. Say I start with above example on Monday. If my flight ends up in KLAX on Tuesday, this should be reflected in the week day settings automatically when I add a third leg. It should not be possible to define a flight plan which is not logical. So the second leg e.g. should not be allowed to depart before the arrival time of the first leg.

Errors when switching between repeat periods
I have seen errors when I was messing around with changing the repeat settings from a daily base to week within a flight plan in progress. The errors were different ones at different times. I have seen something like a freeze where I had to kill the program with the task manager. Then I had a situation where I had lots of unhandled exceptions errors. I tried several times to make to get a reproducible row of events, but it seems to be rather erratic.

Sorry for not providing a better script. You will see it yourself when you add legs and change the repeat period for already saved legs.

Leg display sorting
Sorting the leg display on departure time makes it rather hard to read and is the first design change since the start which I see as a step in the wrong direction. If I imagine that I plan a week trip and while I add the different parts they are getting re-sorted I must say that this probably has a lot potential of confusion.

Change time zone before first leg
Something else I found is that if you change the time zone before you have added data for the first leg, you are informed that "changes have been made to the current flight plan and if you want to save it". If you answer yes it can't save because the departure time is missing.

Time conversion error
There is still something wrong with the time conversion. See the screen shot. My time zone is always UTC +1.
 
Last edited:
It's a Habu I’m flying :D

The route is not realistic and the main purpose of it is not to go there but find possible errors. And for that purpose it was quite good over the last weeks.
Click to expand...
Yes, this routing certainly has been helpful at finding errors over the past little while.

The system is leg oriented. Checks on the whole flight plan before the flight plan is complete may generate some not-so-useful error messages. However, leg duration > repeat period can be checked and I will issue a warning. (If I clear the repeat selection, the leg fields will become disabled.) While I don't do so at the moment, I can also check total flight time when the flight plan is saved and generate another warning there if it exceeds the repeat period.

I've never changed repeat period while editing. The problems likely occur when switching between weekly and non-weekly flight plans. I'll give that area a thorough check. Re the time zone errors you found, I'll suppress the unnecessary error message. The exception should be easy to track down.

Re automatic sorting of the leg list, the difficulty is that if legs aren't in the proper time sequence, it's difficult to impossible to find, reliably, the departure airport, which makes the distance/duration/ETA always suspect. Let me think about that some more.

Don
 
I guess we are running into problems if a flight is taking longer than the repeat period is adjusted to. I have expected this is checked and handled automatically. I think the user should be warned in such a case.
Click to expand...
The system now checks for arrival and departure times with an hour specification greater that the repeat period. For example, with a 12hr repeat period, a time of 13:15 would be invalid. A warning is issued. I can probably also check total flight plan duration when the modified FP is saved back to the flight plan list.

Change time zone before first leg
Click to expand...
Message is now issued only if there is at least one complete leg in the Leg List.
Errors when switching between repeat periods
Click to expand...
I have been unable to duplicate any of these. But there's very little code left that is executed when these controls are used. Most of it was removed last week along with the "starts-up" airport. That's likely what was causing the problem.

Time conversion error
Click to expand...
Fixed

Sorting the leg display on departure time makes it rather hard to read and is the first design change since the start which I see as a step in the wrong direction. If I imagine that I plan a week trip and while I add the different parts they are getting re-sorted I must say that this probably has a lot potential of confusion.
Click to expand...
This is a difficult one. The leg list must be sorted in order to reconstruct the FP for saving. I could copy the list when it's time to save and work on the copy. But, with an unsorted list, the "find departure airport" feature (needed for calculating distance/duration/ETA) won't work reliably - if at all. What I think I'll do in the near term is allow the user to select either a sorted list or an unsorted one but, in the case of the latter, also to sort on command. In either case, once the flight plan is saved and read back into to the editor, it will be sorted.

I'll try to have this all in a release tomorrow. You can take the rest of the day off;).

Don
 
gadgets said:
You can take the rest of the day off;).
Click to expand...

:D

gadgets said:
This is a difficult one. The leg list must be sorted in order to reconstruct the FP for saving. I could copy the list when it's time to save and work on the copy. But, with an unsorted list, the "find departure airport" feature (needed for calculating distance/duration/ETA) won't work reliably - if at all. What I think I'll do in the near term is allow the user to select either a sorted list or an unsorted one but, in the case of the latter, also to sort on command. In either case, once the flight plan is saved and read back into to the editor, it will be sorted.
Click to expand...

Explain it to me, Don. I am sure that I am still not getting what you are aiming at.

Let me make a simple example without real airports. This is a weekly schedule.

  • Start Monday at 12:00 at AP1 and go to AP2
  • Start Tuesday at 11:00 at AP2 and go to AP3
  • Start Thursday at 09:00 at AP3 and go to AP4
  • Start Saturday at AP4 at 07:00 and go to AP1

In the leg list the flights would be sorted exactly the other way round like they are taking place, right? So I would see the Saturday flight first, and the Monday flight last. Why does this need to be this way?

Regarding your departure airport comment: It is always the current list entry -1, isn't it? If you add a leg, it is easy, then it is the last one. If you insert or delete a leg, it is more difficulty. But still it would be the one before the current list entry.

I probably miss the crucial point here, which I would like to understand.
 
Status
Not open for further replies.
Back
Top