Paul Henty

Hi Aidas, The problem is that the text boxes are using these form variable that you've defined: private FsLatitude latitude; private FsLongitude longitude; this.lat.Text = this.latitude.ToString(false, "d", 6); this.lon.Text = this.longitude.ToString(false, "d", 6); But these variables are only ever set in the constructor (i.e. when the form loads): public frmMain() { this.latitude = this.playerLat.Value; this.longitude = this.playerLon.Value; So they will always be 0 degrees. You either need to update these variables after every process, or just use the offset directly. I can't see much point in using another variable... this.lat.Text = this.playerLon.Value.ToString(false, "d", 6); this.lon.Text = this.playerLat.Value.ToString(false, "d", 6); Paul

Hi Lennart , 6576 is an offset, not a control. The PMDG offsets are read-only. The controls are listed in the PMDG SDK. My post below explains how to use the SDK to set up buttons and key presses in FSUIPC. It will give you some background about the SDK, show you where to find the it, and explains how to work out the control numbers and parameter values. The key/joystick button binding requires a registered FSUIPC. However, if you want to use these controls from C++ you have 2 choices: 1. Use FSUIPC offset 0x3110 to send the control (with the parameter) to the sim. See the Offsets Status PDF for details on how to use this offset. 2. Use the PMDG SDK directly to communicate with the aircraft. It's written for C++. I'm not a C programmer so I've no idea how, but presumably it will either be obvious to you as a C++ coder, or PMDG will have some documentation/tutorials. Paul

No, this is not possible with FSUIPC or my DLL. The easiest solution would be to add the airport elevations to your database. Pete makes a program called MakeRunways. Available in this thread in the downloads sub-forum: https://forum.simflight.com/topic/66136-useful-additional-programs/ This extracts airport and runway information from the users' BGL files. This includes airport elevations. My DLL (version 3) has an airports database which reads the output files from MakeRunways and gives you easy access to airport and runway data from .NET. See the section called "Airports Database" in the example code application. This doesn't seem to be available in MakeRunways, so it's not in the DLL's Airports Database. You'll have to source those yourself. Paul

I'm not sure what you're asking with regard to the spare offsets. Reading and writing lvars with FSUIPC is done using two specific offsets. One offset is where you write the name of the lvar you want. The other offset is where you read the result (value). No spare offsets are needed. I can't tell you the actual offset numbers until next week, but they are clearly listed in the offset status list. Search for the word Lvar or L:var. Have you looked? Paul

Maybe. FSUIPC has a facility to read and write LVars. You need to be able to write a string (The name of the Lvar) to an offset. Can the Excel code do that? If you search for Lvar or L:var in the FSUIPC offsets list you'll find the offsets you need and how to use them. I'm away at the moment, back on Sunday. If you can't get it to work I'll be able to help more next week. I don't have access to the documentation right now. Paul

As Pete says, most of those switches are not supported by FSUIPC because they do not exist in FSX/P3D. Only those listed in offset 3122 are built into FSX/P3D. The developers of the aircraft you are using have programmed these switches themselves. They may be accessible to you, but you'll need to ask the developers (or on their forums) how you can do this. It might not be possible. One thing you can try first is to look for Local Panel Variables (L:Vars). If they exist for this aircraft you can read and write them using the DLL. To list the L:Vars for the aircraft, do the following: (You must have registered copy of FSUIPC). 1. Open the FSUIPC interface from the FSX/P3D menu bar (Add-Ons -> FSUIPC). 2. Goto the [Key Presses] tab and assign a key press to the control called "List Local Panel Variables". I have this assigned to ctrl-shit-V. (You could also use a joystick button using the [Buttons + Switches tab] 3. Go to the [Logging] tab and tick [Send to console window]. You can have other options turned on if you want. 5. Press OK and return to the cockpit. Also find the console window with the FSUIPC Log. 6. Load the aircraft you want to work with. (LVars are specific to each aircraft). 7. Press your key combination, or joystick button you assigned above. 8. In the console window you'll see all the LVars listed with their values. If the developer has used LVars you will be able to identify them in the list. Here is what L:Vars look like in the Log Console Window: You can also view them in the FSUIPC.log file located in the Modules folder under your main FSX/P3D install folder. To read and write LVars see the Example Code application: Advanced Concepts -> AC005_ReadWriteLVARS. Yes, that's correct. Paul

