lonewulf47

Ground polygons are created by the respective developer, in your present case this is MS/Aobo with its generic airports. As to my knowledge there is ATM only one delveloper (inibuilds) building LGW/EGKK as an Add-On. There most of the stands have the correct identifiers (see partial screenshot). Don't forget that especially large airports have more or less continuous changes in their parking position layouts due to reconstruction. Hence an airport layout will never be completely accurate if the developer does not continuously update his creation. HTH.

Hi David, Stand numbers are defined by the respective ground polygon BGL. This can be either default MSFS (fs-base-genericairports) or an Add-On. In either case the respective supplier is responsible for the content. EFB is just reading what is in the BGL.

Sorry Darren, I do not use GSX, but nevertheless I would strongly presume that it also uses a similar priority system like EFB does and places purchased Add-Ons on top of default airports. FSDT certainly will be able to answer this.

Hi Darren, Just as an additional information: the ground layout of the MSFS World Map also shows these double parking stands.

Hi ? (please observe the forum rules and sign with your real name) There is actually nothing wrong with the ground layout shown in your picture. It is exactly how pyreegue has created its ground layout BGL with a few additional stands (e.g. 9A on top of 9, or 10 on to of another [presumably 10A]). The other entries in your list do not have any influence on the ground layout. NAX47120.BGL only contains the ILS for all airport in a specific region and APX47120.BGL is the basic ground layout, which is replaced by the Add-On. I have installed the mentioned Add-On from Pyreegue and it shows exactly the same ground layout.

This is purely dependend on the way the developer places his static A/C. Not the worst idea though, this way you know exactly which parking spots are already occupied.

Sorry Ray, for the time being there's only little I can do about that, as I have never seen such behaviour. Did you try to start the DbBuilder directly from the "C:\Program Files\AivlaSoft\EFB2\Server" directory? (always use right click to start as admin). And if you do so, how does it behave? In any case we have to wait until Urs can take care of it. I'm sure he will be here soon.

See AivlaSoft's (Urs) answer. This is the only possibility as the ATR42/72 installation through Marketplace does not provide an aircraft.cfg. All relevant BGLs are encrypted. Encrypted files cannot be read by external apps. Even FSUIPC7 cannot provide a meaningful name. Sorry, there's no other possibility! We do not have witchcraft in our portfolio...

Addendum: It might be useful to remind MS/Asobo to update their generic airport collection. This airport is in operation at least since 2018 (date of last AIP Amendment), possibly even since 2016....

IMHO this is one of the problems that has no solution in MSFS unless someone creates a new airport layout BGL for the new LGPA. Btw LGPX is no longer contained in the MSFS database... There is only LGPA at the old position of LGPX, which makes things even worse. The main reason, why the Add-On LGPA is not shown in EFB, is that there is no plain ground layout BGL for this airport. Add-Ons from Marketplace are usually (individually per user computer) encrypted and therefore simply not readable for EFB.

In fact, the ground layout is provided by Microsoft ("D:\MFS\Official\OneStore\microsoft-airport-katl-atlanta\scenery\Microsoft\Atlanta\KATL-Airport.bgl") and does not contain any TWY designators. Unfortunately there's nothing we can do about.

Not sure whether I understand what you mean. I read in your profile the File Name "at76". Where did you get that name from? When starting up with a new aircraft, the server protocol will show an entry "airfile name : xxxxx" where xxxxx is the name you should use in the profile. Unfortunately with all the changes that were incorporated lastly in MSFS it is not necessarily the ICAO-code anymore that shows up at this entry. Just check your ServerLogfiles (to befound at "C:\Users<Username>\Documents\AivlaSoft\EFB2\Server\Logfiles") for an entry "airfile name" and enter the corresponding name as the File Name in the Profile. This should activate your profile then.

According to my information the ATR 72-600 is ICAO Approach Category "B". Furthermore you should not include SurfaceCategory "4", unless a float version of this specific tpye is available, otherwise all water RWYs of sufficient length will be shown as available for this A/C. Also the value for RemainingFuelBelowKgs is a bit low with 20 kgs... No big issues, but still worth mentioning.

Well, it seems to me that only users with additional 3rd party software (FSLTL, FS Traffic) are affected. I do not use either and do not have any such issues. I use Fenix v1.0.6.146 and FSUIPC 7.3.19. So go figure...

Not entirely true..: See here: https://forum.navigraph.com/t/navdata-pricing/11408 Somehow hidden, but still available... Very tricky, isn't it?

Please, please, if you report any such inconsistencies, ALWAYS add a COMPLETE set of Support Files. For troubleshooting we need ALL information available, not only a cutout of the Server Logfile. Thanks for your understanding.

Hi Dirk, the criterion for the "APT Filter OFF" message is usually insufficient RWY length. In the case of EHRD (which I also have from RDPresets) it means, that the minimum RWY length stipulated in the applied profile is greater than the available RWY length. The RWY length of the EHRD Add-On from RDPresets is 2196 m. If the value in the active profile (See tab "Filters", RWY Min length) is greater than that, the warning will be shown. AFCAD Handling is more or less the same in MSFS, although the term "AFCAD" is no longer used there. It's just handling of the ground layout BGL. As an example: if you use the default profile for the Boeing 747-8F or 8i, the required RWY length is set to 2200 m. Therefore some 4 m are missing... it's all digital these days...😉

It's not EFB, that HAS wrong data, it's EFB being provided with wrong data. EFB only reads them. But anyway, it would be hepful if you could provide more information. Please consider reporting according to our Forum Fules.

See manual 5. Client, Chapter 5.1.3 Function Keys

This has been discussed already. See here: https://forum.aivlasoft.com/topic/7227-egss-after-latest-navigraph-update-2213/

Sounds strange. Normally this error (internal Windows error) disappears when rebooting the computer. When did you last reboot?

C:\Users\<Username>\Documents\AivlaSoft\EFB2\Client\Library is the datapath for a standard installation See also Manual "EN Installation", Page 16: "Installing the client"

Ray, BTW, just to finish this: you will NEVER see any such hint about a "best gear down" distance or similar. This is never part of an approach plate. This is PURELY company procedures and as such depending on things like A/C type, MET conditions, etc.

Funny enough, I just installed LFRN from FranceVFR and on my install the all parking spots are properly connected and the taxi routes work normally. I have installed it through ORBX. The installed airport reads "francevfr-800-rennes" in the community folder and the package version is 1.3.0.

As I can see you're not using the default LFRN scenery. Can you give me exact details about the add-on scenery used? I personally use the LFRN Rennes from "simc" via simMarket, but the layout does not fit the one you are using or maybe not updated to the latest version. Nevertheless it can clearly be seen that most of the parking spots are not connected to the taxiway system. Therefore no reliable taxiroute can be found by EFB. This is a problem on the developer's side. There is a possibility to properly connect everything, uniquely created for EFB, but only if we know EXACTLY the Add-On in use.