Jump to content
The simFlight Network Forums

pellelil

Members
 View Profile  See their activity

  • Posts

    90

  • Joined

  • Last visited

 Content Type 

Posts posted by pellelil

  1. MkRwy have an issue with the latest (Canada) WU (illegal char in XML)

    in FSUIPC Support Pete Dowson Modules

    Posted

    Hi Pete,

    The Runways.xml can be downloaded with this link
    www.liljendal.dk/portals/1/files/tmp2022/error_runways.zip

    I doubt it has anything to say with this issue, however I noted that ICAO-code in Runways.txt it shows as "CAN99", whereas in Runways.XML is shows are "CAN9". Anyway here below is the text regarding CAN99 from Runways.txt. I always use MkRwy with the />1000 argument, but this shouldn't change anything !?

    As it have no runways/gates and the scanned folder-path contains "canada-pois" I am guessing that this is a POI (Point-of-Interrest) rather than an airport? Hence perhaps it shouldn't have been included at all? ... unless it's a helipad !?

      

    =============================================================================
Official\OneStore\microsoft-canada-point-of-interest\scenery\Microsoft\canada-pois\branch1.bgl
=============================================================================
Deletions check for Airport CAN99:
          Delete all taxiways!
          Delete all runways and starts!
          Delete all taxiways!