I don't know. You'd need to ask the developers of those products. The only offsets for turbulence are for the currently set weather. Each cloud layer has it's own turbulence setting when using the internal FSX/P3D weather. I don't know if REX weather sets those values. These offsets can be found in the FSUIPC documentation, specifically the "New Weather Interface" zip file in the SDK. Or, if you're using my DLL you can just use the weather services. There are no offsets that will tell you what level of turbulence the aircraft is currently experiencing. The only way I can see to derive this is from the aircraft acceleration. See my post above yours. Paul

Circuit breakers are not available in FSUIPC. FSX and P3D do not model the circuit breakers. If you load any 'default' aircraft you'll see that none of the circuit breakers work. They are just bitmaps that you cannot click on. If you are using a third-party aircraft that does have working circuit breakers, the developers have written their own code to handle this. You'll need to ask the developers how you can access this data. It might not be possible. If the data is accessible in some way then it might be possible to use FSUIPC, but it will depend on how. For example if the developers have used Local Panel Variables (L:Vars) then these can be read and written with FSUIPC. Paul

If you have changed to using my DLL then you don't need to bother with reading the individual offsets from NewWeather.h any more. Use the WeatherServices of the DLL and you will get back a .NET Class containing all the weather. Please see my Example Code application. Look for the section called 'Weather Services'. If you don't have this you can get it from the downloads section on the website: http://fsuipc.paulhenty.com/#downloads No, the altitudes in the New Weather Interface refer to the TOP of the wind layer (UPPER Altitude). The METAR refers to the lower altitude of the wind layer. (The NewWeather interface has to present the weather the way is was in FS2004.) So to get the base altitude of wind layer [n] you need to take the upper altitude of layer [n-1] and add the 'gap above' of layer [n-1]. For example, in the New Weather the layers could be: (0 is always the ground layer and starts at 0 metres) 0 | Upper Alt: 1000 | Gap above: 500 1 | Upper Alt: 5000 | Gap above: 0 2 | Upper Alt: 10000 | Gap above: 0 The base altitudes of each layer can be calculated: 0 | Base Alt: 0 (always 0) 1 | Base Alt: 1500 (1000 + 500) 2 | Base Alt: 5000 (5000 + 0) Also, when you are comparing make sure you are getting the METAR and NewWeather from the same weather station. Mixing weather stations and global weather may not match up properly. It's also a good idea to call ClearWeather() before you begin making your own weather settings. Paul

Pete, Post now in FAQ section... https://forum.simflight.com/topic/85925-how-to-program-joystick-buttons-and-keys-to-control-pmdg-aircraft/ Paul

