Jump to content
The simFlight Network Forums

Paul Henty

  • Posts

  • Joined

  • Days Won


Everything posted by Paul Henty

  1. Compared to reading offsets, yes. Every LVAR read or write takes one Process() call. Usually around of 10ms. Whereas you can read many offsets in a single process call. There's no problem with a few LVARs per second. Depending on the PC, and what else is running using SimConnect/FSUIPC, I would think you can easily read about 50 per second without problems or running out of time. That's strange. I don't have P3D so I can't test that here. I might be worth asking the John Dowson about this in the main support forum. Yes there are two offsets you can look at: 0x3364: Ready to Fly. (1 Byte). Look for it to be Zero when the sim has finished loading and the flight has started. 0x3365: In Menu or Dialog. (1 byte). Again, look for this to Zero when not in a menu. These offsets work a little differently in each type of sim (FSX/P3D etc.) so you might need to experiment a bit. Paul
  2. The problem is probably with MSFS or the way the A320 is programmed. Even though you have set standard pressure, the code in the aircraft doesn't light the indicator. The RPN script seems to be using local panel variables (LVARs) to force the indicator on. I can't understand the syntax of the script but it seems like L:XMLVAR_Baro1_ForcedToSTD is being used to light the indicator. Unfortunately LVARs are not yet available in FSUIPC when using MSFS (both are still in development). When they are implemented you will likely be able to light the indicator by writing the correct value to the LVARs. Use FSUIPCConnection.ReadLVAR() and FSUIPCConnection.WriteLVAR(). Paul
  3. That was easier than I thought it would be. Version 3.2.0 BETA is now on Nuget. (Tick the box for 'Include Prerelease' to see it. The Nuget package now contains two version, one for .NET 5 (net50-windows) and one for .NET 4.0 Framework as normal. They are both compiled from the same source code, so they will be functionally identical. The package manager in Visual Studio will install the correct version for your project. I've given it a good test under .NET 5 with my Example Code Application and all seems well. Paul
  4. The radar altimeter is in offset 0x31E4. It does have a height limit, above which it stops working. If you need higher altitudes AGL you'll need to stick with the formula that you are currently using. Paul
  5. Ahh, I understand now. I've had a look and I've no plans to do this at the moment. John says he's going to build this into FSUIPC7. When he does I'll see what that means. If LVars become accessible via the normal IPC interface then I won't need to do anything. If this provides a faster way to access LVars than the current IPC method (one LVAR per Process()) then I'll look at adding support for it then. Paul
  6. What kind of support are you thinking about? If you mean referencing the DLL from a WASM application and having it run on the browser then I don't think that's possible. Communication with FSUIPC is done via Windows messaging using the Win32 API. I'm pretty sure that can't be accessed from code running in a browser. You can use the DLL on the server side with an ASP.NET application. Not sure about the new Blazor server apps. Let me know if you had something else in mind. If you want real-time access to FSUIPC data from Javascript or WASM applications you can use my WebSocket server. This runs on the FlightSim computer and allows the browser to request and receive real-time updates over a WebSocket. http://fsuipcwebsockets.paulhenty.com/ Paul
  7. Hi Neil, It looks to be possible. I've got the DLL compiling here against net5.0-windows. It does use some WinForms classes to make some of the helper objects (e.g. Airports) show up in the PropertyGrid properly, so I can't build it against the basic net5.0 without removing those features. (Same goes for Standard). I think this is okay as FSUIPC only runs on Windows anyway, so there's no real point in forcing the DLL to be cross-platform. I'll need to give it a good test and then sort out the NuGet package to include both the net40 and net5.0 versions. If all goes well, I expect to release it by next weekend. Paul
  8. Hi Nach, You can just the the helper method below. This uses offset 0x3110 behind the scenes but is easier to use: FSUIPCConnection.SendControlToFS(c,p) where c is the control number and p is the parameter value you want to write to that control. If the control doesn't need a parameter just pass 0. Paul
  9. Dim points As FsLatLonPoint() = { New FsLatLonPoint(51.828207, -2.669643), New FsLatLonPoint(51.823186, -2.654353), New FsLatLonPoint(51.827549, -2.646808), New FsLatLonPoint(51.836629, -2.638694), New FsLatLonPoint(51.796211, -2.663467), New FsLatLonPoint(51.801533, -2.68468), New FsLatLonPoint(51.812531, -2.68296), New FsLatLonPoint(51.828207, -2.669643) } Dim myPolygon As FsLatLonPolygon = New FsLatLonPolygon(points) Paul
  10. The constructor takes in an array of FsLatLonPoint that define the points (vertices) of a closed polygon. There can be any number of points. The polygon can be convex, concave or complex (having self-intersecting sides). Here is an example I used to test the class. I just supply hard-coded points of the outline of London: (I've removed lots of points in the middle for this example): FsLatLonPoint[] points = new FsLatLonPoint[] { new FsLatLonPoint(51.828207,-2.669643), new FsLatLonPoint(51.823186,-2.654353), new FsLatLonPoint(51.827549,-2.646808), new FsLatLonPoint(51.836629,-2.638694), // Points removed new FsLatLonPoint(51.796211,-2.663467), new FsLatLonPoint(51.801533,-2.68468), new FsLatLonPoint(51.812531,-2.68296), new FsLatLonPoint(51.828207,-2.669643) }; FsLatLonPolygon myPolygon = new FsLatLonPolygon(points); Normally you would get the points from a database or mapping service, so you would need to read the points and create the array of FsLatLonPoint[] in code. If you need more specific help, let me know how you're getting the polygon point data and what format the data is in. I can then explain how to convert them to the point array. Paul
  11. Hi James, The FsFrequency classes are helpers to use the legacy frequency offsets stored in binary-coded decimal format (FSUIPC3/4). These only needed 2 decimals so that's all they can return. The offsets starting at 0x05C4 store the frequency as a normal 32bit int value and therefore will report the 8.33hz spacing properly. As these offsets use normal values there is no need to use the FsFrequency helper classes. Paul
  12. Hi Alex, With the PMDG aircraft (and maybe Aerosoft as well), the developers keep track of the fuel in their own code. This is to more accurately simulate fuel flow. They are constantly overwriting the FSX fuel levels with the levels produced from their own fuel simulation. Therefore whatever you write into the fuel offsets gets overwritten. This also happens if you use the FSX fuel menu. Unfortunately, there is no way around this that I know of. Paul
  13. You can just cast it to an int. It'll be the same bit pattern as the uint when it gets to FSUIPC: Declared as uint... private readonly uint MOUSE_FLAG_RIGHTSINGLE = 0x80000000; Cast to int for the SendControlToFS method... FSUIPCConnection.SendControlToFS(PMDG_737_NGX_Control.EVT_MCP_CMD_A_SWITCH, (int)MOUSE_FLAG_RIGHTSINGLE); Paul
  14. Hi, Sorry I missed your questions. If you find you need delays between the keypresses then Thread.Sleep is the only way I can think of. If you're running this on the main User Interface thread (e.g. inside your main form) then it will cause your application to stop responding while it's sleeping. If that's a problem you can run the keypress code on a background thread. Your code will still pause, but the User Interface will not lock up. The easiest way to do this is to use Tasks: 1. Put your key press code in its own method: private void SelectGSXMenu() { FSUIPCConnection.SendKeyToFS(Keys.F12, SendModifierKeys.Control, null); Thread.Sleep(500); FSUIPCConnection.SendKeyToFS(Keys.F1, SendModifierKeys.None, null); Thread.Sleep(500); FSUIPCConnection.SendKeyToFS(Keys.F1, SendModifierKeys.None, null); Thread.Sleep(500); } 2. Mark your Timer method with the async keyword: e.g.: private async void timer1_Tick(object sender, EventArgs e) 3. When you need to make the menu selection inside the timer use this syntax to call the new method on a background thread: await Task.Run(() => SelectGSXMenu()); It will still take 1.5 seconds to do the keypresses, but your application will not lock up. If your program logic doesn't need to wait for the menu selection to complete, you can remove the async and await keywords. The menu selection will then be done in the background while your main timer continues. Paul
  15. You can see all the offsets in the Intellisense list, but it's quite long. It's best to use the classes with the official FSUIPC documentation for the PMDG Offsets. The latest docs are installed when you update FSUIPC. What offsets are available will depend of the your version of FSUIPC however. e.g. FSUIPC4 for FSX won't have the 737NGXu offsets. Paul
  16. Version 3.1.27 is now available with the updated PMDG 737 offsets and controls. Includes the NGXu. Paul
  17. Version 3.1.27 is now available with the updated PMDG 737 offsets and controls. Well I didn't do it by hand, I cheated a bit. I wrote a program that pulled the information from the .pdf and the .h file and wrote the classes for me. Paul
  18. HI Michiel, FSUIPC can report when a joystick button has been pressed. Have a look at the example code application: Input/Menu Services >> IS002_ButtonPresses That's probably the easiest way. Otherwise you'll need to find a library that will let you use the DirectX/DirectInput features of Windows to read the joystick directly. If you're using PMDG, I'll be releasing a new version of the DLL in a few days. It has a few extra offsets in the 737 helper class for the NGXu. Paul
  19. Hi Ian, All offsets will just return 0, but that's a valid value for most of them. You could try looking for an offset which can never be 0 under normal operation and test that. Something else you can try is writing an out-of-range value to one of the offsets and then read it back after a second or so and see if it's a correct value. This could be 0 but that's okay if you wrote 0xFF. If the connection to PMDG isn't working you'll read your original 0xFF back. Paul
  20. Thanks for clarifying Pete. I've found the updated PDF with the extra NGXu offsets. I will add those to the DLL helper class. I will also check the list of controls (events) to see if there are any changes/additions there and bring those into line. I expect to release a new version early next week. Paul
  21. HI, I doubt Dodosim helos have specific offsets of their own; if they did they would be documented. If they use the normal Flight Sim mechanics for a particular system then you just use the normal offsets. If they use their own internal code to model the systems (which a lot of third-party aircraft do) then your options are limited, especially if there is no SDK from the authors. It may be impossible to get the information from FSUIPC. If you want to view many offsets values at once to see what is changing you can download the FSUIPC SDK and use the program called 'FSInterrogate2std.exe'. Other possibilities are as follows: Events/Controls For controlling actions, the aircraft might use custom events (aka Controls), or make use of an unused built-in event. These can be found by using the logging facilities in FSUIPC. Select the Logging tab and check the box for Events (non-axis controls). Also check the box to "Send to console window". Then operate the control in the aircraft. If it uses an event its number will be logged in the console window. You can use this from FSUIPC directly, or via the DLL, but only for control - you can't 'listen' for these events. LVARS (Local Panel Variables) Many aircraft store data in local panel variables. To see what it available for your aircraft: Go to FSUIPC and assign a key press or joystick button to the control "List Local Panel Vars". Make sure the console logging is enabled (see above), go back to the aircraft and press the button/key. A list of LVAR names will be listed in the console. If any look useful you can use these from LUA or the DLL. (See FSUIPCConnection.ReadLVAR()) Program your own logic Simple example: If it's impossible to get the status for a low oil pressure warning light, you might be able to monitor the oil pressure using the normal offsets and use that information to light the warning lamp when it falls below a particular value. Paul
  22. Hi Peter, As it's a rectangle, I've extended the functionality of the FsLatLonQuadrilateral for this. You can now create a quad from a centre point and a width and height. // Create the centre point of the rectangle FsLatLonPoint centre = new FsLatLonPoint(49.206993, -2.206967); // Create the rectangle 100m high (north to south) and 56m wide (east to west) around the centre point FsLatLonQuadrilateral quad = FsLatLonQuadrilateral.FromCenterMetres(centre, 100, 56); The quad now has new properties to get the Min/Max longitude and latitude. E.g. FsLatitude maxLat = quad.LatitudeMaximum; This is now available for testing in version 3.1.26-BETA. (Tick 'include pre-release" in the Nuget package manager to see the Beta versions). Hopefully this meets your requirements but let me know if I've misunderstood. Paul
  23. I'm glad you fixed it. For the benefit of others searching for the same problem, the easiest way to work with Longitude and Latitude offsets is to declare them with the types 'lon' and 'lat'. var request = { command: 'offsets.declare', name: 'allSettingsOffsets', offsets: [ { name: 'playerLon', address: 0x0568, type: 'lon', size: 8 }, { name: 'playerLat', address: 0x0560, type: 'lat', size: 8 } ] } This will return the values in degrees decimal, so you won't need to do any conversion maths on the client side. Paul
  24. Hi James, For C# you'll need my .NET Client DLL. If you haven't already, please see the website for details on how to install it into your project, and to download the 'Example Code' project which gives examples of how to use the DLL. http://fsuipc.paulhenty.com Specifically, have a look at the example called "BC004: Writing to Offsets" under the 'Basic Concepts' section in the Example Code application. For your Project Magenta offset you'll need to declare it with a type of 'byte'. Then assign the value 51 and call Process(). I recommend using the grouping feature so you can better manage which offsets are processed. (See BC005: Grouping Offsets). If you're totally new to this, I recommend the "Complete Video Guide For Beginners" in the help section of the website. This will show you how everything fits together and how to get everything set up. Paul
  • Create New...

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.