Issue with Lvar and WideClient

[Delphi]

Hi Paul,
I have a problem reading Lvars if my application runs on a remote computer. My application uses some of the GSX Lvars. Works fine if the application is running on the FS PC. On the remote PC the reading of all GSX LVars is '0'. I do not user the private offset range 0x66F8-0x66FF. Some help would be very appreciated.

Ruediger

[Paul Henty]

Hi Ruediger,

I assume you are using the FSUIPCConnection.ReadLVar() method. Unfortunately this doesn't work over WideFS. WideClient is sending your application a cached value, without waiting for the real value to arrive from FSUIPC. This is because of the way this feature is implemented in FSUIPC.

There is a workaround I can try but it will make each LVAR read at least three times slower. They are not fast at the moment so I suspect slowing them down by three will make it unusable. If you're only reading a few LVARs and not very frequently then I can add a new method for reading LVARs over WideFS if you want to try it.

Paul

[Delphi]

Hi Paul,
I'm fine as it works. I can run the application on the FS computer. Thanks for your offer to add a new method for reading Lvars over WideFS. Don't inverst time for it.

Ruediger

[MBS]

Hi Paul,

I have the same Problem when reading several LVars on my Application. I don't have the possibility to run it on the FS Computer.

Is there a solution possible to get it with the Client.dll, I read about 10 LVars and that every second. I can extend the time if needed? 

Regards

Matthias

[Paul Henty]

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

[MBS]

Hi Paul,

Thank you for your quick answer and your support.

Matthias

[Delphi]

Hi Paul,

I will try the workaround, too. Running my GSX application on the remote computer would make the handling more comfortable.

I will let you know the results.

Ruediger

[Delphi]

Well, technically it works but it slows down the communication. Best way still is to let the application running on the FS computer if it is required to read Lvars.

Ruediger

[buick552]

Well.. I am having the same problem.. any improvement on the issue? Besides, is there any way to detect if the user runs widefs? I'd like to try this work around only if the user is on widefs. Normal users should go as they were.

[buick552]

Paul, to be clearer...

 

My app has a dll which reads LVars on specific aircraft. For example, PMDG 738ngxu, Leonardo's MD82, QWings 787 and some more aircraft like these do not use standart offsets for lights. That's why I created a dll. If the aircraft is one of them then the app asks the dll to read the Lvar and return the value. The dll currently searches for the values of strobe, nav light, beacon, landinglight, taxi light, seatbelt light, door and parking brake. As far as I see, all specific aircraft produce "a number" in return when you ask for the value of the Lvar. 

 

So.. let's say the user is on widefs. If my dll asks the aircraft for the value of an Lvar (one the Lvars above), and receives a numeric answer, is it possible to put that value on a free offset, and then the app goes and reads the value of that offset? Would it also be a workaround instead of slowing down the dll?

[Paul Henty]

Quote

. any improvement on the issue? 

Not for FSUIPC versions before 7. This is just how it works and isn't going to change now as development is closed on most of the FSUIPC versions.

For FSUIPC7 the new MSFSVaraibleServices can read many LVars very quickly via the WASM module. This doesn't use WideFS but uses a SimConnect connection. So on remote machines you just set up a remote SimConnect connection.

Quote

, is there any way to detect if the user runs widefs?

Yes, just check the property called FSUIPCConnection.IsConnectedToWideClient

Quote

is it possible to put that value on a free offset, and then the app goes and reads the value of that offset? Would it also be a workaround instead of slowing down the dll?

The value is already put into a free offset by FSUIPC (0x66F8). The issue is that WideFS doesn't transmit this to the WideClient until a few milliseconds after the LVar request is made. This means a second process call must be made to get the value. When running on the FS machine the value is available in the same Process() call.

 

Quote

Would it also be a workaround instead of slowing down the dll?

No. The easiest solution is to detect WideFS and use the slower method of access posted above (basically, a second process call to get the data).

For FSUIPC3-6 the only true workarounds would be:

1. A Lua Plugin that runs in FSUIPC on the FS machine which reads read the lights etc. from whatever LVars you need to and places the values into free offsets. Then your application reads from the offsets. This would require users to have registered FSUIPC and install the Lua plugin.

2. Write your own 'server' program that always runs on the FS machine that reads the LVars. Then either use the offset method like for Lua, or set up your own TCP/IP communication to read the values directly from your server program.

Paul

[buick552]

Paul, I appreciate your precise and quick answer. Thank you very much. Things are clearer now, let's see what we can do about this..

[buick552]

On 9/28/2021 at 10:48 AM, Paul Henty said:

2. Write your own 'server' program that always runs on the FS machine that reads the LVars. Then either use the offset method like for Lua, or set up your own TCP/IP communication to read the values directly from your server program.

Paul

Hi Paul, is it possible to show an example of that server and of the TCP/IP communication via VB.net?

[Paul Henty]

17 hours ago, buick552 said:

Hi Paul, is it possible to show an example of that server and of the TCP/IP communication via VB.net?

Not really, it would take hours to write and test and it would very long.

Over the next few days I'll look into adding a simple client/server that uses sockets to my DLL. It'll just allow you to send text back and forth with a few lines of code, but that should be sufficient for most things.

Paul  

[Paul Henty]

I've thought about this a bit more.

I have already written a websocket server for transferring FSUIPC data. 

http://fsuipcwebsockets.paulhenty.com/#home

It works with any version of FSUIPC from V3 onwards, but is included in the FSUIPC7 installer.

It would make more sense for me to write a .NET library that will talk to this server. (It was designed for Javascript on Web pages but any language that can use websockets can use it).

I will also need to extend the server to use the historic LVARs. At the moment it only reads LVARs from FSUIPC7/MSFS using John's WASM module.

It'll take a few weeks, but this solution will bring the most benefit to everyone and open up the websocket server to all .NET languages.

Paul

[buick552]

Oh my god.. Paul.. you are awesome.. Thank you very much. I will download and start working on it as soon as possible.

[Paul Henty]

You're welcome, but if you wait for the new client library I'm writing it'll be easier than writing the WebSocket client yourself. 

Paul

[buick552]

I sure will. I am looking forward to receiving this new library (dll) to start communicating with this server. You and Dowsons have contributed a lot to this community. We really owe you a lot.

[Paul Henty]

All done. You'll need the latest WebSocket server (V1.0.0):

http://fsuipcwebsockets.paulhenty.com/

There is a new section on that website for my new WebSockets .NET Client. This gives you all the details on how to use it. The NuGet package is called FSUIPCWebSocketsClientDLL.

There is example code on the website, embedded in the main documentation in JavaScript, C# and VB.NET. There are also separate example code applications (C# and VB) that you can download from the section called "Example Code Projects" under ".NET Client".

If the WebSocket server is connected to FSUIPC7 it will use the new WASM module to get LVARs. If it's anything earlier than 7 it will fall back to the legacy LVar access like FSUIPCConnection.ReadLVar() in the FSUIPCClientDLL.

You'll notice that the websocket server also allows for reading/writing offsets. You can of course still use the FSUIPCClientDLL for offsets, and just use the WebSocket server for LVars if you want.

If you have any questions or problem, please start new threads on this sub-forum.

Paul