...
Airport CAN99 :N46:48:42.8253  W071:12:18.8498  181.20ft
          Country Name=""
          State Name=""
          City Name=""
          Airport Name="ChQ�teau Frontenac"

          in file: Official\OneStore\microsoft-canada-point-of-interest\scenery\Microsoft\canada-pois\branch1.bgl

          FSM A/P CAN9, lat=46.811905, long=-71.205238, alt=181.20

     

  7. Illegal char in Runways.xml - MkRwy 5.11

    in FSUIPC Support Pete Dowson Modules

    Posted

    I don't think there is anything wrong with my default Paderborn. As I wrote Monday at 06:01 PM, I tried removing the Aerosoft Paderborn, and ran MkRwy (scanning only the default Paderborn). After this there were no issues with the file generated by MkRwy (no weird chars, and the xml loaded fine into the sim. I then reinstalled the Aerosoft Paderborn, and again I saw wierd chars. That why I said yesterday that I tough it was the "order" (default vs 3rd party Paderborn) ???

    Anyway its working fine now, and I hope MkRwy can remain relevant for some time. Otherwise I hope Asobo/MS are planning to make APT-, RWY- and TWY-info available to 3rd party software some how. The Aerosoft CRJ 550/700 have just released for MSFS embedded with its own nav-data, but as far as I understand this is temporary and the plan is that in the future these 3rd party aircraft should have access to NavBlue data from within MSFS. But naturally that is only valid as long as the scenery is build according to these, and I doubt this will contain all info we have thanks to MkRwy ... time will tell.

  8. Illegal char in Runways.xml - MkRwy 5.11

    in FSUIPC Support Pete Dowson Modules

    Posted

    Pete having run the new MkRwy the Paderborn scenery appears just fine in runways.xml (and it have the correct folder-name):


    <ICAO id="EDLP">
    <ICAOName>Paderborn/Lippstadt</ICAOName>
    <Country></Country>
    <City>Paderborn/Lippstadt</City>
    <File>G:\FS\2020Packages\Official\OneStore\aerosoft-paderborn\scenery\global\scenery\EDLP_Placement.bgl</File>
    <SceneryName>aerosoft-paderborn scenery</SceneryName>

    As requested I have uploaded the new SceneryList.txt
    http://www.liljendal.dk/portals/1/files/tmp2021/SceneryList.txt

    And if you for some reason needs to compare to the old (I uploaded the other day):
    http://www.liljendal.dk/portals/1/files/tmp2021/OldSceneryList.txt

    So it appears it was the order that was affecting the strange city-name I initially saw. Anyway thanks for your hard work my friend 🙂

     

  9. Illegal char in Runways.xml - MkRwy 5.11

    in FSUIPC Support Pete Dowson Modules

    Posted

    I have normally my windows configured to show hidden files, but I'll verify when I can.

    Regarding the encryption its my guess that the files remains encrypted on disk (decrypted in memory when loaded by MSFS) to prevent an owner of "sharing" his purchased scenery with others ... but just a guess.

    Naturally Pete, I'll assist if/when I can 🙂 If you haven't you can remove my suggested hack, as I am guessing its other issues that are at play here.

  10. Illegal char in Runways.xml - MkRwy 5.11

    in FSUIPC Support Pete Dowson Modules

    Posted

    In the Paderborn folder there are BGLs, but in my EKBI/EKCH-folders there is not a single BGL. I don't know if they get installed somewhere else, or if the file extension is changed as part of the encryption-process. The scenery folders were empty, but other folders (like texture had content). But as long as they are encrypted there is no way MkRwy can read them. The actual encryption is done by Asobo/MS (not the individual developers), however the developers might have a say if they should be encrypted or not? Perhaps not all files gets encrypted (why the Paderborn folder still contains BGLs)?

    Any way, I don't think there is much we can do about it. Hopefully the default scenery remains un-encrypted, and all of the free community scenery as well.

  16. Illegal char in Runways.xml - MkRwy 5.11

    in FSUIPC Support Pete Dowson Modules

    Posted

    What I meant about community-folder is the folder "G:\FS\2020Packages\Community" into where I in the past have installed freeware content in form of scenery and community driven updates for the default aircraft (e.g. the work done by "Working Title" updating the CRJ4 and the Garmin 1000/3000). This is all content that cannot be installed through the MSFS-markedplace, hence its more easy to control having a separate folder for it ... but as I said this folder is currently empty.

    The first two lines of SceneryList.txt contains the "link" to the Paderborn scenery:
    001    Active    aerosoft-paderborn scenery
        G:\FS\2020Packages\Official\OneStore\aerosoft-paderborn\scenery\global\scenery

    But Runways.xml list the the file as this:
    <ICAO id="EDLP">
    <ICAOName>Paderborn-Lippstadt</ICAOName>
    <Country>Germany</Country>
    <State>North Rhine-Westphalia</State>
    <City>B+ören</City>
    <File>G:\FS\2020Packages\Official\OneStore\fs-base\scenery\0601\APX50130.bgl</File>
     

    In SceneryList.txt I can't see "links" to be 3rd party EKBI nor EKCH, and these are also listed with a default BGL-file in runways.xml
    <ICAO id="EKBI">
    <ICAOName>Billund</ICAOName>
    <Country></Country>
    <City>Billund</City>
    <File>G:\FS\2020Packages\Official\OneStore\fs-base\scenery\0601\APX50120.bgl</File>

    and:
    <ICAO id="EKCH">
    <ICAOName>Kastrup</ICAOName>
    <Country></Country>
    <City>Copenhagen</City>
    <File>G:\FS\2020Packages\Official\OneStore\fs-base\scenery\0601\APX51120.bgl</File>

    All these 3 airports works just fine in the sim. I can see that my EKCH (installed via the MSFS markedplace) have been installed into the folder: "G:\FS\2020Packages\Official\OneStore\flytampa-copenhagen" and my EKBI have been installed into: "G:\FS\2020Packages\Official\OneStore\vidandesign-billund".

  17. Illegal char in Runways.xml - MkRwy 5.11

    in FSUIPC Support Pete Dowson Modules

    Posted

    I'll have a look, but I am pretty sure the file is listed "wrong" in the runways.xml (or at least not what I would expect). I noticed this for another 3rd party airport as well. My MSFS (Premium Delux) is fully updated, all content downloaded, I currently have nothing in the community folder, and the only 3rd party scenery installed is the free Paderborn along with VidanDesign EKBI and FlyTampa EKCH.

    I can't be sure if the Paderborn is installed "correctly" but had it not been originally, it should be been fixed yesterday when I first removed (shut down the sim and performed a scan with MkRwy), and then starting the sim again, and installed Paderborn once again. When not installed the city is shown as "Paderborn/Lippstadt", but once installed I see this wrong city-name.

    I have NO IDEA why Paderborn is causing this issue (perhaps only on my system). Its the only airport I have seen with a weird value, and only in the city-name.

  18. Illegal char in Runways.xml - MkRwy 5.11

    in FSUIPC Support Pete Dowson Modules

    Posted

    Pete I tried removing the free Paderborn and then I did a new scan, and the city-name was just fine. Then I started the sim again, installed Paderborn and closed the sim. Now when I scan I see the city-name as <City>BPören</City> (where the letter after "P" is shown as xF6 in Notepad++. The only "special" thing I do is I am calling MakeRwys via a link where I have the command-line argument: "/>1000"

    EDIT: Executing MakeRwys directly (without the argument) does not change anything. The city-name from Paderborn still containx xF6 when viewed in NotePad++

    However now it loads as XML just fine, eventhough Notepad++ still shows xF6 ???

  20. Illegal char in Runways.xml - MkRwy 5.11

    in FSUIPC Support Pete Dowson Modules

    Posted

    4 minutes ago, Luke Kolin said:

    If I can load it into VS2019, I'd be willing to look at it. My point is that your challenge is upstream, when you load the strings out of the BGL. I suspect (being optimistic) it might be enough to either load the strings as wchar_t* instead of char* (or cast) and then have your encoding function that you shared here operate on *wchar_t instead of *char. The challenge is going to be how you read from the BGLs, but I suspect it's all bytes and the cast should be OK.

    If you want a low-effort experiment, change the function signature of your encoding function to take wchar_t* instead of char*, cast the pointers before you call it and see if it works.

    Cheers

    Luke

    Depending on how much code is reused and how "old" BGLs were encoded, switching to wchar might break things for FSX/P3D !?

  22. Illegal char in Runways.xml - MkRwy 5.11

    in FSUIPC Support Pete Dowson Modules

    Posted

    That's a very good question Pete 🙂

    It's a two-edged sword. If you only look for 0xA1 followed by 0xF6, chances are there will be other byte-combinations that might break it, and if using my suggested hack, you might end up replacing chars that are just fine.

    As I am apparently the only one who have seen this issue, and so far only with 0xA1 followed by 0xF6 (for this one/single airport), it might be a good idea to only look for, and replace this particular combination.

  24. Illegal char in Runways.xml - MkRwy 5.11

    in FSUIPC Support Pete Dowson Modules

    Posted

    It appears to me the chars in the XML are encoded using Windows-1252. And if you look at the chart from this following link there are (should be) "valid" chars above 0xF0, so my suggested hack will fix the issue I am seeing, but it might result in other "valid" chars being replaced:

    https://en.wikipedia.org/wiki/Windows-1252

    So I don't know why these two chars are being flagged as invalid, as there are many other "special chars" that seems to work just fine (e.g. some of the Danish letters seems to work fine).

    The two chars that are flagged as invalid for me, is the 0xA1 followed by 0xF6. That is why I suggested the hack that I did. But to be honest I don't know at byte level how UTF-8 chars gets encoded (the .Net framework takes care if this for me). I am guessing that 0xA1,0xF6 is a two-byte code for a single char, but when encoded into Windows-1252 they appear as two chars.

     

     

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.