Karli D

Thank you very much for your efforts. I think now I found a way to identify the loaded aircraft. As for now it works well and I hope I can work with it for a while.

The 0 terminator works now. Thank you, John. But... - really sorry for being such a pain in the backend - the variables are not accessible the whole time now. Can't tell if that was the case before. Now I get the values just while in the main menu, but when I load the flight, they're gone! The only way to get the values then, is to switch the aircraft via the dev menu or to go back to the main menu. Of course I understand, that this is not a priority thing. I think I will try to use the title variable to achieve, what I need - the designator thingy doesn't work for all aircraft tho. But anyway, thought I'll report the outcome to you. Thanks for your efforts.

Hi John, I came across strange behavior while reading offstes 09D21 and 0B26 (0618 will probably have the same issue, but didn't check that yet). Already discussed that with Paul Henty, and his guess is, that the 0 terminator isn't being written at the end of the string. The video explains what happens: Here's also the code - it's rather simple: public partial class Form1 : Form { private Offset<string> ICAOmanufacturer = new Offset<string>("Aircraft", 0x09D2, 16); private Offset<string> ICAOModel = new Offset<string>("Aircraft", 0x0B26, 32); public Form1() { InitializeComponent(); } private void Button1_Click(object sender, EventArgs e) { // Connect to FSUIPC try { if (!FSUIPCConnection.IsOpen) { FSUIPCConnection.Open(); button1.Enabled = false; } else { FSUIPCConnection.Close(); } } catch { // NO FSUIPC running } } private void Button2_Click(object sender, EventArgs e) { try { FSUIPCConnection.Process("Aircraft"); tbOutput.AppendText($"Manufacturer: {ICAOmanufacturer.Value}\r\nModel: {ICAOModel.Value}\r\n\r\n"); } catch(Exception ex) { tbOutput.Text = $"Exception: {ex.Message}"; } } private void Form1_FormClosing(object sender, FormClosingEventArgs e) { FSUIPCConnection.Close(); } } Something is messed up and I'm not able to read the manufacturer name and the model correctly. Thank you. -EDIT- I confirm that 0618 (ICAO designator) has the same issue. Most aircraft has a 4 letter/digits designator, so the issue doesn't show up. But the Icon A5 has a shorter designator and here one can see the issue also.

Thank you Paul, first I thought, that I messed up smthg in my code, as I'm working on a bigger project and there are already lots of forms, classes and stuff. I'm a pro at graphics, but not an expert programmer. Still learning new things every day, so I wasn't sure if it's not my fault. That's also the reason why I decided to go with the DLL client and not simconnect. I think it's a big help -> Can't thank you enough for making this possible btw and will definitely donate. So I'm a bit stuck at the moment, because I gotta identify the loaded aircraft and have a hard time to do that. Tried all the listed offsets private Offset<string> aircraftProfileName = new Offset<string>("AircraftID", 0x9540, 64); private Offset<string> AIRfilePathname = new Offset<string>("AircraftID", 0x3C00, 256); private Offset<string> ICAOdesignator = new Offset<string>("AircraftID", 0x0618, 16); private Offset<string> ICAOmanufacturer = new Offset<string>("AircraftID", 0x09D2, 16); private Offset<string> ICAOModel = new Offset<string>("AircraftID", 0x0B26, 32); private Offset<string> title = new Offset<string>("AircraftID", 0x3D00, 256); and found out, that the best way to identify the aircraft is 3D00. However, I gotta have a manufacturer and a model too to display it to the user. Unfortunately ASOBO, as well as third party devs don't really care much about keeping a straight line in naming their aircraft. In fact it's a totally mess! Sometimes the manufacturer name is missing completely, sometimes it's replaced by the dev name, sometimes it's at the beginning of the string, sometimes at the end. There's no structure at all in that. So I hoped the new offsets would help a bit to find a solution for that. Looking for the second double quote sadly doesn't work, as I already came across aircraft, where the second one is missing (for whatever reason). Ok, maybe it's the string length, gotta check that. Will report that to John.

Today I came across a very strange behavior trying to read offsets 09D2 and 0B26 (ICAOmanufacturer and ICAOmodel). I'm not sure if it's caused by the Client DLL or FSUIPC itself. Somehow... the string seems to keep the previous value and just overwrite it partially: The code is rather simple: public partial class Form1 : Form { private Offset<string> ICAOmanufacturer = new Offset<string>("Aircraft", 0x09D2, 16); private Offset<string> ICAOModel = new Offset<string>("Aircraft", 0x0B26, 32); public Form1() { InitializeComponent(); } private void Button1_Click(object sender, EventArgs e) { // Connect to FSUIPC try { if (!FSUIPCConnection.IsOpen) { FSUIPCConnection.Open(); button1.Enabled = false; } else { FSUIPCConnection.Close(); } } catch { // NO FSUIPC running } } private void Button2_Click(object sender, EventArgs e) { try { FSUIPCConnection.Process("Aircraft"); tbOutput.AppendText($"Manufacturer: {ICAOmanufacturer.Value}\r\nModel: {ICAOModel.Value}\r\n\r\n"); } catch(Exception ex) { tbOutput.Text = $"Exception: {ex.Message}"; } } private void Form1_FormClosing(object sender, FormClosingEventArgs e) { FSUIPCConnection.Close(); } } Do I oversee something?

You, sir, are a genius! 😀 Works like a charm! Thank you very much. 👍

Hi Roman, actually it does. Both of them do. Just not the whole time. For example 0x0230 doesn't respond while the sim is paused. But it works for now: https://youtu.be/htEFieeIYck But yeah, an offset would be better. Also FSUIPC handles the connection state way better, safer and faster...

Hi John, kindly asking if we could have as an offset? 🙂 Since FSUIPC7 is an executable on it's own and doesn't run inside the FS process, it also doesn't necessarily exits with MSFS (if someone unchecks the option). If MSFS exits and FSUIPC doesn't, I'm getting no more realtime-data from the offsets, but just the last readings over and over again. Being unable to check if MSFS is still running there is no difference to data that simply didn't change since last process. Actually I did a workaround by continuously checking changes in 0x0230 and 0x0274. So if both have no changes for a while, the sim connection is most probably dead. But I can't tell for sure. So it would be a big help to have an offset to monitor the connection state between FSUIPC and MSFS. Thank you.

Will do. Thank you, Paul.

Thank you, Paul. 0x0230 is a good workaround. Not perfect tho, as it stops sometimes - f.e. when the FS is paused, it delivers no change to the value, but still way better than anything I could find. I think with a combination of timestamp and framerate I'll be able to find out if FS is running or not. An offset that tells us the actual status of the connection between FSUIPC and MSFS would be indeed a niceToHave. 🙂

Hi, Let's say I'm reading two offsets (like fs version and framerate) again and again. By checking FSUIPCConnection.IsOpen I know if FSUIPC is still there. But how do I know, if the user has by chance closed MSFS and left just FSUIPC running? In such case I'm still getting values from last process, but can't tell if it just didn't change or if the sim has been closed. Already tried Offset.Reconnect() hoping to force FSUIPC to read from the sim and give me f.e. 0 for the fs version or maybe 0 for the framerate, but that didn't do the trick. Somehow I'm stuck...