FSNav

[Opa 6]

Hans -I might be helpful to know whose LLBG enhancement your are using (the complete filename and where you got it).Then one of us could take a look at those "sign" bgls and see what they actually are.

[John Hinson 23]

John,Just like you I've been re-arranging my FS9 scenery library priority levels but strangely enough, this sometimes caused hangs on unrelated other airports onwhich hangs had never occured before. There's definitely something fishy going on here especially as I have discovered that "normal" object placement BGL files can sometimes cause the DBC hangs and that during such hangs there's a lot of CPU activity going on. Why and how, I have no logical explanation but there may be a possibility:

Hi Hans,Exactly so! Its clear that there is something about the way FSNAV reads the scenery folders and gets hiccups, but keep jiggling them around and you get the right formula to keep it happy eventually. A bit tedious, I know, but as the product is no longer maintained I think we are stuck with it.

Have you or anyone else ever used a program which searches for duplicate addon scenery texture files and deletes those found when they are already present in the main FS9 texture folder ? With the modern use of MDLs in library.bgl files, combined with object placement BGLs (using GUIDs) and related very specific texture.bmp files, the results of this program could indirectly have something to do with this whole hang problem. I hope you or any technical gurus can comment on this.

I don't think it would be duplicate textures because I would imagine that FSNAV only reads scenery directories - the textures would have no bearing on its end result. I'm no guru, though!But it is true to say that whilst I weed duplicate library files quite aggressively (I wish designers didn't whack them in with every scenery they release) I tend not to go through all the textures to eliminate the duplicates.

But going back to LLBG which was previously a notorious hang airport, I see my tweaked correct airport layout on the FSNav map but down on the bottom right, near the beginning of runway 30, I see 4 other airport reference points stacked on top of each other. These are placed there by 4 scenery folder files: LLBG-Signs.bgl, LLBG-Signs1.bgl, LLBG-Signs2.bgl and LLBG-Signs3.bgl.Now I know from experience that duplicate Afcad files and/or some types of Afcad errors, kan cause a host of unexpected problems, e.g. system crashes and CTDs even in far away places, so my first suspicions are directed towards these 4 files. When I de-activate all 4 of them my AI traffic still goes on as usual, I can fly in and out of LLBG quite normally, the DBC runs without a hang and the FSNav map seems to be OK. So why are these files there ? What do or should they do ?

From what I have read elsewhere, the other files that FSNAV is reading are .bgl files for other functions that the developer has wrongly included "airport headers" in, so FSNAV thinks they are AFCAD files when they are not. And if there are several (as in your LLBG) in the same folder, FSNAV will map the last that it reads, even if it isn't the AFCAD. This can show some strange results and is exactly the circumstannce where I would move the AFCAD to a higher scenery layer (I have a folder dedicated to AFCADs like that) and then that one will be read last and displayed properly.I don't think the various files you mention will run into any "duplicate AFCAD" problems as the others are not really AFCAD files, its just FSNAV is assuming they are from their header composition.Hope this makes sense! As I said above I am no guru, having only picked up what I can tell you as I've gone along. There may be technically-minded people here that will understand the reasons behind all this better, or even tell me I'm talking tripe!Best wishes,John

[hjwalter 25]

Hello David, John and hopefully Jim,The Ben Gurion file name is: llbgacof.zip (LLBGACOF.zip) and it's in the FlightSim.com library. The 4 quoted "Sign" BGLs only seem to contain (unnecessary extra) airport reference points and ILS data. There are more addon airports containing such Afcad type BGL files and these are most often named: Taxiway_signs.bgl. I have very often structurally de-activated these because they have no effect on the airport sceneries concerned nor on any AI activities, etc. But they must be there for good reasons ........ but I still need to discover them.But getting back to the FSNav DBC hang problem, I have the following theories:I realise that I'm probably clutching for straws here but I've already experienced strange and unlogical issues with texture files not or no longer being present in their original positions within some addon airport texture folders. This seems to be especially true when LIB(lary) BGLs containing MDL files are used in conjunction with object placement BGLs which in turn use GUIDs specifying where to search for the related texture files. Jim correctly pointed this out.It then follows that any program, which structurally deletes addon texture files when they have the same names and contents etc. as any such files already present in the main FS9 texture folder, could therefore potentially break such linked chains and least of all, will cause untextured objects in other previously correctly displayed sceneries. My theories about this are based further on my (test) de-activations of certain object placement BGL files, e.g. in my Afonsos (SBAF) airport scenery, which as a spin off also caused the FSNav DBC program to proceed past any previous hang points, in fact even past the above Ben Gurion (LLBG) scenery ???My haphazard "shots in the darkness" evidently didn't directly hit anything but something did certainly move as a result !!My suspicions about these seemingly unrelated texture issues also being responsible for the FSNav DBC hangs, are strengthend further because of the high CPU activity going on during such hangs when the program seemingly, during it's search for Afcad type data in ALL scenery BGLs, gets itself into an endless loop of some kind, thereby causing the program to hang and not to crash (CTD). One of these test loops (hangs) went on for two hours in my system before I manually stopped it, making my CPU very thankful !!Comments are welcome.As john correctly points out, this fantastic FSNav program is no longer supported but there is a new light on the horizon in the way of a comparable Aerosoft program called: FSCommander. It works for FS9 and FSX but will take some getting used to after "growing up" on FSNav during many years. I've seen it working and unlike FSNav, even on a second screen. It also has far more functionalities than FSNav. However, I myself have no direct experience with it ...... yet.RegardsHans

[hjwalter 25]

John wrote:From what I have read elsewhere, the other files that FSNAV is reading are .bgl files for other functions that the developer has wrongly included "airport headers" in, so FSNAV thinks they are AFCAD files when they are not. And if there are several (as in your LLBG) in the same folder, FSNAV will map the last that it reads, even if it isn't the AFCAD. This can show some strange results and is exactly the circumstannce where I would move the AFCAD to a higher scenery layer (I have a folder dedicated to AFCADs like that) and then that one will be read last and displayed properly.I don't think the various files you mention will run into any "duplicate AFCAD" problems as the others are not really AFCAD files, its just FSNAV is assuming they are from their header composition.Hi John,Yes, I agree with you that it's better to place all real AF2_XXXX.bgl files in a separate high priority folder in order to avoid (potential) "strange results" in the FSNav map. I also agree with you that the 4 Afcad type "sign".bgl files in the LLBG airport scenery, will not cause "duplicate Afcad" CTDs because they have no runways and ESPECIALLY because they have no start positions. Duplicate runways are technically speaking OK but duplicate startpositions = BANG = CTD !!However, because LLBG was also a notorious FSNav DBC hang airport in my FS9, I was already crunching that scenery for potential causes. My question was therefore only related to possible reasons for these 4 seemingly unnecessary files to be included in the scenery in the first place. But as I discovered later, they were not in any way responsible for the hot FSNav DBC hang issue at that airport. All 4 have their "airport reference points" in exactly the same positions which caused the FSNav map to seemingly "stack" them on top of each other near the beginning of runway 30.Thanks for your input though.RegardsHans

[pan pan pan 60]

I remember having the FSNAV hanging problem ages ago.From memory, it used to hang on the "addon scenery" section for me when creating the database.Now im recalling from a VERY dodgey memory here, but im sure it had something to do with deleting the two scenery files (Scenery.000 and Scenery.001) from the /modules/fsnavigator folder, then running the "create database" again.Now anybody who wants to try this, i suggest you save these two files before having a crack. As i said, this is from a VERY dodgey memory!

[hjwalter 25]

Pan Pan Pan wrote:I remember having the FSNAV hanging problem ages ago.From memory, it used to hang on the "addon scenery" section for me when creating the database.Now im recalling from a VERY dodgey memory here, but im sure it had something to do with deleting the two scenery files (Scenery.000 and Scenery.001) from the /modules/fsnavigator folder, then running the "create database" again.Now anybody who wants to try this, i suggest you save these two files before having a crack. As i said, this is from a VERY dodgey memory!Thanks for your input but I'm afraid our problem goes a lot deeper and will not be cured by deleting the two files and letting the DBC program create them again from scratch. This has quite obviously been tried many times before but to no avail.For your information, the DBC program creates two tempory files inwhich the necessary data is built up but only after sucessfully reaching it's end will the program overwrite the two files already present, with the new ones. This means that the existing files are not damaged in any way when the program hangs somewhere halfway for whatever reason, nor by the user being obliged to abort it.Hans

[ErnstB 13]

I had FSnavDBC.exe hanging regularly, always when scanning the Addon Scenery\scenery folder with all Afcads and other files in there.My remedy which led to absolutely faultfree function and scans was:1. Create a new, separate Flight Simulator 9\Afcad\scenery directory for ALL Afcads2. Create a separate scenery.cfg for FSnavDBC.exe scans which contains the few scenery entries only which have no AF2 files (rare). All the other, remaining bgls don't need to be scanned by FSNAV. They just add to scanning time and add to the risk of hanging.Backup the real scenery.cfg before overwriting!I have well over 1000 sceneries but have separate scenery.cfgs for Europe, Americas, Asia/Africa/Oceania plus 1 scenery.cfg for FSNAV and 1 for AES scans.Hope this approach helps with sceneries problematic to FSNAV.RegardsErnst

[John Hinson 23]

All the other, remaining bgls don't need to be scanned by FSNAV. They just add to scanning time and add to the risk of hanging.Backup the real scenery.cfg before overwriting!

Not sure on this, but doesn't FSNAV calculate the landscape's height on the map from scanning terrain files? Not that the results it shows on the map seem to make sense to me.John

[ErnstB 13]

Hi John,I think all airport information neeede by FSNAV is contained in the AF2 files.Of course, my scenery.cfg for FSNAV contains all the basic/default scenery files.However, from the addon sceneries with AF2 files I really only use these files. I remove them from their scenery folder and copy them to my Flight Simulator 9\Afcad\scenery folder.If there is no AF2 provided I simply add the main scenery.cfg entry to the FSNAV scenery.cfg.Works like a charm since more than 3 years with 175 scenery entries for FSNAV (but 1525 entries in total! Crazy!?)BTW: I am using Hans Hartmann's SCM2004 scenery utility for organizing my scenery.cfgs. Great little tool!RegardsErnst

[hjwalter 25]

Hey there Ernst,Your explanation about a separate scenery folder inwhich .... ALL ..... addon AF2 files are stored is logical and clear. I assume you have given this folder the highest possible priority in your FS9 scenery library list, i.e. it's right at the top.However, your explanation about using a separate dedicated scenery.cfg only for the FSNav DBC program, raises some questions:Do you, before running the DBC program, de-activate your main scenery.cfg file (by temporarily) renaming it's (.cfg) extension while at the same time activating your separately built up one ?If so and as I think I understand, you are then (technically speaking) doing what can also be done within the program itself, i.e. disabling all ....ADDON ONLY..... NON AF2 scenery folder entries, before running the DBC program. This method, I would agree with you, would be a rather tedious and repetetive process as opposed to your once only building up and maintenance of a separate DBC scenery.cfg and temporarily renaming them so that the DBC program can do it's work. After all, FSNav and it's DBC program is a completely stand alone system which only produces the map with all it's contents and has no further direct links with FS9, other than creating automatic flight plans which I assume will not be negatively influenced by your method.So the main scenery.cfg file used by FS9 when it activates should contain ALL scenery folder entries including the one with all the AF2 files in the highest priority and the separate one, specifically for use by the DBC program, should contain only the AF2 folder entry and the FS9 native/default entries, without any addon scenery entries.Am I correct ?RegardsHans

[gwillmot 31]

This has been my experience with FSNav.I could never get a database update to complete using version 4.7. However, I never have a problem with using version 4.6. Your key should work with either.Try to find version 4.6 and I'm betting that your problem will go away. Evidently there was a difference as to how AFCADs were handled between the two versions. I have version 4.6 in case you need it.I know it works for me. :( gwillmot

[ErnstB 13]

Hi Hans,Basically it exactly is as your are outlining it, it differs only in detail. You probably are also right with giving this Afcad the highest priority, but this is not the case with me. I once had the problem with a Russian scenery that putting the AF2 file in my Afcad folder was not reproducing the airport as it should.I therefore was putting the AF2 file back into the Russian scenery folder and copied the scenery.cfg entry into my scenery.cfg for FSNAV.Your high priority approach would most probably have done the same thing. I'll try your suggestion, however not within the coming 2 weeks since I'll be away from my PC.What I am exactly doing:In my Flight Simulator 9\ directory I have created the following folders:__FSNav Sceneries__Scenery for AES_Scenery Americas_Scenery Asia Africa Oceania_Scenery Europe WITH CHProX_Scenery Europe WITHOUT CHProXThey appear on top of the Flight Simulator 9\ directory.These folders contain the scenery.cfg files for the respective area. I always copy in there the latest version in there and rename with adding the number of scenery entries (e.g. 655 scenery.cfg).Every folder has only 1 file named scenery.cfg, which is the latest version with all actual entries.Every scenery.cfg has the basic and common files needed all over the world plus the addon airports I want to use intercontinentially.For changing from Europe to America I just copy the scenery.cfg from the _Scenery Americas folder into the main directory of Flight Simulator 9, overwrite and start-up FS.For FSNAV or AES or for flying in Asia I just do the same from within the relevant folders. Much faster operation of FSNAV and AES programs since less entries to be scanned.Sounds more complcated and more extensive than it really is, having once established the basic files.Here SCM2004 is of great value, since it renumbers the scenery.cfg entries, you can fast and easily range entries, even multiple entries, rename, add flattens, etc. When starting it it searches and scans the main, active scenery.cfgRe gwillmot: I am using FSNAV 4.7, no probs.Hope these many words explains how it works for me. I find it simple, reliable and above all absolutely trouble-free!RegardsErnst

[gwillmot 31]

Re gwillmot: I am using FSNAV 4.7, no probs.

I understand many had/have no problems using FSNAV 4.7, but there were some (such as I) who could not get a database update no matter what we did. This was documented in the FSNAV forums at the time.I just offer it as a possible solution.gwillmot

[hjwalter 25]

Hi all those who have/had FSnav dbc hang problems.What the FSnav data base creator (DBC) does is create the FSNav map only, nothing more. In order to be able to do this it searches through all active sceneries for Afcad type data but sometimes it will unexpectedly "hang" at certain sceneries for no apparent reason. David names some reasons in this thread and I've also named some others but these are not always the only reasons for hanging.To cut a long story short here's what I've done:I created a new folder in my addon scenery folder and named it "AF2_files" with it's corresponding "scenery" folder. No texture folder.I did a search through my whole FS9 folder looking for file names beginning with or having "AF2_" in their names and I got very many "hits". I cut/pasted ...ALL....hits found to this new AF2_files/scenery folder. To my surprise I even found a number of potential CTD duplicates of which I selected the correct/latest ones and deleted the others.I gave this new AF2_files/scenery folder the highest possible priority, i.e. at the very top of the FS9 scenery library list.This seemed to solve the "hang" problem for once and for all because I havn't had a "hang" since.Thanks Ernst for pointing my nose in the right direction.Hans

[Jive1 2]

Hey!I've been away some time...My original problem has been solved now! I know how to proceed to avoid the problem I had ( see my little story starting this item about FSNav....Each time, when I want to update my FSNav database I just remove the two files Scenery.000 and Scenery.001 in the FSNavigator folder, and start updating the database. Up to now it worked every time! No more database updating problems!.......This was just for your information.GreetzJive1And plaese note!!!!!! I'm using FSNav 4.7!!!!!!!!!!!!!!!!!!!!!!And I am already at 1105 sceneries with no more hanging problems........