[Added Support for LVars/HVars Access in MSFS via John Dowson's WASM Module.]

Hi everyone,

John made some very useful changes to the WAPI DLL. 

This has enabled me to improve the way the MSFSVariableServices works. See version 3.2.3-Beta of my DLL. Note that you will need version 0.5.0 or later of the FSUIPC_WAPID.dll. (See the first post for the location of the download).

The first post in this thread has been updated to include the new changes and also a quick-start example.

The main change is that RefreshData() has now been removed. You don't need to call this anymore because it's now purely event-driven.

The MSFSVariableServices module will now automatically maintain the current LVar values in the background (according to the LVARUpdateFrequency property).

Two new events are now available:

OnVariablesReadyChanged will tell you when the variable have been discovered by the WASM module and it's ready to use. (Check the OnVariablesReady property).

OnValuesChanged will tell you when at least one of the LVar values has been changed. 

I can't test here so please report success/failure here.

Thanks,

Paul

[LVAR access with FSUIPC 7.1.0]

Hello,

Quote

is it now possible read LVARs via old method 

I don't know, sorry. I don't use FSUIPC7 so I'm not following it's development. I can only suggest trying it.

If John has added LVAR access via offset 0x0D70 then the ReadLVar() method will just start working again.

I remember you having problems with MSFSVariableServices. Have you given up with it?

John is upgrading his WASM API soon which will allow me to make considerable improvements to MSFSVariableServices. Mainly, it will let you know when the LVars are ready to read (so no more waiting random seconds) and also it will move to a purely event-driven model. i.e. No need for RefreshData() anymore. Hopefully this will solve the problems people are having with timings and variable discovery.

Paul

[P3D v4.5 stürzt ab, wohl duch FSUIPC6]

Quote

 Kann es mit den Tools zusammen hängen?

Try flying without the tools. If it doesn't crash then one of the tools is the problem. Add back your tools one at a time until you find the problem tool.

If it still crashes without tools then it could be the P3D installation itself, or hardware issues, or driver (e.g. graphics card) issues. 

You should also make sure you are running the latest updates to P3D, your tools, aircraft, graphics drivers etc.

It would be better to ask about your problem on the P3D support forums. They also have troubleshooting guides there. I can't help you any further here as this is a programming forum and I don't have P3D.

Quote

arum kann man hier nicht vernünftig schreiben.

I don't know sorry. I don't have any problems but only write in English. 

Paul

[P3D v4.5 stürzt ab, wohl duch FSUIPC6]

The message in your picture is from an application that uses FSUIPC to communicate with P3D. When your P3D crashes, this application cannot get a reply from FSUIPC so it shows this error.

You need to find out why P3D is crashing. This message if not from P3D or FSUIPC.

Paul

[FS9 problem: not all data is read]

Very strange.

I notice that your example code application is out of date. Can you please try with the latest version, and update it's copy of the client dll to the latest stable or beta version.

Paul

[FS9 problem: not all data is read]

Thanks. I still can't think what could be causing this.

Please can you try using a different FSUIPC client. I suggest FSInterrogate2std.exe from the FSUIPC SDK:

Read the Aircraft Info in that program to see if's working there:

1. Goto the Interrogate Tab

2. Type in an offset range from 3130 to 3177

3. Press [Setup fields]

4. Press [Select all] on the toolbar

5. Press [Read buffer-1] to get the values (They should appear in the last column).

 

If this program also doesn't get the values then there's something wrong with FSUIPC itself or maybe FS2004.

Paul

 

[FS9 problem: not all data is read]

I've tried here with FS2004, the latest version (3.2.2-Beta) of my FSUIPC Client DLL and FSUIPC 3.999z9b and it works fine.

To check if the problem is with my DLL or not, can you please log the following two offsets in FSUIPC:

E004 (U16) and F004 (U16).

These will show how many ground and airborne AI planes FSUIPC is seeing. 

Let me know the results.

Thanks,

Paul

 

[Added Support for LVars/HVars Access in MSFS via John Dowson's WASM Module.]

Quote

now it doesn't work and it crashes as pictured.

It crashes because that HVar doesn't exist. You can see the list of LVARs and HVARs found by using LogHVars() and LogLVars(). What do they show?

Remember that you need to wait a few seconds after Start() before the WASM module is ready.

Paul

[Added Support for LVars/HVars Access in MSFS via John Dowson's WASM Module.]

Quote

the WASM Client connected, but does not collect any LVARS,

There seems to be a problem somewhere other than your code/my dll then. The best thing to do would be to ask John about this in the MSFS support forum under a new topic.

If you tell him the WASMClient.exe is connecting but not finding any LVARs he may be able to suggest things to check,

Paul

[Added Support for LVars/HVars Access in MSFS via John Dowson's WASM Module.]

Your code looks okay now.

Can you please try running John's WASMClient.exe program to check if that is returning any LVars. You can find it in the FSUIPC-WASMv0.4.10.Zip file.

Paul

[Added Support for LVars/HVars Access in MSFS via John Dowson's WASM Module.]

You need to call loglvars after you call refreshdata. 

[Added Support for LVars/HVars Access in MSFS via John Dowson's WASM Module.]

You'll need to add a call to VS.RefreshData() after the sleep, and before you try to read the LVAR.

If it still doesn't work try the following:

1. Waiting longer than 2 seconds.

2. Check the list of LVar names at VS.LVars.Names to see all the LVars that have been found. (If you have logging set up you could also use VS.LogLVars())

Paul

[Added Support for LVars/HVars Access in MSFS via John Dowson's WASM Module.]

Make sure your exe is compiling and running as a 64 bit process. The FSUIPC_WASPID.dll is 64bit so cannot be loaded from a 32-bit process.

In your exe project properties, go to the Build tab. Make sure your platform target is either x64 or "any cpu". If it's "any" make sure the box for 'prefer 32bit" is NOT checked.

Paul

[How to use custom events?]

I can't help much as I don't have MSFS. From what I know:

1. HVars need to be added to a file somewhere so that the WASM module knows about them.

2. You need to wait a few seconds after calling Start() as the WASM module needs time to discover the variables.

3. HVars do not have values. They are only actions that can be 'Set()'.

4. When you change aircraft or change the HVar files you need to call MSFSVariableServices.Reload() to discover the new variables for that aircraft.

If you've added these variables to the file and you've waited for the WASM module then @John Dowson may have some more suggestions.

Paul

[Added Support for LVars/HVars Access in MSFS via John Dowson's WASM Module.]

On 5/3/2021 at 5:59 PM, kingm56 said:

Hello, My Friend!  Is the beta 3.2.1-Beta available via NuGet package?  

Yes, but for Beta versions you must check the box "Include Pre-release" in the Nuget manager..

Paul

[How to use custom events?]

Quote

I'll let @Paul Henty comment if using this with his .net client dll.

My .NET Client DLL now has direct access to LVars/HVars in MSFS from managed code via the MSFSVariableServices class. See here:

This uses John's WAPI DLL in the background.

Paul

[PMDG 777 CDU data]

 

Quote

 checking the data for COMM_ReceiverSwitches[0] at offset 6C5A

If it is then WheelChocksSet must be 6C60.

Paul

[PMDG 777 CDU data]

Thanks. I also noticed the addresses for some of the old offsets seem to have changed now...

Everything from FMC_CruiseAlt onwards has moved 1 byte forward

FMC_PerfInputComplete has typo: 6C20  

FMC_DistanceToTOD onwards have been shifted forward 4 bytes.

Is this intended?

Paul

[PMDG 777 CDU data]

Sorry John, one more error:

FIRE_APUHandleIsUnlocked isn't an array, it should be FIRE_EngineHandleIsUnlocked to match FIRE_EngineHandleIlluminated.

I've double checked against the .h file and all the others seem okay.

Paul

[PMDG 777 CDU data]

Hi John,

I think you uploaded the wrong document - this one you attached doesn't have the arrays and still has COMM_ReceiverSwitches at 6C58.

Paul

[How can I get multiple engine failure in MSFS20?]

Hi T,

This offset doesn't take the engine number like that. As the offsets document says, each bit  in the offset represents an engine. So bit 0 is engine 1, bit 1 is engine 2 etc. If the bit is set to 1 the engine is failed. If 0 it's working ok.

The easiest way to work with bits using the DLL is to declare the offset as an FsBitArray:

private Offset<FsBitArray> engine_failure = new Offset<FsBitArray>(0x0B6B, 1);

Note that the 1 (second parameter) is the length of the offset. This is required for some types like FsBitArray. 1 here means 1 byte as can been seen in the offsets documentation.

To access the individual bits in the offset use the following:

	if (engine_failure.Value[1])
	{
		// engine 2 has failed
	}

 

            engine_failure.Value[0] = true; // Set engine 1 to failed
            engine_failure.Value[3] = true; // Also set engine 4 to failed

 

Another thing you need to be aware of is that you declared this offset as uint which is 4 bytes, but the documentation says this offset is only one byte. If you declare offsets with the wrong type you're going to have problems with the values you read, and writing offsets with the wrong type will result is unexpected things happening in the sim.

Paul

[PMDG 777 CDU data]

Okay - I'll add these new offsets to my DLL.

Paul

[PMDG 777 CDU data]

15 hours ago, John Dowson said:

Ok. Maybe @Paul Henty could advise if an update for this would be needed for his .net client dll, and if so we can coinside the releases.

I don't think there are any updates required. @Jason Fayre seems to have the 777 CDU working from my dll.

Like Luke, I'm a confused as to what has changed with the offsets you mentioned. Those offsets from 0x6C00 were in the Sept 2015 777x offsets list and so are already included in my dll. They don't look to have changed from 2015.

Paul

[Set HVAR from .net SDK]

Hi,

John has confirmed that the delay between calling Reload() and the HVars being available is to be expected. It takes time for the WASM module to gather the data from the files and do it's housekeeping. A few seconds should be enough.

I'll update the documentation to make this clear.

By the way, Start() called Reload() internally so you shouldn't need to call it yourself.

Another point John raised is that there can also be a delay between writing a new LVar value and that value being set in the sim and read back by the WASM module. Because of this I'll need to change the value setting to be on a method (SetValue) instead of setting the value property.

Paul

 

[Set HVAR from .net SDK]

I'm not sure why this is happening, or how long you should wait. I'll ask John about it.

Paul