Paul Henty

Hi Dirk, If you are using MSFS, the ALT key is not supported in FSUIPC7. It does work with FSX and P3D. If you are using either of those simulators, please show your code. Paul

You're using "UB" which is 1 byte. Offset 0x281C is 4 bytes. So you're only testing the first byte. This will always be 0 because the entire 4-byte offset only stores 0 and 1. The actual bit you want to test is in offset 0x281F. You can with target that byte: event.offsetmask(0x281F, 1,"UB","Batteryswitch") or tell LUA read the full 4 bytes from the original offset with "UD" (unsigned double word) event.offsetmask(0x281C, 1,"UD","Batteryswitch") You don't really need to test the individual bit as only one bit is ever flipped - the entire offset value can only be 0 or 1. So you could also use the plain event.offset function like this and test the entire value (0 or 1): event.offset(0x281C,"UD","Batteryswitch") Paul

I don't know sorry, I've never used SODE before. You'll probably need to ask their support. It looks like they have a forum here: https://sode.12bpilot.ch/?forum=support Paul

There's no way that I know of. FSUIPC cannot change any scenery objects. Its main use it to get real-time data out of the flight sim and control the aircraft systems. Paul

Hi Patrick, You can search for a PayloadStation by name using the Find() method: private void btnSendData_Click(object sender, RoutedEventArgs e) { FSUIPCConnection.PayloadServices.RefreshData(); // Assign the payload stations to our class level variable for easier access this.payloadStations = FSUIPCConnection.PayloadServices.PayloadStations; //Assigning only one Cabin // Find PayloadStation by name (NOTE: The matching is case-sensitive) FsPayloadStation CabOA = this.payloadStations.Find(ps => ps.Name == "CAB OA"); if (CabOA != null) { // Payload station found double newWeightKGs = 0; if (double.TryParse(txtboxCabOa.Text, out newWeightKGs)) { CabOA.WeightKgs = newWeightKGs; } } FSUIPCConnection.PayloadServices.WriteChanges(); } Paul

Hi Patrick, There are a few problems I can see. I've marked the corrected code to match the numbered points below: 1. Before you change any payload/fuel data you need to read the current payload/fuel state. 2. Your code never assigns the variable 'this.fuelTanks' to anything. It's always null. There's no need to have this variable. 3. 'tankControl' is specific to my example application. Instead you need to use one of the FSFuelTanks enum values. 4. You can't use the text in the textbox as a number. It's a string. You need to manually convert (parse) it to a number type (in this case double). Here's the corrected code: private void btnWrite_Click(object sender, RoutedEventArgs e) { // Get reference to save typing PayloadServices ps = FSUIPCConnection.PayloadServices; // Get latest values (1) ps.RefreshData(); // Get the centre tank (3) FsFuelTank centreMainTank = ps.FuelTanks[FSFuelTanks.Centre_Main]; // Convert the text (string) in the textbox to a number (double) (4) double newWeightKGs = 0; if (double.TryParse(txtboxCenterTank.Text, out newWeightKGs)) { // Number converted okay // Assign new value to the fuel tank weight centreMainTank.WeightKgs = newWeightKGs; } // Change more fueltanks here.... // Write any changes to the sim ps.WriteChanges(); } Paul

Hi Robert, The diagram makes things much clearer. You could achieve this without using my DLL. If your main application is in C++ and you're using SimConnect there doesn't seem to be any reason to use a .NET DLL. You can use SimConnect to get data from MSFS. (Instead of FSUIPC Offsets). You can also talk to the FSUIPC WASM Module directly from C++. Check the download on the FSUIPC website called "FSUIPC WASM Module 1.0.2 + WAPI 1.0.2". That includes all the C++ libraries/examples you need. http://fsuipc.com That would seem much simpler to me. Only one language, one fewer component, no communication layer between C++ and the VB component, and no .NET runtime. The WASM will handle the L:Vars (XML Vars) and the SimConnect will handle Events and SimVars. Paul

No, my DLL can't process SimConnect Events. It doesn't use SimConnect. The Offsets are how FSUIPC handles data. These mainly map to what I think SimConnect calls "SimVars". There is another, separate example project for the MSFSVariableServices. Paul

Looking at that link it would seem the XML Vars are L: vars. Paul

The MSFSVariableServices in my DLL uses FSUIPC WASM Module. (You could also use C++ if you want to roll your own implementation). MSFSVariableServices allows you to execute calculator code. Paul

Not sure. They usually have the L: prefix, so these might be something different. I've not heard of XML variables and I don't know how you can read them. Paul

If you mean local panel variables (or L:Vars) you can use my DLL. For all sims you can use use: FSUIPCConnection.ReadLVar() For MSFS you can also use the MSFSVariableServices class. This also allows you to set H:Vars as well. This is more complicated, but is thousands of times faster than ReadLVar(). There is an example project dedicated to MSFSVariableServices on the website... http://fsuipc.paulhenty.com/#downloads Paul

Ah brilliant! Glad it's working. That was an obscure problem. Paul

Yes that looks to be what the problem is. It's going for the 32 bit files not the 64 bit ones. Look for the Path variable in the System list (not the user list). You should see them there... Paul

Hmm.. Your dotnet --info is clearly saying there are no .NET SDKs installed. So something has gone wrong. The only thing I can suggest now is to download and manually install the .NET Visual Studio SDK from Microsoft: https://dotnet.microsoft.com/en-us/download/visual-studio-sdks You need the .NET 6.0 Visual Studio 2022 SDK - either x86 or x64 depending on your machine. Paul

Go to the individual components tab and check you have NET SDK checked: That seems to be the part you're missing. Are you on Windows 10/11? Paul

Strange. Seems like something very wrong with your .NET/Visual Studio installation. What does your dotnet --info say now? What version of Windows are you using? Paul

Try this: Just unzip it and open the .sln. KK2023_FSUIPCforNET.zip Paul

One last suggestion I have is to go back to the developer command prompt (as admin) and run this: devenv /InstallVSTemplates Then open Visual Studio and try again. If that doesn't work I'll just create a new project from that template here and sent it to you. That's probably the simplest thing. Paul

Okay - that's some progress. Are my templates still giving the same error? Paul

Check you now have this template and can successfully create a new project from it and run it.

It doesn't look like you've got the Visual Basic language installed. Run the Visual Studio installer and press the modify button. Make sure you've go Windows Desktop Development ticked and then press Modify to install it. If it's already ticked you might have to go back and run a repair. Paul

That's okay - it just filters the list of templates to VB only. Please can you try creating a project using the built-in template called "Windows Forms App" (Not the one with '.NET Framework' at the end). When it asks for the .NET version select NET 6.0. Make sure you can run it and get the blank form up. Let me know if that's okay. Paul

The new templates are now on the website: http://fsuipc.paulhenty.com/#downloads They are for Visual Studio 2022 and target NET6 as that's the current version on Long Term Support. There's now an extra installation step: after you copy the files from the zip you need to run: devenv /updateconfiguration from the developer command prompt (as administrator). This will update the templates cache. Full instructions are on the download page. If you have Visual Studio 2022 installed you will also have the required NET6 development environment. That's all you need. Make a new project from the new templates and everything should work properly. Paul

Hi Demon, I've just checked the templates. They were written 5 years ago so they're a bit out-of-date now. The main problem is that the templates target the .NET 4.0 framework, but the DLL stopped supporting that earlier this year. That's probably why NuGet isn't downloading it. I'll update them sometime this weekend to Visual Studio 2022, targeting .NET 6. I'll post back here when the new ones are on the website. Apologies for the issues. I forgot they'd still be on .NET 4. Paul