aivlasoft

The ATC ribbon lists all manned ATC stations along your route in the right sequence. Without a route/flightplan there are no ATC stations to display. It's as simple as that.

After several tests we came to the following conclusion: Due to the AI-based recognition of aprons, unfortunately many additional areas are defined as 'apron', which have nothing to do with aviation. This leads to the fact that the database is unnecessarily inflated without providing a benefit in terms of aeronautical requirements. The size of the database is almost twice as large as without the aprons, and therefore the loading time and the time needed to synchronize the database between the server and the client(s) takes much longer. So overall, there are too many disadvantages. Here are just two examples. Please see the comments below the images. Airport Megève (LFHM): The entire road and parking space on the south/east/north side of the airport is defined as 'apron'. The green areas are also 'apron'. Airport Gibraltar (LXGB): Many areas around the airport are defined as 'apron'. An 'interesting' one can be seen on the north-west side of the airport. It is the pier of the ship harbor. The different surface materials have been intentionally colored this way. Dark grey means 'asphalt', Light grey means 'concrete', Blue means 'water', Green means 'grass', Red means 'unknown', Yellow means 'other', such as bituminous, sand, clay, etc. All of these areas are defined as 'apron'.

This is the error which is causing all the problems. Het opgegeven pad, de bestandsnaam of beide zijn te lang. De volledig gekwalificeerde bestandsnaam moet minder dan 260 tekens bevatten en de mapnaam minder dan 248 tekens. (English) Either the specified directory name, or the filename, or both are too long. The length of a fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. Due to the fact that the default installation path of MSFS 2020 is given as follows ... c:\users\<username>\appdata\local\packages\microsoft.flightsimulator_8wekyb3d8bbwe\localcache\packages ... the absolute path of an add-on might become too long, depending on the relative path names of the add-on. Even some of the folder names of MSFS itself become too long. e.g. C:\Users\<username>\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages\community\aig-aitraffic-oci-beta\SimObjects\Airplanes\AIGAIM_HTAI_C208B_SuperCargomaster\model.IRO-CSA Air_Old Titles Black Leading Edge Dark Cargo Pod This can only be solved by a clean new installation of MSFS into a separate folder which has a short as possible name, e.g. E:\MSFS

These links seem to be broken. At least on my machine I cannot see them. But anyway, I will have a look at this.

Currently EFB can only depict the FIR boundaries of either VATSIM or IVAO (depending whether they are active or not). Unfortunately I don't know where to get a file which provides the boundaries of the r/w FIR boundaries as x/y-values (Lat/Long coordinates). Maybe you know of such a source?

It cannot find the path to the so called 'generic airports'. Therefore the database cannot be built. I don't have an installation of the steam-version of MSFS so I'm unfortunately unable to advise whether the proposed path 'C:\Users\<username>\AppData\Roaming\Microsoft Flight Simulator\Packages\official\steam\fs-base-genericairports' is the correct path to the generic airports. Maybe there are other users having a steam version on the computer and can help?

Sorry for the inconvenience. Should work again in a few hours. Try it again tomorrow.

If the aircraft begins to start turning backwards to the first waypoint of the flight plan when you enter your flight plan in the EFB, then from my point of view, the autopilot seems to be engaged already. Make sure the autopilot is not yet engaged BEFORE you load the flight plan. The flight plan from EFB is always forwarded to the default GPS of the simulator, as soon as it is created or updated, or deleted. If you don't want to automatically forward the flight plan to the simulator's Default-GPS you should deactivate this option in the respective aircraft profile settings. When your aircraft is airborne already and you are loading the flight plan which you created while you were on the ground, your aircraft is already ahead of the first waypoint of your plan. So after loading the flight plan you should use the 'Direct-to' function to select the next waypoint in front of you and then activate the autopilot.

