Paul Henty

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

Hi David, You've posted this in the wrong sub-forum (this one is for .NET programming). You'll need to repost in the main FSUIPC support forum here: https://forum.simflight.com/forum/30-fsuipc-support-pete-dowson-modules/ Paul

Version 1.1.2 is now on the website: http://fsuipcwebsockets.paulhenty.com/index.html#home I've added two 'wildcard' addresses to the dropdown list. (Note that these are not my invention, they are built into Windows. How they work is down to Windows not me.) * (Handles requests on all physical IP Addresses. Doesn't seem to work with any host names or the 127.0.0.1 loopback address.) + (Handles requests on all IP Addresses and host names. This creates a secure URL that needs admin permissions.) Paul

As John pointed out the Socket Server runs with any version of FSUIPC from 3 onwards. The only difference is that the 'vars' command will run in a legacy mode for all versions before 7. This is significantly slower than the way 'vars' are handled with MSFS. Certain URLs and Ports are secured by Windows. To use them, the account the application is running under needs permission. You can achieve this is two ways: 1. By running the application as Admin. 2. By giving the required permission to the current user. This is done using the following command: (You can execute this in the command window or in code): netsh http add urlacl url=[URL TO REGISTER] user=[DOMAIN]\[USER OR GROUP] e.g. my PC here is call PJH. My user name is Paul. If I want to use the URL http://PJH:2048/fsuipc I would need this command: netsh http add urlacl url=http://PJH:2048/fsuipc/ user=PJH\Paul To run this command you need to be running 'as admin'. But once you've given permissions the socket server will be able to work without admin privileges. I will add this information to the website. A listener can only bind to a one URL. Binding to multiple IPs would require starting multiple listeners on the server side and handling requests from any of them. I don't want to make such a fundamental change to the application at this point. Listening on all IPs might be possible as it looks like the URL can include wildcard symbols. So something like http://*:2048/fsuipc will listen on all IPs. At the moment there's no way of typing this in as you need to choose from the dropdown list. I'll look into change this to allow any URL to be typed in. (If the wildcards work). This will not get around the Windows security however. You'll still need to grant permissions to the wildcard URL or be running 'as administrator'. Paul

Your C# code shows Keys.D1. Did you paste the wrong line? The log shows you sent the 2 key... 867593 FSUIPC Control Action: Ctrl=1070, Param=4658 867593 SendKeyToFS(00030032=[alt+ctl+2], KEYDOWN) ctr=0 I'm assuming you are calling FSUIPCConnection.SendKeyToFS(Keys.D2, SendModifierKeys.Control | SendModifierKeys.Alt); You can see from the log (in bold above) that my DLL has passed on the correct key code to FSUIPC. @John DowsonMight be able to tell you why this key combination is working from the keyboard but not through the IPC interface. Paul