Jump to content

aivlasoft

Administrators
  • Posts

    5,913
  • Joined

  • Last visited

Posts posted by aivlasoft

  1. Hi Ray,

    From my point of view there is no need to do some programming because changing the unit of weight is just one item among others when doing flight preparation. According to the region where a flight takes place one has also to change other units like pressure, or the unit of altitude etc. All these changes can be done easily in the Clients settings dialog.

     

  2. 2 hours ago, Machofner said:

    Because the legs were user created WP's. EFB2 will not load them. I loaded the flight plan from Flightsim.To.

    For several reasons EFBv2 will only use waypoints (fixes, navaids) in a flight plan which are part of the currently loaded database. A database (in terms of EFB) is a merge of simulator data and AIRAC-Cycle data.

  3. Hi Bill

    Apart from the Windows-Full-Size-Mode the Client has its own full-size mode, let's call it 'real full-size'. When this mode is active, the window title bar is no longer visible and also the Windows-Taskbar will be hidden. The idea of this mode is to allow the Client to use the entire screen area when running on smaller monitors like notepads etc.

    This full-size mode can be toggled by double clicking onto the airports name on top of the Client's window.

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

    megeve.png

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

     

    gibraltar.png

     

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

     

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

  6. 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?

     

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

     

  8. 19 hours ago, Citation73 said:

    as soon as i enter the flight plan in the efb my aircraft begins to start the flight all over again . I.e. the autopilot will turn to the very first waypoint instead of maintaining its original course.

    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.

  9. Today we released the new update 2.3 (build #134). This update contains some minor improvements and bug fixes:

     

    Improvements:

    1. Procedures: FM/VM-Leg depiction improved
    2. Procedures: 'ALT between' values right aligned
    3. 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)
    4. 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
    5. Splash screen is now no longer displayed again after pressing 'Hide'.

    6. 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:

    1. 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'.

     

     

     

     

     

     

     

     

  10. @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

     

     


     

  11. 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)

    webpage.png

     

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

    icao.png

     

    Therefore the message in EFB about the invalid element is correct.

     

     

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

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

     

  14. 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:'.

     

    airport exclusion.png

     

     

×
×
  • Create New...