Background PMDG Aircraft for FSX and P3D do not typically use the normal controls provided by the flight sim. This means that many of the aircraft's switches cannot be assigned to buttons and keys using the list of controls in the FSUIPC dropdown boxes. Assigning a standard control in FSUIPC will likely do nothing in the PMDG aircraft when the button or key is pressed. Solution Instead of using the standard list of controls shown in the FSUIPC dropdown box, users must use a different set of controls provided by PMDG for the specific aircraft. These are known as custom controls (or custom events). The custom controls vary for each aircraft and are listed in the SDK that is installed alongside the aircraft. This guide will show you, step-by-step: How to find the SDK files How to calculate the custom control numbers How to work out the parameter value How to assign the control to buttons/keys in FSUIPC The specific examples shown will be taken from the PMDG 737NGX, but the same method works for any PMDG aircraft with an SDK and custom controls (e.g. 777, 747). 1. Locating the SDK From your main Flight Sim install folder, or your MSFS Community folder, and open the PMDG aircraft folder Then select the folder belonging to the aircraft you want to use. e.g. PMDG 737 NG3 or pmdg-aircraft-737 Then select the SDK folder or Documentation\SDK folder for MSFS2020 Locate the file with the .h extension. For the 737 it's called PMDG_NG3_SDK.h (or maybe PMDG_NGX_SDK.h, depending on the sim and variant you are using) You can open this file with Notepad or your favourite text editor. As an example, the document you need for the 737 in MSFS2020 will be: [Community]\pmdg-aircraft-737\Documentation\SDK\PMDG_NG3_SDK.h 2. Calculating the control numbers 2.1. Find THIRD_PARTY_EVENT_ID_MIN The first thing to find is the definition of THIRD_PARTY_EVENT_ID_MIN. Search for the following text: #define THIRD_PARTY_EVENT_ID_MIN You will find a line like this (from the 737 file): #define THIRD_PARTY_EVENT_ID_MIN 0x00011000 // equals to 69632 Note the decimal value at the end. In the case above it's 69632. You will need this value to calculate the control number in the next step. 2.2. Find the control you want to use. Search for the control by name, or look through the listed controls to find the one you want. They are helpfully grouped together by panel. The controls are listed under a comment: // Control Events You can search for this to find where the list of control numbers starts. As an example we'll use the Autopilot CMD A swtich on the MCP. This is the relevant line in the 737 SDK: #define EVT_MCP_CMD_A_SWITCH (THIRD_PARTY_EVENT_ID_MIN + 402) To calculate the control number for this switch we just add 402 to the value of THIRD_PARTY_EVENT_ID_MIN we found earlier. 69632 + 402 = 70034 We have now calculated the control number. We will use this in step 4 to program the button/key. 3. Finding the parameter value PMDG controls need a parameter value. These can one of type types: 3.1. Mouse Click Codes (Shown in the example) You can use these to simulate a mouse click on the particular switch. Mainly it will be the left mouse button, but other clicks types are available (e.g. Right button, left double click etc). To find the codes for each type of click, search for MOUSE_FLAG You'll find a block of #define statements for each type of mouse click. Here are a couple of examples from the 737 sdk: #define MOUSE_FLAG_RIGHTSINGLE 0x80000000 #define MOUSE_FLAG_LEFTSINGLE 0x20000000 Find the click that you want to simulate and get the code. For example, we'll have our key assignment simulate the left mouse button clicking on the CMD A autopilot button. So we'll need 0x20000000 as the parameter value for the control. 3.2. Direct Values (Not shown in the example) Alternatively, some controls can accept a direct value to set the switch to a specific position. To find the direct values you need to look at the top part of the .h file to find the switch definition. These are named differently than the events so you need to search. Taking the battery selector switch as an example, we find the control: #define EVT_OH_ELEC_BATTERY_SWITCH (THIRD_PARTY_EVENT_ID_MIN + 1) For the parameter value we can find the same switch in the top part of the .h file: unsigned char ELEC_BatSelector; // 0: OFF 1: BAT 2: ON This tells us that in addition to mouse clicks, we can also send direct values. In this case: 0 for the OFF position, 1 for the BAT position and 2 for the ON position. It's possible to make a key or button set the Battery Selector directly to the ON position by setting the parameter value to 2 instead of a mouse click code. Simple ON/OFF switches will not have values listed (and will be declared as 'bool'). For these types of switches you can just pass the value 0 for OFF and 1 for ON. 4. Assigning the control to a button or key in FSUIPC Select the [buttons + swtiches] or [key presses] tab in FSUIPC and select the button or key to program. From the "control sent..." dropdown select <custom control> (it's near the top of the list) A popup window appears asking for the control number. Type in the control number you calculated in step 2. For our 'autopilot CMD A' example, we enter 70034 and click OK. The controls dropdown box will now show the control number in angled brackets. In the "parameter" box (below the controls dropdown), enter the parameter value from step 3. This can be a mouse click code or a direct value. Mouse Click Codes: Do not include the first 0 from the number listed in the PMDG SDK. Start with the x. With our example, we would enter x20000000 for the left-button single-click. Note that this code is in hexadecimal. FSUIPC will convert it to the equivalent decimal value. This is nothing to worry about. It's the same number. Entering the value in Hex is more convenient. Direct Values: Just enter the value as a number. Do not add the x at the start like mouse codes. If you're programming a key press, remember to press the [confirm] button. Here is our example control assigned to a button in FSUIPC: Your button or key press should now operate the switch in your PMDG aircraft.

