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

1.6.10 exception on FP update

S

scott967

Messages
1,268
Country
us-hawaii
I am getting many exceptions in 1.6.10 when I try to save an edited flight plan using the "Update FP in List". It says "index was out of range". Looking at the details, this seems to be what was happening:

at AIFP.AIFP.GetListItemIndexByItem_FP(FPListItem& fp)
at AIFP.AIFP.SaveFP(FPListItem& fp, Int32 nMode)
at AIFP.AIFP.btnFPSave_Click(Object sender, EventArgs e)

scott s.
.
 
1.6.10 was a very minor release with no change in that area.

I'm able to save without difficulty, so it wouldn't seem to be a general problem. Perhaps AIFP is sensitive to something I can see nothing amiss in the code.

Please send me the FP file that's giving you difficulty and details about the edit you made. Send it to the e-mail addesss in the user manual/readme if you like.

Don
 
Thanks. I was looking into it further. I had a set of ttools files (fs9) that I d/led and wanted to put into FSX. I needed to do some work (missing airports and changing the aircraft to what mine are) and got that done. Then to the best of my recollection, I tried the "Adjust day-encoding". (As an aside, I still don't know when you need to use this. Any time you have ttools fileset that you want to compile with the fsx option, or does AIFP automatically fix the day of week issue when it compiles?)

Anyway, my flightplans got messed up. I could see it in the validate and that's what I was trying to fix when AIFP had problems. I looked at the flightplans, and here is an example of what was in them:

AC#5,9M-MGA,1%,Week,IFR,6/23:10,5/23:50,130,F,3220,WBKL, 0/00:10,0/00:50,120,F,3221,WBGR ...

On all of them the first leg got messed up somehow (They are all weekly plans, starting at 1/00:10 on the first leg and ending on 0/23:50 on the last one in the original file). Problem is I can't repeat it now. One other thing possibly involved, when I first opened these plans I got warnings about being unable to use local time which was checked. IIRC the reason was that AIFP couldn't determine the offset for some airports. Eventually I did switch to GMT but I can't remember at what point.

So I can't really provide much help on what exactly went wrong.

scott s.
.
 
Last edited:
Any time you have ttools fileset that you want to compile with the fsx option, or does AIFP automatically fix the day of week issue when it compiles?)
Click to expand...
To use a FS9 TTools-format flight plan file for FSX, all you need is load the file set and compile within the FSX checkbox in the compile dialog checked. The adjust days and convert airports functions are provided for the situation where you want to save the FS9 text file in FSX format - which few will want to do.

Anyway, my flightplans got messed up. I could see it in the validate and that's what I was trying to fix when AIFP had problems.
Click to expand...
What did the validate routine "complain" about? Do you still have the original files you downloaded?

I'll take a look at the adjust day-encoding code.

AC#5,9M-MGA,1%,Week,IFR,6/23:10,5/23:50,130,F,3220,WBKL, 0/00:10,0/00:50,120,F,3221,WBGR ...
Click to expand...
When you say "messed-up", do you mean that the first leg starts on Friday, that it's 6 days long or both. There is no need for the first leg in a TTools flight plan to be the earliest in the time period. The legs only need to be in time sequence and circular. The six-day long leg is, however a problem.

Without knowing the "starting point", it's going to be difficult to figure out what went wrong, But I'll give it a try.

Don
 
Scott, at the moment, there are just too many "unknowns".

Please confirm that the arrival time in the first leg was, in fact, "5/23:00" and not a typo. (If it was "6/23:50", that could be a consequence of adjusting day-encoding.)

Had this flight plan been loaded into the leg editor?

Regarding the execption you initially reported, what edits had you made when the problem occurred?

I need to see the original file before delving into this further.

Don
 
Sorry I am a little slow (burning my brain out doing taxes). My core problem, based on what I've tested with, is that somehow the fileset I started with got leg times changed before saving. The best I can make out is what was the last leg (based on departure day) in each plan in the original file was
6/23:15,6/23:50
and in the version that was saved, this leg was moved to the front of the file as
6/23:15,5/23:50
which caused a validation error as the leg shows an override ETA of 23:50+6 which is obviously a problem.


It appears that this is caused if you have the timezone set to local, but one or more of the airports used by flightplans are not in the airportlist.dat list, and no timezone offset is set. You should probably inhibit the local setting unless all airports used by the flightplans have an offset listed.

scott s.
.
 
Thanks, Scott. I thought (fervently hoped) I'd seen the last of the local timezone problems, but it seems "no such luck". Knowing that the "5" is real and not a typo gives me a clue.

You should probably inhibit the local setting unless all airports used by the flightplans have an offset listed.
Click to expand...
Local time is only of consequence in the leg editor. Outside the leg editor, times are always held as UTC (but displayed in local time if selected). The problem you are seeing would seem to be due to a residual conversion issue (over midnight flight on the weekend.)

This thread started off as and exception reporting (which I have been was unable to duplicate). How does the current problem relate to the reported exception?

Don

EDIT: BTW, you said earlier that the flight plan file with which you were experiencing difficult was a FS9 file you had downloaded. Do you still have that original file? If not, do you recall from where it was downloaded.
 
Last edited:
Scott, don't bother sending me further info on the source FP. Ive managed to duplicate the problem. Don't know the specific cause yet, but it's only a matter of time.

Please respond, however, to my query re the exception.

Don

EDIT: Problem causing day change from 6 -> 5 found and fixed. If I haven't heard from you by morning (PST) re the exception, I'll re-release with that fix and fixes for a few other minor issues that have cropped-up over the past week or so.

Don
 
Last edited:
gadgets said:
Scott, don't bother sending me further info on the source FP. Ive managed to duplicate the problem. Don't know the specific cause yet, but it's only a matter of time.

Please respond, however, to my query re the exception.
Click to expand...


The exception came when I was trying to fix the flightplan after the leg times were messed up. I tried editing the leg, by removing the "Override ETA" data for the leg, which was 23:50+6.
The ETA box was 00:04+1 which looked right. So I deleted the "Override ETA" data and clicked the "save edits", which looked like it worked as expected. But then when I clicked the "update FP in list" I got the exception. But, since I figured out there was a problem with how the flightplans had been saved earlier, I stopped worrying about the exception and started focusing on why the flightplan got damaged initially.

The exception is still there though.

scott s.
.
 
Scott, I have found and fixed the code that forced the exception. It appears to have been caused by AIFP encountering a flight plan higher up in the flight plan file than the one being edited, but that was identical to the one being edited (prior to editing) except for having fewer legs. But, the exception could also have been caused by, after loading the flight plan into the Leg Editor but before updating it, using the text editor to modify the flight plan prior to saving from the Leg Editor.

Regarding what was originally the last leg in the flight plan becoming the first leg after editing, that is a natural consequence of the flight plan being edited and saved while in the Local time mode. (6/23:15 UTC is 0/07:15 local, which is the earliest departure time in the flight plan. Therefore, the leg was resequenced to become the first.) As I noted in an earlier post, so long as the legs are "circular" in departure time order, it doesn't matter which one comes first.

I'll release later today.

Now that I know what to look for, so that I can be sure of the cause in this case, would you please send me the original, unmodifed flight plan file or tell me where you found it.

Don
 
Scott, by process of elimination I discovered the file of interest was the AIG MAS flight plans. I've downloaded and tested that file without difficulty. So, I'm assuming the fixes I made this morning fully address the problems you were experiencing.

AI Flight Planner version 1.6.11 now released.

Thanks for persevering.
Don
 
You must log in or register to reply here.
Back
Top