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

[andhog]

  On 3/28/2021 at 4:21 PM, John Dowson said:

I haven't really thought about this, but its open source, no restrictions, use an adapt as needed.

Thats fine - I have no issues with using/changing or redistributing. A comment on the original source would be nice, but I'm also not bothered about that either really - use, change and re-distribute ad you like.

I also have more of an idea how this can be used in managed c or, more generally, by any other language. I am aiming to upload a new dll library project in the next few days, that will use the currently provided API but expose them in a dll so that they can be accessed in other languages.

 

 

Expand  

Thank you sir! Much appreciated.

I'm planning on some further development to make it possible to save the cockpit state of other models as well. I will include your WASM module and give you the creds you deserve, it's an awesome API!

[andhog]

Would it be possible to increase the number of possible LVars that can be read/set by the module? I just noticed that some of the CRJ LVars can't be accessed since it has more variables than the WASM module can read.

[John Dowson]

  On 3/30/2021 at 8:16 AM, andhog said:

Would it be possible to increase the number of possible LVars that can be read/set by the module? I just noticed that some of the CRJ LVars can't be accessed since it has more variables than the WASM module can read.

Expand  

How many lvars does the CRJ have? The WASM currently supports up to 876 lvars, I can increase this to 1024.
I am planning to make a new release in the next few days anyway - with a few extra functions in the API (mainly a creatLvar function needed by  FSUIPC), I will update to handle 1024 lvars in this release.

John

[andhog]

  On 3/30/2021 at 8:48 AM, John Dowson said:

How many lvars does the CRJ have? The WASM currently supports up to 876 lvars, I can increase this to 1024.
I am planning to make a new release in the next few days anyway - with a few extra functions in the API (mainly a creatLvar function needed by  FSUIPC), I will update to handle 1024 lvars in this release.

John

Expand  

I'm at work at the moment so I can't check, but it's more than 1000. Most of them are not interesting for my purpose but they are scattered all over the place, some being at the end of the list. But if I want to access those I'll have to make my own WASM module I guess.

[John Dowson]

  On 3/30/2021 at 8:52 AM, andhog said:

I'm at work at the moment so I can't check, but it's more than 1000. Most of them are not interesting for my purpose but they are scattered all over the place, some being at the end of the list.

Expand  

I can increase to allow however many are needed, although updating to handle more than 1024 lvars is a bit more work.
I can do this (in a later release), but before doing this I would also consider other possibilities to maybe reduce the number of lvars requested to those that are actually being used. Something like I proposed in the Announcement:

  Quote

2. Many LVARS don't seem to relate to the loaded aircraft. This is especially the case when changing aircraft, is it seems many of the lvars used by the previous aircraft are not cleared.
I'm not sure what to do about this at the moment, or if this is an  issue.
One thing I could do is to introduce the concept of lvar files (as we have hvar files - see later). Lvars would still be detected via scanning, but then the list of scanned lvars would be filtered using this list, and so only lvars found by scanning AND that are in the aircraft-specific lvar file would be made available to the client. Of course, the files would be optional and would only be used if present, otherwise all lvars would be loaded.

Expand  

 

[andhog]

  On 3/30/2021 at 9:04 AM, John Dowson said:

I can increase to allow however many are needed, although updating to handle more than 1024 lvars is a bit more work.
I can do this (in a later release), but before doing this I would also consider other possibilities to maybe reduce the number of lvars requested to those that are actually being used. Something like I proposed in the Announcement:

 

Expand  

The concept of LVar files sounds promising!

Another thought is having a WAPI function to provide the module with a list of the variables of interest (like SetLVarList(const std::vector<std::string> &interesting_lvars))

[John Dowson]

  On 3/30/2021 at 9:25 AM, andhog said:

Another thought is having a WAPI function to provide the module with a list of the variables of interest (like SetLVarList(const std::vector<std::string> &interesting_lvars))

Expand  

I don't think that would work due to the way the WASM will automatically reload lvars on an aircraft change. Its a lot easier to handle if the WASM module already had the lvar lists available, rather than filtering on a call post-load....

[John Dowson]

