[VRInsight and Lvar Updates]

Thanks John for Lvar answer. I agree it is very much aircraft dependent and up to the user to set the delay to suit.

Do you have an answer to my main question?

3 hours ago, Scotfleiger said:

Is there a defined polling interval for VRInsight devices with Com connections similar to the FSUIPC7.ini Buttons PollInterval and ButtonRepeat parameters? I ask because the response time to VRI Combo MCP and CDU keys inputs is slow compared with FSUIPC6 and not all inputs are registered for processing.

[VRInsight and Lvar Updates]

Hi John

Is there a defined polling interval for VRInsight devices with Com connections similar to the FSUIPC7.ini Buttons PollInterval and ButtonRepeat parameters? I ask because the response time to VRI Combo MCP and CDU keys inputs is slow compared with FSUIPC6 and not all inputs are registered for processing.

The FSUIPC_WASM.ini setting LvarScanDelay= was added for FSUIPC7 to wait for MSFS to prepare and make available internal Lvar values. A delay of 45sec is recommended but I have found 60sec necessary to pick up all FBW A32NX Lvars. This aircraft has a total of 1268 but I have found the number read can be as low as 1126 missing some key Lvars. When a user selects List Lvars in FSUIPC7/Addons/WASM would it be possible to force WASM to rescan the Lvars available?

[FSUIPC 7.2.15 / WASM 0.5.6 Incompatibility]

Probably. I am getting bewildered by all these Microsoft locations. There are so many appdata and local and roaming hideaways. You mentioned the appdata\roaming.

I will leave things there thank you. I think I will go back to P3D where things are much simpler to comprehend.

[FSUIPC 7.2.15 / WASM 0.5.6 Incompatibility]

7 minutes ago, John Dowson said:

Please let me know the location if/when you find it....

My FSUIPC_WASM.log is saved to appdata\local\packages\microsoft.flightsimulator_xxxxxxx\localstate\packages\fsuipc-lvar-module\work.

[FSUIPC 7.2.15 / WASM 0.5.6 Incompatibility]

6 minutes ago, John Dowson said:

There are two 'correct' folders for the hvar files

I don't have the appdata/roaming MSFS folder just the /community one.

7 minutes ago, John Dowson said:

You mean an MS Store installation? FSUIPC7 does not run on the xbox.

Microsoft now want you to launch MSFS using their games platform XBox app on PCs. If not users aren't able to purchase add-ons from the XBox store (like aircraft and airports) as I found out yesterday.

[FSUIPC 7.2.15 / WASM 0.5.6 Incompatibility]

Hi John

I have found the rouge .hvar file causing the duplicates. It was an 'empty' A32NX FBW.hvar in /FSUIPC7/HvarFiles which I deleted and it fixed the problem. This is weird as I am not sure which Hvar folder is the correct one. I have a FlyByWire_A320_NEO.hvar in /FSUIPC7/HvarFiles and in /Community/fsuipc-lvar-module/modules (I am using the XBox MSFS not Steam). Which is the correct location? You indicated above that it will only use one such file.

[FSUIPC 7.2.15 / WASM 0.5.6 Incompatibility]

7 minutes ago, Paul Henty said:

Can you please try the version attached? This should be okay if your plane has duplicate HVars.

v0.3.4 is working fine. The server now opens with log showing matched WASM and WAPI versions (0.5.6) and 'connected to MSFS.

As per previous post, I am still seeing double the number of Hvars and am still investigating.

[FSUIPC 7.2.15 / WASM 0.5.6 Incompatibility]

35 minutes ago, John Dowson said:

Are you also perhaps still loading multiple hvar files, or have duplicate hvar names?

Hi John, you are correct. I am again seeing a double Hvar count (438). Checking the /community/fsuipc-lvar-module I found that the A320.hvar file had reappeared following FSUIPC7 7.2.15 installation. I have also checked that the UseAirLocForHvars=Yes is present in fsuipc7.ini and wasmclient.ini.

[FSUIPC 7.2.15 / WASM 0.5.6 Incompatibility]

10 minutes ago, Paul Henty said:

I've updated the websocket server package (Version 0.3.3) to include the latest FSUIPC_WAPID.DLL.

Thank you Paul. I downloaded v0.3.3 and copied 3 files to /FSUIPC7/utils. On running it from FSUIPC7/Add-ons/Websocket Server it immediately crashed (windows stopped working message).

[FSUIPC 7.2.15 / WASM 0.5.6 Incompatibility]

I am not into recompiling third-party code - outside my knowledge area especially C/C++. I will leave it there as I don't need this facility. I will just use FSUIPC7 as provided. Thank you for your patience. 

[FSUIPC 7.2.15 / WASM 0.5.6 Incompatibility]

Hi John, I have done the checks you suggested and can confirm WASM 0.5.6 and WAPI 0.5.6 are reported to be installed and started in fsuipc7.log.

   216843 Starting WAPI...
   216843   [INFO]: **** Starting FSUIPC7 WASM Interface (WAPI) version 0.5.6 (WASM version 0.5.6)
   216843   [INFO]: Connected to MSFS

However, the FSUIPC Web Services Server still reports a different between WASM and WAPI versions. I copied the SDK FSUIPC_WAPI files to /FSUIPC7/FSUIPC WASM/FSUIPC_WAPI with no effect.

