lonewulf47

Sure enough ! We called it "the Pimp Season"...😁

Yup, I remember this from my active days. You could only survive daytime when buried to the neck in cooled (neverthelss still 30°C) pool water at the poolbar. Summertime was definitely NOT the holiday season...😀 That's why our flights always arrived and departed around midnight, which meant much cooler (around 34°C) at 100% humidity. Really lovely ! 😁

Hi Ray, Actually the AddOn in question is for both P3DV4 and V5. Neverheless as usual with some "adventurous" AddOns, the installation is somewhat tricky, when it comes to P3DV5. For P3DV4 it should be ok. There is a second file in the download named "OOMS_P3DV5_fix" which IMHO contains all files again. I'm definitely not in the mood to check the difference between the two. More important is the fact, that the ground layout BGL is scr***d up as usual and does not contain any of the ILSes nor does it show the southern RWY as it is deactivated. I have in the meantime built a new "AFX_OOMSP3D.bgl" which replaces the original. In my install at least it works ok and all ILSes are in place. Just in case you intend to nevertheless purchase this AddOn I'll add the corrected BGL below. AFX_OOMSP3D.bgl

Ray, For the moment I would recommend to stay away from the ARMI Project OOMS AddOn. It provides no active runways and therefore needs some modifications before it can be used in EFB2.

Hi Ray, In fact there is a relatively low priced AddOn from ARMI Projects, which should be available for P3DV4 and V5. I'm not advertising it, just hinting to it 😉. I haven't tried it myself yet but will soon, as there are not too many airports im the Middle East for P3D5.

Ray, The problem is that you expect EFB2 to perform miracles... 😉 OOMS has ATM only ONE active RWY and that is 08L/26R. Unfortunately this is the new parallel RWY in the north of the existing old RWY. Due to the fact that there in ONLY ONE ARINC RWY (Ctrl+Alt+A) the automatic RWY assignment algorithm of EFB2 of course assigns this to the only existing RWY in the SIm and that is the Southern RWY, which in fact is not active ATM. As those RWYs are too far apart, there is no possibility to match procedures. . There is an AddOn for P3DV4 and V5 and even better in P3DV5 the default airport is describing the correct RWY (see screenshot) As long as you have no separate AFCAD/Airport Layout BGL, there is no other way to use this airport than to manually tune and fly the ILS for: 08R: 108.30 083° IMW (which is the souther 08) 26L: 110.30 263° ISB (which is the southern 26)

Hi Stephan, EFB2 can only draw what the respective BGL is depicting. In P3DV4 (and maybe in FSX or older P3D Variants) the default ground layout is generally completely out of shape and position. You can easily verify this when using the ARINC RWY overlay (Ctrl+Alt+A). In P3DV5 however everythin is correct. But this is something that LM/MS has to be blamed for, not AivlaSoft. Id you are using an Add-On the same applies. The Add-On designer is responsible for the correct Ground Layout.

First remedy is always to reboot your computer. If the error persists, then please submit a set of support files. Please also read the Forum Rules thoroughly.

Well, not quite most recent status anymore. With the latest cycle 2006 even P3DV5 NVX***.BGL were updated. My guess is however that possibly no ILS'es were updated because of some major changes within the airport (APX***.BGL) layout due to the sloped RWY feature used in P3DV5. Whether or not copyright issues will play a role in the new game is beyond my knowledge. In any case new airport BGLs (AFCAD) can still be produced with ADE Version 179 ff and activated in a common scenery folder. The problem of changed ICAO IDs is however completely different and needs some more considerations inorder to be solved. But nevertheless nothing is impossible...😀 Just in case I have a few ideas should any such problem arise...

Well, we have a link posted here: https://forum.aivlasoft.com/topic/4264-why-are-ils-approaches-not-showing/ Usually those problems are linked to phsically existing navaids (mostly ILS') which unfortunately give more and more problems in all MS-based simulators. So far I wouldn't know of any other important software dealing with similar EFB2 issues.

👍🤞😀

Simply put: the update with the new ICAO Code does not happen with the regular worldwide SORS Navaid update, but with the regional (or in this case worldwide) ILS updates. With the regular navaid update only European ILS' are update. For the rest fo the world the worlwide ILS update is required. See below: The updated airport ICAO is in this replacement BHL:

https://aero.sors.fr/navaids3.html

Ohh, I see. That's somewhat strange then ! In my V4 install I see the correct ICAO code VGHS ! (see above screenshot) Did you ever apply SORS' Navaid Update? Maybe this update also changes the ICAO Code? Other than that I have no explanation. I See only the correct VGHS ICAO code in V4. The old VGZR is not in my V4.

Well, before investing your money I would just give it a try and copy the above mentioned "APX72230.bgl" from P3DV4 into the respective path in P3DV3. To be honest, I never tried ist but AFAIK there were no scenery specs changed between V3 and V4. So it MIGHT work but no guarantee. I have no clue whether there is a verification code included in those default BGLs... Just make sure you don't overwrite the old "APX72230.bgl" but save it to a secure place or set it to "OFF" before and then re-run den DbBuilder. If P3DV3 starts up normally after that it could work. Otherwise just restore the old BGL and you're back to nomal.

They do, but I wouldn't count on 100% correctness. There is no information about the actual state. One can just guess. VGHS = Dhaka, Hazrat Shahjalal Intl. Airport. I think that's what the whole thread is all about...🙂 See the screenshof below. That's where it is in P3DV4.

