aivlasoft
-
Posts
5,919 -
Joined
-
Last visited
Posts posted by aivlasoft
-
-
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.
-
38 minutes ago, RayProudfoot said:
should you decide a v3 was worthwhile
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?
-
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/
-
4 hours ago, Damo said:
The popup when you click hide, hides and then reappears again.
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.
setting default flightplan flight number
in EFB v2 - Support forum
Posted
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.