It appear MkRwy have an issue with (Canada) WU for MSFS

[pellelil 59]

For those of you running MkRwy to update the files you use with Flightplan Visualizer (FV) it appaers MkRwy have an issue with the latest (Canada) WU for MSFS ... at least on my system.

 

When scanning the scenery for the airport "CAN9" ("Château Frontenac") it inserts an illegal char in the generated "runways.xml" file. This illegal char prohibits FV reading this required file, hence FV cannot start-up. If any of you runs in to this issue, you can manually edit your "runways.xml" file, however you need an editor that can load such a large file (when I generate it, I include all runways longer than 1500 feet, hence the generated file will be some +91 MB). When loaded into an editor (I use the 64 bit version of NotePad++) search for "CAN9". If you run into the same issue as me, you should see the illegal char in the "ICAOName" field (NotePad++ will show it in reversed colors). Simply paste in a new name without the illegal char "Château Frontenac").

 

Generally MkRwy is somewhat challenged when it comes to airport-/city-names with unicode-letters (like "â"), so even if not adding illegal chars to the XML, airport/city-names might not show correct in FV. In version 1.22 FV will try to detect these wrong names in the XML, and once detected it will try to in stead fall back and use the names from the airport-database. For the release of 1.22 I have been going through the airport-database and fixed many names that were wrong for airport/cities (also issues with unicode-letters).

[pellelil 59]

As written yesterday, for version 1.22 I have added code to (try to) detect when there is an issue with unicode-letters in the name-fields (typical name of airport and/or name of city). If/when this is detected FV will in stead use the name from the airport-database bundled with FV (updated for version 1.22, for the same reason). However this will NOT change the fact that illegal chars in the XML will prevent FV from reading the Runways.xml file.

 

Running into this issue again yesterday made me rethink how I could try to handle the issue with illegal chars the name-fields of Runways.XML. In the past FV have always read the Runways.xml file, as one large (+90 MB) XML-file containing information of all +40000 airports scanned from the scenery. But as written here it meant the entire import failed if this file contained a single illegal char. As a new feature in version 1.22 FV will catch if- and when an error occur reading Runways.XML. If an  error occur a new message-box (below) will appear informing the user of the issue, and it will ask the user if a new setting called "Robust 'Runways.XML' reading" should be enabled or not:

 

Please login to display this image.

 

If you choose "No" ("Nej" here in my Danish version) the program will work as it did in the past (not being able to read the Runways.XML file). However if you in stead chooses "Yes" ("Ja" in Danish), the Runways.XML file will be split into many small XML-sections (one for each airport), and then all of these sections are being imported in parallel. It will cost some extra CPU power, it will cost some more memory (only during import) but it will allow FV to import the file. If there is an issue with an illegal char in the XML for a single airport (as was the case with "CAN9" yesterday) it will detect this issue and it will make sure the name-fields for this one/single airport are "groomed" to remove any offending chars (data for all other airports will import without the XML needs to be "cleaned" for offending chars). So if you run MkRwy at a later time (e.g. after a future "world-update") the issue with illegal chars in the XML might have disappeared and you can try to go to settings and disable it. Worst case the issue is still there, so simply re-enable the setting on start-up.

 

For the more nerdy users (like myself) I will probably want to "hand-edit" my XML to remove these illegal chars if/when they are being detected, but it will require you to look through the log-file to find the specification of where in the XML the issue was detected, and then you will have to manually load the XML, find the location, and edit the file. This new feature is just a matter of accepting to enable it if/when the issue is detected on start-up, and it will log the issue in a more readable fashion:

 

18:31:25.987|15|INFO |Load Runways.xml (MkRwy) from file: G:\FS\MakeRunways\runways.xml
18:31:26.522|15|INFO |Using normal import of MkRwy Runways.XML file
18:31:26.945|15|ERROR|An error occurred while  reading Runways.xml (can happen due to illegal chars in XML generated by MkRwy).
18:32:16.109|15|INFO |User decided to enable robust-reading
18:32:16.122|15|INFO |Save App-settings(xml): C:\Users\pelle\AppData\Roaming\FlightplanVisualizer\UserData\Settings.xml
18:32:16.146|15|INFO |Using robust import of MkRwy Runways.XML file
18:32:18.704|14|WARN |Had to use robust import of MkRwy airport: CAN9
18:32:19.279|15|INFO |Airports imported (MkRwy): 41100

 

The log clearly states what happened, and that the user chose to enable this new setting. Also in the second last line you can see it occurred importing the XML for the "CAN9" airport, so if you want to hand-edit the XML (remove the illegal char), you in this case simply have to search for the "CAN9" airport. But the less nerdy can simply enable the feature and disregard the log, and the hand-edit part.