I have just released version 0.4.3. This supports of to 1022 lvars. There is also a minor change to the CDAType enum that may require code changes to anyone implemeting their own client.

[trigger87]

Guten Tag,

i have tested the new FSUIPC-WASMv0.4.3-Modul.  I like the idea to set/get hvars and lvars. i've tested some functions and it works pretty good with MSFS2020.

I'm currently programming a small addon with visual studio 19 (c#) and using the FSUIPCConnection.... It is missing such a great function like setting the H:Vars via code (FSUIPCConnection.setHvar). I hope it will get implemented soon. Great work so far, keep on going 🙂

Greetz Trigger

[John Dowson]

  On 3/30/2021 at 2:14 PM, trigger87 said:

I'm currently programming a small addon with visual studio 19 (c#) and using the FSUIPCConnection.... It is missing such a great function like setting the H:Vars via code (FSUIPCConnection.setHvar). I hope it will get implemented soon.

Expand  

Yes, I still need to look into providing hvar access via the SDK. And, as I guess you are using Paul Henty's .net client library that will also need updating. However, before I look at the SDK I will add the lvar/hvar access functionality to FSUIPC7, so it will be a while before I can get around to looking at the SDK.

I also intend to provide a dll of the WASM API (WAPI) which can be used to talk to the WASM module directly (rather than via FSUIPC), so you could look into using that as a solution for the time being (when available!).

[andhog]

Is it correct that it's only possible to set LVars using "Execute calculate code", not getting their value?

[John Dowson]

  On 3/30/2021 at 5:02 PM, andhog said:

Is it correct that it's only possible to set LVars using "Execute calculate code", not getting their value?

Expand  

I'm not sure I understand you....

You can set lvars using one of the setLvar functions. To get the value of an lvar, use the getLvar functions.
The execute calculator functions only executes the provided code, it does not return any values.

[andhog]

  On 3/30/2021 at 5:06 PM, John Dowson said:

I'm not sure I understand you....

You can set lvars using one of the setLvar functions. To get the value of an lvar, use the getLvar functions.
The execute calculator functions only executes the provided code, it does not return any values.

Expand  

Forget about that question, I wasn't thinking straight. However, even with the latest version I still only get 876 LVars with getLvarList.

There are two particular variables I'm trying to read in the CRJ. In the previous version they didn't show up either, but when I used "Execute Calculator Code" with for instance "1 (>L:ASCRJ_FO_ARMREST_UP)" I was able to set them. That's why I asked if it was possible to get Lvars with that method as well.

Any idea what I'm doing wrong so that I don't get more variables?

[John Dowson]

  On 3/30/2021 at 5:24 PM, andhog said:

However, even with the latest version I still only get 876 LVars with getLvarList.

Expand  

Are you using the new WASM with the new client (both have been updated)?
If so, can you set both the WASM + the client to debug logging (using the ini files), load the CRJ and then list the lvars and then show me your log files (WASM + Client).

  On 3/30/2021 at 5:24 PM, andhog said:

That's why I asked if it was possible to get Lvars with that method as well.

Expand  

Ok, but there is no output returned from that function. There's no way to see the lvars & values unless its picked-up by the WASM.

 

  On 3/30/2021 at 5:24 PM, andhog said:

Any idea what I'm doing wrong so that I don't get more variables?

Expand  

Your log files should give me a clue.

[andhog]

  On 3/30/2021 at 7:23 PM, John Dowson said:

Are you using the new WASM with the new client (both have been updated)?
If so, can you set both the WASM + the client to debug logging (using the ini files), load the CRJ and then list the lvars and then show me your log files (WASM + Client).

Ok, but there is no output returned from that function. There's no way to see the lvars & values unless its picked-up by the WASM.

 

Your log files should give me a clue.

Expand  

I should have thought of that of course. It's like calling helpdesk without having restarted the computer first 🙂

Here are my logs. I can see that the WASM module reports finding 1022 LVars, but as you can see the client doesn't list more than 876.

FSUIPC_WASMIF.logFetching info... FSUIPC_WASM.logFetching info...

[John Dowson]

Ah - I forgot to add an extra receiving event for the additional CDA - I'll correct that shortly and upload a new version. Sorry about that.

