aivlasoft

Hi Rolf it could also have been a formatting error on SimBrief's side. The XML-file which will be downloaded when importing a flight plan is also not set in stone and sometimes it is undergoing maintenance. Anyway, hopefully it works again for your flight back to EDDK.

Thank you for testing EFBv2. Unfortunately I have no Steam installation so my advisory is also taken from the search function of this forum. I guess that this thread will help to figure out the required path (it is worth to read the entire thread):

Profiles can easily be created (or updated) using the Profile Editor. Especially if one owns the respective aircraft then usually the developers will provide the kind of information which is required to create/update a profile. We do not have all these aircraft.

Hi Iain I assume you mean the 'calibration' caution/warning on the sidebar? This is an option which can be activated/deactivated in the A/C profile. Just run the profile editor and update the A/C profile accordingly.

@romoni Do you use the integrated import function in EFB, or do you copy/paste the routing string? I just did a quick test and created a route from ESSA to EDDK in SimBrief. Although the ICAO formatted flight plan contains the KOPAG2V arrival, internally it will be recognised and removed so I'm finally getting the following routing: ESSA DCT PETEV N872 ELPAX Z703 UMIXA DCT KULUD Z703 ALS M852 POVEL Q201 PODER Z189 RUNER T858 KOPAG DCT EDDK. To remember, EFB does not import procedures (neither DEP nor ARR). Procedures always have to be selected/added manually using the PROC-dialog.

There is no specific start sequence required. I would not delete the profile but move it to another folder instead.

It looks like MSFS provides different aircraft codes for different liveries. I haven't seen that before. From the first logfile I see that the following codes are provided: b738 737 b736 If you don't use the profiles for the 737-600 and -700, I suggest that you remove these two profiles and then add the aforementioned codes to the profile for the 737-800. This way the profile for the 737-800 will be selected in either way.

I don't think that the liveries are the cause for the issue, because a livery is 'just graphics', not logic. But to be on the secure side you can try whether the issue also happens when another aircraft (other than the PMDG 738) is in use. Are you running other popular add-ons while EFB is running? e.g. LittleNavMap, SimStarter, any AI-Traffic generating tool, etc. FSUIPC is used for the connection between EFB Server and MSFS. The connection between EFB Server and its Clients does not require FSUIPC.

According to the log file the name of the AIR-file (which in fact points to the aircraft.cfg) changes several times but I cannot see why. It 's always the same sequence, the first read seems to be OK, it returns the full path to the aircraft.cfg which can be utilized and then, some minutes later, the AIR-file name changes again, but then only a relative path is provided which cannot be utilized, hence the aircraft.cfg cannot be read. Whenever this happens, the Server is trying to get the information about the model from FSUIPC internal variables which obviously are not properly set. I have no idea what is causing this re-reading and/or changing of the AIR-file name and I also have no idea about FSUIPC internals. The first thing that should be found out is the reason for the changing AIR-file name. Are you running any other MSFS add-ons which might be the cause for that? Can you try running MSFS with EFB only?

I have the same log entries because it is the default database.

The folder XPAPT is not meant for placing the earth_nav.dat file. It is meant for certain/single apt.dat files. For details please see the manual "4 EN Database.pdf", chapter 2.7 and 2.8. According to the logfile entries I have to go the way to eliminate all possible reasons and therefore the first step is trying to create a database without any errors. As I already mentioned before, the error at the Client happens when the program is trying to access a certain airport which obviously is not present in the database. If an airport is not present in the database points to an error at the creation process of the database. When you strip out the extraneous information all the alternate airports are no longer part of the flight plan and therefore the program is not trying to access them. Most likely this is the difference and the reason why it works then.

Thanks for uploading the files. It is indeed an error which is causing the map drawing process to exit before it has finished. The error happens because it is trying to read an airport from the airports database but this airport seems not to be available. So my idea is that something must have happened when the database was created. I can see from the logfile that an error was logged when the DbBuilder was trying to analyze the folder 'XPAPT' in the Servers directory structure. So the question is which airports are in this folder and can you give it a try to rebuild the database without these airports?

I have no idea why the runways have these identifiers. Maybe the creator of the scenery can help. But anyway, it's not important for the database building process. The database will be built despite of the warnings. Just ignore them.

Please re-read my post, I just have edited it.

Thanks for the screenshots. I assume that the designator 'W' stands for water. I don't know whether this is an official designator. Maybe EFB is too tight in this regard. Because this is not an error I would recommend to ignore these entries. Airport OPOR According to Google Maps there is a second but smaller runway on the right side of 06/24. The smaller runway seems to be the first entry in the file at line number #9178177. Unfortunately the identifiers are not different. I suggest to change the identifiers of the first entry from '6' to '06R' and the identifier from '24' to '24L'. On the second line (#9178178) I guess the runway width (50.00) is too wide. According to the measure tape in Google Maps, it's 45.00 meters.

The first four entries are not errors, just information. The other one is an error which is caused by a runway designator which obviously is assigned multiple times at the airport with ICAO code OPOR. The first four entries have not official ICAO designators, so I have no idea which airports are concerned. I don't know whether the airport OPOR is provided by XPlane or whether it is an add-on. In any case the file should be fixed.

Hi Shawn If the aircraft icon disappears, means that an internal error in the drawing code happened and the routine was left before the icon could have been drawn. One reason could be that the NAT tracks were no longer valid at the time when the aircraft was in the air. The routing contains the term 'NATE' which will be resolved in single waypoints according to the downloaded tracks information. This happens only once when the flightplan will be created. Assuming that the NAT tracks have changed, or better said, became invalid between the successful check and the time when you get airborne, would lead to invalid waypoints in the routing which then could be the cause for the error. Could that be the reason? If this was not the cause for the issue, then please create a set of support files when it happens next time and upload the files here. Thanks.

Currently we do not have plans to implement it.

EFB is reading this data from the simulator via FSUIPC. If other values are updated in EFB and GW not, then I guess that the GW does also not change in the simulator, or GW is calculated outside the simulator and not updated there by the add-on. BTW, GW stands for Gross weight, not ground weight.

Traffic data is provided to the Clients by the Server. If traffic is visible on one Client then it is also visible on a second Client, as long as the configuration of the Clients is identical. I have no idea from where this 'step by step' list is. If it was originally taken from the official EFB documents at all then this instructions would be just for the basic communication between the Server and the Client, but has nothing to do with the traffic configuration. From the screenshot above I can see that there is a yellow dot on the TFC button. From the manual I can read: " ...whereas a yellow dot indicates that a filter is activated and only partial traffic will be depicted." Maybe this is the cause for not seeing traffic? Please see the manual "5 EN Client.pdf", chapter 13 "Online with VATSIM or IVAO", especially 13.6 "Traffic". Also worth to see is page 117 which describes a vertical filter for traffic.

There is no such exclude for X-Plane because X-Plane is much more 'open' in this regard. As to my knowledge you can easily edit almost all configuration files with any text editor.

Hi Stephan Regarding the integration of TOPCAT we unfortunately have to live with what we have. It's many years ago when I gave up trying to get in touch with the developer of TOPCAT. While it was a real pleasure to work with him when we implemented the interface to TOPCAT many years ago, I never understood why he later stopped responding to my attempts to get back in touch with him.

Hi Peter Regarding your question #1, please create a support file and upload it here. #2) Make sure that there are STARs available at your destination airport. STARs are not available at all airports.

Thanks for reporting back.

Maybe some kind of anti virus software, auto backup software, or similar which has its 'hands' on the file?