Paul Henty

Polling can't be avoided with FSUIPC because the protocol is based on polling. Applications that use FSUIPC are meant to constantly poll for look for changes. As John says, my Websocket Server does have an event-driven model, but it has to use polling in the background to monitor for changed values. The developer can choose the polling rate. My C# DLL does not have an event model for offsets (only LVars which uses John's LVar WAPI server and not FSUIPC). If you're comfortable using the Node.JS SDK for FSUIPC then you should probably stick with that and just use polling. FSUIPC can comfortably handle requests every 40ms, maybe faster on modern hardware. The only reason I can see to use another SDK is if the Node.JS wrapper is too slow to manage this rate of polling for some reason. Paul

Check which altitude you are reading. FSUIPC offers a few different offsets, giving different altitudes . e.g.: The actual altitude is given by offsets 0x6020 and 0x0570. The indicated altitude (i.e. what the altimeter in the aircraft is showing) is found at 0x3324. This reading is dependent on the barometer setting in the aircraft. Below 18,000ft the player should set this to the local air pressure as set by the weather. Above 18,000ft the player should set this to standard pressure (1013mb or 29.92inHG). You need to know which one your application is reading and what your altimeter in the aircraft is showing (i.e. what pressure is set). You're likely seeing a problem because you're either mixing up the two values, or the altimeter in the aircraft is showing the wrong altitude because the barometer is not set to the correct pressure. If you don't use any weather the default air pressure is 1013mb which is also the default setting on the barometer. You won't see any problems until you use weather which changes the local air pressure. Paul

Not from FSUIPC directly. You'll need to open the file in code and read through it until you find that line. You can find the path to the aircraft.cfg file in offset 0x3C00 (Also string * 256). In FSUIPC3 to 6, this contains the full path to the .air file. The aircraft.cfg will be in the same folder you just need to get the folder from the path and substitute the file name. In FSUIPC7 the offset list seems to suggest this will be the aircraft.cfg instead, so you can probably just use it directly. Paul

You can get the 'title' of the aircraft (as specified in the aircraft.cfg file) from offset 0x3D00 (String of size 256). That will probably give you enough info to differentiate aircraft from different developers. Paul

Hi, All of these offsets are only 1 byte in length. This can be seen from the FSUIPC Offsets document: e,g,0x3101 By declaring these offsets with type <int> you are reading 4 bytes instead of 1. For offset 0x3101 you are also reading 3102, 3103 and 3104 into one variable. You must declare these offsets to be an integer of length 1. The C# type for this is either byte (unsigned: + values only) or sbyte (signed: + and - values). Since the possible values for these offsets are only 0 and 1, just use <byte> like this: private Offset<byte> alternatoroffset = new Offset<byte>("alternator", 0x3101); private Offset<byte> masterbatteryoffset = new Offset<byte>("masterbattery", 0x3102); private Offset<byte> avionpwrofset = new Offset<byte>("avionicspower", 0x3103); For more information on which C# type to use with different size offsets, please see the "Offset Types Chart" in the downloads section of the website: http://fsuipc.paulhenty.com/#downloads Paul

The only thing I can think of is that your virus checker is seeing it as a false-positive and quarenteening it. You can probably check to see if that's happened and add an exception. You could also try renaming the .nupkg to .zip, then you can unzip it and find the DLL under \lib\net6.0-windows7.0 Paul

Hi Matt, I haven't provided any alternatives to NuGet, but I've attached the NuGet package here. You can copy this to your NuGet 'local store' which you can select in the 'package source' dropdown: If you don't have one, or don't know the path, you can view and create stores with the cog icon. Once you have the nuget file in the local store you can install it as normal. The DLL takes a dependency on protobuf-net so I've also included that package. Paul FSUIPCClientDLL.3.3.8.nupkg protobuf-net.3.2.26.nupkg

Yes, just set the property before calling Init() MSFSVariableServices.SimConfigConnection = 1; // Use config 1. Default is 0 MSFSVariableServices.Init(); // Initialise Paul

Yes, that's how WideFS and WideClient work. You run WideClient on the notebook and any FSUIPC Client software you run (or develop) will see it as FSUIPC and connect. The only thing I'm not sure about it the new WASM module to read/write LVars, HVars and run calculator code. @John Dowson will be able to tell you if you can use that on the remote PC. This is separate from the normal FSUIPC protocol and so I don't think it is handled by WideFS7. Paul

