Paul Henty

Version 3.1.15 BETA is now available on NuGET. Remember to tick the 'Include Pre-release" box so that the beta version will show up. After Process() you can now check the ValueChanged property on any offset to see if the value is different than the last time it was processed. Also, if an offset was written in the last Process() then ValueChanged will be set to true. Paul

Okay, I'll add this in the next day or two. For your flaps question: Yes, a Sleep will block the rest of your program, so don't do that. I would set up a bool variable called FlapsInMotion. This starts off a false. When it's false you look for any change in flap position. When you detect this you set FlapsInMotion to true. When it's true you look for that value to stop changing (same as previous value). Then you set FlapsInMotion back to false and give the update on the new flap position. This way you don't need to sleep, it all happens in the main timer loop. You're just doing different checks depending on what's happening with the flaps. Paul

Hi Jason, I could add a property to the offset class to tell you if the value was changed at the last Process() call. Would that be of use? You wouldn't be able to get the previous value, just know if it changed. Something like: FSUIPCConnection.Process(); if (this.myOffset.ValueChanged) { // Tell the user } The problem I can see with this is that you won't be able to decide how much of a change to respond to. For example, your program may not care about a change in 1 foot of altitude, just maybe 100ft. If knowing the previous value is important, or you need to be able to specify minimum changes, then the easiest way is just as you described. Just have a set of variables storing the previous values and test them applying your minimum thresholds. Paul

There's no discount when upgrading from FSUIPC4. If you also bought WideFS you don't need to buy that again, just a FSUIPC6 licence. Paul

Hi Martin, The MoveAircraft() method uses the "Initial Position" feature in FSUIPC that makes sure the scenery, weather, atc etc gets reloaded. This is normally used for things like instructor stations that get you set up for an approach to a selected airport. You would want everything reloaded in that case. If you don't want to reload the scenery etc, then you can write directly to the Aircraft Longitude, Latitude, Heading, Altitude offsets etc. Example using just Lon and Lat: Declare offsets.. private Offset<FsLongitude> playerLon = new Offset<FsLongitude>("Position", 0x0568, 8); private Offset<FsLatitude> playerLat = new Offset<FsLatitude>("Position", 0x0560, 8); Move aircraft... this.playerLat.Value = lon; // lon here is an instance of FsLongitude this.playerLon.Value = lat; // lat here is an instance of FsLatitude FSUIPCConnection.Process("Position"); // Instant move, no reload. Paul

Not without losing focus, no. The DLL has a method FSUIPCConnection.SendKeyToFS(). There are some overloads that take a reference to a form in your application to return the focus to. e.g. The following line will: 1. Send a request to FSUIPC to fire an 'm' key press. 2. FSUIPC will make FSX the active window then send the 'm' key press 3. The DLL will then return focus to your form FSUIPCConnection.SendKeyToFS(Keys.M, this); The round trip for this is about 300ms, so you might see a flash as the FSX screen comes to the foreground. I suggest trying it and seeing if it's acceptable. If it must be done by a key press then this is the best that can be done. The way Windows works, only the foreground (focused) window can read the keyboard buffer. It's impossible to send a key press to a specific window that isn't in focus. Windows only has a single, global, keyboard buffer and only the focused window can read it. The alternative would be if ADE can use another method to receive instructions. e.g. if it responds to custom FSX controls (also known as 'events'), or values written to FSUIPC offsets. These can be used while the FSX window is in the background. But, this would require that the authors of ADE have built in such a feature and are listening for these signals. You would need to ask the authors or see if there is anything in the documentation. Paul

It's just the way LVARs are read and written from an external program. The FSUIPC external interface can only process one LVar at a time. So each LVar requires a complete data exchange cycle (Process() Call). This takes time so reading 20 or more Lvars in real time isn't very practical from an external program. This doesn't apply to normal Offsets of course, just LVars. Yes, both require FSUIPC. Lua needs a paid (registered) copy. External programs can use a free (unregistered) copy. This seems like the sort of thing the Lua system was intended for, but I can't say how easy it would be; I'm not a Lua expert and don't do anything with hardware. If you have a registered copy of FSUIPC I would try Lua first and see if you can get a switch and a LED working. Paul

