pellelil

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.

I don't know which of the two are more likely to appear natural, but "#" is fine be me

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.

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.

Some kind of encoding have to/will take place when you have special characters in the file. Text-files are seldom ASCII these days, so special chars gets encoded into 2, 3 or 4 byte values, which is just fine as long as the program generating the file and the program reading the file agree on the encoding in use (why BOM is a thing). I fully understand that you are only using the value you get from the BGL, and in this case I only saw this issue with Paderborn so I am guessing its the Aerosoft airport that either have a "strange" city-name or that you for some reason see it as such (don't know if its possible for them to generate/write the BGL in a way, where MkRwy have trouble reading/decoding the BGL). I don't think changing the XML header will change any thing. I lean more towards BOM or the encoding used when generating the XML-file. But I will see if I can figure something out, trying to see if anything changes by adding a BOM

Back in the days with ASCII things were easy (as long as you didn't had to use special characters). Now there are multiple ways to encode text-files (ASCII, UTF-7, -8, -32 and what not). BOM (Byte Order Mask) is a 2, 3, or 4 byte binary-code in the beginning of a text-file that can be used by the programs reading those files (to know how the characters within that file were encoded). So when Notepad++ shows this character wrong, its a result of it not knowing the correct encoding of this character and why the .Net framework (that I am using to read/parse the XML) is complaining about illegal characters. Do you know how the XML-files you generate are encoded? I will later today try to do a test where I plan to add the BOM for UTF-8 (0xFE, 0xBB, 0xBF) in the front of the file and then see how it looks in Notepad++ and/or if it can be loaded by the .Net framework without it complaining - I'll let you know if/what I see.

Just an idea? Since Notepad++ did not show the char correct (reversed "xF6" in stead of "ö"), perhaps its just a matter of a missing/incorrect BOM (Byte Order Mask) in the beginning of the file? EDIT: I'm leaning towards the BOM. Just tried entering "ö" into a text-field and saved it to XML. The letter is not escaped in anyway, and it shows up just fine in Notepad++ (so BOM and/or the actual char encoding): <AirlineInfo ICAO="MOA" IATA="" Name="My öwn airline" ...>

In stead of "proper" encoding/escaping the content of the field-values, you could consider simply removing the "diacritics" (accents and so on) so an "ô" is simply changed into an "o". Here some C# code that does exactly that: EDIT: Sorry ... bad idea

Hi Pete I am guessing you are forming your own XML in stead of using a framework/library to do it, as a framework/library would normally take care of encoding/escaping the values. There are many values that cannot be written directly into XML-fields and needs to be encoded/escaped, e.g. an ampersand "&" should be encoded as "&amp;" and less-than "<" should be encoded as "&lt;" (the reason for why the ampersand on its own needs to be encoded).

Hi Pete, I have an issue where I cannot read the runways.xml generated by MkRwy version 5.11 as the generated XML contains an illegal char. It occurs for the airport EDLP. When loading the xml into Notepad++ the name of the city contains (shown in reversed colors, as its a "special" char) "xF6" where it below is show as the char "ö" ... <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> <SceneryName>fs-base scenery 0601</SceneryName> ...

A Danish guy contacted me regarding an error he got when using the the Delphi-port of the SDK. I had a look at it and and there is a small change that is needed since Delphi 2009. So if you plan to update the SDK at any time, in the file FPCuser.Pas in function "FSUIPC_Open" the "szName" variable need to be changed from "AnsiString" to "String". Hence from: Function FSUIPC_Open(dwFSReq : DWORD; var dwResult : DWORD) : Boolean; var szName : AnsiString; to: Function FSUIPC_Open(dwFSReq : DWORD; var dwResult : DWORD) : Boolean; var szName : String;

Yes and Yes. Every time you you perform a Read or a Write all you are doing is putting your requests into a buffer (and you can mix read and write as much as you want). When you call process, this buffer is transferred to FSUIPC, and if you have read requests the data you request are put back into this buffer by FSUIPC so they are available to you after the Process call have been executed.

Pete, isn't there a max of 0x7F00 bytes in the request-buffer (content of the memory-mapped file shared by the client and FSUIPC) or this is an old limitation?

Jeff I don't know the C++ implementation but from Delphi (which is also un-managed code) I would simply perform a single read implementation (e.g. read the number of bytes you need) into a byte-array, and then use simple pointer math to set the pointer to point at a specific position in this array, and then read the value you expect to find at that location (whether its a byte, short, int or whatever). So in stead of reading a single int (4 bytes) in a read operation you read 256, 512 ... whatever number of bytes you need. EDIT: Probably misread your question. You can have multiple reads for a single Process like this: char chTime1; char chTime2; char chTime3; FSUIPC_Read(0x238, 1, chTime1, &dwResult); FSUIPC_Read(0x239, 1, chTime2, &dwResult); FSUIPC_Read(0x23A, 1, chTime3, &dwResult); FSUIPC_Process(&dwResult); But in this case, the following is better (one read operation, reading 3 bytes) char chTime[3]; FSUIPC_Read(0x238, 3, chTime, &dwResult); FSUIPC_Process(&dwResult);

Thanks Pete that is great. Pelle

Hi Pete I don't know if it is the data (scanned scenery) or MkRwy, but as far I can tell it detects all runways as "Concrete". E.g. EKKA (vanilla scenery) both have Concrete and Grass runways, but MkRwy5 scanning MSFS scenery detects them all as Concrete. EDIT: Forgot to mention I am reading the content of Runways.xml

Just one idea, make sure your power saving in windows is not cutting power to USB-devices.

You are welcome Pete. It appears to be written using Qt (https://www.qt.io/). Anyhow I am glad to hear you are making progress despite the lack of proper (or any) documentation, and I don't envy any bit trying to find heads-and-tail is the mess 🙂

Hi Pete The source source should be easy to access. Just follow the last link I added for the navdatareader and press the green "Code" button (with the arrow pointing down) and choose "Download ZIP" in order to download a zip containing the source. Likewise for Little Navmap simply use this link, and same procedure: https://github.com/albar965/littlenavmap to get the source. I understand about others source vs. your own. I prefer my own also - probably why I am currently writing my own .Net FSUIPC connector 🙂 I am glad to hear you are making progress, but I hope that I will not be as complicated with Steam and DVD installs. I got my MSFS from the Microsoft store and while running Little Navmap it both detected my default scenery, the Fly Tampa EKCH addon bought throgh the marketplace, and the free Meigs Fields I have manually installed into my Community folder on my G-Drive.

Pete I don't know if it can kick-start the process, but I have just installed Little Navnap and it is able to scan the installed MSFS scenery (incl. RWY, TWY and Gates). Little Navmap is (C++) free open source !? https://albar965.github.io/ EDIT: Guessing this is the project for the scanner alone https://github.com/albar965/navdatareader

I see, thanks Pete. I was initially thinking of targeting SimConnect for what I am doing, but FSUIPC seems a lot simpler, as I don't have to deal with different versions of SimConnect. Glad John is now keeping the "family-tradition alive", and you are still in the loop 🙂 Pelle

Does 3rd party software connected to non-licensed FSUIPC's still require an accredited key, or is this a thing of the past (remember that FS-Interrogate used one). Pelle

Just to clarify, as of now I have not done any axis/button assignment via FSUIPC, and all my assignments are currently done within MSFS. But I guess FSUIPC will be affected by this bug as well.

Thanks Pete, and you are right regarding "FS2020" vs. "MSFS".

I don't think this have to do with FSUIPC. There is a bug in FS2020. If any of my 2/3 ways switches on my Warthog Thorttle are left in their on-position the headed-bug jumps in 10° interval, even if those 2/3 ways switches are not configured to do anything. As soon as I set the 2/3-way buttons to their off-position I can change the heading in 1° increments. This is both observed using the mouse to rotate the heading knob on the visual autopilot or if setting up a button on my joystick to change the heading bug.