[andhog]

  On 3/31/2021 at 8:26 AM, John Dowson said:

Ah - I forgot to add an extra receiving event for the additional CDA - I'll correct that shortly and upload a new version. Sorry about that.

Expand  

No worries, I'm glad you found it!

[John Dowson]

The updated version has just been released - let me know how many lvars you now see and if ASCRJ_FO_ARMREST_UP is one of them. Either way, I think its better, for the time being at least, if I load all available lvars. I'll take a look at this over  Easter.

 

[andhog]

  On 3/31/2021 at 9:24 AM, John Dowson said:

The updated version has just been released - let me know how many lvars you now see and if ASCRJ_FO_ARMREST_UP is one of them. Either way, I think its better, for the time being at least, if I load all available lvars. I'll take a look at this over  Easter.

 

Expand  

Wow, that was fast! Thank you so much for your efforts in this, super appreciated.

 

And yes, I now get 1022 LVars. Unfortunately the armrest variables are not among them, but that's probably due to their position being outside the 1022 limit 😕

[andhog]

Another question entirely, would it be possible to make it possible to subscribe to HEvents? Or is that already possible somehow?

[John Dowson]

  On 3/31/2021 at 10:57 AM, andhog said:

would it be possible to make it possible to subscribe to HEvents?

Expand  

What do you mean - to get some sort of callback when a H var is activated? If so, then no, I don't think that is possible.

Can hvars have values? I thought/assumed they were something you activated/set. You can do this using the WASM + API, but I have only included an hvar file or the A320Neo. For other aircraft, you will have to discover and provide your own hvar file to use hvars.

 

[jaxx]

  On 3/28/2021 at 4:21 PM, John Dowson said:

I also have more of an idea how this can be used in managed c or, more generally, by any other language. I am aiming to upload a new dll library project in the next few days, that will use the currently provided API but expose them in a dll so that they can be accessed in other languages.

Expand  

I'm looking forward to this, I tried to wrap the module into a dll, but my C++ knowledge is decades old and I couldn't get anywhere.

[John Dowson]

  On 3/31/2021 at 2:12 PM, jaxx said:

I'm looking forward to this, I tried to wrap the module into a dll, but my C++ knowledge is decades old and I couldn't get anywhere.

Expand  

I did this this morning, but haven't gotten around to test it yet...you could try with the following (you will still need the static lib): FSUIPC_WAPI.dllFSUIPC_WAPI.h

As I said, its untested - I am planning to write a simple C client to test, but may take me a few days....

John

[andhog]

  On 3/31/2021 at 2:01 PM, John Dowson said:

What do you mean - to get some sort of callback when a H var is activated? If so, then no, I don't think that is possible

Expand  

Yes that's what I meant. In my application I would like to do something when the sim is started, paused or stopped and I assume this triggers some kind of event.

Looking at the in-game console I've noticed that when this happens there are printouts like "ASCRJ_INIT: Started" and "ASCRJ_INIT: Paused". Having a limited knowledge about these things I thought maybe that was a HEvent that was triggered with an argument with the sim state. But that was probably wrong then.

I recon I need to 1 read up on the documentation and 2 develop my own SimConnect implementation to do these kind of things.

[jaxx]

  On 3/31/2021 at 2:19 PM, John Dowson said:

I did this this morning, but haven't gotten around to test it yet...you could try with the following (you will still need the static lib): FSUIPC_WAPI.dllFSUIPC_WAPI.h

As I said, its untested - I am planning to write a simple C client to test, but may take me a few days....

John

Expand  

Thank you, I had a short look. Do you have any tips on how to call the methods?

I call:
- I call fsuipcw_init with the event id from the FSUIPC_WASM.ini (0x1FFF0) and a logger callback
- Then fsuipcw_start -> logger callback receives "  [INFO]: Connected to MSFS", so it looks the general setup is correct
- Then fsuipcw_logLvars -> "  [INFO]: We have 000 lvars: "
So it seems I'm missing something, using the test client I can verify there are lvars present (and I made sure not to run the test client and my code at the same time in case they conflict).

Any suggestions on what I'm missing?