Hi Peter, The two technologies are used for different kinds of tasks, so It really depends on what your program will do. Generally Lua can be thought of as a way of writing 'plug ins' that extend the functionality of FSUIPC. Typical uses are driving hardware connected to the sim monitoring the flight, looking for certain conditions then taking actions (e.g. play a cabin announcement at the right time) creating functions that can be bound to buttons/keys (e.g. set fuel to 80% when a key is pressed) creating simple display windows to show information from the sim. (e.g. calculate time until fuel runs out and show it in a window in real time). Using the DLL in an external program is better (or required) if any of these are true: you need a complex user interface where users need to interact with your application (selecting menus, filling out forms etc, drawing charts) the application needs to do other things beside interacting with FSUIPC (e.g. has a flight planner than plans routes) the application will require hundreds of lines of code (debugging and code organisation is much easier in Visual Studio) Other considerations: Lua scripts can only be run on a registered copy of FSUIPC. An external program can be used with an unregistered copy. If you want others to use your program this might be a consideration. If you need to access many L:Vars (Panel Variables) Lua is much more efficient for this. Hopefully that helps. If you're still unsure let me know what your program will be doing and I can give more specific advice. Paul

Hi Jason, Unfortunately you won't be able to use my DLL in a UWP application. UWP Apps are run in a sandbox and do not have access to the full Win32 API. This API is what FSUIPC uses to communicate with all the flight sims as they were written as windows 'desktop' applications. A UWP app therefore will not have the means to communicate via FSUIPC. You might be able to use the managed SimConnect library in UWP as this uses standard network protocols rather than WIn32. But I don't know for certain as I'm not that familiar with SimConnect. If you want to stick with FSUIPC and use my DLL (which is much easier than SimConnect) you'll need to choose between WinForms or the newer, more modern-looking WPF framework. Paul

Gauges can't be created with C# unfortunately. You would need to use C++ or XML. Paul

I don't know any way to accept a string input inside of the Flight Sim. I don't think that's possible. You would have to do this on a form or message box in your own application. You can respond to key presses in the sim. So you could display a list of options and then wait for the user to press the appropriate key (or key combo) in the sim. See the example code application under 'Input Services', specifically IS001_KeyPresses. Paul

Yes the DLL is written in C# so I would be able to paste your function in. If you'd like to paste it here, or send it in a private message, I'll consider including it in the DLL. Thanks, Paul

