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

[andhog]

  On 3/31/2021 at 4:28 PM, jaxx said:

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?

Expand  

Have you loaded an aircraft and started the flight? Before you have done that there aren't any Lvars to read.

[jaxx]

  On 3/31/2021 at 4:37 PM, andhog said:

Have you loaded an aircraft and started the flight? Before you have done that there aren't any Lvars to read.

Expand  

Of course, as I said, the test client is showing the lvars.

[John Dowson]

  On 3/31/2021 at 4:28 PM, jaxx said:

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

Expand  

As I said, I haven't tested yet. I'll take a look over the next days...

  On 3/31/2021 at 4:28 PM, jaxx said:

- I call fsuipcw_init with the event id from the FSUIPC_WASM.ini (0x1FFF0) and a logger callback

Expand  

Thats fine, you can also just use 0 for the start event number and the default will be used, and if you can also give a 0/nullPtr for the logging function, and its own logging file will be created.

  On 3/31/2021 at 4:28 PM, jaxx said:

- Then fsuipcw_logLvars -> "  [INFO]: We have 000 lvars: "

Expand  

Not sure why that is - I will take a look.

John

[John Dowson]

  On 3/31/2021 at 2:38 PM, andhog said:

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.

 

Expand  

Those are standard events that you  need to request via Simconnect, ot you could use the FSUIPC SDK and use the offset area instead. Nothing to do with hvars.

  On 3/31/2021 at 2:38 PM, andhog said:

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.

Expand  

I have no idea what they are....!

To log simconnect events, you could install FSUIPC and use its logging facilities, which are available in the unregistered version.

 

[andhog]

  On 3/31/2021 at 5:04 PM, John Dowson said:

Those are standard events that you  need to request via Simconnect, ot you could use the FSUIPC SDK and use the offset area instead. Nothing to do with hvars.

I have no idea what they are....!

To log simconnect events, you could install FSUIPC and use its logging facilities, which are available in the unregistered version.

 

Expand  

Thank you for taking your time to answer my stupid questions. I have been using the paid version of FSUIPC for a long time now, I will have a look on how to use it in my app!

[jaxx]

  On 3/31/2021 at 4:59 PM, John Dowson said:

Not sure why that is - I will take a look.

Expand  

Thank you.
I tested and can confirm that fsuipcw_createAircraftLvarFile will trigger the creation of the file in the work directory and it contains the Lvars, so at least my setup is not completely wrong.

One more thing, would it be possible to provide an alternative the following methods?
extern "C" FSUIPC_WAPI_API void fsuipcw_getLvarValues(map<string, double >&returnMap);
extern "C" FSUIPC_WAPI_API void fsuipcw_getLvarList(unordered_map<int, string >&returnMap);
extern "C" FSUIPC_WAPI_API void fsuipcw_getHvarList(unordered_map<int, string >&returnMap);

C# cannot work with C++ std maps. A struct-array should work or a callback function that is called for each key-value pair.

[John Dowson]

  On 3/31/2021 at 5:34 PM, jaxx said:

I tested and can confirm that fsuipcw_createAircraftLvarFile will trigger the creation of the file in the work directory and it contains the Lvars, so at least my setup is not completely wrong.

Expand  

Ok, so something is working...

I have an idea of what the issue might be. I'll look into this, but tomorrow now.

  On 3/31/2021 at 5:34 PM, jaxx said:

C# cannot work with C++ std maps. A struct-array should work or a callback function that is called for each key-value pair.

Expand  

I didn't know that but makes sense now I think about it! I can do that. I can provide both methods as they are trivial to implement. For the struct-array methods, would you prefer to pass in pre-allocated (with a size), or should the function allocate and the caller free the memory?

 

[andhog]

Now this got messy! Setting a Lvar double value triggers a completely different Lvar. Setting "ASCRJ_AUDIO1_VHF1_VOL" to 1 turns the knob, but setting it to 1.0 triggers the GPWS terrain warning sound! 🙂

This applies to both the WASMClient and using setLvar(unsigned short id, double value)

[John Dowson]

  On 3/31/2021 at 5:51 PM, andhog said:

Setting a Lvar double value triggers a completely different Lvar. Setting "ASCRJ_AUDIO1_VHF1_VOL" to 1 turns the knob, but setting it to 1.0 triggers the GPWS terrain warning sound! 🙂

This applies to both the WASMClient and using setLvar(unsigned short id, double value)

