Jump to content
The simFlight Network Forums

Paul Henty

Members
  • Content Count

    1,069
  • Joined

  • Last visited

  • Days Won

    34

Paul Henty last won the day on June 3 2019

Paul Henty had the most liked content!

Community Reputation

58 Excellent

4 Followers

About Paul Henty

  • Rank
    Advanced Member
  • Birthday 01/01/1970

Profile Information

  • Gender
    Male
  • Location
    Gloucestershire, UK

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Not without losing focus, no. The DLL has a method FSUIPCConnection.SendKeyToFS(). There are some overloads that take a reference to a form in your application to return the focus to. e.g. The following line will: 1. Send a request to FSUIPC to fire an 'm' key press. 2. FSUIPC will make FSX the active window then send the 'm' key press 3. The DLL will then return focus to your form FSUIPCConnection.SendKeyToFS(Keys.M, this); The round trip for this is about 300ms, so you might see a flash as the FSX screen comes to the foreground. I suggest trying it and seeing if it's acceptable. If it must be done by a key press then this is the best that can be done. The way Windows works, only the foreground (focused) window can read the keyboard buffer. It's impossible to send a key press to a specific window that isn't in focus. Windows only has a single, global, keyboard buffer and only the focused window can read it. The alternative would be if ADE can use another method to receive instructions. e.g. if it responds to custom FSX controls (also known as 'events'), or values written to FSUIPC offsets. These can be used while the FSX window is in the background. But, this would require that the authors of ADE have built in such a feature and are listening for these signals. You would need to ask the authors or see if there is anything in the documentation. Paul
  2. It's just the way LVARs are read and written from an external program. The FSUIPC external interface can only process one LVar at a time. So each LVar requires a complete data exchange cycle (Process() Call). This takes time so reading 20 or more Lvars in real time isn't very practical from an external program. This doesn't apply to normal Offsets of course, just LVars. Yes, both require FSUIPC. Lua needs a paid (registered) copy. External programs can use a free (unregistered) copy. This seems like the sort of thing the Lua system was intended for, but I can't say how easy it would be; I'm not a Lua expert and don't do anything with hardware. If you have a registered copy of FSUIPC I would try Lua first and see if you can get a switch and a LED working. Paul
  3. Hi Peter, The two technologies are used for different kinds of tasks, so It really depends on what your program will do. Generally Lua can be thought of as a way of writing 'plug ins' that extend the functionality of FSUIPC. Typical uses are driving hardware connected to the sim monitoring the flight, looking for certain conditions then taking actions (e.g. play a cabin announcement at the right time) creating functions that can be bound to buttons/keys (e.g. set fuel to 80% when a key is pressed) creating simple display windows to show information from the sim. (e.g. calculate time until fuel runs out and show it in a window in real time). Using the DLL in an external program is better (or required) if any of these are true: you need a complex user interface where users need to interact with your application (selecting menus, filling out forms etc, drawing charts) the application needs to do other things beside interacting with FSUIPC (e.g. has a flight planner than plans routes) the application will require hundreds of lines of code (debugging and code organisation is much easier in Visual Studio) Other considerations: Lua scripts can only be run on a registered copy of FSUIPC. An external program can be used with an unregistered copy. If you want others to use your program this might be a consideration. If you need to access many L:Vars (Panel Variables) Lua is much more efficient for this. Hopefully that helps. If you're still unsure let me know what your program will be doing and I can give more specific advice. Paul
  4. Hi Jason, Unfortunately you won't be able to use my DLL in a UWP application. UWP Apps are run in a sandbox and do not have access to the full Win32 API. This API is what FSUIPC uses to communicate with all the flight sims as they were written as windows 'desktop' applications. A UWP app therefore will not have the means to communicate via FSUIPC. You might be able to use the managed SimConnect library in UWP as this uses standard network protocols rather than WIn32. But I don't know for certain as I'm not that familiar with SimConnect. If you want to stick with FSUIPC and use my DLL (which is much easier than SimConnect) you'll need to choose between WinForms or the newer, more modern-looking WPF framework. Paul
  5. Gauges can't be created with C# unfortunately. You would need to use C++ or XML. Paul
  6. I don't know any way to accept a string input inside of the Flight Sim. I don't think that's possible. You would have to do this on a form or message box in your own application. You can respond to key presses in the sim. So you could display a list of options and then wait for the user to press the appropriate key (or key combo) in the sim. See the example code application under 'Input Services', specifically IS001_KeyPresses. Paul
  7. Yes the DLL is written in C# so I would be able to paste your function in. If you'd like to paste it here, or send it in a private message, I'll consider including it in the DLL. Thanks, Paul
  8. Hi Matthias, Yes it's possible. I've included some code below (VB and C#). Call this new function (ReadLVarWideFS) in the same way as you call FSUIPCConnection.ReadLVar(). It works by reading the value some milliseconds after the normal ReadLVar is called. This gives time for WideFS to see the change and update its cached value for the user offset. This obviously slows things down a lot. On my system here a 150ms delay produces reliable reads. You'll need to experiment. Maybe your system can use a lower value, or maybe, if you have a lot of other WideFS traffic, or lots of add ons, or a slower PC, you might need to increase this time. C# private Offset<double> lvarData = new Offset<double>("LvarData", 0x66F8); private int WideFSLVarDelay = 150; private double ReadLVarWideFS(string LVAR) { FSUIPCConnection.ReadLVar(LVAR); Thread.Sleep(WideFSLVarDelay); FSUIPCConnection.Process("LvarData"); return lvarData.Value; } VB.NET Private lvarData As Offset(Of Double) = New Offset(Of Double)("LvarData", &H66F8) Private WideFSLVarDelay As Integer = 150 Private Function ReadLVarWideFS(LVAR As String) As Double FSUIPCConnection.ReadLVar(LVAR) Thread.Sleep(WideFSLVarDelay) FSUIPCConnection.Process("LvarData") Return lvarData.Value End Function Paul
  9. If you are upgrading from version 2, then there are a few breaking changes, but nothing major. Also the DLL is now delivered as a Nuget package. There are instructions and a video on my website about upgrading from version 2. http://fsuipc.paulhenty.com/#help Let me know (new thread please) if you have any problems. Paul
  10. Hi, First you need to decide which Offset you are going to write to. There is a block of unused offsets starting at 0x66C0. Also decide how many bytes you need for the value and what data type you want. Then declare this offset. For the seat belt status we only need one byte so we'll declare it like this: Private pmdgSeatBelt As Offset(Of Byte) = New Offset(Of Byte)("PMDG", &H66C0, True) Then, to read the LVAR and copy the value into that offset you do this: (I don't know that the actual LVAR name is - I've just made something up here). ' Read the LVAR Dim seatBeltSwitch As Double = FSUIPCConnection.ReadLVar("L:SeatBeltSelector") ' Write value to user offset pmdgSeatBelt.Value = CByte(seatBeltSwitch) FSUIPCConnection.Process("pmdg") However, do you really need to copy it into an offset? You already have the LVAR value when you execute the first line (value is in seatBeltSwitch). Also, reading LVARs is very very slow compared to offsets. You should only use LVARs as a last resort. The PMDG 737 (and other PMDG aircraft) have a special set of offsets. You can find these in the PDF file in the "Modules\FSUIPC Documents" folder. e.g. "Offset Mapping for PMDG 737NGX.pdf". The offset for the 737 seatbelt selector would be declared as: Private PMDG_737_FastenBeltsSelector As Offset(Of Byte) = New Offset(Of Byte)("PMDG_737", &H649F) See the document for how to enable these offsets. I recommend using these offsets instead of LVARs where available. Paul
  11. You'll probably need to ask XPUIPC support. For this to work XPUIPC would need to support the new 64bit FSUIPC interface (UIPC64_SDK_C_version2 in the FSUIPC SDK). Paul
  12. @Patrick Weber That's great. Thanks for testing it and getting back to me. @John Dowson I've attached a ZIP file for the 64 Java SDK. It includes the new compiled library files and the modified source code projects. Paul UIPC_SDK_JAVA_64bit.zip
  13. Hi Everyone, I had a go at sorting this out and I think I've it working for 64bit Java. Attached is a zip containing: fsuipc_java64.dll - This is the Java/C wrapper around the 64bit version of the C User Lib (Version 2). fsuipc64.jar - The FSUIPC Jar library compiled to use the new 64bit wrapper. Everything should work exactly the same as the 32-bit versions. I've tested it on WideClient 7.1.5.6 and it works fine. I cannot test it directly connected to a flight sim because I don't have any 64bit Sims. I doesn't work connecting directly to 32-bit sims but I'm pretty sure that's to be expected. I don't think "UIPC64_SDK_C_version2" works with FSUIPC3 or 4. Perhaps John can confirm. I took the liberty of adding a new function called "GetResult()" which returns an int. This is useful to get the error code after a process() or open() fails. I needed this while I was testing. If these files work I will give John the new source so he can add it to the SDK. Paul FSUIPC_JAVA64.zip
  14. Okay - thanks for the tests. It looks like FSUIPC6 is not giving the correct minor and build version from offset 0x3304. @John Dowson Can you look into this please? 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.