Jump to content
The simFlight Network Forums

Paul Henty

Members
  • Posts

    1,644
  • Joined

  • Days Won

    74

Everything posted by Paul Henty

  1. I've updated the websocket server package (Version 0.3.3) to include the latest FSUIPC_WAPID.DLL. http://fsuipcwebsockets.paulhenty.com/ Paul
  2. The MSFSVariableServices part of the dll allows access to H: and L: vars (in MSFS only). This works via the WASM module loaded into MSFS. The main part of the dll talks to FSUIPC which in turn talks to the Flight Sim via SimConnect. This allows reading (and sometimes writing) of A: variables via FSUIPC Offsets. The offsets system was developed long before MSFS and SimConnect so the method of accessing the data is via numeric addresses rather than named variables. K: Events are known as 'Controls' in FSUIPC and can be activated using the FSUIPCConnection.SendControlToFS() method. For historic reasons the controls are also numeric but the dll provides enums for the various control sets to make it easier. I don't think reading XML vars is possible via FSUIPC. The MSFSVariableServices does have a method to execute "calculator code" via the WASM module. I've never used it, but if it's possible to do things with A: and K: and XML vars via calculator code then you could experiment with that. I don't know anything about it though so I don't know if it's possible or not. Paul
  3. Hi Andy, This sounds a lot like the work I did for you and Jason at the end of 2020. I'm pretty sure the FsLatLonPolygon can be used to do what you described. Paul
  4. The dll isn't writing offset 0x3F00 the second and subsequent times because the value has not changed. It was 1, but it's still 1 so no write takes place. The offset value is read instead. To make this work you need to mark the offset as write-only (set third parameter to 'True'). These type of offsets will be written every time you process them, regardless of whether the value has changed or not. They are never read. Dim oSaveCmd As Offset(Of Short) = New FSUIPC.Offset(Of Short)("saveflt", &H3F00, True) Paul
  5. Hi Hans, Probably best to make new threads. It's easier for others to search for specific problems. Yes you need FSUIPC for A and K. FSUIPC uses 'offsets' for reading and writing A variables. It uses 'Controls' to write to the K variables. FSUIPC has no way of using names; offsets and controls are numbers. My DLL does however have an enum for the Controls, so you can use names for controls via the enum, but I don't know if these names are the same as the underlying K variable. I would think so, but you'd have to ask John. Both FSUIPC and the WASM interface do use SimConnect. I assume they make their own separate connections. Yes, use the method ExecuteCalculatorCode() on your MSFSVariableServices object. No, the DLL is closed source. Paul
  6. Hi Hans, The two projects demonstrate two different ways of communicating with the Flight Sim. (Before MSFS there was just one - FSUIPC). FSUIPC - Shown in the FSUIPCExampleCode project. This doesn't require the WAPID DLL and doesn't use the WASM module. This allows getting and setting data via 'offsets', and sending actions to the Sim known as 'Controls' (some people call them 'events'). This does of course require FSUIPC to be running as that's what the DLL talks to. It can be any version of FSUIPC from 3 to 7 running in any supported flight sim (FSX, P3D, MSFS, XPlane). WASM - Shown in the MSFS_VariableServices project. This is only applicable to MSFS and requires both the WASM module to be installed in MSFS and the WAPID DLL on the client machine. This is limited to getting LVars (local panel variables) and setting LVars and HVars in MSFS. My FSUIPCClient library allows you to use one or both of these methods together to build your application. Which you use depends on what data you want to read/write from the sim and where that data can found (e.g. Offsets/LVars). If you only want LVars you don't need FSUIPC running. If you only use offsets you don't need the WASM module or the WAPID dll. There is no need as this example project is not using the WASM module, only FSUIPC. I think this depends on what folder you downloaded them to. Some folders are marked as 'trusted' but some are not. If you download to an untrusted folder you just need to mark them as trusted as you have done. The example projects are the main documentation as they show you all the features available and how to use them. There is reference documentation (links in the top right corner of most examples) but I don't think this is the easiest way to see what's available or learn how to use the library. The library has intellisense documentation that tells you what properties/methods/parameters exist while you're coding. Paul
  7. Hi Hans, The example projects had an old version of the FSUIPC_WAPID.DLL (0.5.3). I've just updated them to the new 0.5.5d version which will be compatible with the latest 0.5.5 WASM module. Please download version 1.1. of the variable services example project: http://fsuipc.paulhenty.com/#downloads Paul
  8. Version 3.2.11 is now available on NuGet with a .NET 6 DLL. From now on the package will have three DLLs targeting the following: net6.0-windows net5.0-windows net40 (.NET 4.0 Framework) Paul
  9. Yes, I'll have a look at this over the next few days. I'll post back here when I have something. Paul
  10. HI, Looking at the offset list, 3364 is only 1 byte. You've declared it as 4 bytes (Integer). You'll also be reading the data from the next 3 offsets which may be messing things up. Declare this offset as 1 byte (Byte): Private SimIsReadyToFly As Offset(Of Byte) = New Offset(Of Byte)("SIMSTATUS", &H3364) MSFS works differently than previous Microsoft sims and P3D. You may also need to check the next offset 3365 - "In Menu" to make sure that is also 0: Private SimIsInMenu As Offset(Of Byte) = New Offset(Of Byte)("SIMSTATUS", &H3365) From reading other threads about "Ready to Fly" in MSFS, you might also have to check the Pause flag to be 0. MSFS sets this at some point when loading the flight. If might not be necessary (I can't test it here) but just in case: Private SimIsPaused As Offset(Of Short) = New Offset(Of Short)("SIMSTATUS", &H264) You'll need to experiment with these offsets. Maybe monitor them as MSFS is loading the flight to get an idea of how they change and what the values are when you need to start your logging app. Paul
  11. I'm afraid so; the control events in Lua won't work if FSUIPC isn't seeing them. I can't remember if the PMDG aircraft use LVars. You can try listing the LVars and see if there is anything that looks useful... In the buttons or keypresses tab of FSUIPC you can bind the command "List Local Panel Vars". If you press this key/joystick button with the log being displayed in a console window you'll be able to see all the available Lvars and their current values. If any look promising you can read them with FSUIPCConnection.ReadLVar(). Other than that I can't think of any other way of detecting the operation of those buttons. Maybe not. @John Dowsoncan confirm. Paul
  12. Hi Amine, The PMDG interface to which is used by FSUIPC doesn't have any way to tell if the pilot pressed those buttons. When those buttons are pressed on the glareshield they should generate a custom flightsim control (also known as an event). However, the FSUIPC interface doesn't have any way to track events happening in the Sim. The only way I can see to do this is to use a Lua plugin: The FSUIPC Lua library has a way of intercepting controls with the event.control function which might work. If those switches in the cockpit generate a control (event) number then you should be able to trap it with Lua. Turn on the Event logging (or control logging - I can't remember which terminology is used) in the FSUIPC logging tab. Send the log to a console and operate the switches in the PMDG aircraft. If the events are logged then you can proceed. Note down the event/control number which you will need for your Lua function. Very briefly, the idea is to set up a Lua plugin to run a function when the control from those switches is sent. For this you use the event.control function. This function would update one of the free user offsets (using the ipc.write function) which you would then read from your VB application as normal. Using Lua requires users to have a registered copy of FSUIPC. The Lua documentation and examples are in the modules/fsuipc documents folder. If you can trap the events in the fsuipc log and you want to give this a go let me know and I can help you with the Lua part if you're new to Lua. Paul
  13. Sorry, I forgot to update the link. Should be okay now. Paul
  14. Hi Peter, The log shows that it's not even attempting to read the fuel tanks or write the radios. I had a good look at the VB project and all of the event bindings were messed up. I don't know why it worked okay on my PC here. I've gone through and fixed them all, so please get version 1.2 from the website. Everything should work okay now. http://fsuipc.paulhenty.com/#downloads Sorry for the inconvenience. Paul
  15. Hi Peter, The log doesn't show any IPC Read or Writes. I think it's because you made a new log and posted the wrong one... Please can you try again. With the logging (IPC Read/Writes) enabled in FSUIPC: Start FSX Use the example program to read the Radios Try to change a radio Try to read the fuel Close FSX. That should get the proper log. Paul
  16. Hi Joe, The server was designed for multiple clients so that shouldn't be a problem. For IPv6 addresses: there was a bug in the server which I have now fixed. Please get the latest version (0.5.2). For host names and IP addresses other than local: Windows does not allow binding to some IP addresses and hostnames unless the application is running "as Administrator". If you are getting the error "Access is Denied" then this is the problem. If you run the Websocket Server "as Administrator" then you also need to run FSUIPC7 and MSFS "as Administrator". Running the new version "as Administrator" should solve your problems. Paul
  17. Hi Peter, I don't know what could be causing this. It's working here with FSX/Windows 10. Sometimes third-party add-on aircraft don't use the standard FSX data for radios and fuel, but I see you've tried many aircraft. I assume that includes the default aircraft. Could you please enable the IPC Read and IPC Write logging in the Logging tab of FSUIPC. Then try the Fuel and radios again, shut down the sim and paste the log here. The log will be called FSUIPC4.Log in the Modules folder under the main FSX folder. That might give me some clues. Paul
  18. I don't know sorry. I can only suggest trying to set them with John's WASMClient.exe (from the FSUIPC WASM Module 0.5.5a.zip on fsuipc.com). If it doesn't work from there either then maybe ask John about it in the FSUIPC7/MSFS forum. If FBW have a support forum you might try asking there as well. Paul
  19. In my library the WAPI access is independent of the FSUIPC SDK. It can be used without a connection to FSUIPC. That's using FSUIPC/WideFS so nothing to do with SimConnect on the client machine. Do you mean this works on the remote (Client) PC or the MSFS PC? I think this is to select different connections set up within the SimConnect configuration file. So in the SimConnect file you can have a local connection (0) and a remote connection (1).
  20. The OP is wanting to use the WAPID.DLL (via my DLL) on a second machine, talking to the LVars WASM module on the MSFS PC. Am I right in thinking that's just SimConnect and doesn't use FSUIPC? Paul
  21. I can't help with this unfortunately as I've never done this myself. It might be better to ask in the FSUIPC7/MSFS sub-forum. John Dowson might know how to do this. Paul
  22. Hi Marc, You've declared these an standard read/write offsets (WriteOnly set to false). They will only send values if the value you sent is different from the current value (at last process()). If you want to send these values even if the current values are the same, you need to make them WriteOnly (set last boolean parameter to true). That way the offsets will write the value on every process. You won't be able to monitor the values with these offsets however. If you do want to monitor them and only send the values only when you detect a pause or different sim rate then leave them as read/write, but note that the DLL won't bother to write the values that haven't changed. e.g. if the user pauses, it won't send the simrate or slew mode. Earlier versions of the DLL did behave slightly differently in this regard, but it didn't really work properly so I had to fix it. I suspect you wrote this feature using one of those earlier versions and you're now seeing a different behaviour. Paul
  23. There should be a section on the download page for "MSFSVariableServices Example Code". Expanding that, you should see buttons for the C# and VB download. If not, press [CTRL-F5] for force the browser to download the new version of the page. It may be using a cached version. 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.