Jump to content
The simFlight Network Forums

FSUIPC 7.2.15 / WASM 0.5.6 Incompatibility


Scotfleiger

Recommended Posts

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.

 

Link to comment
Share on other sites

15 minutes ago, Scotfleiger said:

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.

Can you please check that you are using the correct header file in the include folder. The WASMIF.h file should contain:
   #define WAPI_VERSION            "0.5.6"
It looks like you are still using the 0.5.5 release. I have checked the downloadable zip (available at www.fsuipc.com) and this does contain the correct version.

So, update and recompile using the latest WAPI from that zip - both headers and lib.

John

Later: also checked the FSUIPC-WASM.zip included in the FSUIPC SDK folder, and that also contains the correct version.

Edited by John Dowson
Later added
Link to comment
Share on other sites

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.

WebsocketError.png

wasm.png

Link to comment
Share on other sites

1 hour ago, Scotfleiger said:

I copied the SDK FSUIPC_WAPI files to /FSUIPC7/FSUIPC WASM/FSUIPC_WAPI with no effect.

Why would that may any difference? No idea why you would want to do that...

You need to recompile the WebSocket server code using the latest WAPI lib and headers (0.5.6).  It looks like it is still compiled against version 0.5.5.

Did you not try that?

Link to comment
Share on other sites

1 minute ago, Scotfleiger said:

I am not into recompiling third-party code

Ah, sorry... I forgot that the WebSocket server was developed by @Paul Henty. He needs to make a new version of the web-socket server (and also the .net client dll) to be compatible with the latest release. Hopefully he will pick-up the tag and update, otherwise I will DM him.

John

  • Upvote 1
Link to comment
Share on other sites

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).

Link to comment
Share on other sites

13 minutes ago, Scotfleiger said:

On running it from FSUIPC7/Add-ons/Websocket Server it immediately crashed (windows stopped working message).

I get the same behavior. It seems to crash on or soon after receiving the CDA data. It is reporting the correct WASM / WAPI version though.

I had forgotten that the websocket server was included in the Utils folder. I will update the released installer with the latest websocket server version, although I'll wait to see if this issue can be addressed first. I will also give Paul advanced noticed of any WAPI updates so that i can include a compatible websocket server version when I release.

John

Link to comment
Share on other sites

1 minute ago, Paul Henty said:

Did you change any of the function/callbacks (parameters/return values)?

No. The only change in this WAPI version was to update the compatible WASM version, and to change the check on WASM versions to just log a message if the version of the installed WASM doesn't match and continue, rather than stop.

John

Link to comment
Share on other sites

Just tried with a different aircraft and it is working fine. The 2nd aircraft I tried had no hvars - could it be an issue with receiving hvars?

Can I generate a WAPI log file from the websocket server, and if so, how? I can see a log level in the config file, but no output file is produced - does it just log to the websocket server console?

John

Link to comment
Share on other sites

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

Link to comment
Share on other sites

3 minutes ago, Paul Henty said:

Have you changed anything about how HVars are handled since 0.5.5d?

Only in the WASM, not the WAPI.

4 minutes ago, Paul Henty said:

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.

The WAPI is fine - that is used by FSUIPC7 without issue. I don't use the WAPID.dll, I just updated the WAPI in the WAPID project and recompiled.

Was the WebSocket server previously tested with hvars?

I have just checked again and now also have it working with hvars!

It seems the issue/crash occurs when I have duplicate hvar files being loaded, i.e. when a hvar name is duplicated. I removed/renamed one of the hvar files (I was loading two files containing the same hvar names), and now it seems to be working ok. @Scotfleiger Are you also perhaps still loading multiple hvar files, or have duplicate hvar names?
 

23 minutes ago, Paul Henty said:

Usually I would debug everything here and track down exactly where the problem is, but I don't have MSFS anymore.

Ah...that could be a problem... Do you have any unit tests with the WAPI calls mocked-out? If so, you could maybe try a test with duplicate hvar names, to see if that is the issue.

I can (and probably should) update the WASM to not allow duplicate hvar names really. Doesn't make any sense to allow this - apart from if they are the same for the first MAX_VAR_NAME_SIZE characters (currently set to 56) and then differ... 

Link to comment
Share on other sites

Quote

you could maybe try a test with duplicate hvar names, to see if that is the issue.

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Thanks 1
Link to comment
Share on other sites

6 minutes ago, Paul Henty said:

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.

Ok, thanks Paul. No need to do this with lvars as I don't think they can be duplicated (although I may be wrong.

I will also update the WASM to remove duplicate (full) hvar names, but this won't be until the next FSUIPC7 release now.
However, once I have implemented this, you could still possibly see duplicate hvar (and lvar) names if they are the same in the first 55 characters but differ after that. I allow this as all actions on hvars/lvars are performed on id, so as long as you know the correct id of the lvar/hvar you are using, the name doesn't matter. The user would only see the 55 character truncated name though, so would somehow need to know which is which (either via testing, or for hvars by checking the order in the .hvar file(s)).

7 minutes ago, Paul Henty said:

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

Yes, that works for me. It shows the duplicated hvars though, which I think is better...

5 minutes ago, Scotfleiger said:

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.

Ok. You should put your (renamed) hvar files under the AppData\Roaming\Microsoft Flight Simulator\Packages\fsuipc-lvar-module\work folder (for Steam, path is different in MS Store installations) instead. When a hvar file is loaded from this folder, it will not scan the Community\fsuipc-lvar-module\modules folder for further hvar files.

1 minute ago, Scotfleiger said:

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

Try as advised above, i.e. use the other folder for your hvar files. This is not touched during installation.

John

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

5 minutes ago, Scotfleiger said:

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.

Yes, I have just noticed that file, and have now added the hvars to it.  But deleting that should have no affect at all - that folder IS NOT  USED. You need to copy/move the .hvar files from that folder to one of the two correct locations for them to be used.

7 minutes ago, Scotfleiger said:

This is weird as I am not sure which Hvar folder is the correct one.

There are two 'correct' folders for the hvar files - please see my comment above, or the Advanced User manual.

8 minutes ago, Scotfleiger said:

I have a FlyByWire_A320_NEO.hvar in /FSUIPC7/HvarFiles and in /Community/fsuipc-lvar-module/modules

Only the one in Community/fsuipc-lvar-module/modules will be used. Bit you should really put that file in the other location, to prevent the A320.hvar file also being loaded when you re-install, as explained above....

9 minutes ago, Scotfleiger said:

(I am using the XBox MSFS not Steam)

You mean an MS Store installation? FSUIPC7 does not run on the xbox... From the Advanced User manual, P46

Quote

For MS Store installs, in the following folder under your user account:
    AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\Packages\fsuipc-lvarmodule\work
 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • 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.