Jump to content


  • Content Count

  • Joined

  • Last visited

  1. Please consider option 3) as well. 3) Any 3rd party tool updates/changes the flightplan within the sim. So only watching for a loading event initiated by the p3d gui would be not enough. Any change, any time introduced from whatever source to the flightplan in the sim should be recognised by the efb server. A perfect solution might have a efb server config option too that defines how such a sync behaves. - No Sync - EFB to Sim only (default) - Sim to EFB only - Bidirectional And in case you have extra time for a mindblowing feature, you might analyse the incoming waypoint data based on the actual AIRAC nav data to find out automatically which SID, STAR, Transition and approach has been applied to generate the actual lateral flight path..... Think in most if not all cases there will be only one valid and easy to find solution for that puzzle. But that might be asking for too much. On the other hand, having that solver implemented, would be very usefull for implementing the upcoming inflight uplink feature as well... Cheers Stephan
  2. Hi Aivla Team, sorry to bump this thread and some others - content wise. How ever, pulling active flightplan data automatically from the sim and updating the visualization in the EFB is excatly what I would expect from an EFB! More on that - it is perfectly in sync with your envisioned big picture that is intended by the uplink feature in the first place. All default planes use the flightplan in the sim as their 'FMS/GPS' source. Many ATC tools like Pilot to ATC use it too (P2ATC can be configured to update (complete) the sim FP after SID / STAR / APPROACH assignments where given and cleared). So importing/syncing FP data from the sim with the EFB would be the most logical way to integrate an EFB into the sim. With your current approach, Aivla EFB needs to pull the FP data from the 3rd party FMS or the 3rd party vendor needs to publish the actual FP to the Aivla EFB (e.g. using something like the uplink folder). For all the default planes the P3D Team would need to use your uplink feature too..!? Guess this will not happen any time soon. So syncing the EFB with the sim FP would make Aivla EFB working IMHO as expected from any EFB in case the sim FP is changed. Actually the sim FP is updated by Aivla EFB already in case the user changes the FP in Aivla EFB. Both features together with all the other stuff we have already in Aivla EFB, would make Aivla EFB a full featured FMS for all aircraft using the aged default GPS. So the business value for Aivla and the community of this sim/EFB FP live sync feature is way higher and fully under your control to be implemented soon. The uplink feature is nice too, though it needs support of others that may never come any time soon. As an AddOn developer of a proprietary FMS (like PMDG or like) I would choose to publish the FP to or even bidirectionally sync my FMS with the sim FP rather than implement an additional interface to any other 3rd party vendor like yours, because of the same reasons you ceased to implement FP exporters! The sim itself should be the master for 3rd party AddOns to pull and feed flight plan information to/from (Hub and Spoke approach rather than a n:m network approach). Anything else would seriously violate the idea of an open sandbox everybody can easily connect their extensions to. Don't get me wrong. Aivla EFB V2 is a great tool that have come a long way. But with the V2 we lost some integration paths that IMHO need to be replaced to keep the usability or usage value we had prior to V2 and expected to have continued. At the end of day, it's not a real EFB for real live usage. It's a EFB like 3rd party payware Addon that should easily integrate in the sim ecosystem we have today. We have no scheduling, planning or ATC staff that provides us with data and stuff. Most of us are lonely simmers and everything that reduces work load or number of addons to be used is highly appreciated. Aivla EFB might not be intended to be a flight planning or FMS tool - fair enough. How ever, a lot of your customers use it as such very enthusiastically though. And as such we need a bidirectional sync option with the sim FP that ideally impose NO extra workload or manual tasks and works any time the sim and Aivla EFB is up and connected. Be it airborn or at the ground. From my point of view, such a seamless integration would make me pay money for. Others may tune in too. Cheers Stephan
  3. As i found out, a resinstall of the EFB is not neccessary to get rid of the error message regarding a missing Runways.txt. Just create an empty file with the name Runways.txt using notepad or like in the UserData folder. If you encounter some conflict messages betwween the FSX Scenery Data and your current Airac Cycle, you may opt to fix them when they appear as described in the Data Provider manual. The other option is to put the original content into that file again, to align the stock FSX Scenery with the real world as close as possible for use with the EFB. However this may lead you to haveing some runways not available in the EFB that are available in your current Airac and/or Scenery data. Those entries represent excemptions that take precedence to any data found by the Data Provider for the listed airports in the FSX installation. So if you have installed Scenery AddOn's for any of the listed airports you schould check if the below listed exemption entry for this AddOn airport is still valid. See the Data Provider Manual for more details on that subject. // Aivlasoft EFB, Runway assignment table: FSX runway to Navdata runway // Copyright by AivlaSoft - www.aivlasoft.com // // *** %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% // *** it is important to always define ALL runways from an airport, // *** whether they have changed or not! // *** %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% // // General) // Column 1: ICAO 4-letter code of the affected airport // // A ) if the designator of an existing runway in FSX has been replaced/changed: // Column 2: Designator of the FSX-Rwy // Column 3: Designator of the corresponding Navdata-Runway // // B ) if a runway in FSX does no longer exist in reality (and therefore is no longer listed in Navdata) // Column 2: Designator of the FSX-Rwy // Column 3: 'nil' (without quotation marks) // // C ) if a runway in reality (and in Navdata) is existing, but is not available in FSX // *** this case is not possible to assign *** // // ICAO FSX Navdata CYHZ 06 05 CYHZ 24 23 CYHZ 15 14 CYHZ 33 32 PAOM 09 10 PAOM 27 28 PAOM 02 03 PAOM 20 21 EDDP 08 08L EDDP 26 26R EDDP 10 nil EDDP 28 nil LFSB 08 08 LFSB 26 26 LFSB 16 15 LFSB 34 33 LFSB 16L 15R LFSB 34R 33L PAFA 01 02 PAFA 19 20 PAFA 01L 02L PAFA 19R 20R PAFA 01R 02R PAFA 19L 20L PAFA 01Water 02C PAFA 19Water 20C EDXW 15 14 EDXW 33 32 EDXW 06 06 EDXW 24 24 LFQB 05 05 LFQB 23 23 LFQB 18 17 LFQB 36 35 LFQB 18R 17R LFQB 36L 35L EDDB 07R 07 EDDB 25L 25 EDDB 07L nil EDDB 25R nil LIPX 05 04 LIPX 23 22 KCRX 17 18 KCRX 35 36 LTBS 01 01L LTBS 19 19R KCVG 09 09 KCVG 27 27 KCVG 18L 18L KCVG 36R 36R KCVG 18R 18C KCVG 36L 36C LEMH 01 01L LEMH 19 19R KEUG 16 16R KEUG 34 34L KEUG 03 nil KEUG 21 nil Cheers Stephan aka Harlekin
  4. Kind of solved... I just pulled back the Runways.txt from my Backup and studied the Manual again regarding this topic. 1- The Format of the Aivla EFB Runways.txt has nothing in common with Pete's Runways.txt. Using this Filename is VERY misleading 'cause Pete's Runways.txt created by MakeRwys.exe is used in several major AddOns and has a distinct format and use. Pls change that in V2. 2- The content of this file specifies EXCEMPTIONS for the EFB only. If a AP is listed in there this data take precedence above what ever may be in the FSX Nav-Database or Airac Data. My Problem with EDDP was that the EFB Runways.txt reflected a rather old situation where EDDP just has only one proper runway to use. Actually EDDP has been reworked in the real world as well as in the Scenery Data and Airac Data several time. Nowaday EDDP has two full fledged CAT3 runways 08 R/L and 26 R/L. German Airports 2 has the proper Airport Model already but not the actual ILS Frequences included. (They have changed by OCT 2014 way after the release of GA2 and AS did no update by now AFAIK). I have updated the EDDP .BGL file by my self using ADE and the FSX(P3D) SDK to reflect the current situation at EDDP. How ever since the EFB Runways.txt had the old config of EDDP still in there, those changes were not reflected in the EFB. The solution was just to delete the entries for the EDDP excemptions in the EFB's Runways.txt because my FSX Nav Data, Navigraph Airac and Airport Scenery are in sync now and those corrective entrys are not needed any longer. Actually I deleted all the entries by now and will fix upcomming conflict messages by the Data Provider when they appear.. Four things to suggest: 1- The Airport Database Details Dialog mentioned in the Data Provider Manual section is not described in the Data Unit Section as stated and I was not able to find that one at all. Pls update the Manual so one can find that AP details dialog properly. 2- Changing a .TXT file manually is something that not everybody will feel comfortable with. A simple Dialog to maintain those excemptions would help a lot. 3- Deleting the Runways.txt throws an Error on the Data Provider everytime one tries to get certain Airport Data. Unfortunately there is no option to create an empty Runways.txt to solve that error message. I guess (not tested yet) just creating an empty Runways.txt wolud silence this error message. My suggestion would be to just create an empty one automatically if it is not there. 4- What about putting in some intelligence? During the gathering of Scenery Data (done by the Data Provider) it should be possible to find all conflicts at once. When a conflict is found an empty entry may be written into the Runways.txt to be completed by the user. And of course any excemption in there, that is no longer needed because there is no conflict found for that airport, should be removed (commented) as well. This way I would have never run in that problem at all 'cause the Data Provider would have removed the false EDDP excemptions as soon as the conflict between Scenery Data and Airac was solved by me. Cheers and fly safe Stephan aka Harlekin
  5. Hi all, I was missing some approaches at EDDE, some ILS Data was wrong at EDDP and EDDK. The reason was that within the runways.txt of the EFB those data were not included or just old. I just updated all those Airports usingg ADE and recreated the runway.txt using Peter's MakeRunways as usual. Now every other AddOn has all the approaches and such in there again, except the Aivla EFB. It throws lots of format errors now. I guess the EFB can not digest the output of the actual MakeRunways 4.679 properly. Two questions: 1- How can I fix those missing approaches and outdated airports now for the EFB ? 2- How we are supposed to update the runways.txt regularily after changing Scenary Data, if MakeRunways is not the proper tool for that task? The famous FSC has no problems parsing the output of MakeRunways 4.679..... This issue is a show stopper (->Deal Breaker - I'm still on trial for 4 days to come) for me. Updating a separate runways.txt manually for the EFB every time something is changed in my scenery data is simply a no go for a otherwise very nice product. My expectation was, that the Data Provider, while scanning the FSX scenery database, would build a proper runways.txt for use with the display units. Obviously it does not as my tests revealed (probably it just saves that runway.txt to a wrong location???) pls adv Stephan aka Harlekin
  • Create New...