[FSUIPC 7.2.15 / WASM 0.5.6 Incompatibility]

Will check later.

[FSUIPC 7.2.15 / WASM 0.5.6 Incompatibility]

With formal release of FSUIPC 7.2.15 and updated WASM 0.5.6 I am getting an incompatibility error message when FSUIPC Websockets Server 0.3.1 is open on MSFS Variables page. The message is: [ERROR]: **** Incompatible WASM version: The WASM version is 0.5.6 while WAPI version is 0.5.5. Cannot continue.

 

[FBW A320 Parking Brake]

@CXA001 The Lvar A32NX_PARK_BRAKE_LEVER_POS can be used to operate the Park Brake handle - set to 0 for off, 1 for on. This is the LUA code I am using in LINDA:

-- $ Park Brake

function A32nx_PARK_BRAKE_on()
    ipc.writeLvar("L:A32NX_PARK_BRAKE_LEVER_POS", 1)
end

function A32nx_PARK_BRAKE_off()
    ipc.writeLvar("L:A32NX_PARK_BRAKE_LEVER_POS", 0)
end

function A32nx_PARK_BRAKE_toggle()
    if ipc.readLvar("L:A32NX_PARK_BRAKE_LEVER_POS") > 0 then
        A32nx_PARK_BRAKE_off()
    else
        A32nx_PARK_BRAKE_on()
    end
end

 

[For every Liverie a new profile?]

13 minutes ago, John Dowson said:

Yes, I know - that is what I was trying to tell you!

I was replying to your suggestion. I will look at my setup and see if I can find anything to point you in the right direction.

[For every Liverie a new profile?]

Sorted thank you. Only 218 Hvars loading now. I had the old A320.hvar and FlyByWire_A320_NEO.hvar present and renamed the former.

[For every Liverie a new profile?]

Disregard the previous post. I appear to have had multiple fsuipc_lvar_module folders installed. The following refers to /packages/community/fsuipc-lvar-module.

There are a number of Hvar files found and 436 hvars found (twice that in the FlyByWire_A320_Neo.hvar). There are a couple of lines referring to loading 72 unique Hvars from .\modules\A320.hvar and .\modules\FlyByWire_A320_NEO.hvar.

FSUIPC_WASM.log FSUIPC_WASM.ini

[For every Liverie a new profile?]

3 hours ago, John Dowson said:

Activate debug logging in the WASM and check your FSUIPC_WASM.log

I have set the Logging to Debug in WASMClient.ini (in LocalState/Packages/fsuipc-lvar-module) and restarted MSFS and FSUIPC7. For both the FBW A32NX base and BA livery variant the log reports 436 Hvar found. List Hvars still shows a doubled up list of Hvars.

FSUIPC_WASM.log WASMClient.ini

[For every Liverie a new profile?]

Further to your question

On 1/21/2022 at 4:50 PM, John Dowson said:

Do you really have > 400 hvars for the aircraft you have loaded (FBW A320?)?

I have checked my code to read the available Hvars using the new ipc.getHvarName(). I found that the resulting list has double the number of Hvars than in the HvarFiles source (436 and not 218). The list is repeated twice for some unknown reason. I am searching using a loop from 0 and stopping at the first nil or blank response (see attached - ignore logging lines). As I can see the getHavName is reading the list twice.

GetHvar.lua

[For every Liverie a new profile?]

2 minutes ago, John Dowson said:

Do you really have > 400 hvars for the aircraft you have loaded (FBW A320?)?

I only have those provided with your updates. I am only just getting my head around understanding MSFS, FBW and available Lvars, Hvars, Events, etc.

[For every Liverie a new profile?]

1 minute ago, John Dowson said:

Please re-read my previous response...I said I would look into changing this the next time I update the WAPI.
Or is this something that you cannot live without? 

Sorry I did read and I was just clarifying. This can be lived with as I am extracting the Hvar list separately. The fact that Hvars are now readable for variation aircraft is brilliant. Thank you.

[For every Liverie a new profile?]

Hi John

The entry/index numbers are correctly matched to the hvar name as accessed by the getHvarList function. It is just the display order that has gone awry. (I have been having similar issues with the order in work I am doing on LINDA.

PS. The fsuipc7.log list is in the expected ordered.

[For every Liverie a new profile?]

Hi John

Thank you for the updates. I have tried 7.2.15e with the revised .wasm and json files. Using the FBW A32NX British Airways livery from OperatorLand468 I can using the FSUIPC7 panel to list the Hvars matching the Airfile:

[START] Current Aircraft: British Airways OperatorLand468 FBW
[START] Air file: SimObjects\Airplanes\FlyByWire_A320_NEO\aircraft.CFG

The only issue spotted is that the numbered lines and Hvar references are not sorted. See attached.

[For every Liverie a new profile?]

It was my dyslexia KO. I will try update and report.

[For every Liverie a new profile?]

Hi John, thanks for your reply. I understand the need to create hvar files to match alternative liveries and am using this myself. In the longer term changes to WASM would cope with the growing number of MSFS community liveries that use alternative names. The aircraft.cfg base model entry would be accessible to WASM independent of FSUIPC and offsets.

PS. the additional hvar functions you provided in the trial build (7.2.15d) are working well and should be incorporated in the baseline when time allows.