Paul Henty

Hi Joe, Yes. Offsets can be registered in groups. An update for the group is only sent to the client when there are changes to any of the offsets in that group. Additionally there is an option per group to only include data from offsets that have changed since the last update was sent. This give two methods of consuming data, one suitable for real time displays and another for event driven applications like flight logs. The types are handled (as in string, int, float etc). The unit conversions are not. That still needs to be done by the client (except for Lon and Lat which are done for you). While it's possible to add unit conversion on the server side, it's a lot of manual work given the number of offsets. In the PDF offset lists the formulas are embedded in blocks of text and are not in a standard format so it makes it difficult to pull them out programmatically. There will be helper modules added in the future (like in my .NET DLL for FSUIPC) that will make it easier to deal with certain data. The only one I've added at the moment is Payload and Fuel services. This allows reading and writing of the payload and fuel levels directly in common units (lbs/litres/gallons/kg etc). Paul

Okay, I'm posting a modified version of SendKeyToFS below for you to try. Can you copy this into your code somewhere and use that instead (in your timer event). If it still doesn't work, please experiment with the timeout between when it gives focus to P3D and sending the keystroke. It might work with a larger delay. 150ms was fine for FSX but maybe P3D needs longer to be ready. Maybe 250 or even 500? private void SendKeyToFS(Keys Key, SendModifierKeys Modifiers) { // First make sure the Flight Sim has the focus SendControlToFS(FSUIPCControl.Key_focus_restore, 0); // Please experiment with this delay if this doesn't work Thread.Sleep(150); // Send the key SendControlToFS(FSUIPCControl.Key_Press_and_Release, (int)Key + ((int)Modifiers * 256)); } Paul

Hi, I'm not sure what the problem could be if the sample app works. When you use this function is P3D obtaining the focus okay? Does it the P3D window come to the foreground and un-grey it's title bar? Paul

The main causes of this are: Declaring an offsets as the wrong type Not converting the values from FSUIPC units to human units correctly. Refer to the FSUIPC Offset list to check the offset types and also to get the conversion formulas (if applicable). If you can't spot the problem, please post your offset declarations and the code where you are using the values. I'll be able to tell you what the exact problem is. I can't really help much without code. Paul

Hi, The offset needs to be declared as FsBitArray so you can address the individual bits. For BitArrays, you also need to specify the length in Bytes (2 in this case). like this: Private lights As New Offset(Of FsBitArray)(&HD0C, 2) You need version 3.1.22 or later for FsBitArray. Paul

Yes they are registered globally when they are instantiated. They are processed whenever the group they are in is processed. Offsets are updated with new values from FSUIPC unless their value has been changed. In this case the new value is written to FSUIPC. Yes, that's the easiest way to handle such offsets. It might need to be connected. I've tried your KeyPressed and KeyRelease code here (not via Stream Deck though as I don't have one) and it works fine. I would try with FSUIPC connected. It might ignore IPC requests until its connected. If it still doesn't work, check what is actually being sent to FSUIPC by enabling the "IPC Writes" logging in the Logging tab. Use the option to send the log to a console window to check in real time. Have you considered adding the ability to send controls (events) directly to FSUIPC from the stream deck? e.g. try { if (!FSUIPCConnection.IsOpen) { Logger.Instance.LogMessage(TracingLevel.INFO, "Opening FSUIPC connection..."); FSUIPCConnection.Open(); } Logger.Instance.LogMessage(TracingLevel.INFO, "Sending control " + (settings.ControlNumber).ToString()); FSUIPCConnection.SendControlToFS(settings.ControlNumber, settings.Parameter); } catch (Exception ex) { Logger.Instance.LogMessage(TracingLevel.ERROR, ex.ToString()); } This would bypass the need to do any button mapping. e.g. sending control 66079 (with parameter 0) would raise the landing gear. Control numbers are listed in "The 2016 List of FSX and P3D Controls.pdf" in the FSUIPC Documents folder. Most controls don't need a parameter value so 0 is sent. Paul

Read the aircraft altitude (e.g., offset 6020) then subtract the ground height (e.g. 0B4C). Don't expect 0 when you are on the ground - the altitude is measured from the origin of the aircraft model which is usually in the middle of the aircraft. So it will be a few feet off the ground. You could also try the radio altitude which measures the height above the ground, but I think this might only work at low altitudes as in real life. See offset 31E4. Paul

Not much. The Open() takes as much time as a Process(). Its usually in the region of 200ms. It is. The ideal scenario would be that your plugin is only instantiated once by the streamdeck. This will allow you to open the connection in the constructor and declare the offsets at the class level (once). Then every button press would just set the values of the the pre-declared offset(s) and call Process(). If there is one instance of the plugin per panel you'll have a separate FSUIPC connection for each device which isn't a problem. If it's one instance per button then that will be a lot of open connections. I don't know if FSUIPC has a limit on how many simultaneous connections it will accept. You might have to keep opening and closing the connection for each button press. That would be inefficient, and may make the button press feel a bit sluggish, but it would probably be usable on modern PCs. Yes the Process() call is synchronous. Paul

Hi, This looks like a problem with either FSUIPC7 or SimConnect. It will likely get fixed as development of FSUIPC7 and MSFS continues. Maybe @John Dowson can confirm. Paul

Hi, Yes it looks to be very straightforward. You'll need to add the DLL to the project via NuGet, then adapt the application to manage the connection to FSUIPC. There are templates available that show automatic connection handling (opening and detecting closing). You will also need to be familiar with reading and writing offsets using the DLL. Everything you need can be found on the website: http://fsuipc.paulhenty.com For the virtual buttons you can use offsets 0x3340 and onwards directly. You can declare one 32-byte offset (as FsBitArray type) and have one large bitarray, or you could declare 9 4-byte bitarrays, and have one for each joystick. Alternatively, offset 0x29F0 might be easier if you don't need to read or keep track of the virtual button states. Here you just supply the joystick and button number and the action (toggle, press, release). If you opt for 0x29F0 you could either assemble the 4-byte integer value yourself, or declare 3 1-byte offsets (29F0, 29F1, 29F3). When you declare these it's important to have 29F0 declared last as it this address that will trigger the action. This is a very broad overview. Let me know if need any more details. Paul

Yes, this was certainly one of the previous bugs that lead to the changes in the read/write system. Setting ActionAtNextProcess is no longer necessary with the latest versions of the DLL, but it won't do any harm either. Paul

Hi Andy, Yes, that's clear. You'll be able to specify any location and heading for the query. Paul

Hi Jason, There are some well-known methods for doing this that you can find on the net, but they do involve a bit of trigonometry. I can add a class for this to the dll over the Christmas/New Year period. It will be a polygon class that will take in the list of Lon/Lat points for the outline of the area. You'll then be able to query if a location is inside or outside the area. Also, given a location and heading it will tell you if you will enter or exit the area and the distance to the crossing. I think that covers what you want but let me know if there's anything else. Paul

I don't have that aircraft so I can't test it myself unfortunately. You might want to repost this question in the main FSUIPC forum as more people will see it there. In case you don't know, version 3.1.24 of the DLL introduced a helper class for the PMDG 747 offsets. It might be worth trying it to see if it's any different. Details here: Paul

Hi Pete, Only if both offsets are declared as WriteOnly. Offsets which are not explicitly declared as WriteOnly only get written when the value changes. WriteOnly offsets always get written during the Process() call (even if the value has not changed). This is how those offsets should be declared in VB.NET. (The last parameter is the WriteOnly flag). Dim FSControlParam As Offset(Of Integer) = New Offset(Of Integer)("FSControls", &H3114, True) Dim FSControlNum As Offset(Of Integer) = New Offset(Of Integer)("FSControls", &H3110, True) Note also that the order of declaration is important as it determines the order in the FSUIPC file, so 3110 must be declared after 3114. The method used by the DLL to detect the need for writing did change in the early days of Version 3: In version 2 it would be enough to assign a value, so this would be enough to trigger a write, even if the current value was 1070 : FSControlNum.Value = 1070 From version 3 you need to write a different value to trigger a write for a read/write offset. Therefore, these types of offsets need to be used in write-only mode. From what you describe it sounds like ProsimUtils isn't using Write-Only mode. Paul

You need to build the project first. This will download and install the client dll from NuGet. Until then you will see errors. If it doesn't work after the build, please show me the errors. Yes you can read offsets on a different thread to the main GUI, e.g. a background worker thread or a Task. Note that you won't be able to directly update the GUI from this thread however. You'll need to use Invoke() to switch back to the GUI thread, or, have the GUI update itself regularly with the latest read offset values. Paul

Hi, XPUIPC isn't supported in these forums as it's written by different people than FSUIPC (which is for Microsoft Sims and P3D). XPUIPC does come with a WideClient clone called XPWideClient which allows client machines to connect to XPUIPC over the network. However, you will need to ask Project Magenta directly if their software works with XPUIPC as it's only a partial emulation of FSUIPC. Paul

I didn't update the version number. Fixed now. Paul

Hi John, That depends on FSUIPC7. It's still in development. Best to ask in the FSUIPC7 sub-forum if the payload and fuel offsets are working yet. If FSUIPC7 supplies the data then PayloadServices will work. Paul

Yes you can. They are proper offsets that work just as if you had declared them yourself. Paul

Version 3.1.24 is now available. The TextMenu class now recognises all the message types (see new property MessageType) and gives the colours for the single line messages (MessageColor). Paul

Version 3.1.24 is now available. Includes the 747 and 777 control enums and helper classes for the PMDG offsets. See here for details: Paul

Hi Jason, I've just released V3.1.24 which has helper classes for the PMDG 737, 747 and 777 offsets, and adds enums for the 747 and 777 Controls. The offset helper classes are called: PMDG_737_NGX_Offsets PMDG_747QOTSII_Offsets PMDG_777X_Offsets These all work the same way - Examples below are for the 737 First declare a new instance of the helper class. This is best done at the class or form level like normal offsets. C# private PMDG_737_NGX_Offsets pmdg737 = new PMDG_737_NGX_Offsets(); VB.NET Private pmdg737 As PMDG_737_NGX_Offsets = New PMDG_737_NGX_Offsets() With the connection open, call the RefreshData() method to get the latest data. The class contains all the known offsets for the aircraft. The names are the same as in the supplied FSUIPC Documentation. Where there are multiple values (e.g. The pilot and co-pilot MCP values) these are arrays of Offsets. The example below shows getting the state of the left-hand wiper switch and the EFIS mode selector switch on the pilot and co-pilot side: C# // Get latest data pmdg737.RefreshData(); // Get left wiper switch. Single offset int leftWiper = pmdg737.OH_WiperLSelector.Value; // Get EIFS Mode selectors (array of 2 offsets, Pilot and Co-Pilot) int pilotEFISMode = pmdg737.EFIS_ModeSel[0].Value; int copilotEFISMode = pmdg737.EFIS_ModeSel[1].Value; VB.NET ' Get latest data pmdg737.RefreshData() ' Get left wiper switch. Single offset Dim leftWiper As Integer = pmdg737.OH_WiperLSelector.Value ' Get EIFS Mode selectors (array of 2 offsets, Pilot And Co-Pilot) Dim pilotEFISMode As Integer = pmdg737.EFIS_ModeSel(0).Value Dim copilotEFISMode As Integer = pmdg737.EFIS_ModeSel(1).Value Paul

All good from my point of view. I'll be changing the DLL to incorporate the new type codes and colours. As for the event ID, it works fine in FSUIPC4, so I guess it's an issue with the P3D simconnect versions. It doesn't seem important. Thanks all. Paul

Thanks for the info Pete and John. Paul