Expand  

Logs?
Any issues, please show me your log files, both WASM + Client, with Debug logging enabled.

And ALWAYS please, or at least for any issue that you want me to look at....

[jaxx]

  On 3/31/2021 at 5:44 PM, John Dowson said:

I didn't know that but makes sense now I think about it! I can do that. I can provide both methods as they are trivial to implement. For the struct-array methods, would you prefer to pass in pre-allocated (with a size), or should the function allocate and the caller free the memory?

Expand  

I don't think I'm qualified to answer that, C# is not my main language. I can use it well enough to write standard applications, but don't know how it would behave in such cases.

[andhog]

  On 3/31/2021 at 7:07 PM, John Dowson said:

Logs?
Any issues, please show me your log files, both WASM + Client, with Debug logging enabled.

And ALWAYS please, or at least for any issue that you want me to look at....

Expand  

It won't happen again!

 

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

[John Dowson]

  On 3/31/2021 at 5:51 PM, andhog said:

Now this got messy! Setting a Lvar double value triggers a completely different Lvar. Setting "ASCRJ_AUDIO1_VHF1_VOL" to 1 turns the knob, but setting it to 1.0 triggers the GPWS terrain warning sound! 🙂

This applies to both the WASMClient and using setLvar(unsigned short id, double value)

Expand  

There was a bug in the WASM now corrected, Please try the following WASM module:  

fsuipc-lvar-module.zipFetching info...

(Also now released as 0.4.5)

[d147]

I have installed fsuipc_lvar-module 0.4.5 and tried FSUIPC_WAPI.dll.

I am not sure of what the sequence should be, this is what my app does:

to begin: 

  fsuipcw_init(handle, 0x1FFF0, myLoggerFunction);
  fsuipcw_setLogLevel(LOG_LEVEL_TRACE);
  fsuipcw_setLvarUpdateFrequency(0);
  fsuipcw_start();

where handle is the Handle to the app main window and myLoggerFunction is my logger function.

then:

to create a Lvar list file:

  fsuipcw_createAircraftLvarFile(); // OK, file created in 'work' folder

to read a Lvar value:

  fsuipcw_getLvarFromName(theName); // OK, correct value returned

to write a value to the same Lvar, since all the fsuipcw_setLvarAsXXX() functions require an ID, the solution is first to get the list of the Lvar names and IDs:

  unordered_map<int, string> result;
  fsuipcw_getLvarList(result);  // error: Access violation at address xxx in module 'FSUIPC_WAPI.DLL'. Read of address yyy.

I don't know what the issue is. Note that my app is linked statically toFSUIPC_WAPI.dll; to do that, I had to create a C++ Builder compatible library, using a tool that comes with the IDE. Should you have no clue, I'll try to load FSUIPC_WAPI.dll dynamically and get pointers to the functions I actually use.

 

FSUIPC_WASM.logFetching info...

[John Dowson]

  On 4/1/2021 at 3:12 PM, d147 said:

I have installed fsuipc_lvar-module 0.4.5 and tried FSUIPC_WAPI.dll.

Expand  

The dll is currently nor working, and I don't really have time to look into it.
However, the API is available if someone else wants to try to create a dll from the static lib project.
 

  On 4/1/2021 at 3:12 PM, d147 said:

fsuipcw_init(handle, 0x1FFF0, myLoggerFunction);

Expand  

Thats ok - you can also just use:
    fsuipcw_init(NULL, 0, NULL);

  On 4/1/2021 at 3:12 PM, d147 said:

  fsuipcw_setLogLevel(LOG_LEVEL_TRACE);

Expand  

The parameter to this function is now an int, but you can still use the enum I guess (if supported by your language).

  On 4/1/2021 at 3:12 PM, d147 said:

fsuipcw_setLvarUpdateFrequency(0);

Expand  

Thats the default so you can skip this if you like.

 

  On 4/1/2021 at 3:12 PM, d147 said:

to write a value to the same Lvar, since all the fsuipcw_setLvarAsXXX() functions require an ID, the solution is first to get the list of the Lvar names and IDs:unordered_map<int, string> result;
  fsuipcw_getLvarList(result);  // error: Access violation at address xxx in module 'FSUIPC_WAPI.DLL'. Read of address yyy.

Expand  

As @jaxx mentioned above, these functions need to be updated:

  On 3/31/2021 at 5:34 PM, jaxx said:

One more thing, would it be possible to provide an alternative the following methods?
extern "C" FSUIPC_WAPI_API void fsuipcw_getLvarValues(map<string, double >&returnMap);
extern "C" FSUIPC_WAPI_API void fsuipcw_getLvarList(unordered_map<int, string >&returnMap);
extern "C" FSUIPC_WAPI_API void fsuipcw_getHvarList(unordered_map<int, string >&returnMap);

C# cannot work with C++ std maps. A struct-array should work or a callback function that is called for each key-value pair.

Expand  

But, I'm surprised you have as much working as you do! I can update those functions (maybe later this week), and maybe also provide write functions that accept the lvar name rather than the id for you. Please remind me if you haven't heard from me on this by Friday.

John

 

[John Dowson]

Hi @andhog

  On 3/31/2021 at 9:29 AM, andhog said:

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 😕

Expand  

I have a new version ready for release that has support for up to 2048 lvars , although it is only currently configured to support 1168.

However, as I don't have any aircraft with so many lvars (although I guess I could create lots...!), would you be able to test this for me before I release?

Also, is support for 1168 enough - do you know how many lvars the CRJ has? The latest version is currently configured for 2 lvar values CDAs (2048 values) but only 1168 lvars (8*(8k/56)) but I can easily increase this now if/when needed.

FSUIPC-WASMv0.4.6.zipFetching info...

 

Edited April 6, 2021 by John Dowson
zip attached

[andhog]

  On 4/6/2021 at 1:35 PM, John Dowson said:

Hi @andhog

I have a new version ready for release that has support for up to 2048 lvars , although it is only currently configured to support 1168.

However, as I don't have any aircraft with so many lvars (although I guess I could create lots...!), would you be able to test this for me before I release?

Also, is support for 1168 enough - do you know how many lvars the CRJ has? The latest version is currently configured for 2 lvar values CDAs (2048 values) but only 1168 lvars (8*(8k/56)) but I can easily increase this now if/when needed.

FSUIPC-WASMv0.4.6.zip 1.88 MB · 9 downloads

 

Expand  

Hi there!

Hope you had a great easter!

I will try that right away. The LVar files created by your WASM client gives me 1738 LVars. However, I don't think anyone need access to all of those at the same time so your suggestion to have a file with variables of interest together with the module would be great.

[John Dowson]

  On 4/6/2021 at 6:18 PM, andhog said:

I will try that right away. The LVar files created by your WASM client gives me 1738 LVars. However, I don't think anyone need access to all of those at the same time so your suggestion to have a file with variables of interest together with the module would be great.

Expand  

I don't think its an issue (at the moment) as only the CDAs needed (for the names) will be created, and its only an additional 8k CDA for the second values CDA, which won't get used by the client anyway. I'll look into allowing user restriction on the available lvars at a later date.

Another quick and easy alternative for the time being would to add an extra ini parameter which can be set if you wanted to use more than 1022 variables, but I don't think its needed at the moment. Allocating an extra 8k, even if unused, shouldn't be too problematic these days....

Anyway, please try the version I attached. I can easily extend to allow for 1738 lvars (by allowing 12 lvar name CDAs which would accommodate 1752 lvars), or you can build yourself by changing the following in the WASM.h header file (if you are programming yourself, of course - if not, please ignore!):

  Quote

#define MAX_NO_LVAR_CDAS        8 // Allows for 1168 lvars (7*(8k/56)): 14 is max and allows for 2044 lvars - the max allowed for the 2 value areas (8k/8) is 2048

Expand  

to

  Quote

#define MAX_NO_LVAR_CDAS        12 // Allows for 1752 lvars (12*(8k/56)): 14 is max and allows for 2044 lvars - the max allowed for the 2 value areas (8k/8) is 2048

Expand  

Let me know if you want me to make a build for this...maybe this is something I can allow the user to set as an  ini parameter, to basically tune to the needs of the user. However, this is obviously aircraft dependent, so I would need to allow tuning for profiles. 

Really, I need to concentrate on getting the basic functionality out and useable in FSUIPC7 before I consider such changes, but I don't mind over-tuning the parameters for the initial release, so it works for all/most add-ons, before I start adding the bells and whistles to tune.

 

[andhog]

  On 4/6/2021 at 1:35 PM, John Dowson said:

Hi @andhog

