Jump to content
The simFlight Network Forums

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


John Dowson

Recommended Posts

21 minutes ago, 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.

 

 

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!

  • Like 1
Link to comment
Share on other sites

27 minutes ago, 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.

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

Link to comment
Share on other sites

1 minute ago, 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

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.

Link to comment
Share on other sites

3 minutes ago, 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.

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.

 

Link to comment
Share on other sites

13 minutes ago, 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:

 

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

Link to comment
Share on other sites

37 minutes ago, 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))

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

3 minutes ago, 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.

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

Link to comment
Share on other sites

3 minutes ago, andhog said:

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

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.

Link to comment
Share on other sites

3 minutes ago, 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.

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?

Link to comment
Share on other sites

1 hour ago, andhog said:

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

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

1 hour ago, andhog said:

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

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.

 

1 hour ago, andhog said:

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

Your log files should give me a clue.

Link to comment
Share on other sites

1 hour ago, 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.

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.log FSUIPC_WASM.log

Link to comment
Share on other sites

10 minutes ago, 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.

 

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 😕

Link to comment
Share on other sites

3 hours ago, andhog said:

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

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.

 

Link to comment
Share on other sites

On 3/28/2021 at 6: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.

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.

Link to comment
Share on other sites

3 minutes ago, 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.

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

Link to comment
Share on other sites

29 minutes ago, 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

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.

Link to comment
Share on other sites

1 hour ago, 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

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?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • 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.