Jump to content
The simFlight Network Forums

Paul Henty

Members
  • Posts

    1,366
  • Joined

  • Days Won

    44

Everything posted by Paul Henty

  1. You'll need to add a call to VS.RefreshData() after the sleep, and before you try to read the LVAR. If it still doesn't work try the following: 1. Waiting longer than 2 seconds. 2. Check the list of LVar names at VS.LVars.Names to see all the LVars that have been found. (If you have logging set up you could also use VS.LogLVars()) Paul
  2. Make sure your exe is compiling and running as a 64 bit process. The FSUIPC_WASPID.dll is 64bit so cannot be loaded from a 32-bit process. In your exe project properties, go to the Build tab. Make sure your platform target is either x64 or "any cpu". If it's "any" make sure the box for 'prefer 32bit" is NOT checked. Paul
  3. I can't help much as I don't have MSFS. From what I know: 1. HVars need to be added to a file somewhere so that the WASM module knows about them. 2. You need to wait a few seconds after calling Start() as the WASM module needs time to discover the variables. 3. HVars do not have values. They are only actions that can be 'Set()'. 4. When you change aircraft or change the HVar files you need to call MSFSVariableServices.Reload() to discover the new variables for that aircraft. If you've added these variables to the file and you've waited for the WASM module then @John Dowson may have some more suggestions. Paul
  4. Yes, but for Beta versions you must check the box "Include Pre-release" in the Nuget manager.. Paul
  5. My .NET Client DLL now has direct access to LVars/HVars in MSFS from managed code via the MSFSVariableServices class. See here: This uses John's WAPI DLL in the background. Paul
  6. If it is then WheelChocksSet must be 6C60. Paul
  7. Thanks. I also noticed the addresses for some of the old offsets seem to have changed now... Everything from FMC_CruiseAlt onwards has moved 1 byte forward FMC_PerfInputComplete has typo: 6C20 FMC_DistanceToTOD onwards have been shifted forward 4 bytes. Is this intended? Paul
  8. Sorry John, one more error: FIRE_APUHandleIsUnlocked isn't an array, it should be FIRE_EngineHandleIsUnlocked to match FIRE_EngineHandleIlluminated. I've double checked against the .h file and all the others seem okay. Paul
  9. Hi John, I think you uploaded the wrong document - this one you attached doesn't have the arrays and still has COMM_ReceiverSwitches at 6C58. Paul
  10. Hi T, This offset doesn't take the engine number like that. As the offsets document says, each bit in the offset represents an engine. So bit 0 is engine 1, bit 1 is engine 2 etc. If the bit is set to 1 the engine is failed. If 0 it's working ok. The easiest way to work with bits using the DLL is to declare the offset as an FsBitArray: private Offset<FsBitArray> engine_failure = new Offset<FsBitArray>(0x0B6B, 1); Note that the 1 (second parameter) is the length of the offset. This is required for some types like FsBitArray. 1 here means 1 byte as can been seen in the offsets documentation. To access the individual bits in the offset use the following: if (engine_failure.Value[1]) { // engine 2 has failed } engine_failure.Value[0] = true; // Set engine 1 to failed engine_failure.Value[3] = true; // Also set engine 4 to failed Another thing you need to be aware of is that you declared this offset as uint which is 4 bytes, but the documentation says this offset is only one byte. If you declare offsets with the wrong type you're going to have problems with the values you read, and writing offsets with the wrong type will result is unexpected things happening in the sim. Paul
  11. Okay - I'll add these new offsets to my DLL. Paul
  12. I don't think there are any updates required. @Jason Fayre seems to have the 777 CDU working from my dll. Like Luke, I'm a confused as to what has changed with the offsets you mentioned. Those offsets from 0x6C00 were in the Sept 2015 777x offsets list and so are already included in my dll. They don't look to have changed from 2015. Paul
  13. Hi, John has confirmed that the delay between calling Reload() and the HVars being available is to be expected. It takes time for the WASM module to gather the data from the files and do it's housekeeping. A few seconds should be enough. I'll update the documentation to make this clear. By the way, Start() called Reload() internally so you shouldn't need to call it yourself. Another point John raised is that there can also be a delay between writing a new LVar value and that value being set in the sim and read back by the WASM module. Because of this I'll need to change the value setting to be on a method (SetValue) instead of setting the value property. Paul
  14. I'm not sure why this is happening, or how long you should wait. I'll ask John about it. Paul
  15. You need to call Start() sometime after Init(). Sorry, I completely left that out of the other post. I'll go and fix it now. If you're using LVars as well then you'll also need to call RefreshData() periodically to get the latest values. Paul
  16. Hi Matt, The new beta version of my DLL is now available with support for LVars and HVars in MSFS via John's WASM Module. It's on NuGet (3.2.1-Beta) (remember to tick the box to 'include pre-release'.) Documentation is here: Paul
  17. Hi, The beta is now available on NuGet (3.2.1-Beta) (remember to tick the box to 'include pre-release'. Documentation is here: https://forum.simflight.com/topic/92372-added-support-for-lvarshvars-access-in-msfs-via-john-dowsons-wasm-module/ Paul
  18. MSFSVariableServices Background A new class called MSFSVariableServices has been added to the FSUIPCClient dll from Version 3.2.1-Beta. This module allows direct access to LVars and HVars for MSFS. Other Flight Sims (e.g. P3D) are NOT supported. It uses John Dowson's WASM module for MSFS which must be installed in your MSFS and will also need to be installed in your users' MSFS. This module is installed by the FSUIPC7 installer. This facility is completely independent of FSUIPC. When using this feature in the FSUIPCClient dll you will not need a connection to FSUIPC. It works separately. Note that the FSUIPCConnection.ReadLVar() and WriteLVar() methods still use the legacy LVAR access provided by Offset 0x0D70. You can still use these, however this method of LVAR access has historically been slow (read one variable per Process()) and will continue to be. The new MSFSVariableServices offers significant performance advantages. Requirements As the developer you will also need John's FSUIPC_WAPID.dll. This can be found in latest the WASM package which can be downloaded from the "Additional Free Software" section of the FSUIPC website: (Look for "FSUIPC WASM Module x.x.x") http://www.fsuipc.com/ Inside the Zip file, the DLL can be found in \FSUIPC_WAPI\dll This dll must be distributed with your application and should be located in the same folder as your .exe and FSUIPCClient.dll. In Visual Studio you can add this DLL to your project as a normal project item and set the property "Copy to Output Directory" to "Copy if Newer". You CANNOT add this dll as a reference to your project as it's an unmanged C-style DLL. Example Code: An example project can be downloaded from the FSUIPCClient DLL website: http://fsuipc.paulhenty.com/#downloads C# only at the moment. I will convert to VB.NET if anyone requests it in this thread. How to Use: Setup: First create an instance of the MSFSVariableServices class: MSFSVariableServices VS = new MSFSVariableServices(); Events: This module is purely event-driven. The following events should be handled: OnValuesChanged will notify you when any of the LVar values in the sim change. VS.OnValuesChanged += VS_OnValuesChanged; private void VS_OnValuesChanged(object sender, EventArgs e) { // At least one LVar value has changed. // Do work with new values. For examples see later in this post } OnVariableListChanged will notify you when the WASM module has discovered new LVars and HVars. VS.OnVariableListChanged += VS_VariableListChanged ; private void VS_VariableListChanged (object sender, EventArgs e) { // Variables have been discovered or changed } OnLogEntryReceived. This event will notify you of log entries being produced by the WASM module. This will give you status updates, errors etc. What you do with the messages is up to you. In the example below I'm writing the log entries to a listbox, but you could show them in the Debug output window or write to your own log. VS.OnLogEntryReceived += VS_OnLogEntryReceived; private void VS_OnLogEntryReceived(object sender, LogEventArgs e) { this.lstLog.Items.Add(e.LogEntry); } Initialisation: After setting up your events, you need to call Init(). This will attempt a connection to the flight sim via SimConnect. The result of this will be returned as a log entry. You need to pass in the handle of the main window in your application: e.g: Assuming the code is in the code behind the main form/window: WinForms: VS.Init(this.Handle); WPF: VS.Init(new WindowInteropHelper(this).Handle); Configuration: There are a number of properties to control how the module behaves. The default values for these properties are good for most cases. VS.LogLevel Defines what kinds of events (if any) are logged via the logging system. Values can be: DISABLE_LOG LOG_LEVEL_INFO LOG_LEVEL_BUFFER LOG_LEVEL_DEBUG LOG_LEVEL_TRACE ENABLE_LOG VS.LVARUpdateFrequency This is the number of times per second (Hz) that the WASM Module will get the latest LVar values. This can be used to limit the impact of the WASM module if fast updates are not required. The default is 6Hz. You can slow this down or speed it up depending on how frequently your application will be requesting updates. VS.SimConfigConnection By default the MSFSVariableServices will connect to the local instance of SimConnect. If you have other instances configured on your machine (e.g. connections to remote PCs running MSFS) you can change this property to use them. Starting the module: After initializing and setting your configuration, you must then call Start() to tell the WASM module to start receiving data. VS.Start(); NOTE: After calling Start() it will take the WASM module a few seconds to collect the data from the flight sim and do its housekeeping. This means that LVars and HVars may not be instantly available. It's best to wait until the OnVariableListChanged event has fired before reading LVars. If you ever want to pause the data transfer you can call VS.Stop(); No more data updates will be received by the WASM module until you call Start() again. Accessing LVars: The module automatically discovers the loaded LVars. These are located in the LVars property and are stored as a collection of FsLVar objects. You can access the individual FsLVar objects in three ways: 1. Iterate through all of them: foreach (FsLVar lvar in VS.LVars) { // Do something with each LVar... e.g. CheckLVar(lvar); } 2. Get a specific LVar by name: FsLVar myLVar = VS.LVars["B747_8_MFD_Range"]; 3. Get a specific LVar by ID FsLVar myLVar = VS.LVars[26]; Getting names of all LVars You can find a List<string> of all known LVar names at: VS.LVars.Names Checking if LVars exist To find if an LVar exists by ID or Name use: if (VS.LVars.Exists(26)) { // Exists } if (VS.LVars.Exists("B747_8_MFD_Range")) { // Exists } Counting number of LVars You can get the number of LVars with: VA.LVars.Count Accessing HVars HVars are stored as a collection in the property VS.HVars This collection works in exactly the same way as LVars above. Using the LVar values: Each FsLVar object has a Value property. This is a double type as all LVars are stored as doubles within the Flight Sim. e.g. To get the value for B747_8_MFD_Range use: double range = VS.LVars["B747_8_MFD_Range"].Value; Advanced use: You can also keep a reference to the LVar FsLVar mfdRange = VS.LVars["B747_8_MFD_Range"]; double range = mfdRange.Value; Updating the LVar values: To write a new value for an LVar call the SetValue() method. This will sent the new value to be written to the Flight Sim. e.g. VS.LVars["B747_8_MFD_Range"].SetValue(2); NOTE: This will NOT update the local Value property of the FsLVar. The Value property will be updated after the Sim has received the new value and it's sent back to your application. The OnPropertyChanged event will also fire at this time. Setting HVars: To set an HVar, call the Set() method of the FsHVar object: VS.HVars["AS1000_PFD_NAV_Switch"].Set(); This will cause the new HVar to be set in the Flight Sim immediately. Checking for changes in LVars: There are a number of ways to know if LVar values have changed: 1. Check the ValueChanged property of the FsLVar object: if (VS.LVars["B747_8_MFD_Range"].ValueChanged) { // do something with new range value } 2. Get a collection of all the changed LVars from the LVarsChanged property: foreach (FsLVar lvar in VS.LVarsChanged) { // Do something with each changed LVar... e.g. NotifyChangesTo(lvar); } Note that the LVarChanged collection works the same way as the normal LVars collection. 3. You can handle the OnValueChanged event of an FsLVar: e.g. to be notified of changed to B747_8_MFD_Range: VS.LVars["B747_8_MFD_Range"].OnValueChanged += MFDRange_OnValueChanged; private void MFDRange_OnValueChanged(object sender, LVarEvent e) { double newSetting = e.LVar.Value; MessageBox.Show("MFD Range Changed to " + newSetting.ToString()); } Logging LVars and HVars: List of LVars and HVars can sent to the log by calling: VS.LogLVars(); VS.LogHVars(); Creating a new LVar: Call CreateNewLVar passing in the name of the new LVar and its initial value. VS.CreateLVar("My_New_LVar", 100); Executing Calculator Code: VS.ExecuteCalculatorCode(myCode); where myCode is a string containing the code to execute. Paul
  19. I've had a quick look at John's WASM C DLL and have successfully connected to it from my .net DLL. Over the next few days I will add a proper module to my dll that will (hopefully) allow fast access to LVars and HVars. The only potential problem is that I don't have MSFS so I can't test or debug anything here. I'll post here again when a beta is ready for testing. Paul
  20. Hi, The basic use of the airports database is covered in the example code application. The examples below for the ILS info assume you already have an FsAirport object. I've used EGLL: // Get airport info for EGLL FsAirport egll = db.Airports["EGLL"]; Example 1: Getting all runways at the airport with ILS info and displaying the ILS details in a listbox: // Clear any ILS info in the listbox this.lstILS.Items.Clear(); // Go through each runway and find those with ILS info foreach (FsRunway rw in egll.Runways) { if (rw.ILSInfo != null) { // This runway has ILS Data - Show it in the list box string ilsInfo = "Runway " + rw.ID + " | Freq: " + rw.ILSInfo.Frequency + " | Hdg: " + rw.ILSInfo.Heading.ToString("F0"); this.lstILS.Items.Add(ilsInfo); } } Example 2: Getting ILS info for a specific runway at the airport: string runwayID = "27L"; FsRunway rw = egll.Runways[runwayID]; if (rw != null) { if (rw.ILSInfo != null) { string ilsInfo = "Runway " + runwayID + " | Freq: " + rw.ILSInfo.Frequency + " | Hdg: " + rw.ILSInfo.Heading.ToString("F0"); MessageBox.Show(ilsInfo); } else { MessageBox.Show("Runway " + runwayID + " has no ILS"); } } The FsILSInfo class has a few other properties: http://fsuipc.paulhenty.com/Reference/html/classFSUIPC_1_1FsILSInfo.html Paul
  21. Hi Peter, Correct. It's only for the local PC. If you want it running over WideFS then getting the info from the ini or (as Pete suggested) the log file would be better. You'll need the user to setup windows file sharing though. They aren't no.. Lua is just a programming language and you're just using a Lua library to talk to your HID devices. There are .NET libraries available for talking to hid devices. I've never done this myself so I can't recommend any, or tell you how easy/difficult it is. One other thought comes to mind... You already have Lua plugins that handle the Joystick/LED stuff. Are you trying to replace these with your C# program, or do you intend having a Lua component to your application? If you're going to have both, then you could set up communication between your Lua plugin and your C# program. The easiest way would be via the user offsets. This would then run over WideFS without problems as the Joystick/HID code is all on the FS PC (in LUA). You could have the LUA plugin give information to the C# program and have the C# program tell the LUA program to light LEDs etc. (Your users would need a registered version of the FSUIPC to run the LUA part). If you're intending to replace the Lua code with C# then you'll need to replicate everything you do in Lua in C#. My DLL will only handle reading/writing offsets and LVars. For everything else you'll need to find other .NET libraries that handle the particular task. Paul
  22. Hi Peter, Unfortunately the DLL does not have that feature. There's no way to get the joystick names from the IPC interface. Two ideas you can look into: 1. Have your program read the user's FSUIPCx.ini file. There are lines there detailing what the joystick numbers are: e.g. [JoyNames] AutoAssignLetters=No 0=Controller (Xbox One For Windows) 0.GUID={363210E0-98B7-11EB-8001-444553540000} 2. Use a .net library that lets you talk to the Windows Direct Input API to enumerate the plugged-in joysticks on the user's computer. I'm pretty sure that's how FSUIPC gets the joystick numbers. This is an example using the SharpDX.DirectInput library, available as a NuGet package: private void button1_Click(object sender, EventArgs e) { this.listBox1.Items.Clear(); DirectInput di = new DirectInput(); IList<DeviceInstance> devices = di.GetDevices(DeviceClass.GameControl, DeviceEnumerationFlags.AttachedOnly); for (int i = 0; i < devices.Count; i++) { DeviceInstance device = devices[i]; this.listBox1.Items.Add(i.ToString() + " = " + device.InstanceName + " | GUID=" + device.InstanceGuid.ToString()); } } Paul
  23. Hi, Most of these feature are not simulated by P3D. This means there are no offsets for them. I can suggest trying the following however: Instruments switch - usually the 'Master Avionics' at 0x2E80 Master Ignition Switch - Maybe 0x3B00 General Engine 1 Starter , or, 0x0892 Engine 1 Magneto Switch Position The features you listed are being simulated within the aircraft's code. They might be available to you in two ways: 1. The author of the plane might be using custom controls, or redundant controls (e.g. helicopter/turboprop controls). 2. The author might be storing the values for these features in local panel variables (LVARs). There is no guarantee that the author has used these two methods. They might be completely inaccessible to you. Here is how you can find out what is available: Events/Controls These can be found by using the logging facilities in FSUIPC. Select the Logging tab in FSUIPC 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 (e.g. Inverter Switch). If it uses an event its number will be logged in the console window. You can use via the DLL (FSUIPCConnection.SendControlToFS()), 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 you just mapped. A list of LVAR names will be listed in the console. If any look useful you can use these from the DLL. (See FSUIPCConnection.ReadLVAR() and FSUIPCConnection.WriteLVAR() ) Paul
  24. Just an update - John posted today that he's got LVARs working in FSUIPC7: Paul
  25. Hi Neil, It's FSUIPC unfortunately. The LVAR support only has a single offset where you can request an LVAR (0x0D70), so that's where the limitation comes from. Internally, FSUIPC6 and previous versions, call into the Flight Sim Panels dll which would be very fast at getting and setting LVARs. I suspect SPAD is doing the same thing. C++ programmers can use this tequnique via SimConnect, but it doubt it can be done from managed code. Sticking with FSUIPC6 and previous, it's possible to read/write LVARs values in LUA plugins. This would be fast as this doesn't need to go through the IPC (offsets) interface. The LUA plugin would then copy the values into user offsets and then your program would read the values from the offsets. For large numbers of LVARs this would be much faster. BUT there are some disadvantages to this method: You or your users would need to maintain the LUA plugin LUA Plugins only work on the registered version of FSUIPC In FSUIPC7 (MSFS 2020) things are slightly different. John has written a plugin for MSFS that allows users to read/write LVARS outside of FSUIPC. At the moment though it's only available to C++ users. I'm hoping John and I can get it working from managed code but there's no guarantee at the moment. 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.