This is all explained in my post I linked to above. Have another look at it. It's takes you through each step. Paul

See this post for how to find the PMDG SDK, calculate the control numbers and bind them to a key/joystick button in FSUIPC: The instructions are specifically for the 737 but the technique would be the same for the 747. Just note that the line numbers may not be the same, but you can search the text to find them. Pete: Would you like me to post this in the FAQ section? I've seen this asked a few times recently. I'll make it a bit more generic for any PMDG aircraft. Paul

There is an offset for this. This is from newWeather.h: int nUpperVisCtr; // C38C C78C CB8C CF8C // Number of upper Vis layer (new in FSX) NewVis UpperVis[12]; // C390 C790 CB90 CF90 Note that for visibility, the base (surface) layer is stored separately: NewVis Vis; // C02C C42C C82C CC2C // Base Vis The intended purpose of FsInterrogate is to examine the contents of offsets. It should never be used to find out what offsets are available. Its list of offsets incomplete (it's 11 years old) and sometimes wrong. Always work from Pete's documentation (e.g. FSUIPC4 Offset Status.pdf, newWeather.h) instead. Paul

If you're using my DLL it's best to declare this offset as a bitarray. Please see the example code application - AC002_BitArrays under 'Advanced Concepts'. This example uses the lights offset you are referring to. If you're not using my DLL then you need to keep the value as a short, but test each bit using boolean arithmetic (bit-wise 'and', 'or' etc.) Paul

No, the wind layers are 16 bytes each. So the second wind layer will be 0xC50C. I'm not sure where you're getting your information. The wind layers are from 0xC4FC-0xC67B. The document you should be looking at is called NewWeather.h. This is found in a ZIP file called "New Weather Interface for FS2004.zip". This is found in the FSUIPC SDK. It tells you the locations of each array and the size and layout of each structure (e.g. Wind, Clouds etc). Paul

The cloud layers start at 0xC680. Each layer is 16 (0x10) bytes. So the second layer will start at 0xC690 (not c68F). The third will be 0xC6A0 etc. Paul

