Jump to content
The simFlight Network Forums

Paul Henty

Members
  • Posts

    1,652
  • Joined

  • Days Won

    74

Posts posted by Paul Henty

  1. It doesn't look like these work in FSUIPC7.

    The dll uses the FSUIPC facilities at offsets 0x3210 (keypresses) and 0x2910 (joystick buttons).

    The offset status spreadsheet for FSUIPC7 says that 0x3210 is "Probably not working". 0x2910 has a status of 'unknown/untested'.

    You'll need to ask John if there are any plans to implement these features in FSUIPC7.

    Paul

  2. I've experimented with different types of .NET6 projects. I managed to reproduce the error by using a .NET6 Console application.

    The problem was that by default, console applications do not target the windows operating system. The DLL uses the .NET6-Windows framework (net6.0-windows), so your application needs to also target Windows specifically. (An FSUIPC client cannot run on any other operating system because it uses the Win32 API).

    I suspect your application is also not set to target Windows.

    Check your project properties and set to Windows if it's not already:

    image.thumb.png.fb87931695a419588c7191d8ce3ee035.png

    Paul 

     

  3. I don't know what else to suggest. I'm pretty sure the NuGet package is okay. I've made a new .NET 6 project here and added the NuGet package and it compiles fine.

    Maybe you can test it on a new project. If you don't get the error on the new project then it must be something to do with the configuration of your current project/solution.

    Paul

  4. Not sure what this could be. Sounds like something has gone wrong with the package management in your project.

    Try going to NuGet and updating to the latest version (3.2.16).

    If that doesn't work try removing the package from the solution explorer and then adding it in again via NuGet.

    Paul

  5. Quote

    you could maybe try a test with duplicate hvar names, to see if that is the issue.

    ahh yes that would cause a crash in the socket server/client dll. The code assumes they are unique. I'll add a check to make sure I'm not attempting to add duplicates. I'll do the same with LVars as well.

    Thanks for narrowing this down.

    Paul

  6. Have you changed anything about how HVars are handled since 0.5.5d?

    I don't think there is much I can do. My software only talks to the WAPID dll. If that hasn't changed (except for the version check) and my software hasn't changed (except for its version number) I don't think the problem can be on my side of things.

    Usually I would debug everything here and track down exactly where the problem is, but I don't have MSFS anymore.

    Paul

  7. 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

  8. 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

  9. Hi Hans,

    Probably best to make new threads. It's easier for others to search for specific problems.

    Quote

    But if I want to use other variable types, like A:, K:, etc..., I assume I need to use the FSUIPC part, right? But is everything controlled through Offsets? Or are there ways to control things by name?

    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.

    Quote

    And does that require a second SimConnect connection?

    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.

    Quote

    Is there also a function "Execute_Calculator_Code", 

    Yes, use the method ExecuteCalculatorCode() on your MSFSVariableServices object.

    Quote

    Is the sourcecode of your C# implementation available somewhere?

    No, the DLL is closed source.

    Paul

  10. 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.

    Quote

    FSUIPC_WAPID.dll was not included 

    There is no need as this example project is not using the WASM module, only FSUIPC.

    Quote

    There were 4 "*.resx" files for which I needed to remove "the mark of the web"

    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.

    Quote

    I'm sure you have somewhere included a list with all the functions with their parameters, or are the examples meant for that?

    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

  11. 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

  12. Quote

     does this  it mean it's a dead end?

    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.

     

    Quote

    is FSUIPC supposed to be able to capture Custom events at all?

    Maybe not. @John Dowsoncan confirm.

    Paul

  13. 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

     

  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...

    Quote
    [Log closed by user request, and continued in new file]

    Please can you try again. With the logging (IPC Read/Writes) enabled in FSUIPC:

    1. Start FSX
    2. Use the example program to read the Radios
    3. Try to change a radio
    4. Try to read the fuel
    5. 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

    • Thanks 1
×
×
  • 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.