FSUIPC WASM module + client-side API + lvar/hvar discussion topic

[John Dowson]

This topic is for discussion (including bug reports, feature requests, etc) of the FSUIPC WASM module for MSFS and the client API for using this module, available here: 

 

 

 

[MarkStallen]

Can I download it somewhere. I would love to test it

[Pete Dowson]

13 minutes ago, MarkStallen said:

Can I download it somewhere. I would love to test it

The link is in the Announcement.

Pete

 

[MarkStallen]

I get a non-permission as I click on the announcement, oh wait via announcements it works

[John Dowson]

32 minutes ago, MarkStallen said:

I get a non-permission as I click on the announcement, oh wait via announcements it works

Yes, sorry. The initial link was to edit that post for which you don't have permissions. I've corrected this now.

[roarkr]

Not working for me.

As soon as I click File/Start it connects, but freezes. Not able to get into any of the menus. Then after a while it closes.

I am running latest MSFS version released yesterday.

[John Dowson]

24 minutes ago, roarkr said:

I am running latest MSFS version released yesterday.

Please download and try again, as I updated the packages this morning, recompiled against the latest version (although I didn't update the version number).

I haven't had time to check it works with the latest release yet though, I'll do that now....

If you still have issues, can you tell me what message, if any, was displayed in the main window, and attach the logs from both the WASM module and the client.

And let me know if you are using a Steam or MS Store install.

Later: just checked and its working ok for me still (steam install), so if its not working for you, please attach your logs.

Edited March 10, 2021 by John Dowson
Further info added

[asessa]

Hi, can i use it in combination with mobiflight?

I mean, can i read lvar values from MF interface for my output values?

[John Dowson]

8 hours ago, asessa said:

Hi, can i use it in combination with mobiflight?

Yes, shouldn't be a problem to use this with any other WASM module. If any other WASM module is using the same event numbers as the FSUIPC WASM then that will cause problems. However, if that occurs, you can change the event numbers that the FSUIPC WASM uses via the ini files. Not needed for the MF WASM.

[asessa]

1 hour ago, John Dowson said:

Yes, shouldn't be a problem to use this with any other WASM module. If any other WASM module is using the same event numbers as the FSUIPC WASM then that will cause problems. However, if that occurs, you can change the event numbers that the FSUIPC WASM uses via the ini files. Not needed for the MF WASM.

Ok thanks, i will do a check in the weekend.

I think also MF should update its software to read lvars from fsuipc, do you think?

[John Dowson]

1 hour ago, asessa said:

I think also MF should update its software to read lvars from fsuipc, do you think?

I think that's up to them. The problem is that all MF users aren't necessarily FSUIPC users (and vica-versa).

I think the best long term solution would be (barring MSFS providing direct access to lvars via SimConnect!) for a single open-source WASM module that provides access to lvars/hvars and also does event processing. Basically a combination of the functionality offered by the MF WASM module and the FSUIPC one.

[asessa]

22 hours ago, John Dowson said:

I think that's up to them. The problem is that all MF users aren't necessarily FSUIPC users (and vica-versa).

I think the best long term solution would be (barring MSFS providing direct access to lvars via SimConnect!) for a single open-source WASM module that provides access to lvars/hvars and also does event processing. Basically a combination of the functionality offered by the MF WASM module and the FSUIPC one.

Yes . The last version of MF give us the possibility to fireup MSFS/A320nx/CJ4 events directly, but for output it use fsuipc offset.

So the problem is read the value from sim for the custom lvar.

 

[asessa]

@John Dowson if i active the fsuipc wasm module to read lvar then are they avalaible via fsuipc ?

[John Dowson]

7 minutes ago, asessa said:

 if i active the fsuipc wasm module to read lvar then are they avalaible via fsuipc ?

No, not at the moment. Did you not read the Announcement?

[asessa]

1 hour ago, John Dowson said:

No, not at the moment. Did you not read the Announcement?

Oh yes, sorry.

So we will wait for it, thanks

[John Dowson]

v0.2 has been released. Both the WASM module and API/Client have been updated to use the default local simconnect connection by default (-1, was 0), and allow for a different connection to be used via a new ini parameter UseSimConnection, The WASMClient code has also been re-organised to make it clearer what is the code from the client and what is imported from the WAPI module. Available: FSUIPC-WASMv0.2.zip

John

[d147]

Hello,

I have tested a number of functions: start(), end(), reload(), getLvarList(), LogVars(), getLvarValue(), getLvar() and setLvar().

I used the source files posted on march 9th and the release 0.2 posted today and made an app inspired after "WASMClient.cpp". My IDE is Embarcadero C++ Builder. I got a few errors at compilation, maybe the compiler is less permissive? I can give you details, if you wish. I made a few modifications and compiled and executed successfully.

The only concern is setLvar() that does not work in debug mode, and works in release mode, although the logging is the same; I tested this with the King Air and the Lvar "XMLVAR_YokeHidden1", set to either 1 or 0:

 [DEBUG]: Control sent to set lvars with parameter 65560 (10018): lvarId=24 (18), value=1 (1)
 [DEBUG]: Control sent to set lvars with parameter 24 (18): lvarId=24 (18), value=0 (0)

("does not work" means that the yoke visibility does not change).

Also, I am curious to know why getLvar() has a single prototype that returns a double, and setLvar() has several prototypes.

Thanks for your work,

Dan

[John Dowson]

1 hour ago, d147 said:

I got a few errors at compilation, maybe the compiler is less permissive? I can give you details, if you wish. I made a few modifications and compiled and executed successfully.

Yes please - provide me with details and I will check. There are various warnings I need to address, but there should be no compilation errors....

1 hour ago, d147 said:

The only concern is setLvar() that does not work in debug mode, and works in release mode, although the logging is the same; I tested this with the King Air and the Lvar "XMLVAR_YokeHidden1", set to either 1 or 0:

 [DEBUG]: Control sent to set lvars with parameter 65560 (10018): lvarId=24 (18), value=1 (1)
 [DEBUG]: Control sent to set lvars with parameter 24 (18): lvarId=24 (18), value=0 (0)

("does not work" means that the yoke visibility does not change).

That is strange - I will check that here....next week...

1 hour ago, d147 said:

Also, I am curious to know why getLvar() has a single prototype that returns a double, and setLvar() has several prototypes.

Lvars, as far as my understanding goes, are always 8bytes/64bits, even if they are only actually used as booleans or ints. When you get the value, it just returns this as a double, and you can interpret as you like.
When setting, I have provided overloaded functions so that its more user-friendly. If you use the function that excepts a string (recommended), then this will interpret the string value and cast to the correct actual type (either short, unsigned short, double or char*). Also, in the current implementation, the setting of lvars goes via different paths - for short values, I encode in an event parameter and use an event, for anything bigger, a CDA (Client Data Area) is used to pass the value (up to 8bytes).

I could easily provide more get functions if useful, e.g. getLvarAsInt(_). getLvarAsString(), etc. Of course, they would be distinct functions (rather than being overloaded) as the parameters would be the same, just the return type different. Also, very easy to add yourself if thats what you want to use....

Thanks for the report. Glad to hear someone has actually tried it, an is even implementing there own application with the API.

Please let me know of any issues with building and compiling these. I use Visual Studio, so I'm afraid that the repos are tied to the IDE. I am relatively new to VS, and have previously been used to providing IDE-independent repositories (previous to this, I have always been a unix/linix developer using eclipse/netbeans or IntelliJ....). 

The v0.1 release was also a bit of a mess in this respect, but hopefully a bit clearer in v.0.2. I am open to suggestions to make this more user-friendly, especially in order to use/include the API in your own projects, so any advise on how I can do this is much appreciated.

Regards,

John

 

 

[d147]

Quote

Yes please - provide me with details and I will check. There are various warnings I need to address, but there should be no compilation errors....

These are the compilation errors (not warnings) I got, in either UNICODE or ANSI mode:
In "CDAIdBank.cpp":
- line 21: "std::map<int, pair<string, int>>::iterator it;" changed to
           "std::multimap<int, pair<string, int>>::iterator it;"
           that's because the iterator is used for "availableBank" declared as "multimap<int, pair<string, int>>" in "CDAIdBank.h"
- line 44: ditto
- line 33: "string newName = string(CDA_NAME_TEMPLATE + to_string(nextId));" changed to
           "string newName = string(CDA_NAME_TEMPLATE + to_string((long long)nextId));"
           it looks like std::to_string(int) is not supported by my compiler (although it is supposed to support C++ 11)
In "Logger.cpp":
- lines 170 and 171: "const auto nowMs = std::chrono::duration_cast<std::chrono::milliseconds>(now.time_since_epoch()) % 1000;"
                     Error message: "invalid operands to binary expression ('std::chrono::duration<long long, std::ratio<1, 1000> >' and 'int')"
                     std::chrono is not familiar to me, so I just commented out the lines and modified the lines 174 and 175 to ignore "nowMs".

 

I have also tested getHvarList() and setHvar() with the A320. Similarly to setLvar(), setHvar() only works in release mode.

As for executeCalclatorCode() (typo in "WASMIF.h"?), I have not added it in my app; I tried your "WASMClient.exe" with something like "1 3 +" but I got no result or I did not find it. Do I misuse it? Could you provide a working example?

Regards,

Dan

 

[ylevesque]

Hi

Thanks for your works on LVars access.

I tried WASMClient. It works fine when it is alone in the community folder.

But when I add FlyByWire A32NX  add-on, WASMClient crashes when I start the connection with MSFS.

I tried to change the StartEventNo  in both the WASM and the WASM client (I tried  0x1FF8 and 0x2FF0. I don't know what is the acceptable range).

I attached both log files.

MSFS 1.14.5.0

FBW recent dev version

Yves 

 

 

FSUIPC_WASM.log FSUIPC_WASMIF.log

[John Dowson]

On 3/14/2021 at 10:36 AM, d147 said:

These are the compilation errors (not warnings) I got, in either UNICODE or ANSI mode:

In needs yo be built as Multibyte in VS, so use ANSI.

On 3/14/2021 at 10:36 AM, d147 said:

In "CDAIdBank.cpp":
- line 21: "std::map<int, pair<string, int>>::iterator it;" changed to
           "std::multimap<int, pair<string, int>>::iterator it;"
           that's because the iterator is used for "availableBank" declared as "multimap<int, pair<string, int>>" in "CDAIdBank.h"
- line 44: ditto

Corrected. Strange I don't get any compiler errors (or even warnings) for those...

On 3/14/2021 at 10:36 AM, d147 said:

- line 33: "string newName = string(CDA_NAME_TEMPLATE + to_string(nextId));" changed to
           "string newName = string(CDA_NAME_TEMPLATE + to_string((long long)nextId));"
           it looks like std::to_string(int) is not supported by my compiler (although it is supposed to support C++ 11)

Yes, that should be supported. However, as it works with a long long or an int in VS, I can add a cast there for you.

On 3/14/2021 at 10:36 AM, d147 said:

In "Logger.cpp":
- lines 170 and 171: "const auto nowMs = std::chrono::duration_cast<std::chrono::milliseconds>(now.time_since_epoch()) % 1000;"
                     Error message: "invalid operands to binary expression ('std::chrono::duration<long long, std::ratio<1, 1000> >' and 'int')"
                     std::chrono is not familiar to me, so I just commented out the lines and modified the lines 174 and 175 to ignore "nowMs".

Not sure why thats not working, Thats the code to get the timestamp for the logger messages. You can pass in your own logging function that will ommit this.

I\ll take a look at some point to make it more portable (maybe switch to using a tick count instead, its not really that important what timestamp there is, as long as there is one!).

On 3/14/2021 at 10:36 AM, d147 said:

As for executeCalclatorCode() (typo in "WASMIF.h"?), I have not added it in my app; I tried your "WASMClient.exe" with something like "1 3 +" but I got no result or I did not find it. Do I misuse it? Could you provide a working example?

No result is returned when executing calculator code. I'm not sure if I'll keep that function. Its in the beta release as it provides an easy way to test for hvars , before you add them to a *.hvar file. So, to activate a hvar, e.g. A320_Neo_CDU_MODE_SELECTED_SPEED in the A320Nei, then enter calculator code:
   (>H:A320_Neo_CDU_MODE_SELECTED_SPEED)

On 3/14/2021 at 10:36 AM, d147 said:

I have also tested getHvarList() and setHvar() with the A320. Similarly to setLvar(), setHvar() only works in release mode.

Yes, I just tried a debug build and get the same. Even worse, when running in the debugger it cannot open a simconnect connection. Not sure why this is at the moment, and don't really have time to look into this now, but I've made a note and will take a look when I can.

I've pushed the corrections to the FSUIPC_WAPI github project (but haven't made a release for this yet).

John
 

[John Dowson]

Hi Yves,

ok - I haven't tried with the FBW WASM for a while, I'll do that now and report back. However, a quick look at your logs reveals that there are a lot of lvars - 598 in total. Which of the FBW A320 mods are you using?

The issue is most probably that the lvar limit (for the values area) is exceeded, as this is currently sized for a maximum of 512 lvars,. Also, only 4 CDAs are currently configured for lvar names, allowing for a maximum of 585 lvars (with a current max lvar/hvar name size of 56 characters). Of course, if more are found then this should be handled gracefully, loading the maximum allowed and ignoring the rest. I thought that is how I implemented, but it looks like there is a problem somewhere (this is untested until now!).

So, I'll revise this and get back to you. I'll first make sure that the WASM module handles this correctly, then I'll increase the maximum number of lvars allowed.

Thanks for the report,

John

 

[ylevesque]

Hi John

I use the latest FBW development version (updated today). I can't find a version number.

Yves

[John Dowson]

1 hour ago, ylevesque said:

I use the latest FBW development version (updated today). I can't find a version number.

Yes, that has a lot more lvars than the stable....

I've now corrected the handling of lvars so it should now load the maximum available for the configured space (was 584) and ignore the rest.
I have also allowed for two more client data areas to pass across the names, so the current config will support up to 876 lvars).
There was also a problem with the buffer used to display lvar values in the client, which has also been corrected.

The github repos have been updated, and I have released the WASM + API + Client as v0.3.

Please let me know if you have any further issues.

John

[John Dowson]

3 hours ago, John Dowson said:

The issue is most probably that the lvar limit (for the values area) is exceeded, as this is currently sized for a maximum of 512 lvars,

Sorry, that was wrong! The lvar values CDA is sized to hold the maximum number of lvars that the name CDAs can hold (now 876), up to a maximum of 1024 values.
It does this (rather than creating sized to the actual number of lvars) so that it can be re-used with different aircraft, rather than have to be re-created each time with a different size.