Paul Henty

Yes, the checking for changing values has also changed. Before it was sometimes writing when it shouldn't and causing problems for some users. Now it compares the current and previous values so you can't write the same value twice with a read/write offset. If you need to do that you should be using a write-only offset in a named group. The SendControlToFS() is easier to use than manually writing to those offsets. The DLL uses those offsets behind the scenes anyway so it's not really any different. I've no plans to publish the source code at the moment. Paul

Hi Sebastian, The main change was that offsets marked as write-only now write every time you process them, even if you haven't set a new value. It sounds like your offsets for sending the events/controls were marked as Write-Only. I had to change this because for some offsets you need to set the same value as before. The DLL didn't see this as a change in value so the offset didn't get written the second time. There were also problems if you wanted to write a 0 as the first value. Because the initial value is 0 you couldn't write a 0 as the first value. With the new behaviour, you need to put write-only offsets into a named group and only process them when you need to send the new values to the sim. Offsets the are not marked as Write-Only work the same as before. They read unless you've set a new value; then they will write. Paul

Those new offsets in FSUIPC5 won't work with the FsFrequencyCOM class. The documentation says that the new offsets store the frequency in Hz rather than the old BCD format. So you just need to read the offset as a normal Int and divide by 1,000,000 to get the frequency in the more common Mhz units. The frequency helper classes was added to help people with encoding and decoding to/from the old BCD format. Because the new offsets are not in BCD I can't really add support for them in the same class in a way that makes sense. The new format is very easy to use now so there really isn't a need for the helper class any more. Paul

Further to Pete's reply, the DLL facility is just a wrapper over the joystick scanning facility in FSUIPC provided at offset 0x2910. As Pete says, this can only read real Joysticks 0-15. I can see offset 0x3340 deals with Virtual joysticks but there is no wrapper in the DLL for this. You'll need to access this offset directly. I recommend declaring an offset of type BitArray (4 bytes) for each Joystick. Then you can directly access each bit (button) as being 'true' or 'false' without needing to do bitwise masking. Each joystick will be at increments of 4 from the base offset of 3340. e.g. 3340, 3344, 3348, 334C etc... Paul

There is Aircraft Model which you could use in addition to the Aircraft Type... private Offset<string> aircraftModel = new Offset<string>(0x3500, 24) There is also Aircraft Name. This often includes the livery as well. private Offset<string> aircraftName = new Offset<string>(0x3D00, 256); The contents of these offsets depends on what the developer of the aircraft has written in the Aircraft.cfg file. Paul

Hi Quinch, This code doesn't look correct to me: string aircraftData = "({ATCID} - {ATCTYPE })"; It should have a $ in front of the string to use variable concatenation. At the moment this string would have the value "({ATCID} - {ATCTYPE })". You don't show your output code, but I suspect it's not outputting the 'aircraftData' string but something else. The code below works. You can try it for yourself and change it to fit into your code: private Offset<string> aircraftType = new Offset<string>(0x3160, 24); private Offset<string> aircraftID = new Offset<string>(0x3130, 12); private void Button6_Click(object sender, EventArgs e) { FSUIPCConnection.Process(); string ATCID = aircraftID.Value; string ATCTYPE = aircraftType.Value; string aircraftData = $"({ATCID} - {ATCTYPE})"; MessageBox.Show(aircraftData); } Paul

