aivlasoft

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.

There are different values for the range stored in the BGL-files, depending on the navaid type: VOR High = 195 NM VOR Low = 60 NM VOR Terminal = 38 NM ILS = 27 NM These are the values for the range distances stored in the files. But the question is how it is implemented in the simulator itself. Are these ranges varying depending on the surrounding topography like in real life, or are all VORs tuneable within these ranges, regardless of other restrictions? However, the current EFB database structure does not make use of this information. It would require a change in the database structure to allow this data to be used, but such a change is currently not planned.

IIRC there is a value for the range of a VOR stored in the BGL file. But the question is how accurate this value is.

It's not the worst idea to keep the programs up to date. Sometimes updates provide bug fixes which improves the overall experience.

I have to check this.

Shame? WHY? Just because I do not implement all the personal wishes of every single customer? If every single wish would always be implemented, in the meantime we would have hundreds of check boxes in the settings dialog. This would make the dialog very unclear and confusing, and it would also require the same, or an even higher number of 'if-then-statements' in the source code to follow and check all the conditions and this would make the program slower. These are the reasons why I do not implement all wishes, it's not that I don't want. It would be nice if you could see this little difference. BTW, the popup is programmed to be displayed at the center of the Client window. It has nothing to do whether it's in a network environment or on a single machine. I'm running several instances of the Client in a network and the popup always is being displayed at the center of the Client and not at the center of the screen. So something on your system must definitely be wrong. Only for the very first time (after initial installation) the popup appears in the middle of the screen when the file "clientFormState.txt" (C:\Users\<username>\Documents\AivlaSoft\EFB2\Client\Settings) does not yet exist. This file will be written when the Client window closes and contains the position and size of the Client window, so the popup knows where it has to display itself upon next startup. Maybe this file does not exist on your system because of a too aggressive AntiVirus program?

@737flyer Thank you very much for your kind words on EFB, which is much appreciated.

Maybe time compression was also the reason for the disagree here? https://forum.aivlasoft.com/topic/6431-flighttime-im-efb/

That's because loading is not yet completed at this stage. Displaying a startup screen is supposed to inform the user about the status of the loading process and has been a Windows standard since the early days of Windows. I can't understand what bothers you about it.

Please, also read the announcement here: Introduction of corrected/expanded Ground Layouts for MSFS Add-on airports Find below a list of Ground Layout files, alphabetically sorted by the ICAO code. To use such a file, just download and place it into the \ARPT folder in your EFB2 Client's data folder structure and restart the Client. No Database-Building is required. For a default installation the path of the data folder is: C:\Users\<username>\Documents\AivlaSoft\EFB2\Client\ARPT To remove a file, just delete the desired file within the \ARPT folder and restart the Client. Again, no Database-Building is required. ICAO Name Developer Adjustments Remarks ENBR Bergen Flesland RDPresets Twy Names, Parkings - KDEN Denver Intl FlightBeam Parking Pos - KTEB Teterboro Dreamflight Parking Pos linked, TWYs - LIRN Napoli RDPresets Twy Names, Parkings - LSZH Zurich FSDreamTeam Added Tarmac and Buildings * Demo sample to show the possibilities of the enhanced ground layout MWCR Roberts Intl RWY26 Sim Parking Pos linked, TWYs -

We are aware that quite a few MSFS Add-Ons do not provide a complete dataset of the Ground Layout in the underlying BGL-File. The reason for this is developer-specific. In many cases parking positions are not linked to the TWY-system or even all TWYs are missing. In some minor cases just a few minor items like TWY-designators or RWY-extensions or Blast Pads are missing. AivlaSoft has created the possibility to use additional and specially formatted binary files to improve the Ground Layout of a certain Add-on airport. The binary files for such an improved Ground Layout are created with our own Airport Layout Designer, which allows us to create more accurate layouts with additional features. Such Extended Ground Layout Files are of our own *.arpt format and are placed in a specially designed folder named \ARPT within the Client's data folder structure. Whenever an error in the Ground Layout of a specific Add-On airport is detected, we might be able to provide a corrected file for this airport. A comprehensive (and hopefully growing) list of such Ground Layouts will be carried in a new thread in the Download Section. Limitations: We do not do corrections for default airports. Whenever an incomplete or buggy Ground Layout is reported, it will take some time until a corrected file can be presented. Depending on the errors and airport size this can take from a few hours to a few days as most of the corrective work is done manually. In case an airport is available by more than one Developer, be aware that a corrected Ground Layout is applicable only for the Add-On developer specified in the list. Be aware that this Service is uniquely applicable for MSFS Add-Ons and does IN NO WAY have any influence on the respective Add-On in the MSFS community folder. All corrections are ONLY done in the Client's depiction logic.

Hello would it be possible to create a support file and upload it here? Alternatively you may also send it to support@aivlasoft.com. Thanks.

I see what you mean but this would require to implement it at several places. Maybe an idea for a future version.

@stephane20 Did you update Client and Server to the latest version?

What about 'Main menu' > 'Settings' > 'Units' ?

You have to distinguish between 'flight time in total' and 'flight time since liftoff'. 'Flight time in total' is (according to your information) 10:58h. This is a predicted time and it usually comes from the flight plan. 'Flight time since liftoff' seems to be 04:23:58 (according to the screenshot). This time is displayed in EFB while your aircraft is in flight.

Is 10:58 the planned flight time in total, or the time since liftoff. I have never had an issue with this. Maybe your Client was restarted during the flight?

This is not UTC time, this is the duration since liftoff. Flight time automatically starts to run as soon as liftoff has been detected. See the manual "5 DE Client.pdf", chapter 9.1.

Please tell us which airport (ICAO code) from which developer in which simulator. If we do not know this information, providing help is impossible.

Just open the FPL window a bit more to the right side, you will see the hint about the step climb in the remarks column. However, I will have a look at this and whether it could be implemented in a future release. Nothing promised.

It has to be distinguished between flying 'online' (either VATSIM or IVAO), or flying 'offline'. When flying offline, AI-Traffic depicted in EFB is either artificially generated traffic by MSFS, or one of the other options of traffic available in MSFS, or externally generated and injected AI-Traffic from third-party add-ons. EFB is reading this traffic via FSUIPC but does not 'know' who or which is the generator of this traffic. When flying online with VATSIM or IVAO, there are two ways of getting traffic data. For details please see the manual "5 EN Client.pdf", chapter 13.2 'Online data' as well as 13.6 'Traffic'. When I was writing my first answer above, I was assuming that joinFS is generating and injecting traffic data into MSFS, but obviously it doesn't. If I'm right then joinFS provides data of other group members only via a download similar to VATSIM or IVAO.

Hi Sven finally I found the way to reproduce it. It has nothing to do with your system, it's a small bug in the DbBuilder logic which allows to create a new database combination (Combination means 'Simulator' + 'Navdata Provider', e.g. 'MSFS + Navigraph') while a same combination with an older AIRAC cycle is already existing. I have to fix this in a future update. For the time being ... To update any existing database when a new AIRAC cycle is available, you should use the DbBuilder function 'Update Navdata' instead of the button 'Create new'. The function 'Create new' is meant to use when no database is existing yet for a certain combination of 'Simulator' and 'Navdata Provider'.