aivlasoft

Thanks for uploading the files. From the DatabaseBuilder's logfile I can see that only 980 airports (instead of approx. 25'000) have been found according to the different add-on.xml files and scenery.cfg. I must assume that something went wrong when you updated your P3Dv5 installation.

Could you please create a set of support files, one from the Server and one from the Client. Please upload them here for further investigations. Thanks.

You will find all the required information and links here: https://www.aivlasoft.com/

Have a look at these screenshots. 1) KCLM ILS08 via JIGEB: This is a good example for so many approaches, especially in the US where you fly over a VOR or a fix, then outbound to another fix where you make a procedure turn and then fly back the same way again. Here you have to pass the waypoints in the red circles twice. If the 'logic' were taking just the closest waypoint, then all the waypoints after ELWHA were being considered as passed as soon as you pass ELWHA for the first time. Another example where taking only the closest waypoint could lead to unwanted effects. Approach EDDS ILS25 via REU25: While on the northeast leg (068°) passing IBIRU, or later at DS522, the waypoints on the 'other side' are too close to get activated, especially when you don't fly accurate enough on the desired track. From my point of view there is no reason to change the currently implemented logic. It works for a vast majority of situations, and for all not covered cases just use the DIR-TO function to sync the flight plan.

Especially on certain (RNAV-) approaches this will not work because the waypoints are too close to each other. That's the reason why the requirement was implemented that all waypoints before must be passed. Otherwise the sequence might get a hick-up.

This is the logic which is implemented already. A WPT is considered as passed if you fly over or by within a range of 3 NM. However, the condition is that all waypoints before must also be passed. Changing an arrival and/or an approach when you already are on this arrival or approach will always cancel the above mentioned logic because changing an arrival and/or an approach will change/remove multiple waypoints in the flight plan and therefore the logic must be manually reset. If you change your flight plan you always have to use the DIR-TO function to re-sync the logic with your current flight plan. There is no other way to accomplish this.

That's fine, thanks. Just a few thoughts from my side as the programmer. To implement a logic in a program one requires that clear and unambiguous rules are available, which this logic must then strictly follow. I think that there are a lot of different possibilities in the situations described above, so that it is almost impossible to identify all cases and to determine an appropriate set of rules from them. Not always every situation can be solved with a program (at least not with reasonable effort), therefore the DIR-TO function was implemented, which allows the pilot to make its decisions based on his experience and the situational awareness and then to act accordingly.

Sorry, my fault. You're right, the path cannot be indicated because the file isn't recognized. Look for the respective airport folder in '..\official\onestore'. If you have located the folder, look for the folder '..\scenery'. There you should see the airport file having a postfix '.fsarchive'.

Unfortunately we do not have this airport in our collection. You can check in the installation path (path should be mentioned in the 'i'-window of the airport) whether the file type is '.fsarchive'. If so, the airport data is encrypted as I mentioned above.

Thanks. Standby ...

Unfortunately airports which have been purchased through the in-game-marketplace are often encrypted due to copyright reasons. Such airports cannot be read by EFB (see restrictions). I don't know whether this is the case for the airport that you are talking about. Can you provide the ICAO code and the developer?

If you forget it, how shall the software know about it? I guess that this is not possible. Why not just use the DIR-TO function in such a situation? If programmable at all, such a logic would be far too error prone.

The values for speed are taken from the output of the simulator. There is not much we can do in this regard.

Hi Rene you can use the same installation for all simulators, but you have to create a database for each simulator first. Then, to switch from one simulator to the other, just change the database. You can do this by selecting the required database in the DatabaseBuilders dialog. Please see the manuals, thanks.

What kind of data format (which program creates it) do you mean with .fpl ? Did you already have a look in the manual "6 EN Flightplan.pdf" ? There are several options to load a flight plan into EFB.

P3D requires FSUIPC, as described in the manuals. See also here: https://forum.aivlasoft.com/topic/7783-incorrect-airport-on-startup/

Please see the updated announcement here: https://forum.aivlasoft.com/topic/7787-update-23-140/

On your screenshot I can see 'Airfile name: 737'. Did you already try to add '737' to the list of Airfile names in the profile of your aircraft?

This seems to be a commonly known issue with certain aircraft. Did you already use the search function of this forum? I'm quite sure this has been answered several times already.

Could you please provide a screenshot which shows the error? Thanks.

v2.3 #140 has been released today.

Today the new version 2.3 #140 has been released. Among some minor bug fixes, it contains the integration for Prepar3D v6. EDIT: 2023-07-22, 19:45z: We had to stop the Auto-Update for this latest build because there is a bug which mixes up the existing databases. We apologize for the inconvenience and will fix it asap. As a remedy for this, please do the following steps: Quit EFB Server and/or DatabaseBuilder Locate the folder 'C:\Users\<username>\Documents\AivlaSoft\EFB2\Server\DbBuilder\Ready' (default installation path) Delete the entire folder Start the DatabaseBuilder and create the EFB database(s) EDIT: 2023-07-23, 07:17z: Issue resolved. Auto-Update is back to normal.

Assuming you have the technical data from your aircraft you will use the Profile Editor. Please see the manual "5 EN Client.pdf", chapter 12.2 "Profiles editor"

In the meantime some users have tested the new version and it looks good. Most likely we can release the new version by the end of this week.

After some investigation it turned out that the Navigraph AIRAC cycle 2307 rev 1 was faulty. In the meantime Navigraph has updated the cycle and everyone should re-download the latest revision 3 from cycle 2307 using the Navigraph FMS Data Manager. Then rebuild the EFB database using the "Update Navdata" function in the DatabaseBuilder. This will bring back the functionality in EFB as it was with 2306.