Today we released the new update 2.3 (build #134). This update contains some minor improvements and bug fixes: Improvements: Procedures: FM/VM-Leg depiction improved Procedures: 'ALT between' values right aligned Long procedure names are recognized as a valid element in ATS route (e.g. when downloading a FPL from SimBrief using the built-in download function in EFB) Named Taxiways function slightly improved (see also this post: https://forum.aivlasoft.com/topic/6617-choosing-taxiways-never-seem-to-work/?do=findComment&comment=30091 Splash screen is now no longer displayed again after pressing 'Hide'. Scanning BGL-files logic improved. If you are using a BGL-file based database like for P3D, or MSFS you might want to rebuild the database using the DbBuilder function 'Update Simulator'. Bug fixes: DbBuilder allows to create a database which already exists. A 'database' in this regard means a combination of 'simulator + navdata' (e.g. 'MSFS + Navigraph', or 'P3D + Aerosoft'). For details please see the manual '4 EN Database.pdf'.

@krzylisz Thank you for sending the support files. There are two problems reported in the log files: 1) EFB Server and Client data folder has been selected on a path which is synchronized with a cloud service (OneDrive). Please see this FAQ: https://forum.aivlasoft.com/topic/2951-win10-onedrive-cloud/ Please uninstall EFB Server and Client and then do a new installation. When the installation dialog is asking for the data folder (not the installation folder), please select a location which is NOT synchronized with a cloud service. 2) Due to the fact that the default installation path of MSFS 2020 is given as follows ... c:\users\<username>\appdata\local\packages\microsoft.flightsimulator_8wekyb3d8bbwe\localcache\packages ... the absolute path of an add-on might become too long, depending on the relative path names of the add-on. Even some of the folder names of MSFS itself become too long, e.g. C:\Users\<username>\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages\official\onestore\microsoft-aircraft-pilatus-pc6-g950-wheels-livery-xbox-aviators\SimObjects\Airplanes\Microsoft_Pilatus_PC6_G950_Wheels_Livery_Xbox_Aviators\texture.aviators', The following error text has been logged: (Polish) Okre�lona �cie�ka, nazwa pliku albo oba te parametry s� za d�ugie. D�ugo�� w pe�ni kwalifikowanej nazwy pliku musi by� mniejsza ni� 260 znak�w, a nazwy katalogu mniejsza ni� 248 znak�w. (English) Either the specified directory name, or the filename, or both are too long. The length of a fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. Issue #2 can only be solved by a clean new installation of MSFS into a separate folder which has a short as possible name, e.g. E:\MSFS

Thanks, I will fix it. BTW, next time, please ask for permission before you post a screenshot from this forum in any other forum.

Ben, the .efbr file format does not contain the callsign. When using the SimBrief downloader program, you will not get any information about the current callsign. That's by design. Just use the built-in download in EFB, which downloads an XML-file from SimBrief which contains all required information.

Hi Reinhold Thanks for this additional information. I can reproduce it. It seems that there is a tiny bug in SimBrief when they are generating the ICAO-FPL which is part of the downloaded XML-file. On their webpage the first element in the routing (the name of the departure route) is properly named as TOM9WD (see next screenshot) But in the ICAO-formatted flight plan, which is part of the downloaded XML-file, the first element (name of the departure route) is wrong, because the name is too long, see next screenshot. And BTW, the last element (arrival route) is also not properly named (NAPSA4A, instead of NAPS4A). Therefore the message in EFB about the invalid element is correct.

Hi Reinhold Could you please provide the full routing string, so I can try to reproduce it here. And please confirm that you use the built-in download function from EFB and not the SimBrief Downloader, thanks.

Thanks for reporting. The procedure coding at/after BL529 reads as follows: 1) FM: BL529 244° 2) CF: 064° BL525 MAX 200KT The definition of a FM-leg is as follows: Defines a specified track over ground from a database fix until Manual termination of the leg. This means that the aircraft has to fly a track of 244° but the end of the leg is an uncertain position (depending on the time how long this track is flown and the speed of the aircraft). Because EFB doesn't know the end of the leg, it has to assume a certain distance, from where it connects to the next leg. The next CF-leg means that the aircraft has to fly onto a course of 064° to the fix BL525 with a max speed of 200 kts. I'm with you that the CF-leg is not properly depicted on the screenshot above, and therefore the course of 064° is misleading. I will check whether a better depiction of this combination can be provided in a future update.