Hi Pete, This is going to be a specific issue with using my DLL (or C# programming). I'll investigate further and help the OP. In the mean time it's best to move it to my sub forum. Thanks, Paul

Hi Emerson, I'm glad to hear you got it working. Congratulations on creating your landing gear product, and good luck with it. Paul

I'm not sure an infinite loop is the best way to do this. You might have better performance using the event system. This monitors the LVar values in the background and fires an event when they change. Here's an example from another user... writeN1(varname, value) ipc.writeUB(0x66C0, value) end event.Lvar("B200CFuelCrossfeed", 100, "writeN1") writeN2(varname, value) ipc.writeUB(0x66C1, value) end event.Lvar("B200CRvsNotReady", 100, "writeN2") writeN3(varname, value) ipc.writeUB(0x66C2, value) end event.Lvar("B200CLBld", 100, "writeN3") writeN4(varname, value) ipc.writeUB(0x66C3, value) end event.Lvar("B200CRBld", 100, "writeN4") You declare a function that sets the value to the offset and then register this with the event system (event.Lvar). See the FSUIPC Lua docs for full details but in summary the call is: event.Lvar(lvarName, polling_interval_in_ms, function_to_run) If you prefer you can make only one function that is called by all the events. This would need to test the LVAR name (varname argument) and write to the correct offset. I don't know about the logging as I don't use lua at all. You'll need to ask Pete about that in the main support forum. Paul

Good to hear that worked. These are the only official user offsets. However, if your application is only for your use you can try using the blocks marked as reserved. These are allocated to third-party software. For example 0x04E0 (88 Bytes) is for Project Magenta software. If you don't use that then you could try that block. Or there is a block from 0x6420 to 0x65EC (640 bytes) which is for PMDG aircraft if you don't have those. If your software is for general release (free or commercial) then you need to ask Pete (in the main support forum) for some offsets to be allocated for you so you don't clash with other software. Paul

Hi Agoston, That's what the DLL does when you call ReadLVAR(). It's just a nicer way of using the offsets provided. Yes only one LVAR can be read or written for each process() call. That's just how FSUIPC works with LVARS. When you use ReadLVAR() in the DLL it does a process call. When you need to read a lot of LVARS then the time adds up. On my machine with FSX and default aircraft it takes about 20ms to get one LVAR. So reading 25 lvars will take half a second for me. No it won't make it faster. FSUIPC communicates on a single thread. The DLL is 'thread safe' which means if you use it from multiple threads and nothing bad will happen. But each thread will have to wait for the others to make Process calls. Only one thread can be talking to FSUIPC at a time. You could look into SimConnect. It's not very easy to use from .NET languages and the documentation is very poor for .NET. It might let you read LVARS faster, but I don't know. The LUA scripting in FSUIPC also allows you to read LVARS and also monitor them for changes (an LUA event is fired). You could write a LUA script to monitor your LVARs and send the values to user offsets where you can read them from your program. LUA scripts can only be run with a licensed copy of FSUIPC however. Documentation for the LUA library can be found in the Modules/FSUIPC Documents folder. Paul

You've declared the offset as an unsigned integer. That's why you are not getting negative values. private Offset<uint> verticalspeed = new Offset<uint>(0x02C8); My code again: private Offset<int> verticalSpeed = new Offset<int>(0x02C8); // 4-byte offset - Signed integer  That will fix it. Paul

You can post in the main support forum here: https://forum.simflight.com/forum/30-fsuipc-support-pete-dowson-modules/ BUT: There would be no point if my Example Application shows the correct value. Please try that first. If that works then your code is wrong, not FSUIPC. If you post the relevant parts of your code here I can check it very quickly. I can't help much without seeing the code. Paul

The code I posted works fine with FSUIPC4. I've test both 02C8 and 030C. Are you using the code above unchanged? If not, I'll need to see your offset declaration and the code where you read, convert and display the value. You should also try running the Example Code application and going to the form called "BC003: Reading and Using Offsets" under the Basic Concepts node. If this shows large values instead of negatives then you'll need to contact Pete in the main forum as something is wrong with your FSUIPC. Paul

The code below is taken from the 'Example Code' solution. It works fine for vertical speed (02C8). You can download this from the website: http://fsuipc.paulhenty.com/#downloads private Offset<int> verticalSpeed = new Offset<int>(0x02C8); // 4-byte offset - Signed integer protected override void timerMain_Tick(object sender, EventArgs e) { // Call Process() to get the data from FSUIPC FSUIPCConnection.Process(); // -------------------- // VERTICAL SPEED // -------------------- // FSUIPC Documentation says this offset is 4 bytes, signed (int) and holds the speed as metres/second * 256 // We need to convert back to metres/second by / 256 // Offset is 'int' so cast to double for conversion. double verticalSpeedMPS = (double)this.verticalSpeed.Value / 256d; // If you want to display as feet/minute a further conversion is required: double verticalSpeedFPM = verticalSpeedMPS * 60d * 3.28084d; // Display one of these on the form (this time rounded to 0dp) // this.txtVerticalSpeed.Text = verticalSpeedMPS.ToString("F0"); this.txtVerticalSpeed.Text = verticalSpeedFPM.ToString("F0"); } 030C is a copy of this offset, but it's not updated on the ground. It should work exactly the same as 02C8. Just change the offset in the declaration. Paul

Hi Emerson, The chkAvionicsMaster_CheckedChanged method is for reacting to when the user ticks the checkbox on the screen. I think what you want is to react to the things changing inside the flight sim. Your code should therefore go inside the Timer_Tick(). After the Process() call you can text the current value of the master avionics switch. You can then turn your light on or off. Something like the code below: (The code is placed after the existing line to update the on-screen checkbox): I don't know what you need to send to the serial port but I assume you do... // 2. Master Avionics this.chkAvionicsMaster.Checked = avionicsMaster.Value > 0; if (serialPort1.IsOpen) { if (avionicsMaster.Value > 0) { // Master switch is ON. Send command to turn on the light serialPort1.WriteLine("1"); } else { // Master switch is OFF. Send command to turn off the light serialPort1.WriteLine("0"); } } Note that this timer runs 20 times per second. If it's a problem sending data to the serial port that often then you'll need a variable to remember the last value of the Avionics Master switch. If the current value is the same as the last then you don't need to resend the same command to the serial port. For the landing gear you need to declare the offsets to read the gear position (See Offsets 0x0BEC, 0x0BF0 and 0x0BF4). Then in the timer, check the values and determine if the gear is up, down or in transit. Then send the commands to your serial port to turn the lights on/off. Paul

You're searching through the entire list, overwriting the results for each one. So you end up with the results for the last item every time. This might work if you only have one airport in range, but if there are more it won't work. You need to do something like this: ' Find Closest Airport that doesn't start with X Dim closestAiport As FsAirport = airports.Find(Function(ap) Not ap.ICAO.StartsWith("X")) ' Test if this is the Dept or Arrival Noairportlbl.Text = "Not in any airport" If (closestAiport IsNot Nothing) Then If closestAiport.ICAO = getDeptICAO Then Noairportlbl.Text = "" GreenText1.Value = "You are at your departure location!" GreenText2.Value = 10 ElseIf closestAiport.ICAO = getArrivalICAO Then Noairportlbl.Text = "" GreenText1.Value = "You are at your destination location!" GreenText2.Value = 10 End If End If Paul

Yes you can use offsets 0x3380 and 0x32FA. See the offsets documentation for details, but in summary: Declare an offset for 3380 (string with length 128) Declare an offset for 32FA (Short) It's important they are in this order. 3380 must be declared first. Mark them both as write only and put them in their own group (e.g. SendText). When you want to write text: set the text in 3380. Set 32FA depending on how to want the text displayed (see the docs). Process the "SendText" group. Paul

Okay but the fake XWSS airport is still in index 0. If you use index 1 for other airports it won't work. That's why you need to search through the array to get the first ICAO that doesn't start with X. Paul

FSX and P3D do not simulate passengers. If you have GSX and want to track GSX passengers then I think there are L:Vars you can access. I don't have GSX so you'll need to ask in their support forums. Or they may have an SDK you can download. Paul

Is your plane at Singapore Changi airport? Do you have third-party scenery (add-on) for that airport? If 'yes' then It looks like the scenery developer has put a fake airport in. Is there anything at index 1? airports(1).ToString() If that has the correct airport then you'll need to go through each runway in the array and look for the first one that doesn't begin with an X. Paul

Yes. Just use the code in DB003_FindingAirportsInRange. Ask for airports within 5km airports.InRangeOfKilometres(5). If you get any back and the aircraft is on the ground then you can assume that the player is at that airport. Paul

Hi, This is fairly easy if you're using version 3.x of my DLL. Have a look at the Example Code application, under "Airports Database", form "DB003_FindingAirportsInRange". If you don't have the Example Code application you can download it from the website: http://fsuipc.paulhenty.com/#downloads You can amend this example easily to find if an airport close enough so that the player is 'at' the airport. For example within 5km. (And check if the player is on the ground). Paul

Hi Ruediger, The first thing to try is to increase the timeout for weather reading. In the Sample Projects I set them to 2000ms. (See Code Below). Try increasing this to something like 10 seconds. If it works you'll be able to see how much time it takes for the weather to be read. I only have FSX. Maybe P3D takes a bit longer to provide weather to FSUIPC. Paul private void btnGetWeatherAtAirport_Click(object sender, EventArgs e) { // Using a try catch block as the service will time out if the weather station is not active // This could be because the IACO is not valid, or it is out of range and therefore inactive WeatherServices ws = FSUIPCConnection.WeatherServices; // The time out can be changed. Here it's set to 2 seconds. This is usually enough time for weather data to be returned. ws.LocationReadTimeout = 2000; // <<<<<<<<<< TRY SETTING A LONGER TIMEOUT try { FsWeather weather = ws.GetWeatherAtLocation(this.txtICAO.Text.ToUpper()); displayWeather(weather); } catch (Exception ex) { MessageBox.Show(ex.Message, "FSUIPC Examples", MessageBoxButtons.OK, MessageBoxIcon.Exclamation); } }

It's difficult to see what's happening when I don't have the complete code. At the moment I suspect that the sim rate is being written more often than you want. You can confirm this by using the logging in FSUIPC. If you enable the logging for 'IPC Writes' and send the log to the console you will be able to see when the sim rate is being written. We can find out for sure if the sim rate is being 'spammed' (sent over and over again), or if it just gets written once when your program calls SetSimRate(). Thanks, Paul