Jump to content
The simFlight Network Forums

Paul Henty

  • Content count

  • Joined

  • Last visited

  • Days Won


Paul Henty last won the day on May 6

Paul Henty had the most liked content!

Community Reputation

47 Excellent


About Paul Henty

  • Rank
    Advanced Member
  • Birthday 01/01/1970

Profile Information

  • Gender
  • Location
    Gloucestershire, UK

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Paul Henty

    About audios ,using .net DLL.

    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
  2. Paul Henty


    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
  3. Paul Henty

    About Breakers ,using .net DLL.

    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
  4. 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
  5. Paul Henty

    747 mouse macros

    Pete, Post now in FAQ section... https://forum.simflight.com/topic/85925-how-to-program-joystick-buttons-and-keys-to-control-pmdg-aircraft/ Paul
  6. 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, open the PMDG folder. Then select the folder belonging to the aircraft you want to use. e.g. PMDG 737 NGX Then select the SDK folder Locate the file with the .h extension. For the 737 it's called PMDG_NGX_SDK.h You can open this file with Notepad or your favourite text editor. As an example, the document you need for the 737 will be: [FlightSimInstallFolder]\PMDG\PMDG 737 NGX\SDK\PMDG_NGX_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 which represents what type of mouse click to simulate for 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. Now we have the control number and parameter value. 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 mouse code from step 3. 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. 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.
  7. Paul Henty

    747 mouse macros

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

    747 mouse macros

    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
  9. 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
  10. Paul Henty

    Issues in lights read and write .

    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
  11. 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
  12. 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
  13. Are you using a .NET language (C#, VB.NET) with my helper DLL for the .NET Framework? Paul
  14. Paul Henty


    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
  15. Paul Henty

    About data-reading issues .

    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

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.