Paul Henty

All keypress and button assignments should be recorded by FSUIPC. You should only need to program the buttons/keys once. After that, every time you load P3D, FSUIPC will automatically load in the assignments and they should work as before. Paul

Hi Mac, Your link doesn't work. Can you try posting it again please. Paul

I can't see anything in your code which would cause it not to work. It's probably down to XPUIPC not implementing the move feature. For this feature, the dll writes the Airspeed and OnGround flag to a special offset specifically for used for setting the aircraft initial position. This triggers FSUIPC to make a special SimConnect call that sets the new position of the aircraft. XPlane of course doesn't use SimConnect so it would be down to the authors to translate that to the XPlane equivalent (or fake it if there isn't one). So my guess is that they haven't implemented that particular offset. If XPUIPC is still being developed you could ask for a fix. (It's offsets 0x0558 and 0x55C which are not working). Otherwise, the you could try writing the Lon/Lat/Alt etc using the normal offsets (0x0560/0x0568/0x5070 etc). You might find this more basic and direct approach works, rather than using the 'special' SimConnect move feature. Paul

Hi Ruediger, Your code works okay for me. Make sure you've got the latest DLL (3.1.11). Does it work using different airports in the hashset? or does it break with any? Paul

Hi Gerard, Version 3.1.11 is now available. This fixes the rounding problems in the payload services for Kgs. In my testing it's much better. On the Cessna 172, changing between 100% fuel and 25% fuel, the empty weight would change by ~1kg. Now it's only 0.08kg. I can't get it perfect as FSUIPC gives the fuel tank levels in volume not weight. So there is always going to be some small rounding error going from gallons to lbs. Paul

I'm not really sure what's causing this then. I would put some messages (Debug.WriteLine) in your code to see the timing and the order in which your methods and events are being called. That might give you a clue as to what's going wrong. Generally, it sounds like UDPConnection.UDPDataReceived is being fired too quickly and FSUIPC/FSX just can't keep up with the requests to change the transponder code. Paul

Hi Gerard, Yes, I think I can see why. The empty weight is calculated by subtracting the total fuel and payload from the Gross Weight. All of the weight values are stored in lbs. To get kg they need converting. At the moment that conversion is done for every fuel tank and payload station. This means the small conversion errors for each tank/payload station will add up to something noticeable. I'm not sure why I did that, but in the next few days I will improve this by just converting once at the end. This should improve things. I'll let you know when a new Beta version is ready for your to test. I think this is just down to the time taken for the payload data to arrive at the sim. The DLL sends the data to FSUIPC, which then has to prepare SimConnect calls and pass the data to the sim. Once the sim receives these it has to change the active payload values. This is all going to take a bit of time, so reading the value back too soon won't be accurate. I would think it's unnecessary anyway. If you're just trying to check that your values have been written properly, then it's reasonable to add the delay to give all the steps time to complete. Paul

Hi Robert, It's a bit difficult to tell from the code you've posted. One thing I'm not clear on is where the process() is happening. I would expect it to be in SetTransponder() after the value is set. If your process() call is elsewhere (like on a separate timer loop) then it's probably that the UDPDataReceived event is firing faster than the Process() calls. So it's going something like this: FSUIPC_TransponderCode.Value = 1 Process() FSUIPC_TransponderCode.Value = 2 FSUIPC_TransponderCode.Value = 3 FSUIPC_TransponderCode.Value = 4 Process() In that case you would only see 1 and 4 set in the sim, Do you mean the local variable (FSUIPC_TransponderCode.Value)? That will just hold a copy of whatever you've set it to locally. Or do you mean you've done a Process() call to get the current value back from FSUIPC? Paul

Here's the required code in VB with your control names... Dim airports As FsAirportCollection = FSUIPCConnection.AirportsDatabase.Airports ' 1. Get the airport from the database using the ICAO code... Dim airport As FsAirport = airports(Me.txtICAO.Text.ToUpper()) ' 2, Get the selected helipad ID from the combo box Dim helipadID As String = Me.cbxHeli.Text ' 3. Try to get the helipad using the ID Dim helipad As FsHelipad = airport.Helipads(helipadID) ' 4. Make sure we got one back... If (helipad IsNot Nothing) Then ' 5. Pass this to MoveAircraft FSUIPCConnection.MoveAircraft(helipad, True) ' move aircraft To helipad And leave paused. ' Or call the helper method on the helipad... ' helipad.MoveAircraftHere(true) ' move aircraft to helipad And leave paused. End If That should work. You can use the same process with runways and gates. Paul