Hi Matthias, Yes it's possible. I've included some code below (VB and C#). Call this new function (ReadLVarWideFS) in the same way as you call FSUIPCConnection.ReadLVar(). It works by reading the value some milliseconds after the normal ReadLVar is called. This gives time for WideFS to see the change and update its cached value for the user offset. This obviously slows things down a lot. On my system here a 150ms delay produces reliable reads. You'll need to experiment. Maybe your system can use a lower value, or maybe, if you have a lot of other WideFS traffic, or lots of add ons, or a slower PC, you might need to increase this time. C# private Offset<double> lvarData = new Offset<double>("LvarData", 0x66F8); private int WideFSLVarDelay = 150; private double ReadLVarWideFS(string LVAR) { FSUIPCConnection.ReadLVar(LVAR); Thread.Sleep(WideFSLVarDelay); FSUIPCConnection.Process("LvarData"); return lvarData.Value; } VB.NET Private lvarData As Offset(Of Double) = New Offset(Of Double)("LvarData", &H66F8) Private WideFSLVarDelay As Integer = 150 Private Function ReadLVarWideFS(LVAR As String) As Double FSUIPCConnection.ReadLVar(LVAR) Thread.Sleep(WideFSLVarDelay) FSUIPCConnection.Process("LvarData") Return lvarData.Value End Function Paul

If you are upgrading from version 2, then there are a few breaking changes, but nothing major. Also the DLL is now delivered as a Nuget package. There are instructions and a video on my website about upgrading from version 2. http://fsuipc.paulhenty.com/#help Let me know (new thread please) if you have any problems. Paul

Hi, First you need to decide which Offset you are going to write to. There is a block of unused offsets starting at 0x66C0. Also decide how many bytes you need for the value and what data type you want. Then declare this offset. For the seat belt status we only need one byte so we'll declare it like this: Private pmdgSeatBelt As Offset(Of Byte) = New Offset(Of Byte)("PMDG", &H66C0, True) Then, to read the LVAR and copy the value into that offset you do this: (I don't know that the actual LVAR name is - I've just made something up here). ' Read the LVAR Dim seatBeltSwitch As Double = FSUIPCConnection.ReadLVar("L:SeatBeltSelector") ' Write value to user offset pmdgSeatBelt.Value = CByte(seatBeltSwitch) FSUIPCConnection.Process("pmdg") However, do you really need to copy it into an offset? You already have the LVAR value when you execute the first line (value is in seatBeltSwitch). Also, reading LVARs is very very slow compared to offsets. You should only use LVARs as a last resort. The PMDG 737 (and other PMDG aircraft) have a special set of offsets. You can find these in the PDF file in the "Modules\FSUIPC Documents" folder. e.g. "Offset Mapping for PMDG 737NGX.pdf". The offset for the 737 seatbelt selector would be declared as: Private PMDG_737_FastenBeltsSelector As Offset(Of Byte) = New Offset(Of Byte)("PMDG_737", &H649F) See the document for how to enable these offsets. I recommend using these offsets instead of LVARs where available. Paul

You'll probably need to ask XPUIPC support. For this to work XPUIPC would need to support the new 64bit FSUIPC interface (UIPC64_SDK_C_version2 in the FSUIPC SDK). Paul

@Patrick Weber That's great. Thanks for testing it and getting back to me. @John Dowson I've attached a ZIP file for the 64 Java SDK. It includes the new compiled library files and the modified source code projects. Paul UIPC_SDK_JAVA_64bit.zip

Hi Everyone, I had a go at sorting this out and I think I've it working for 64bit Java. Attached is a zip containing: fsuipc_java64.dll - This is the Java/C wrapper around the 64bit version of the C User Lib (Version 2). fsuipc64.jar - The FSUIPC Jar library compiled to use the new 64bit wrapper. Everything should work exactly the same as the 32-bit versions. I've tested it on WideClient 7.1.5.6 and it works fine. I cannot test it directly connected to a flight sim because I don't have any 64bit Sims. I doesn't work connecting directly to 32-bit sims but I'm pretty sure that's to be expected. I don't think "UIPC64_SDK_C_version2" works with FSUIPC3 or 4. Perhaps John can confirm. I took the liberty of adding a new function called "GetResult()" which returns an int. This is useful to get the error code after a process() or open() fails. I needed this while I was testing. If these files work I will give John the new source so he can add it to the SDK. Paul FSUIPC_JAVA64.zip

Okay - thanks for the tests. It looks like FSUIPC6 is not giving the correct minor and build version from offset 0x3304. @John Dowson Can you look into this please? Paul

FSUIPCConnection.FSUIPCVersion.Minor is returning 3? Paul

Hi Fred, Return FSUIPC V6.00000 Is that from this line? Console.WriteLine(literal.ToString) The ToString() function is formatted to 3 decimals, so I can't see how you can get 6.00000. Can you please check the values of: FSUIPCConnection.FSUIPCVersion.Major FSUIPCConnection.FSUIPCVersion.Minor FSUIPCConnection.FSUIPCVersion.Build Or is it from this line? Console.WriteLine("FSUIPC V: {0}", substring) Your 'substring' variable only contains the major version. Paul

Hi Rob, I can't test this here as I don't have P3D. If other controls work it could be a P3D or Simconnect bug. I think @John Dowson will be able to look into this a bit more. In the mean time, a useful test would be to map a key or joystick press directly to one of these menu controls. See if these controls work there. Paul

Thank John, What about 0x3308? Will that still be 12 (meaning all P3D 64bit versions)? Paul

I don't know. I'm sure @John Dowson will be able to tell us. If it's different than P3D V4 I will add a new entry to the Enum. Paul

Glad you got it sorted. To answer the above question... These kind of helper methods (getPositionSnapshot(), ReadLVAR() etc.) all do a Process() in the background. You only need to call Process() to handle your own Offsets. It's not required when you use any helper method or module (e.g PayloadServices). Paul