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

FS2004 AIFP3 eats up all memory

I loaded AIFP - Bulk Traffic - Traffic and Parking - Analyser: installed aircraft were scanned. Okay so far.
Then I clicked Traffic Files - All Files currently Accessible in FS9. Traffic Files are loaded and displayed.
Extracting airports and aircraft was running about 10min, then the memory was eaten up. For HD based mode I clicked "yes" and the same happened again.

AIFP3212(c) works fine, (h) and (j) use all my memory 16GB, even in disk based mode.
I attach 2 screenshot including Hardware Info at the 2 situations.
 

Attachments

  • AIFP.zip
    1.1 MB · Views: 108

gadgets

Resource contributor
Is there a way to detect multi-week plans?
If you mean, will AIFP tell you that one or more of a multitude of files contains a multi-week FP, No. If you load one into the editor, Yes.

So as not to require a major re-design to allow AIFP to accommodate multi-week FPs, the amount of data collected by the AIFP Traffic Analyser depends on the longest repeat period encountered. So, if, for example, one of your traffic file contains a 5-week repeat period FP, AIFP will collect 5 weeks of data for every leg of every flight plan whereas, before, it collected only one week-s worth of data. But, in your case, you are running out of memory while initially loading the FP data, which is a little strange.

Please try loading with fewer files and see what happens.

Don
 
The (c) works fine with all my traffic bgls

AIFP3.jpg

It uses less than 5 GB.
I will try some tests with fewer files.
 

gadgets

Resource contributor
Guenther, there's been a lot of "water under the bridge" since (c) was released. Further (c) "knows nothing" about multi-week FPs and will interpret them as sub-24 hr repeats.

I tested (j) with the first 30 of my more than 900 bgls and the error was there:
So, now, what I'd like you to do is determine if the problem is caused by one particular file or is it's really a cumulative issue. With only 30 files, you should be able to isolate the culprit (if there is a single culprit) with fewer than 11 tests. Pick half those files and check again. if the problem occurs, pick half of that half, and so on. If the problem does not occur at any stage, then check the other half. If the problem doesn't occur with either of the first halves (i.e., 15 files) then we know it's a cumulative issue.

But, before doing anything, please install Development Release 3.2.12(k), just posted. There was a problem in the compiler that could lead to an error message on decompile, So, we first need to ensure your entire issue wasn't caused by a recently-compiled traffic file containing that error condition.

Don
 

gadgets

Resource contributor
next test with (k) not better
I didn't think it would be. But, there was no point in potentially wasting your time is it was.

Are you going to be able to narrow things down for me?

Don
 
Hi Don,
my last tests were done with (k). A single random bgl went fine, two random bgls went fine, the first about 25 went wrong.
So I will test as you suggested and find the mean bgl.
But I am sorry, it will be tomorrow...
 
Hi Don,
I could find the (or one of the) culprit bgl: TrafficBrive.bgl.
It contains invalid data:
AIFP6.jpg
 

Attachments

  • TrafficBrive.bgl
    560.7 KB · Views: 214

gadgets

Resource contributor
That message was likely "hiding" behind one of the dialogs earlier. All is well otherwise, I presume.

Don
 
No Don,
I deactivated TrafficBrive.bgl and I get other "memory eatings" at further tests.
Perhaps you could catch those "zero periods" in my traffic bgls before I run further tests?
 
That message was likely "hiding" behind one of the dialogs earlier. All is well otherwise, I presume.

Don
This message was not hidden behind some other dialogs. It appeared in the "main window" (not in Traffic and Parking Analising) when I tried to have a look to TrafficBrive.bgl
 

gadgets

Resource contributor
I deactivated TrafficBrive.bgl and I get other "memory eatings" at further tests.
Without a sample file to test, I would be looking for a "needle in a haystack". I really do need for you to isolate a file that causes you situation.

Perhaps you could catch those "zero periods" in my traffic bgls before I run further tests?
I purposely avoided re-validating each traffic file before loading it for analysis so as to not unduly delay startup of the analysis. I guess I should take another look at that philosophy.

Please send me one of your faulty traffic files so that I can see what "minimum" testing might be required.

Don
 

gadgets

Resource contributor
Thanks. I've got to go out for a while, But I will have a morning greeting for you tomorrow.

Don
 

gadgets

Resource contributor
Found two errors, one old and one new. In my changes to accommodate multi-week FPs, I inadvertently disallowed 1Hr repeats, declaring them invalid. That's the new one. The other, which has been there since I added the function, is that when the analyser encountered an invalid repeat period, it attempted to create an infinite number of analyser "items" thus exhausting memory.

The file you sent (and that was causing your difficulty) contained two 1Hr repeat FP, which were declared invalid and triggered the second issue. Incidentally, some of the departue/arrival times in the file are invalid for a 1Hr repeat.

Development release 3.2.12(l) at http://stuff4fs.com fixes both issues you reported. I leave it to you to address the invalid times..

Don
 
Top