Paul Henty

Hi Axel, My DLL is just reporting the value from the WAPID.DLL, however I've made a mistake with converting that value into a .NET bool. I'll have a beta for you to test tomorrow. Paul

Hi Jason, The rotor brake method is described in this guide I wrote. It's aimed at people programming keys and joysticks but you will get the idea. Since the parameter is used to send the command you can only send mouse click actions. I can't see any way of sending values along with the command. However, I would caution against jumping into this immediately and rewriting your app until PMDG give a clear statement on which method is supposed to be used. The SDK document and .h file are using the same custom events method as P3D (which doesn't seem to work). During development they've been using the rotor brake method, which apparently does still work. It would be very strange for an established and serious company to release an SDK that it complete nonsense, but I suppose it's possible. I would wait to see if there is any clarity, or you might find you have to change your code again. I'm certainly not integrating any of this into my DLL until I know what's going on. Paul

It looks like the latest PMDG SDK has moved away from the rotor brake and reverted to normal events system like in P3D. Some of my users are also reporting not being able to send high event numbers. The SDK document and .h file make no mention of the Rotor Brake event. Paul

That's the only way to to it. That string (LogEventArgs.LogEntry) is the only thing I get from the WAPID dll as far as logging goes. The internal logging system is not exposed at all. I don't know of any way for external programs to write to the FSUIPC log. The flight-sim eco-system is made up of many different bits of software, from different authors. Most have evolved over decades. It's inevitable that the pieces don't interact with each other as well as we might hope. Paul

Ah, yes I didn't notice you are using PMDG_737_NGX_Offsets(). This class was created for PMDG aircraft running in P3D. The MSFS offsets are different. I think the current list is in this thread: The PMDG offsets for FSUIPC7 were changing quite frequently which is why I've not added them to my DLL yet. When they get finalised I will add them. Until then, you need to declare the offsets in the normal way, using the PDF in the linked post. Paul

Thanks. It was the PMDG_NG3_SDK.h file I was after as that has all the values in. But it does seem they've abandoned the RotorBrake method. However, according to pdubost above, it seems FSUIPC7 is having problems with control numbers over 69632. It's really a question for John at the moment. Paul

Hi Chris, The PMDG offset area is read-only. You won't be able to write to them. Controlling the aircraft has to be done with the control (events). Paul

Maybe @John Dowsonknows something about this? Paul

It's difficult to comment as I don't have the SDK. Is there a download link or can you DM it to me? So far, on MSFS aircraft, PMDG have been accepting all events as a parameter to the ROTORBRAKE control. Have they abandoned that and reverted to direct control numbers? Paul

No I'm pretty sure that's not possible either. John's DLL doesn't expose the SimConnect connection it uses. I think it's quite normal to have multiple connections open. Paul

Hi Axel, The SimConnect connection for the WASM module is created and managed by John's WASM Client DLL (FSUIPC_WAPID.DLL). My .NET dll doesn't create a SimConnect connection and if you use it you won't need to create one either. If you already have one running, I can't see any way you could get John's DLL to use it. Paul

Yes, that's correct. Paul

The original design was that if you need polymorphism then you use the Offset base class directly, without the strong-typing like this: var thrustInput1Offset = new Offset(0x089A, 2, true); // Untyped offset - Must always set the length int value3 = 9000; var convertedValue = Convert.ChangeType(value3, typeof(short)); thrustInput1Offset.SetValue(convertedValue); FSUIPCConnection.Process(); // Read like this... short readValue = thrustInput1Offset.GetValue<short>(); // or like this... short readValue2 = (short)thrustInput1Offset.GetValue(typeof(short)); However, I've now overridden SetValue() and GetValue() in the strongly-typed Offset<> class to handle the extra stuff that's needed for Offset<>. Both methods should now work with the Offset<> class. There is a new preview release on NuGet 3.2.22-beta2. Check the [include pre-release] box to see it, Paul

Hi, The SetValue() and GetValue() methods should not be visible when using the Offset<> class. It's an oversight on my part. If you're using the strong-typing class like Offset<short> you should be setting the value with thrustInput1Offset.Value = convertedValue; I'll hide these two methods in the next release. Paul

HI, I can't see anything in the MSFSVariableServices code that would prevent writing negative values. First, please make sure you have all the latest versions: FSUIPC 7.3.11 WAPIID dll 0.9.0 My dll 3.2.21 The first two can be found at fsuipc.com If it still doesn't work please try the following: In the "FSUIPC WASM Module 0.9.0 + WAPI 0.9.0" package (fsuipc.com), find the WASMClient.exe and run it. Try using that program to write your negative values. If that works then the problem is with my DLL. Let me know and I'll investigate further. If it doesn't work in that program then it's not my DLL. You'll need to ask John about it in the FSUIPC7 (MSFS) support forum. Let him know you've tried it with the WASMClient.exe. Paul

A new pre-release version is now on NuGet - Version 3.2.21-beta. Tick the [Include Pre-release] box in NuGet package manager to see it. It requires the John new beta WASM module (installed with FSUIPC 7.3.9h) and the 0.9.0 FSUIPC_WAPID.dll. (see post above). Paul

Partly true. 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 using a process): 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. Paul

