lonewulf47

Hi Robert, I assume you are talking about KTEB Teterboro, developed for MSFS by DreamFlight. Some of the developers do not care for any extended ground layout and therefore just "paint" all TWYs without designing a proper ground layout BGL. Of course for the simmers this is enough to run the desired airport, however all 3rd party software using information from the ground layout BGL are "left behind"... Fortunately we are in the position to redesign such missing ground layouts in our own Airport Layout Designer. Find attached the ground layout fo the requested airport KTEB Teterboro. Put the downloaded file into the "ARPT" folder of your CLIENT documents and you will be done with the proper layout. Default path for a standard installation is: C:\Users\<username>\Documents\AivlaSoft\EFB2\Client\ARPT. No database rebuild is required, just restart the client to activate this layout. To remove the layout file and go back to the default layout, just delete it from the mentioned path and restart the client. Edit: For download of the respective file see here: https://forum.aivlasoft.com/topic/6527-introduction-of-correctedexpanded-ground-layouts-for-msfs-add-ons/ and here: https://forum.aivlasoft.com/topic/6528-msfs-correctedexpanded-ground-layouts/

At present FSUIPC does not provide access to multiplayer aircraft. See also here: https://forum.aivlasoft.com/topic/6397-visibility-in-aivlasoft-when-doing-a-grp-flight-with-joinfs/

Why don't you just press "hide" ? 😉

Check whether you have the corresponding checkmark set in the aircraft's profile Profile Options Tab -> Vertical Guidance Checkmark)

see here: https://forum.aivlasoft.com/topic/6389-length-cannot-be-less-than-zero/ This error may appear at random and is not connected to any version.

No, this is not version-specific. This is an error that comes up with erroneous meteo data. There are multiple reasons for this, mainly transmittal errors. I had the same error this afternoon, but at the next session (which is currently running), the error does not show up.

Check the Server window. On the top line, where the active database is indicated, there's a button labelled "change". This starts the DbBuilder, where you can select the appropriate database. Mark the desired database from the list and press "select". This will start the Server again. If you start the Sim (and FSUIPC) before EFB, then EFB will detect the Sim Type and start with the appropriate database. This does however NOT work with X-Plane. Only MS-based simulators (and thus using FSUIPC) will be self-detected. Alternatively you might also check Manual 4: Database, para 2.2: Create/Select EFB database

Sorry Razkal, please read the Forum Rules, in particular item 3. We cannot provide any help with NO infomation.

Rebuild the Database. Reading update notes also woud help: https://forum.aivlasoft.com/topic/6273-update-23-132/

It generally needs some analyzing work, before such a file is created and released. So at least for the time being we'll decide from case to case. It will generally depend on the accuracy and reliability of the scenery designers. In any case as a next step we will organize the whole matter in a separate thread in the "Downoad" section of this forum. Preparatory work is under way.

I'm happy to present the solution for the misinterpreted ground layout BGLs. As chances are that more such cases will show up, we will at a later stage create a distinctive thread in the "Download" section of this Forum, where such "remedy" files will be collected. As mentioned before we were preparing EFB2 to handle such events by creating a dedicated path in the EFB2 Client's file structure. See the picture below: The folder "ARPT" was created with EFB2 V2.3 Build #131 onwards and is empty. It is dedicated to a special file format *.arpt. This format is uniquely used within EFB2 Client and is created in our own binary format. Whatever file is placed into this path must consist of this *.arpt format and compiled by our own compiler. Nothing else will have any effect. All copyrights for *.arpt files are held by Apprimus Informatik GmbH, manufacturer of AivlaSoft's EFB2. Please note that this will only affect EFB2 Ground Layout. Nothing will be altered in the Add-On. Please also note that this procedure is uniquely for MSFS. Handling is very simple and straightforward: Whenever similar discrepancies like mentioned in this thread will show up, a "remedy" file will be created by AivlaSoft to replace the EFB2 ground layout of the airport concerned. The user just copies this file into the "ARPT" Folder and restarts the Client. Nothing else is required. Whenever a user does not like the "remedy" file, he/she can delete it and restart the Client again. That's all. This file will be Add-On Developer specific and replaces in any case the EFB2 ground layout of the airport concerned. For the present case with LOWW the follwing file needs to be placed into this "ARPT" folder: remedy file for Gaya Simulations LOWW: LOWW.arpt Download this file, place it into the "ARPT" folder and restart the Client. This will represent the exact Ground layout with taxiways and parking positions as used by Gaya Simulation's LOWW Add-On.