Hi Robert, That's correct. By default, all offsets will be read on process() except when you have changed the value, in which case the new value is written. They then go back to reading again. If you want an offset to only be written (even when the value hasn't changed) you need to mark it as WriteOnly by setting the parameter in the constructor: public Offset<BitArray> ControlInhibit = new Offset<BitArray>(0x310A, 1, true); // Write only That will make the DLL write the current value every time you call process. You could also consider putting this offset in a named group so you can process() this at a different time from other offsets you might be using. Here's how you would do that... public Offset<BitArray> ControlInhibit = new Offset<BitArray>("inhibit", 0x310A, 1, true); FSUIPCConnection.Process("inhibit"); ... but it's not required. Paul

I believe HVars need a file to be accessed directly by the WASM module. LVars don't need the file. I think that's also correct. Probably yes. FSUIPC4 and above uses SimConnect in the background for most things. @John Dowson will be able to confirm. Paul

Yes, I've upload a new version for you to try: 3.3.8-beta. I've reduced the memory overhead to about 12% of what it was. Remember to tick "Show Pre-Release" in the NuGet package manager to see this beta version. Please let me know how it goes. Thanks, Paul

Thanks, Work fine here with your code and those files. The rebuild took 20 seconds to run on my rather old machine. Can you try logging the progress output from the RebuildDatabase method? This will tell us how far it's getting/where it's stopping. The code will be something like this... if (db.MakeRunwaysFilesExist) { Progress<string> progress = new Progress<string>(); progress.ProgressChanged += (o,s) => logger.Info(s); await db.RebuildDatabaseAsync(progress); db.Load(); I'll look at this again tomorrow morning. Paul

I wonder if it's something to do with the data in the MakeRunways files. Can you send me your makerunways output files? I can try running them here and see if there's something my code isn't handling. (I don't have MSFS). They should zip down pretty small - I only need: Runways.xml F5.csv R5.csv G5.csv Helipads.csv T5.csv Thanks, Paul

I'm not sure what you mean by 'fails' if there are no exceptions or errors. What are you seeing to make you believe it has failed? If you step through this method does it continue past this line, or does the method just return, or does the whole application just stop? Paul

Hi Brandon, Presets are just containers for calculator code, so they end up executing calculator code eventually. They are useful in the FSUIPC front-end, but if you are using code then it's just an extra step. Also the way you call presets from code via FSUIPC is not very efficient. If you're using code I would stick to either sending calculator code or using the HVars/LVars directly using the MSFSVariableServices class in my DLL. Which you choose is down to personal preference/convenience/situation. For example, if you're just wanting to read/write a single LVar or activate a single HVar then using the direct method might be easier: MSFSVariableServices.HVars["MyHVar"].Set(); However, if you've found some complicated calculator code on the web, or in a preset, then you might not want to decode what it's doing and replicated the logic yourself. In this instance it would be easier just to copy the code into your application and send it via MSFSVariableServices.ExecuteCalculateCode() For aircraft where LVars/HVars are not available you may need to fall back on 'legacy' methods like Events (aka Controls) and Offsets. In this case you need an FSUIPC Connection. Events/Controls perform actions in the aircraft (Like HVars). Use the FSUIPCConnection.SendControlToFS() feature. To read data use the Offsets. Some offsets can also be written to. I don't recommend executing presets themselves from code. It's best to just take the underlying calculator code from the preset and execute that. You can copy it directly into your source code. Alternatively, you can have your application read it from your own text file if you want to be able to modify/add calculator code without recompiling your application. If you have not already downloaded the MSFSVariableServices example code project please get it from here: http://fsuipc.paulhenty.com/#downloads It doesn't have an example for calculator code but it will show you how to make a connection and use LVars/Hvars directly. In this thread I give an example of executing calculator code as well as using the same HVar directly. There is also a link to a good website where you can find the underlying calculator code for all the presets. Feel free to ask further questions. It's a bit confusing if you're coming into this new because there are two systems in use for MSFS: The legacy Events/Controls/Offsets system and the newer LVars/HVars/Calculator code system. Paul

Hi Andy, Copying files is an easy thing to do in .NET, so I can't see that I'd be adding much value to the DLL, or significant time-saving to coders, by including this. Paul

Hi Andy, This was a bug on my side. I've just uploaded 3.3.7 to NuGet which fixes this. Also note that you'll need to load the database after you rebuild it, or you'll get 0 airports: await db.RebuildDatabaseAsync(); db.Load(); System.Windows.MessageBox.Show($"MSFS airports build successfully. Total {db.Airports.Count}"); logger.Info($"MSFS airports build successfully. Total {db.Airports.Count}"); Paul