Are you using a .NET language (C#, VB.NET) with my helper DLL for the .NET Framework? Paul

It's difficult to detect turbulence because it can be generated in the sim in different ways. For example: By the FSX/P3D weather engine - this can be wind turbulence or cloud turbulence By an addon which induces turbulence for realism by directly pushing the plane around It's possible to get the current turbulence values set in the weather engine using the weather services in the dll. It's just a matter of working out which cloud and wind layer the player is in and reading the level of turbulence set. (See my sample code application). However, this won't work if the turbulence is coming from another source, or if a third-party weather system is not updating the Sim's turbulence values. I remember a user trying to detect turbulence from the cloud layers with ActiveSky and the turbulence always seemed to be set to 'none' in the sim. So maybe programs like ActiveSky are doing turbulence a different way. I think the most robust way (but also more difficult) would be to monitor the acceleration with respect to the airframe (See offsets 0x3060, 3068 and 3070). You'll probably need to calculate and test the rate of change in acceleration (i.e. metres per second cubed) rather than the raw acceleration values. You'll need to determine which levels are turbulence and which are normal. There is also the added complication of different aircraft being different weights which will affect the acceleration values. Just my initial thoughts on this; I've never tried to detect turbulence. Maybe another user has already worked out a good solution for this... Paul

That is the ToString() representation. You can get the Degrees in decimal by using: playerLon.Value.DecimalDegrees Degrees is easily converted to radians. Yes, the documentation says 8 bytes and doesn't mention how the data is stored. Usually that would mean an 8 byte integer. Maybe these are actually 'double' types? Have you tried using private Offset<double> EleBusMain = new Offset<double>("PerSecond1times", 0x2840); The documentation here is unclear. If double doesn't give the expected results then please ask Pete Dowson about these offsets in the main support forum. You have two options: 1. Use the string converter library in .NET to convert the Unicode C# string to an array of ASCII bytes: byte[] asciiBytes = ASCIIEncoding.ASCII.GetBytes("The C# String"); OR 2. Declare the offset as a byte array: private Offset<byte[]> stringOffset = new Offset<byte[]>(0x3160, 24); The string is returned from FSUIPC in single-byte ASCII. So you can just use the raw byte array to send to your QT app. FSUIPC gets its data from SimConnect. If you think some offsets are reporting the wrong values please ask Pete about that in the main support forum. 'kohlsmann' is at 0x0330, except it's spelled correctly as Kollsman in the FSUIPC documentation. I don't know of any, but you could check with Pete. Paul

Version 3.1.7-beta is now available on NuGet. I've given it a good test here and everything looks okay - your strings should read 100% of the time now. Paul

I've found the problem. The strings coming from FSUIPC sometimes have junk after the zero terminator (from previous values). The DLL is cleaning up these strings internally, but this means that when the cleaned string is compared to the original raw string it thinks the value has been changed and does a write. I'll hopefully get a fix up by the end of the day. This area is foundational to the DLL so I need to make sure the fix isn't going to break something else. Paul

I don't know anything about QT5. You will need to ask their support (or on their forum) about calling .NET libraries. There are no pre-defined group names. Groups are created by you the programmer. You do this by declaring Offsets and giving them a group name that you choose. e.g. private Offset<string> aircraftType = new Offset<string>("AircraftInfo", 0x3160, 24); private Offset<string> aircraftModel = new Offset<string>("AircraftInfo", 0x3500, 24); private Offset<ushort> manifoldPressure1 = new Offset<ushort>("EngineData", 0x08C0); private Offset<ushort> manifoldPressure2 = new Offset<ushort>("EngineData", 0x0958); Here I've declared the 4 offsets I need and placed them into 2 groups, AircraftInfo and EngineData. Please see the "Example Code Applications" - Section "BC005_GroupingOffsets". You can download this from the website: http://fsuipc.paulhenty.com/#downloads Paul

I've run your code and I did have the same problem but only twice in about 20 mins of trying. The problem is caused by the DLL writing rather than reading. So it changes the RegNo (for example) to the one that's currently in the value - which is from the previous aircraft. I can see the write in the FSUIPC Log. I can't get this to happen in a reliable, repeatable way so it's going to be difficult to track down. But it looks like a problem with the DLL writing when it shouldn't. Leave it with me and I'll see if I can fix it in the next few days. If you have a reliable way to recreate the problem then please let me know the steps. - it will let me fix it much faster. Paul

Hi Ian, I've tried it here with FSX:SE and it works fine. After switching aircraft the offsets return the correct information instantly, first time. I don't have P3D so I can't check if it's a problem with that (or FSUIPC5). Have you tried using the Logging tab in FSUIPC to log these offsets to the screen? example: If the values are wrong when logged to the screen by FSUIPC then you need to ask Pete about it the main support forum. Also, please try with the latest beta version of my DLL and see if that makes any difference. (V3.1.6-Beta). Tick [include prerelease] in the Nuget Manager to get the beta version to show up. Paul