Although the algorithm could be slightly improved in the meantime (available with next update), it brought up that the outcome of the algorithm is highly and mainly depending on the quality of the taxiway layout provided by the simulator's scenery files. This means: all segments of a named taxiway must be properly connected all segments of a named taxiway must be consistently named a named taxiway must not have branches Unfortunately these requirements are not fulfilled at all airports, especially not at the generic-airports from MSFS. To our knowledge these generic airports will be generated automatically using kind of a KI algorithm which sometimes does not provide a meaningful taxiway layout. It goes without saying that we cannot manually correct approx. 5 to 10 thousand airports to get a proper layout. Unfortunately even the payware airports are not always properly designed in this regard. On many of these airports we have found inconsistently named and branched taxiways. Conclusion: Use the function 'named taxiways' with caution. Sometimes the result is good, sometimes not. Using just the 'shortest path' (provided when NOT using the 'named taxiways') usually brings up a good result.

Thanks for the files. When touchdown at KTPA was detected, the airport ZTPA was selected as the nearest airport, instead of KTPA according to the flight plan. In EFB terms, the nearest airport is defined by the distance to its ARP (airport reference position). Obviously the distance from the touchdown position to the ARP of ZTPA is less than the distance to the ARP of KTPA. I don't know ZTPA but I guess that this is not a real world airport. Maybe it has been added by FlyTampa for internal purposes. Unfortunately it will be detected as an airport when EFB DbBuilder is scanning the BGL files from the simulator. As a remedy for this you can define an exclusion for the airport ZTPA and then rebuild the EFB database using the function 'Update simulator'. An excluded airport will no longer be considered when scanning the simulators BGL files and therefore it will no longer be available in EFB. However, the simulators database is not affected in any way by this. To create an exclusion proceed as follows: 1. Locate the file "BglSceneryExclude.txt" in the following path (default installation): "C:\Users\<username>\Documents\AivlaSoft\EFB2\Server\DbBuilder\Base" 2. Open this file with a text editor 3. At the lower end add the following line: airport:ZTPA 4. Save the file 5. Rebuild the EFB database using the function 'Update simulator'. See Screenshot below of an example entry. There is actually no necessity to add an empty line before the new entry like in the sample below.. It's just made for clarity, to separate new entries from older ones. You may add as much airport exclusions as needed. For each exclusion add a new line starting with the prefix 'airport:'.

Ben, did you update Client and Server to the latest version? Can you describe how you import the plan from SimBrief? Are you using the downloader, or the built in function in EFB Client?

Hi Brian, when the airport geometry is no longer depicted, most probably a program exception happened before. Could you please create a set of support files, one from the Server and one from the Client. You may upload them here, or if you prefer, you may send them to support@aivlasoft.com. I will have a look at them, hoping to find the reason for the issue.

Just some additional information to what @dualznz has said: Profiles -> C:\Users\<username>\Documents\AivlaSoft\EFB2\Client\Profiles Checklists -> C:\Users\<username>\Documents\AivlaSoft\EFB2\Client\Checklists When using Checklists, do not forget to assign the checklists in the respective profile.

Hi Dane thank you very much for the further information and the screenshots. There have been found two independent issues: 1) There are two further taxiway segments (after taxiway 'P') which are also named 'K'. This means that taxiway 'K' is not entirely connected and therefore when using named taxiways, the algorithm is not returning a useful result. 2) Also after fixing the taxiways layout, the algorithm still does not work properly which I have to fix. For the time being it is recommended to simply use the default selection which provides reasonable results.

Hi Dane You are not doing anything wrong. To be able to find a way along certain taxiways it is required that all segments of the taxiway are properly connected. Properly in this regard means that the lat/long coordinates of an ending point of a segment are equal to the coordinates of the beginning point of a next segment. Sometimes developers do not connect the segments exactly enough which usually is not visible to the eye and therefore nobody complains, but an algorithm cannot proceed then. If you let us know which airport it is (ICAO code, developer, simulator) we may try to investigate.

Sorry, I have deleted the list after the tests because I thought that it is not necessary to keep it.

I'm pretty sure that the provided key is valid. I suggest that you send your complaint to support@aivlasoft.com because discussing license key troubles should not be done in the public area. When you write to the support, please provide the order-number, thanks.

Indeed, a question which is not easy to answer.