It seems that we were able to identify the cause of the "misbehaviour". The main culprit is that MSFS DOES NOT follow (anymore?) some of the basic BGL rules regarding the so-called "delete-section", which tells the graphic engine of the simulator, which parts of the default (=generic) airport have to be replaced (=overwritten) by the add-On and which not. In this case the whole Taxiway section is concerned. Gaya's ground layout BGL is missing the Overwrite Flag for the Taxiways (which includes parking positions also). EFB is (so far) strictly following the Rules and thus DOES NOT replace the default taxiway system for LOWW. Therefore the default (=generic) taxiway layout is shown in EFB. Gaya however uses a somewhat simplified Parking Positions Layout, which is clearly seen in the Parking Positions shown in the simulator's GUI. When ignoring the missing flag and replacing ALL TAXIWAYS AND PARKING POSITIONS, the correct (and identical to the GUI layout) Ground Layout is shown in EFB. Thanks god we were anticipating such problems during our continuous hard work with MSFS (politely expressed), thus we are able to present an easy workaround for this. You will soon receive simple instructions to overcome this unpleasant situation.

Ok, things are becoming a bit strange. I have uninstalled and reinstalled Gaya's (ORBX) LOWW airport and re-run the database builder (talking indeed also of MSFS). I now get pretty much the same layout and wrong gate numbers as in your screenshot, although there has never been an update offered by the ORBX system. There have been changes in the gate numberig within EFB lately, but on most airports the numbering seems correct. We will have to investigate on this matter, why in some cases the prefix and suffix is mixed up. Please stand by on this.

The navigraph layer only has an influence on navaids, which is - as from a few AIRAC Cycles back - always at top priority to ascertain that navaids - especially the ILS'es - are always used from the most recent AIRAC cycle and not by an eventual own definition used by the Add-On developer. As for the stand numbering this always depends on the layout design used to draw the ground layout. As you can see in the screenshot attached, the ground layout correctly shows "E43" using Gaya's (ORBX) Add-On.

I doubt that the Add-On sceneries are skipped. Symlinks are treated as normal datapaths. Of course the Symlinks need to show up in the Community folder. The paths that are skipped are the paths "below" the usual scenery path or non-pertinent paths like texure, contentinfo and similar. Have you checked after building of the database whether the mentioned add-ons are REALLY NOT processed by the DbBuilding process? As an example I have attached the Airport Info Page of LSZH, which is created by FSDreamTeam and linked to the \communitly folder by a Symlink. Nevertheless it is processed and displayed normally. And that's how the respective datapaths show up in the IEExplorer:

Hi Rolando, Thanks for your feedback. great to hear that it works now. Enjoy !

Hi Rolando, did you check that the profile has the correct call-up name (airfile name) for the MSFS PMDG DC-6 ? See attached example. It may be missing in the default profile. It was however discussed in this forum a few times. Please note that the MSFS PMDG DC-6 airfile name does not distinguish between the 6A and the 6B model. Both have the same airfile name "dc6". In addition to that please make sure that the airfile name "dc6" is only entered in ONE of the two profiles. No two profiles must have the same airfile name.

After an Update it is generally a good idea to recreate the database.... This will clear up the situation.

Please check my message above ! We see a problem with VATSIM. With IVAO everything seems to work normally. We need to investigate why VATSIM ATC information disappears after the first 30 sec cycle. Please give us the required time. There's no need to issue any consecutive report. We are working on it. Just hang on !! Your life is not endangered !!

Hang on. We have to investigate further. Possibly an issue with VATSIM. IVAO seems to be working normally, indepoendent of Simulator type. Just wait for further information, please.

First thing is that SU9 has done quite some harm to the filesystem of MSFS. Inorder to do at least some part of cleanup, I heavily recommend to delete the content.xml and have it rebuild by MSFS. Additionaly if you have Navigraph installed, you need to reinstall it after MSFS shutdown.Thereafter a complete rebuild of the database is necessary. After this we may discuss further problems. Without this we are simply unable to give any advice as we have no insight into the state of your MSFS and EFB installation Before starting this cleanup, if you have any kind of automatic backup systems of any kind, please deactivate it and leave it deactivated.

Honestly, I have no idea. I fly the A320neo regularly without the effect described by you. However I use he FBW A320neo with flighplans created through SimBrief und inported into both the A320 and EFB. This works flawlessly. Using EFB flight plans in an A/C with FMGX or similar is never a good idea as we do not know how MSFS processes the EFB flight plan (*.pln format) internally.

EFB does not interact with MSFS. If you transfer a route into MSFS it only copies the routing into C:\Users\User\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState for reading by MSFS. No further interaction is taking place.

Sorry, unable to read chinese writing...

Difficult to say. Maybe connection problems? At a similar setup I see an active ATC zone over GB and some active airports in build #131. As for a rollback to a previous version: similar to MSFS there is no rollback possible for EFB.