You've still got the declarations the wrong way round. 3114 must be declared first, then 3110. Please see the code I pasted in my last reply. You don't need the Disconnect(), but you definitely need to delete the group if you declare (recreate) the offsets each time you send them. The DLL is thread-safe and (by default) offsets can be declared on one thread and set/processed on another. If this is the case then either: 1. Another application is sending these events. 2. Your application is sending these events from elsewhere in the code. Make sure you haven't declared these offsets somewhere else in another group (or in the default, empty group). Also, if you are using a version of my DLL before 3.1.6 you'll need to update as the write-only offsets were buggy before that. Paul

In the code you've posted you're still declaring the offsets in the wrong order. You need to declare 3114 then 3110. I noticed you have swapped the order you set the values, but that doesn't matter. It should be this: Do Until myEventQueue.IsEmpty Dim mySimEventParams As New Offset(Of Integer)("SendControl", &H3114, True) Dim mySimEvent As New Offset(Of Integer)("SendControl", &H3110, True) Dim myEvent As SimEvents myEventQueue.TryDequeue(myEvent) mySimEventParams.SetValue(myEvent.MouseID) mySimEvent.SetValue(myEvent.EventID) SimLogger.Trace("Sending Control {0} with parameter {1}", myEvent.EventID, myEvent.MouseID) FSUIPCConnection.Process("SendControl") FSUIPCConnection.DeleteGroup("SendControl") Thread.Sleep(1000) Loop However, this might not solve the problem since your examples are always sending the same parameter value. It would only make a difference on the first ever call. But, you should fix the order in case you ever need to send a different parameter value. Other things you might try: Turn on the Event (control) logging in FSUIPC and output to the console. Check that FSUIPC is receiving what you think the code is sending. And you'll be able to see if anything else is writing that control. Try with a non-mouse parameter. I think some of the PMDG controls can also take direct values like 0/1 for open/close. Paul

The order of these offsets matters. FSUIPC sends the control to the sim as soon as you write 3110. So that's before you've written the new parameter - the offsets are written in the order they are declared. If you reverse the order of these two lines (declare 3114 first, then 3110) it should work as expected. Paul

Hi Tony, The new offsets for COM frequencies start at 0x05C4. These are just normal 4-byte 'int' offsets that store the frequency in Hz. To convert to/from the normal MHz value just multiply/divide by 1,000,000. These offsets are read/write in P3D, however the Offset Status document for FSUIPC7 (MSFS) says that writing to these offsets does not work yet. It's worth trying though. Also, some third-party aircraft may use their own coding for com frequencies and so these offset won't work at all for those aircraft. Paul

It sounds like the WASM module isn't seeing the HVars. I don't have MSFS so I can't really help with that. @John Dowson will be able to help with getting the HVars recognised by the WASM module. Hopefully he will see this and reply here. If not, please ask John directly in the MSFS sub-forum: https://forum.simflight.com/forum/183-fsuipc7-msfs/ Paul

Hi, If you go to this site you can look up all the MSFS presets and find out how they work: https://hubhop.mobiflight.com/presets/ (Make sure you select MSFS and not XPlane in the top left). If you search for 'AS1000_MFD_RANGE_INC' and expand one of the results you will see the 'code' field. This is the 'calculator code' that get executed when you run the preset: (>H:AS1000_MFD_RANGE_INC) This is just setting an HVar (not LVar) called AS1000_MFD_RANGE_INC. You have two choices to do this with the Client DLL: 1. Use MSFSVariableServices to execute this exact calculator code: string incMFDRange = "(>H:AS1000_MFD_RANGE_INC)"; MSFSVariableServices.ExecuteCalculatorCode(incMFDRange); 2. Use MSFSVariableServices to set the HVar directly: FsHVar mdfRange = MSFSVariableServices.HVars["AS1000_MFD_RANGE_INC"]; if (mdfRange != null) { mdfRange.Set(); } When you are looking for controls for an aircraft, be sure to check HVars as well as LVars. Many controls are done with HVars when no values need to be set or read. Paul

Hi, I can't see anything obviously wrong. The haversine calculation is giving correct values. The only thing I can't check is the ground speed conversion: Dim speed As Double = ((gspeed.Value / 33714.6311111111) * 1.852) ' User's Groundspeed Where is gspeed coming from? What units is it in? Paul