We just need to wait for John to release the updated WAPID.dll. I see he checked the code into GitHub a few hours ago, so I guess the release will be soon. I also see there is a change to the public interface so I'll need to make a small change in my DLL and push it up to NuGet. But I can't do anything until we get the new WAPID.dll. Paul

I don't really know. If the problems are happening with WASMClient then it's not my DLL that's the problem. I do know John has made some changes to the WASM modules this week, but so far he hasn't updated the release package on FSUIPC. I think the new version is just in Beta at the moment. When it's released there will be an updated WASMClient that uses the new modules, and a new FSUIPC_WAPID.DLL that is used by my MSFSVariableServices. This might fix your problems. You should probably ask John about all this though,. Paul

Looks like you have a beta version with newer WASM and WAPI modules. You'll need to wait for John to also update the FSUIPC_WAPID.dll. That's what my MSFSVariableServices uses and where your error is coming from. You should be able to replace your existing version without any problems, although certain changes might require me to update my DLL. Paul

I can't see any updates to the client-side wasm libraries. It's still showing 0,5.9a as the latest version. If you want to check if there is a problem is with my DLL, please download John's WASM package called "FSUIPC WASM Module 0.5.9 + WAPI 0.5.10" from fsuipc.com. Unzip and find the WASMClient folder. In there, run the WASMClient.exe. It will allow you to connect, read and update LVars. If that doesn't work then the problem is either with the way the aircraft is written, or with John's WASM software. If iWASMClient CAN update those LVars then the problem is with my DLL. Let me know and I'll look into it. Paul

Microsoft.FlightSimulator.SimConnect.dl is a library supplied by the authors of the Flight Sim to enable .NET languages to interface with SimConnect directly. SimConnect is an API for reading and writing data to/from the Flight Sim. It was written to do the same job as FSUIPC. FSUIP4 and above uses SimConnect in the background. It's a library to enable programs written in any language to talk to John Dowson's WASM module for MSFS (2020). The WASM module allows the client program to read/write LVar and HVar variables from aircraft that use them. My FSUIPCClientDLL for ,NET uses this in the background for the MSFSVariableServices feature. You would use SimConnect if you didn't want to use FSUIPC. You would use FSUIPC_WAPID.dll if you want access to John's WASM module and you are not using my FSUIPCClientDLL for .NET. SimConnect is installed in the normal way you add any .NET library through Visual Studio - PROJECT-> Add Reference. You must have installed the Flight Sim sdk to get the SimConnect dll installed on your computer. The WASM dll is not a .NET dll, so this is just copied into the project and loaded at runtime with the [DLLImport] tag. You must also declare copies of each of the functions in the DLL that you want to access. In summary if you're using .NET just use my ClientDLL and everything is taken care of for you. You won't need to worry about either of these DLLs. Use of both of these DLLs requires advanced knowledge of programming. Paul

Hi, I don't have any plans to add an automatic update. In version 1.0.0 of the WebSocketServer I added a property to the 'about.read' response called 'newServerVersionAvailable'. Your web socket client program (or website) can check this. If it's 'true' it means that the WebSocketServer you are connected to is out of date. You can then warn the user and give instructions on updating. Will that fit your needs? Paul

Ah, yes. I've checked the offset status for FSUIPC7 - the writes for those offsets are not working yet. Apparently waiting for Asobo add an event: "Currently no available event. Reported to Asobo.". I don't know of any other way of setting three decimal frequencies. There might be an LVar you can use, but that would be specific to the aircraft you're using. Paul

When you get 0 back it usually means the LVar doesn't exist. Please see John's advice above. Alternatively, if this is a new application you might consider using the new MSFSVariableServices class. It's much faster than the ReadLVar() method, although it's a bit more complicated to use. One advantage is that it has an event that tells you when the LVars have been scanned and are ready to use. See this post for details: https://forum.simflight.com/topic/92372-added-support-for-lvarshvars-access-in-msfs-via-john-dowsons-wasm-module/ Or download the MSFSVariableServices example application from the website: http://fsuipc.paulhenty.com/#downloads Paul