Jump to content
The simFlight Network Forums

pellelil

Members
  • Posts

    86
  • Joined

  • Last visited

Everything posted by pellelil

  1. Thanks for your efforts Pete. Don't know where the original weird city name came from, but its fixed with this updated MkRwy
  2. 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.
  3. 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 🙂
  4. 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.
  5. 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.
  6. Pete I wrote the author of the EKBI scenery, telling him you and I were pulling out the last of our hairs, trying to work out this issue. He told me that scenery installed through the marketplace gets encrypted, and that is why MkRwy can find/read it
  7. I becomes more and more weird. The two sub-folders containing EKCH and EKBI don't contain any .BGL files (hence probably why MkRwy don't have these) ??? They contain a lot of texture files and json files, but just no .BGL EDIT: BOTH EKBI and EKCH are payware
  8. All my 3rd party scenery are in the same folder (or subfolders to this), so if it can find one it should find them all. Strange that MkRwy finds 1 (the Aerosoft) but not the 2 others (all 3 are in sub-folders to "G:\FS\2020Packages\Official\OneStore").
  9. I've just started the sim up at Paderborn, The Aerosoft scenery looks fine ... don't see any default scenery bleed through or anything (that should indicate it have a lesser priority than the default). I then loaded up the aircraft at EKCH, and it is indeed the FlyTampa EKCH I see in the sim, even though it is lon at all listed in the SceneryList file ???
  10. I just installed it through the markedplace, don't know how/why MSFS did what it did. You mean the SceneryList.txt? http://www.liljendal.dk/portals/1/files/tmp2021/SceneryList.txt
  11. 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".
  12. 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.
  13. 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 ???
  14. Something weird is going on. Now with the new version it instead is <City>B÷ren</City> shown in Notepad++ x87xF7 I'll try to remove Paderborn and see when it scans then
  15. Depending on how much code is reused and how "old" BGLs were encoded, switching to wchar might break things for FSX/P3D !?
  16. Thanks Pete, sorry for the emotional roller coaster most likely caused by a "weird" value in a BGL 😉
  17. 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.
  18. The escaping of char in XML you have implemented appears (to me) to be just fine, so the only issue is the encoding of wide-chars. There are currently chars in the XML in the range 0x80 to 0xFF that works just fine, so not sure why these 2 chars are causing an issue
  19. 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.
  20. Pete regarding it being optional, I was just thinking that if this hack have some side-effects, people at least have a chance to disable it, or only those who noticed an issue can enable it. As of now it appears I'm the only one who have run into this issue, and currently I have added my own "pre-processor" to pre-process the XML-content before I hand it over to the .Net XML-parser.
  21. Can't comment on the char/wchar side of things, but this should take care of escaping these 5 chars in XML. So I would not change this part. My suggested hack was regrading looking at multiple chars at the same time (e.g. finding a char equal-to/greater-than 0xF0 and if found look at the previous/next char), so I don't think it can be handled by this method only looking at a single char at a time. Anyway what I suggested is a hack, so perhaps make it optional via a command-line argument.
  22. I don't know which of the two are more likely to appear natural, but "#" is fine be me
  23. I know its a hack. I would first look if the string contains any char/byte values equal or greater than 0xF0. If it doesn't I would use the string as it is. If however it does contain a char/byte equal or greater than 0xF0 I would remove (or replace) this char, and if there are any pre-/suffixing char greater that 0x7F I would remove them as well. If a string contain: "0xA1, 0x12, 0x34, 0xCD, 0xF0, 0xBC ,0x56" I would remove (or replace) "0xCD,0xF0, 0xBC" so the resulting string would be "0xA1, 0x12, 0x23, 0x56". Its probably better to just replace the chars with a dummy-char (e.g. "*") to indicate that something should have been there, but was removed.
  24. Yes the BOM is just the very first 2,3 or 4 bytes in the file before the "text-content". But I've tried adding it and it does not fix it. I should have known - as the rest of the file is not UTF-8 encoded (at least not these two chars causing problems), so naturally its a bad idea to add a BOM saying "here is some UTF-8 encoded text" while the text is not actually UTF-8. The "correct way" to fix it would be as Luke write, would be to find out how text is encoded in BGLs (and I would guess UTF-8 as well) and then use a library/framework to generate the XML as it takes care of encoding the chars, and escaping those that needs escaping. But I am guessing that will NOT be a quick fix. No doubt this issue is caused by some weird city-name in a BGL. I see it for Paderborn only, and guessing its the free Aerosoft version, so I raised the question on their forum if something strange is going on with this city name, but so far no replies. I tried analyzing the generated runways.xml and there are many chars with a byte value above 0xA0 that works just fine. In this city name I see two values (shown in reversed in Notepad++) "xA1xF6" where the "0xF6" is only value at/above 0xF0 in the file. So I tried removing only 0xF6 and leaving "0xA1" in the file, but both Notepad++ and the XML parser in .Net still complained. So for a quick fix I would scan the text line and see it if contains bytes at- or greater than 0xF0, then remove this and any prefixing/suffixing chars greater than 0X7F. Its not pretty, its not perfect and if anything more a hack ... but at least it would allow the .net XML parser to do its work and Notepad++ would also stop complaining.
×
×
  • 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.