Hi Padraig, The easiest way is to get the FsHelipad object for the required helipad. You can either call the MoveAircraftHere() method on that helipad, or pass the helipad directly to FSUIPCConnection.MoveAircraft(). How you get the FsHelipad object depends on how you've populated the combo box. If you've just filled the combo box with the text IDs then you need something like the following code: // 1. Get the airport from the database using the ICAO code... FsAirport airport = FSUIPCConnection.AirportsDatabase["EGLL"]; // 2, Get the selected helipad ID from the combo box string helipadID = this.cbxHelipads.Text; // 3. Check it exists at this airport if (airport.Helipads.Contains(helipadID) { // 4. It does, so get the FsHelipad object using the ID FsHelipad helipad = airport.Helipads[helipadID]; // 5. Pass this to MoveAircraft FSUIPCConnection.MoveAircraft(helipad, true); // move aircraft to helipad and leave paused. // OR call the helper method on the helipad... // helipad.MoveAircraftHere(true); // move aircraft to helipad and leave paused. } If you've populated the combo boxes directly with the FsHelipadCollection then you need to get the fsHelipad from the combo box. Something like this... // 1, Get the selected helipad from the combo box if (this.cbxHelipads.SelectedItem != null) { FsHelipad helipad = (FsHelipad)this.cbxHelipads.SelectedItem; // 2. Pass this to MoveAircraft FSUIPCConnection.MoveAircraft(helipad, true); // move aircraft to helipad and leave paused. // OR call the helper method on the helipad... // helipad.MoveAircraftHere(true); // move aircraft to helipad and leave paused. } If none of that helps, please show me the code that populates one of your combo boxes and I can give you the exact code. Paul

