Jump to content

aivlasoft

Administrators
  • Posts

    5,891
  • Joined

  • Last visited

Posts posted by aivlasoft

  1. Thanks very much for your tests and reports. A better way than deleting/removing a folder would be to figure out a naming pattern for the files which should be excluded from the scanning process. As you might know, in EFB you can define a kind of a blacklist for folders and (bgl-)files to exclude. Have a look at the following location: C:\Users\<username>\Documents\AivlaSoft\EFB2\Server\DbBuilder\Base. There you can see two files which start with 'BglSceneryExclude...', one is exclusively for MSFS whereas the other is for FSX and all versions of P3D. Just open the file with any text editor (like Notepad.exe). On top of the file you will find detailed explanations about how to use this file. If you have any questions, feel free to ask here.

  2. On 10/5/2023 at 8:29 PM, michael1508 said:

    Is this, because I have installed multiple new airports? Does it pop up per new entry in the scenery.cfg???

    I guess that this is the reason for the message. But from my point of view this is not "annoying", it is meant as a service to let you know whenever the simulator's database has been altered whereas EFB database was not updated to reflect these changes. Rebuilding the database means to run the function "Update simulator" from the DatabaseBuilders dialog. For further information on proper database handling please see the respective manual.

  3. According to the logfile the cause for the error is different than to what the poster above described. The missing comservices file is just a subsequent error and not the reason for the non-existing database.

    Unfortunately there is one of the zillions of the MSFS binary files which seems to be corrupt and therefore the DbBuilder throws an overflow error when it is trying to read it. In your post you write that you have installed some new airports. Please undo this action and then try each airport after the other and after each airport try to create the database. This way you can isolate and then eliminate the faulty airport.

     

    From the logfile I can also see that you have chosen a data folder for EFB Server and Client which is located on a drive which is synchronized with OneDrive. According to the installation manual you should not do that instead of selecting a data folder at a location which is not synchronized with a cloud storage service (https://forum.aivlasoft.com/topic/2951-win10-onedrive-cloud/)

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

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

     

    KCLM ILS08 JIGEB.png

     

    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.

    EDDS REU25.png

     

    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.

     

     

  6. 13 minutes ago, Berzerker said:

    That's my point, I think it should not have that requirement. If you pass directly (or within 3nm) of a waypoint, it should update no matter what you've passed before. I can't think of a situation where when you're passing within 2-3nm of a waypoint means that's not your current DIR and it shouldn't update.

    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.

  7. 2 hours ago, Berzerker said:

    If you pass directly over a WPT or at least within a few NM (1-2nm), it's clear you were DIR that WPT and it should auto update

    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.

    2 hours ago, Berzerker said:

    Inputting an approach after already being on the arrival/having input the arrival should put you back on the previous DIR WPT you were on before you input, not back to the beginning.

    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.

  8. 1 hour ago, Berzerker said:

    Just trying to throw out some ideas.

    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.

     

  9. 46 minutes ago, Berzerker said:

    Would it be possible to add in some logic on the backend that handles situations where if you forget to set a DIR after being given one, it never updates your flight plan once you reach subsequent waypoints?

    If you forget it, how shall the software know about it? I guess that this is not possible.

     

    46 minutes ago, Berzerker said:

    Also, when adding in an arrival, or updating an arrival, it always seems to set your Active WPT to the first WPT in the arrival/approach, it would be good if there was some logic to recognize which one you're inbound to or near, or perhaps to update it once you pass over the next one to know which your Active WPT truly is.

    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.

×
×
  • Create New...