Not true either😀... EFB2 is using what the Sim offers. As for the ILS it only CHECKS whether the correct one is supplied by the Sim and eventually reports an error. You can NEVER tune any Navaid which is only available in NavDataPro or Navigraph. It MUST be included in a BGL, either AddOn or Default. We can't change this. It's hard-coded in all MS-Based Sims. BTW, you are still on P3DV3, aren't you? From P3DV4 onwards VGHS would be included...😉That's at least what I see on my installs.

Hi Ray, There still seems to be a large misunderstanding about the airport database in EFB2. EFB2 can only build a database on the content of the respective Simulator. If the Airport in question is not contained in the Simulator, EFB2 cannot include it in its datadase. The NavDataPro or Navigraph databases only supply procedure for these airports, and I bet there are no procedures available for VGZR, as this airport does not exist anymore in neither NavDataPro nor Navigraph. So in short: if the database (default I guess) of your simulator still contains VGZR, then of course EFB2 reads this data. As VGZR does not exist anymore in the worldwide database of Navigraph and NavdataPro, consequently there will be no procedures available. To have VGHS in your database, you will need an AddOn of any kind to provide airport layout and airport navdata (ILS). There's no way around. it's just one of these restrictions set by the way MS-Based simulators handles airports and it's navaids.

Hi Klaus Now for the problem with SBFZ Fortaleza. The reason for this misbehaviour lies in a somewhat "unusual" handling of RWY assignments by the Brazilian Authorities. It would be going too far into details if I would start explaining the algorithms EFB is using to properly identify (and possibly replace) RWY identifiers. Anyway in this specific case it was a "virtual" RWY 12/30 that was used for one specific RNAV/RNP apporach to the displaced THR of RWY13. As said before, this is a very unusual way to handle approaches but unfortunately sometimes used especially by our colleagues on the southern hemispere. We have a feature available in the DbBuilder, called "Enhance Runways". With this feature you can oversteer EFB2's algorithms for RWY assignments. I will explain in the following two screenshots, how to handle this. It is also described in the Manual "4 Database", chapter "2.5 Enhance/Update Runways". First start the DbBuilder 1) select the tab "Enhance/Update Runways" 2) selecte respective simulator 3) open the selection window for the airport selection 4) Enter the ICAO Code 5) Confirm with "OK" Then proceed as follows: 1) Click on the required airport (here already a second airport SBPA with the same problem is already entered) 2) Click on the first RWY 3) in the entry field below labelled "ARINC Rwy" enter the required RWY ID "13", do the same with the second RWY and enter the ID "31" 4) Close the operation by pressing "OK" will see the following After having completed you may do the same for SBPA which is also affected by the same issue for RWY 11/29.To complete the operation run the "Update Simulator" for X-Plane and you're done. You will have now access to all procedures for the RWYs in use.

Hi Klaus, as for SBSV I cannot confirm the missing SID TIRK1A. Scrolling down shows the missing SID: Things are a bit different for SBFZ. The reason why there are no procedures shown is of course due to the wrong RWY alignment 12-30 iso 13-31. I see the very same in my install, however for the moment I have no explanation why this wrong RWY is shown, as according to the apt.dat in Global Airports the RWY is clearly defined as 13-31. Something I have never seen before. We need to investigate on that.

Ok, first of all: what A/C type does EFB2 show, if you have loaded the Zibo 737-800? Does it reset to the Default A/C? As I do not have the 737-800 zibo I do not know what is set as ICAO Code in the *.acf file. Please check this with PlaneMaker. In this example the entry for the default B737-800 of Laminar is shown. My guess is however that the zibo carries the same code. With this code it should show up normally in EFB2, as it is already contained in the B737-800 profile.

Hi ??? (please follow our forum rules and sign your posts with your real name) It's all described in the same manual chapter. See here:

Thanks, Simon, for the update! Even with the provided Support Files it is sometimes not possible, to find the REAL cause of the issue. In any case there seems to have been a mismatch between different databases. As for the warnings: well, this is up to you. Sceneries below Specs 1000 cannot be displayed by EFB2. Therefore the Default or World Aiport layout will be used. To be honest, I wouldn't use those outdated sceneries anymore as they can create problems with the newest X-Plane specs. A remedy could be to recompile those airports by using WED whenever possible.

I have quicly recreated an X-Plane database with Navigraph Cycle 2006 and couldn't reproduce your issues. See here:

Hi Simon, I see that the DbBuilding Process was not completed without errors. This is the first issue that needs to be cleared. You cannot expect EFB2 to work if the DbBuilding Process is not completed error free. Furthermore I see a strange entry in the DbBuilderLogfile, that I'm unable to explain. When it tries to read the "earth_nav.dat" file it returns an error " 2020-06-02 09:33:47.578 Error : Spec version '1150' is not implemented. Cannot read file! #2 (main) Checking my Navigraph earth_nav.dat file from the last AIRAC Cycle I do not see a specification 1150. Here it still reads "1100 Version - data cycle 2006, build 20200515, metadata NavXP1100." I will have to check with the Navigraph Data Source whether there are two different data specs available. So far I have no knowledge of that. Edit: I'm currently on X-Plane 11.50b9 and I haven't seen any Specifications change for the navdata.