Hi Frazer, Yes the change in behaviour is because of the code revision in 3.1.6 Beta. Write-only offsets now write every time, regardless of whether they have been changed or not. So it's not ideal to put them in a group with read/write offsets. 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. If the pushback is starting then there must be a process() before the value is set to 3. It's writing the initial 0 value now. With 3.1.5 it wouldn't do that. There are two things you can do: 1. Make sure that group is not processed before the value 3 is set. 2. Put the pushback control in its own group and only process() it when you want pushback to start/stop. I recommend 2. With option 1 it will work but you're always going to be writing the pushback control value. While FSUIPC will probably be okay with that (it probably ignores the value if it's the same as the current pushback status) it's just a waste of a write. Paul

The DLL thinks the connection is still open because you're not doing any process() calls. Because of the way FSUIPC works, the DLL can only know that P3D has been closed by trying to talk to it. During a process(), if the sim is not answering then the DLL knows the 'connection' is lost. Only then will the IsOpen flag be set to false. Unless you call Process() there is no attempted communication with P3D. If you need a good starting point for an application with the automatic connection handling already written, please check out the FSUIPC application templates available on the website... http://fsuipc.paulhenty.com/#downloads Even if you don't use them as templates, you can see the best way handle the connection and main program loop by looking at the code. Paul

Looks like you forgot to paste the code in. Paul

It would be best for you to repost your question in Pete's main support forum: https://forum.simflight.com/forum/30-fsuipc-support-pete-dowson-modules/ This is a sub-forum about using FSUIPC with .NET programming languages. Pete might not see your post here and I don't know enough about LUA to answer your question here. Paul

Hi Robert, As Pete mentioned, with this old-style C# SDK you make multiple calls to Read(), then Process(), then multiple Get()s to get the values. The key is the 'token' value which is assigned during the Read() and then used to by the Get() to return the correct value. So to give you a real example... // Declare 'tokens' int tasToken; int iasToken; int verticalSpeedToken; // Declare variables to hold the incomming values int tasValue; int iasValue int verticalSpeedValue; // Variable to check is everything was okay int dwResult; // Stack all your reads first (writes can also be stacked) // Tokens will be assigned a value by the Read() method. fsuipc.FSUIPC_Read(0x02B8, 4, ref tasToken, ref dwResult); fsuipc.FSUIPC_Read(0x02BC, 4, ref iasToken, ref dwResult); fsuipc.FSUIPC_Read(0x02C8, 4, ref verticalSpeedToken, ref dwResult); // Single process will get all the stacked offsets fsuipc.FSUIPC_Process(ref dwResult); // Get the values fsuipc.FSUIPC_Get(ref tasToken, ref tasValue); fsuipc.FSUIPC_Get(ref iasToken, ref iasValue); fsuipc.FSUIPC_Get(ref verticalSpeedToken, ref verticalSpeedValue); // 'Value' variables are now filled. double tasKnots = (double)tasValue / 128d; // ... etc It's not pretty, which is why I wrote my DLL. I think the original C interface is cleaner than this. The 'Tokens' seem to be unique to the old C# and VB.NET SDKs because those languages don't have the concept of 'pointers' like C. Paul

Hi Agoston, The solution depends on how A2A have coded the aircraft. If it's using the standard FS facilities then you should be able to find the info in one of the offsets. For example, if it's tuning the NAV2 radio in the background you could check the DME2 distance (0x0C33), the DME2 Lat/Lon (0x0834 & 0x0838), or maybe the VOR2 Lat/Lon (0x0858 & 0x0860). There a few other such offsets near those so have a look at the offsets list. If it's not setting the NAV2 or NAV1 radio then FSUIPC won't be able to help. In that case you'll need to ask A2A if you can get access to any of the information (e.g. Via LVARS or some other method). If you can at least get hold of the frequency you have tuned then you can query a database of NAVAIDS (with Frequency and Lat/Lon) if you can find one. Unfortunately neither FSUIPC nor my DLL can help with such a database. If you manage to get the location of the tuned NAVAID you can use FsLatLon class to calculate the distance. Paul

Hi Ruediger. Sample code below showing the declarations. Tested on FSX Steam Edition. ' CameraSetRelative6DOF offsets. 0x86A0 MUST be declared last Dim Camera_H As Offset(Of Single) = New Offset(Of Single)("SetCamera", &H86B4, True) ' Heading Dim Camera_B As Offset(Of Single) = New Offset(Of Single)("SetCamera", &H86B0, True) ' Bank Dim Camera_P As Offset(Of Single) = New Offset(Of Single)("SetCamera", &H86AC, True) ' Pitch Dim Camera_Z As Offset(Of Single) = New Offset(Of Single)("SetCamera", &H86A8, True) ' Z Dim Camera_Y As Offset(Of Single) = New Offset(Of Single)("SetCamera", &H86A4, True) ' Y Dim Camera_X As Offset(Of Single) = New Offset(Of Single)("SetCamera", &H86A0, True) ' X Private Sub btn6DOF_Click(sender As Object, e As EventArgs) Handles btn6DOF.Click ' Values can be set in any order ' Example: Centre Camera but look out of Left Window Camera_X.Value = 0 Camera_Y.Value = 0 Camera_Z.Value = 0 Camera_P.Value = 0 Camera_B.Value = 0 Camera_H.Value = -90.0 ' Heading -90 degrees relative to the cockpit (Left Window) FSUIPCConnection.Process("SetCamera") End Sub Paul

It's the one that goes in the Sim. In the Modules folder. (Backup or rename your current one in case you need to go back). Paul

Hi Matthius, Just to let you know... John Dowson has been investigating this and got the same problem as you. He's made a fix in FSUIPC5 so FSUIPConnection.SendKeyToFS() should work with his new version. The details are here if you're interested: Paul

Hi John, Thanks for looking at this. I don't have P3D so I can't give you any feedback on it, but it sounds like you've seen exactly the same problem and fixed it. Paul

Great. Thanks for checking. Paul

Hi Pete, One of my users is having problems with restoring focus to P3D (V4.4) from my DLL. I don't have P3D so I can't test it myself. My DLL makes use of control 1125 (Key Focus Restore) which works fine for FSX. The user experiences a flashing P3D icon in the task bar, but the P3D window doesn't actually get focus or jump to the foreground. The P3D window is not minimised. Can you please check this in FSUIPC5 and see if it works okay? My user has solved the problem using Win32 calls to ShowWindow and SetForegroundWIndow but I'd rather stick to issuing the FSUIPC control if possible. Thanks, Paul

I'm glad you got it working. It seems like the focus feature in FSUIPC isn't working properly for P3D. I'll discuss it with Pete. Thanks for the DLL import code. Paul

It's not clear to me if you've tried the new version of the dll (3.1.9). Does it not work? If not, then it's possible there's something different about P3D when switching focus. I don't have P3D so I can't test it here. It works fine on FSX. Your video shows that P3D isn't getting focus properly. It should come the foreground above your application. I don't know why it's just flashing. Here is the code to switch focus to the flight sim: SendControlToFS(FSUIPCControl.Key_focus_restore, 0); You can try this on its own and see if P3D gets proper focus or not. If this also gives you a flashing icon without proper focus then we'll have to ask Pete about this. Paul

It sounds like the focus is taking longer than the dll expects. I've increased the wait time from 150 to 300 ms and released 3.1.9-beta. Please upgrade via Nuget and let me know if it fixes the problem. (To get beta versions you need tick the box called 'include pre-release' in the nuget manager). Paul