I have a new version ready for release that has support for up to 2048 lvars , although it is only currently configured to support 1168.

However, as I don't have any aircraft with so many lvars (although I guess I could create lots...!), would you be able to test this for me before I release?

Also, is support for 1168 enough - do you know how many lvars the CRJ has? The latest version is currently configured for 2 lvar values CDAs (2048 values) but only 1168 lvars (8*(8k/56)) but I can easily increase this now if/when needed.

FSUIPC-WASMv0.4.6.zip 1.88 MB · 9 downloads

 

Expand  

Unfortunately that didn't go so well. First I tried with the WASM client (see the log files that I for once managed to attach!). Then I compiled my application with the new FSUIPC_WAPI lib and that worked, but when I started the app I got "Microsoft C++ exception: std::out_of_range".

I think I might have found the reason in WASM.h:

	typedef struct _CONFIG_CDA
	{
		char CDA_Names[MAX_NO_LVAR_CDAS + MAX_NO_HVAR_CDAS + 1][MAX_CDA_NAME_SIZE];
		int CDA_Size[MAX_NO_LVAR_CDAS + MAX_NO_HVAR_CDAS + 1];
		CDAType CDA_Type[MAX_NO_LVAR_CDAS + MAX_NO_HVAR_CDAS + 1];
	} CONFIG_CDA;

And since you increased MAX_NO_VALUE_CDAS it gets out of range here in WASMIF.cpp:

for (int i = 0; i < MAX_NO_LVAR_CDAS + MAX_NO_HVAR_CDAS + MAX_NO_VALUE_CDAS; i++)

 

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

[andhog]

@John Dowson you have a pull request 🙂

[John Dowson]

  On 4/6/2021 at 6:48 PM, andhog said:

I think I might have found the reason in WASM.h:

	typedef struct _CONFIG_CDA
	{
		char CDA_Names[MAX_NO_LVAR_CDAS + MAX_NO_HVAR_CDAS + 1][MAX_CDA_NAME_SIZE];
		int CDA_Size[MAX_NO_LVAR_CDAS + MAX_NO_HVAR_CDAS + 1];
		CDAType CDA_Type[MAX_NO_LVAR_CDAS + MAX_NO_HVAR_CDAS + 1];
	} CONFIG_CDA;

And since you increased MAX_NO_VALUE_CDAS it gets out of range here in WASMIF.cpp:

Expand  

Ah, yes - missed that. I will correct and let you know - tomorrow now though - power/electricity has just gone....

[John Dowson]

...power just back! 

  On 4/6/2021 at 7:04 PM, andhog said:

@John Dowson you have a pull request 🙂

Expand  

Ok, will take a look. But tomorrow now..😴

[John Dowson]

@andhogHere's the corrected version: 

FSUIPC-WASMv0.4.6.zipFetching info...

[John Dowson]

@d147 I have updated the interface rebuild the dll against he latest WAPI. Files attached below:

FSUIPC_WAPI.hFetching info... FSUIPC_WAPID.libFetching info... FSUIPC_WAPID.dllFetching info...

I still don't think these are correct though, as the dll is only 96KB and the lib 8KB, whereas the WAPI lib is 6,473KB.

I can push the DLL project to github if anyone wants to try and sort this out - I don't have time at the moment I'm afraid.

John

Later: I've just replaced the .lib/.dll so please download again. Project also available on github: https://github.com/jldowson/FSUIPC_WDLL

As I have said previously, I don't think this is working at the moment.....

 

Edited April 7, 2021 by John Dowson
Downloadable files updated, github repo added

[John Dowson]

  On 4/7/2021 at 8:41 AM, John Dowson said:

@andhogHere's the corrected version: 

Expand  

Some issues with that version, please try the following: FSUIPC-WASMv0.4.7.zip

[jaxx]

I tried with the new DLL and still can't read L/Hvars through it.
But I tried writing and that works for what I can see.

• log L/Hvars functions -> No vars found
• get list/values functions -> nothing
• get Lvar (name, id) functions -> returns nothing/0
   
• set lvar functions -> works!
• set hvar function -> works!
• createLvar -> works!
• createAircraftLvarFile -> works!

So I'm not sure what it could be that writing works, but I can't read through the DLL, and the writes without the reads are not really usable, as you need to somehow get the ID from the name (which for testing I could only do through the WAPI Client).

For reference, this is the C# wrapper I'm using around the DLL: FsuipcWapi.cs