Jump to content
The simFlight Network Forums

Paul Henty

Members
  • Posts

    1,644
  • Joined

  • Days Won

    74

Everything posted by Paul Henty

  1. Yes, you can use the MSFSVariableServices class in my DLL. Make sure you have version 3.2.19. The main documentation for this class is a separate example project. You can download it here: http://fsuipc.paulhenty.com/#downloads Also, the first post in the following thread has an overview of this class, requirements and how to use it: https://forum.simflight.com/topic/92372-added-support-for-lvarshvars-access-in-msfs-via-john-dowsons-wasm-module/ I don't think so, people seem to be using LVars and HVars for this aircraft. Paul
  2. Probably you have not enabled the second CDU broadcast in the ini file: (In bold below). If you have that line but it still doesn't work, let me know and I'll investigate more. Also let me know which flight sim you are using. Paul
  3. Version 3.2.19 is now on NuGet. Details of the changes to MSFSVariableServices are here: https://forum.simflight.com/topic/94374-breaking-changes-for-msfsvariableservices-in-version-3219/ Paul
  4. Version 3.2.19 Unfortunately, I've had to introduces some breaking changes to MSFSVariableServices. This had to be done as the old way was wrong and was (understandably) causing confusion for users working with this class for the first time. The breaking changes are: 1. The MSFSVariableServices is now a static class. Until now, you needed to make an instance of the class: e.g. MSFSVariableServices vs = new MSFSVariableServices(); This implies that more than one can be created and that you can dispose of this class. This is not the case because of how the FSUIPC_WAPID.DLL works. Now you directly access the class using it's name. e.g. MSFSVariableServices.Start(); You can no longer create instances. If you don't like using the full name you can create an alias at the top of your code file: C# using VS = FSUIPC.MSFSVariableServices; VB.NET Imports VS = FSUIPC.MSFSVariableServices This will let you just use 'VS': VS.Open(); 2. You can no longer access an LVar or HVar based on it's ID. You can only use the variable name now. The ID was arbitrary and had nothing to do with MSFS. I can't imagine the ID was useful at all so it's been removed to simplify things. Bug fix: MSFSVariableServices.CreateLVar() now accepts a double instead of an integer. Improvement: Any FsLVar/FSHVar objects you keep a reference to will persist between Reload() and Stop()/Start() calls. This means any ValueChanged events you have registered will still be valid. In the previous version, new FsLVar/FsHVar objects were created by the DLL meaning your exiting references and events stopped working. The example code applications in C# and VB.NET have been updated (V1.2) to use the new version of the DLL: http://fsuipc.paulhenty.com/#downloads Paul
  5. I will be making changes to MSFSVariableServces to prevent both these problems. Paul
  6. I don't have MSFS here so I'm not sure how useful your project will be. I can certainly have a look and see if I can see anything obvious. But I won't be able to run and debug it. I still recommend the three steps in my last post: The debug/trace level log will likely show the problem. My example code should work and will show you if the DLL works okay. John's client program will show if the problem is in your MSFS/FSUIPC install is okay. Paul
  7. I've been looking into this in more detail. When I made MSFSVariableServices a normal class, this was a design mistake by me. It should have been a static class. The FSUIPC_WAPID.dll that I use is written in a singleton pattern, and only one copy of that DLL can be loaded by my dll. So it doesn't make sense to dispose the MSFSVariableServices once you create it. Setting the reference to null means that the .NET garbage collector will dispose of it for you. I will change this to a static class in the future, but for now you should not dispose it or lose the reference to it by setting it to null. This is a separate issue from the above. Here are some things you can try to find the problem: 1. Turn the logging level up (e.g. debug/trace) and see what the log says when the connection fails. 2. Try stopping and starting with my example code application for MSFSVaraibleServices: (You might need to update the FSUIPC_WAPID.dll and my DLL via nuget). http://fsuipc.paulhenty.com/#downloads If this works then something is different in your code. You can compare them. 3. Try stopping and starting with John's client program in the FSUIPC-WASMv0.5.6 package (\WASMClient\WASMClient.exe). If this doesn't work either then there is problem with John's code, or your setup. Paul
  8. Hi, First, can you please check that you're using all the latest versions: My DLL: 3.2.17 (Update on NuGet) FSUIPC: 7.3.1 (http://fsuipc.com) FSUIPC_WAPID.DLL from the 0.5.6 version of the "FSUIPC WASM Module" package. (http://fsuipc.com) If you're still getting the error: Are you disposing of the MSFSVariableServices object, or setting the reference to null when this happens? I think when you call stop() the WASM module will try to send back a log message to say it's shut down. If the MSFSVariableServices class no longer exists it'll throw this exception. The best thing is to keep the instance alive once you've created it. Calling Stop() is enough to shutdown the connection. If none of that helps, perhaps you can post your code where you call Stop() and also where you create the MSFSVariableServices. Paul
  9. If you're using Simconnect and MSFS there is a SimConnect variable called CAMERA_STATE and one called CAMERA_VIEW_TYPE_AND_INDEX which looks like it will do what you want. You can make a request to John to add these as offsets. https://docs.flightsimulator.com/html/Programming_Tools/SimVars/Camera_Variables.htm I can't see anything like this in the P3D reference though. It depends if all views use the same 'eye-point' or not. The coordinates returned from this function are relative to the eye-point. So if the external view eye-point is different to the cockpit eye-point then you won't be able to do this. If they are the same you would then need to know the rough geometry of the plane to know if you were inside or out. Paul
  10. You can try offset 0x8320 (1 byte). The documentation suggests this might not be reliable. I don't know if this works in FSUIPC7. That would be the only way using FSUIPC. Paul
  11. If you want to run everything on the NET core 3.1 runtime then you'll need a specific version of my dll for that. Your app might work with the existing dll, but your users will need the correct .NET runtime installed. I suspect it will use the 4.6 Framework version, so they'll need that as well as your core 3.1 runtime. I'll have a look tomorrow to see if it's possible for the dll to target core 3.1. I believe it includes Winforms so it might be okay. I know I couldn't do Core 2 as there was no winforms. I don't think I tried 3. Paul
  12. NAudio is free (MIT licence) and you can extend it to play ogg files with the additional NAudio.Vorbis library. Both are available on NuGet. https://github.com/naudio/NAudio https://github.com/naudio/Vorbis Paul
  13. FSUIPC can play sounds within the sim via offset 0x4200, but it's limited to .WAV files only. If you want to try this, I can give you some example code. The only other alternative is to have your application play the sounds using the System.Media.SoundPlayer class. This supports all types of sound files, but of course will play on the computer that your application is running on. https://stackoverflow.com/questions/3502311/how-to-play-a-sound-in-c-net Paul
  14. Hi Matthias, For MS2020: I'm not sure that FSUIPC7 supports writing to these offsets at the moment. In the FSUIPC7 offsets status spreadsheet (offsetStatus-v0.27.ods) the payload offsets (starting at 0x1400) are marked as okay for reading but unknown/untested for writing. If you are testing with a third-party aircraft try one of the built-in aircraft. If you still have no luck you can ask John about this in the MSFS/FSUIPC7 sub-forum. For XPlane: XPUIPC is only a partial emulation of FSUIPC. Some offsets are not supported. It sounds like the payload offsets haven't been implemented. You'll need to check with the developers if they are still supporting XPUIPC. An alternative to XPUIPC is to use the 'XPlaneConnector' library (also on NuGet). It works differently to FSUIPC but does allow access to all the XPlane data. It works well but it's not well supported. If you need to read/write strings you'll need to download the source and compile it yourself as the NuGet package is out-of-date and doesn't support strings at the moment. https://github.com/MaxFerretti/XPlaneConnector Paul
  15. Hi Matt, Some things to check: 1. Your joystick/button IDs should be the same a FSUIPC displays on it's "Buttons and Switches" tab when you press the joystick button. 2.The buttons presses are only detected when the Flight Sim window has focus. It won't work if FSUIPC7 or your application are in focus. 3. Can you please let me know the values of offsets 0x2910 and 0x290C running under FSUIPC7, but *without* using any of the User Input features: (Both are 4-byte ints) I would test everything here myself but I don't have MSFS. Those offsets should tell me if there is a problem with FSUIPC7. If none of this helps I can prepare a version of the DLL with debug logging that should pin the problem down. Thanks, Paul
  16. There nothing for me to do; user input services is already in the DLL and works fine in FSUIPC4,5 and 6. To check if it works in FSUIPC7, please try the UserInput examples in my ExampleCode solution on the website: (Please update my DLL to the latest version as these solutions tend to restore a previous version). http://fsuipc.paulhenty.com/#downloads If those examples do not work with FSUIPC7 then let me know and I'll speak with John to see where the problem is. Let me know if there are any exceptions thrown. If they do work then compare the example code with your code. When you test your code, make sure you're not ignoring any Exceptions with blank Catch() blocks. Any exceptions thrown by the DLL could point to what the problem is. Paul
  17. You can combine the modifier keys with the bit-wise 'or' operator (| in C#) like this: FSUIPCConnection.SendKeyToFS(Keys.F1, SendModifierKeys.Control | SendModifierKeys.Shift, null); Paul
  18. 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
  19. 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: Paul
  20. 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
  21. 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
  22. @ScotfleigerCan you please try the version attached? This should be okay if your plane has duplicate HVars. Thanks, Paul FSUIPCWebSocketServer_V0.3.4.zip
  23. 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
  24. 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
  25. I've not changed anything in my code. On github it didn't look like anything substantial changed in the WAPID.DLL, just the version number. Did you change any of the function/callbacks (parameters/return values)? 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.