d147 Posted March 15, 2021 Report Posted March 15, 2021 Hi John, Quote The github repos have been updated, and I have released the WASM + API + Client as v0.3. Got it, thank you! Quote In needs yo be built as Multibyte in VS, so use ANSI. Nice, so does my app normally. Quote On 3/14/2021 at 10:36 AM, d147 said: "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. Well, you are nice to me, but I don't really like to introduce unnecessary code as a workaround to a weakness of my compiler. Quote On 3/14/2021 at 10:36 AM, d147 said: 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')" 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 searched the web and I found something, it's the ".count()" that my compiler founds misplaced. For me, it compiles with: line 170: const auto nowMs = (std::chrono::duration_cast<std::chrono::milliseconds>(now.time_since_epoch())).count() % 1000; line 174: << '.' << std::setfill('0') << std::setw(3) << nowMs; or alternatively: line 170: const auto nowMs = (std::chrono::duration_cast<std::chrono::milliseconds>(now.time_since_epoch())).count(); line 174: << '.' << std::setfill('0') << std::setw(3) << nowMs % 1000; Quote 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) Sadly, I get no effect. I also tried "(>H:A320_Neo_CDU_MODE_SELECTED_SPEED)" that has no effect, whereas Set Hvar 24 works. By the way, I found how to list the Lvars in MSFS Dev menus, but not how to list the Hvars. Quote 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. OK, I really understand you may be otherwise busy, this is certainly not a priority. Thanks again, Dan
John Dowson Posted March 15, 2021 Author Report Posted March 15, 2021 43 minutes ago, d147 said: Well, you are nice to me, but I don't really like to introduce unnecessary code as a workaround to a weakness of my compiler. Me neither....but its done now. Do you want me to remove? 43 minutes ago, d147 said: I searched the web and I found something, it's the ".count()" that my compiler founds misplaced. For me, it compiles with: line 170: const auto nowMs = (std::chrono::duration_cast<std::chrono::milliseconds>(now.time_since_epoch())).count() % 1000; line 174: << '.' << std::setfill('0') << std::setw(3) << nowMs; or alternatively: line 170: const auto nowMs = (std::chrono::duration_cast<std::chrono::milliseconds>(now.time_since_epoch())).count(); line 174: << '.' << std::setfill('0') << std::setw(3) << nowMs % 1000; Ok, no issues changing this so thats also done. 43 minutes ago, d147 said: Sadly, I get no effect. I also tried "(>H:A320_Neo_CDU_MODE_SELECTED_SPEED)" that has no effect, whereas Set Hvar 24 works. Ok, I'll take a look to see whats happening here. 43 minutes ago, d147 said: By the way, I found how to list the Lvars in MSFS Dev menus, but not how to list the Hvars. Yes - instructions were posted in the Asobo forums on how to find hvars using the dev console, but I can't seem to find that anymore. I think SPAD.next comes with some scripts that you can run to discover hvars. I've been meaning to look at this for a while, but not sure if I have access to it at the moment (I have Spad.next but no current support license). If anyone else has access, it would be good to use that to get some initial hvar scripts for the default aircraft. I've update the github repos with those changes, but I won't be making a new release for the time being. John
ylevesque Posted March 15, 2021 Report Posted March 15, 2021 Hi John The WASM Client crash is solved with v0.3 but all tools in Control menu do not work. Pressing Reload crash the sim. Yves
John Dowson Posted March 16, 2021 Author Report Posted March 16, 2021 16 hours ago, ylevesque said: The WASM Client crash is solved with v0.3 but all tools in Control menu do not work. Pressing Reload crash the sim. Ok, but that doesn't help me investigate this issue for you. I have tried here and it is generally ok, although I have noticed a minor issue that needs addressing - you need to issue a reload to get the initial data. I'll look into this. But to look into why this isn't working for you, I need to see you log files (and also each time you report an issue).
John Dowson Posted March 16, 2021 Author Report Posted March 16, 2021 1 hour ago, John Dowson said: I have noticed a minor issue that needs addressing - you need to issue a reload to get the initial data. I'll look into this. This has been corrected in v0.4. Please download and try again. I have tried various configurations and aircraft, switching aircraft, etc, and can't get it to crash or otherwise mis-behave, so please report any issue and also always attach both the WASM log + the client log (if using). Also, please change the log level (via the ini files) to Debug before generating your log file. Also, if you have modified the StartEventNo then please let me know what you are using, and also if you are controlling lvar updates via rhe client or WASM (i.e. if you have changed the LvarUpdateFrequency in either client or WASM). And let me know what aircraft you are using (including the mod provider + version if applicable). Thanks, John
d147 Posted March 16, 2021 Report Posted March 16, 2021 Hi John, I have downloaded the v0.4. I found something that may explain why the debug builds had issues. In "WASMIF.cpp": Lines 77 to 83: const char* WASMIF::getEventString(int eventNo) { std::stringstream stream; stream << "#0x" << std::hex << startEventNo + eventNo; std::string result(stream.str()); return result.c_str(); } I think the returned char* is not reliable because result is static and destroyed when the function is exited. My workaround (straightforward, not smart): char buf[300]; const char* WASMIF::getEventString(int eventNo) { std::stringstream stream; stream << "#0x" << std::hex << startEventNo + eventNo; std::string result(stream.str()); strcpy(buf, result.c_str()); return buf; } Now, SetLvar() and SetHvar() do work with either debug or release builds. Quote On 3/15/2021 at 4:55 PM, d147 said: Well, you are nice to me, but I don't really like to introduce unnecessary code as a workaround to a weakness of my compiler. Me neither....but its done now. Do you want me to remove? It's really up to you, I don't want to add any burden. Just for information, I got a warning that I had not noticed before: In the same file, line 778: sprintf(szLogBuffer, "We have %03d lvars: ", lvarNames.size()); My compiler says: "warning W3436: format specifies type 'int' but the argument has type 'size_type' (aka 'unsigned long long')". My workaround: sprintf(szLogBuffer, "We have %03d lvars: ", int(lvarNames.size())); Best regards, Dan
John Dowson Posted March 16, 2021 Author Report Posted March 16, 2021 (edited) 20 minutes ago, d147 said: In "WASMIF.cpp": Lines 77 to 83: const char* WASMIF::getEventString(int eventNo) { std::stringstream stream; stream << "#0x" << std::hex << startEventNo + eventNo; std::string result(stream.str()); return result.c_str(); } I think the returned char* is not reliable because result is static and destroyed when the function is exited. My workaround (straightforward, not smart): char buf[300]; const char* WASMIF::getEventString(int eventNo) { std::stringstream stream; stream << "#0x" << std::hex << startEventNo + eventNo; std::string result(stream.str()); strcpy(buf, result.c_str()); return buf; } Now, SetLvar() and SetHvar() do work with either debug or release builds. Ok, yes that is an issue. I will correct this - I will use new though, rather than a global buffer. It doesn't matter if the allocated memory for this isn't released. 20 minutes ago, d147 said: It's really up to you, I don't want to add any burden. No problem leaving it as it is for me, although I'll add a comment as to why I did that change, for future reference - otherwise I may reverse it! 20 minutes ago, d147 said: Just for information, I got a warning that I had not noticed before: In the same file, line 778: sprintf(szLogBuffer, "We have %03d lvars: ", lvarNames.size()); My compiler says: "warning W3436: format specifies type 'int' but the argument has type 'size_type' (aka 'unsigned long long')". My workaround: sprintf(szLogBuffer, "We have %03d lvars: ", int(lvarNames.size())); Yes, although I don't get that warning on my compiler. I'm a but lazy and tend to ignore those type of warnings anyway when I know the implicit cast won't be an issue...the number of lvars certainly will never exceed the max value held by an int! Probably a better fix is to change the printf code from '%03d' to '%03llu', I can do that... Thanks, John Later: I have made those changes and pushed to github if you would like to try. Edited March 16, 2021 by John Dowson Later added
kingm56 Posted March 17, 2021 Report Posted March 17, 2021 Mr. Dowson, Do you have any managed code (e.g. C# or VB) examples of the WASM client? Thank you for all you do, sir!
John Dowson Posted March 17, 2021 Author Report Posted March 17, 2021 8 hours ago, kingm56 said: Do you have any managed code (e.g. C# or VB) examples of the WASM client? No, sorry. I'm not that familiar with c#. To use the API in c#, you would need to rebuild the API as a dll project (rather than a static library), and the public functions would need to be exported. You could then call them using P/Invoke, or write a managed wrapper facade. I could re-build as a dynamic library project at some stage if someone wants to look into this.
d147 Posted March 17, 2021 Report Posted March 17, 2021 Hi John, 22 hours ago, John Dowson said: I have made those changes and pushed to github if you would like to try. Nice, I have downloaded the files and updated my app. Everything is OK. A user said he had crashes; as for me, I can switch to another aircraft without any crash, with either your own client or mine. Thank you for providing these improvements to the basic SimConnect interface. For the long term, are your plans to include the Lvars and Hvars in FSUIPC and Lua scripts, similarly to FSX? Dan
John Dowson Posted March 17, 2021 Author Report Posted March 17, 2021 48 minutes ago, d147 said: Thank you for providing these improvements to the basic SimConnect interface. For the long term, are your plans to include the Lvars and Hvars in FSUIPC and Lua scripts, similarly to FSX? Yes, that's the next stage. There will probably be more API updates when I do this, but that will be to add in functionality not change existing functionality. Cheers, John
ylevesque Posted March 18, 2021 Report Posted March 18, 2021 Hi John WASM v0.4 if working fine. No crash. I notice that List LVARs creates a list that is shorter than what is visible in Get LVARs or in Create aircraft LVARs file. I attached some logs. FSUIPC_WASMIF.log Airbus A320 Neo Asobo.1.lvar Airbus A320 Neo Asobo.2.lvar Airbus A320 Neo Asobo.3.lvar Airbus A320 Neo Asobo.4.lvar Airbus A320 Neo Asobo.5.lvar FSUIPC_WASM.log List LVARs.txt
John Dowson Posted March 18, 2021 Author Report Posted March 18, 2021 9 hours ago, ylevesque said: I notice that List LVARs creates a list that is shorter than what is visible in Get LVARs or in Create aircraft LVARs file. The 'Create aircraft LVARs file' facility is a hangover from an earlier version of the WASM where I loaded lvars from files. When this is called, lvars are re-scanned to create the files and so may not necessarily correspond to the lvars currently loaded (lvars can be created during the lifetime of the aircraft. You log shows that the initial scan found 616 lvars: Quote Wed Mar 17 14:44:20 2021 [INFO]: 616 lvars loaded for aircraft 'Airbus A320 Neo Asobo' And the scan performed when generating the files found 618 - so 2 were added in the 10 hours that it as running: Quote Thu Mar 18 00:14:31 2021 [INFO]: Found 618 lvars: Max number of lvars per Client Data Area is 146 - will split You can 'Reload' to scan and update the internal lvar/hvar lists. The list created is shorter to a minor bug in the client where the display buffer is still restricted to 16300 characters - I will remove that.
John Dowson Posted March 18, 2021 Author Report Posted March 18, 2021 11 minutes ago, John Dowson said: The list created is shorter to a minor bug in the client where the display buffer is still restricted to 16300 characters - I will remove that. I've fixed this and released as 0.4.1.
John Dowson Posted March 18, 2021 Author Report Posted March 18, 2021 On 3/15/2021 at 4:55 PM, d147 said: Quote 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) Sadly, I get no effect. I also tried "(>H:A320_Neo_CDU_MODE_SELECTED_SPEED)" that has no effect, whereas Set Hvar 24 works. There was an issue with the loading of hvars that has now been corrected (and released as v0.4.2). Only one hvar CDA was being created. I'm not sure this has anything to do with this though. However, if I set a hvar or execute calculator code, the same code is executed in the WASM: Quote Thu Mar 18 12:28:26 2021 [DEBUG]: EventHandler: WASM_START_EVENTNO+2 - Control to set HVARS: event=131058 (1FFF2), evdata=8 (8) Thu Mar 18 12:28:26 2021 [DEBUG]: Executing hvar in CDA 0 with index 8: (>H:A320_Neo_CDU_MODE_SELECTED_SPEED) Thu Mar 18 12:32:14 2021 [DEBUG]: Calculator code executed: '(>H:A320_Neo_CDU_MODE_SELECTED_SPEED)' So, please try again with the latest version and let me know if you have any issues. John
John Dowson Posted March 18, 2021 Author Report Posted March 18, 2021 I've also checked the exec calc code functionality with lvars, and this also works - this is a test to hide/show/hide the yoke via lvars (in the King Air) using set lvar and then execute calculator code twice: Quote Thu Mar 18 12:50:48 2021 [DEBUG]: EventHandler: WASM_START_EVENTNO+1 - Control to set LVARS: event=131057 (1FFF1), evdata=66039 (101F7) Thu Mar 18 12:50:48 2021 [DEBUG]: Checking index 503 is in CDA 0 with 146 items... Thu Mar 18 12:50:48 2021 [DEBUG]: Checking index 357 is in CDA 1 with 146 items... Thu Mar 18 12:50:48 2021 [DEBUG]: Checking index 211 is in CDA 2 with 146 items... Thu Mar 18 12:50:48 2021 [DEBUG]: Checking index 65 is in CDA 3 with 146 items... Thu Mar 18 12:50:48 2021 [DEBUG]: EventHandler: LVAR with index=503 set to param=1.000000 Thu Mar 18 12:53:42 2021 [DEBUG]: Calculator code executed: '0 (>L:XMLVAR_YokeHidden1) ' Thu Mar 18 12:54:26 2021 [DEBUG]: Calculator code executed: '1 (>L:XMLVAR_YokeHidden1) '
John Dowson Posted March 18, 2021 Author Report Posted March 18, 2021 50 minutes ago, MarkStallen said: Can't wait to access with FSUIPC 7 Will be a while coming...I'm going to take the weekend off (bar support) and start on this next week... 1
d147 Posted March 18, 2021 Report Posted March 18, 2021 Hi, I have downloaded and used v0.4.2. I have also added the calculator to my app. All OK, I used it successfully with a Hvar and a Lvar. Have a good (and deserved) week-end, Dan
laertes Posted March 20, 2021 Report Posted March 20, 2021 I'd just like to add my name to the list of people who'd like to see some managed access to these functions (C#), making a dll that would work with C# is way above my head but making programs that allow binding of input on new aircraft would be really easy if we got access to this API with managed code.
Jimmy neutron Posted March 21, 2021 Report Posted March 21, 2021 I agree with the above, plus, John, if you are already so familiar with Java and C++ you'd probably have a blast with C#. It’s gotten a lot of attention in the past few years from MS.
John Dowson Posted March 22, 2021 Author Report Posted March 22, 2021 16 hours ago, Jimmy neutron said: I agree with the above, plus, John, if you are already so familiar with Java and C++ you'd probably have a blast with C#. It’s gotten a lot of attention in the past few years from MS. I've far too much to do and no time to start looking at c#. I can rebuild the API as a dll at some point though, and export the public functions of the WASMIF class. Not sure when I'll get time for this at the moment, but I'll let you know when its done.
Jimmy neutron Posted March 22, 2021 Report Posted March 22, 2021 8 hours ago, John Dowson said: I've far too much to do and no time to start looking at c#. I can rebuild the API as a dll at some point though, and export the public functions of the WASMIF class. Not sure when I'll get time for this at the moment, but I'll let you know when its done. No problem, and thanks for the support and effort on your part. Didn’t mean at all to sound demanding, I’m forever grateful for you and Pete’s work.
andhog Posted March 28, 2021 Report Posted March 28, 2021 (edited) I'm a Linux developer, but against those odds I managed to create a simple little app using the WAPI. It's called PersistentCRJ and has two buttons, one that reads the LVars of almost every switch and knob in the CRJ and stores those values in a file. The other button loads the values from the file and write them to the LVars, giving you the cockpit state you saved. Now to my question (that I would probably have asked before), what kind of license is the WAPI and module released under? I've uploaded it to flightsim.to (pending approval) and in the info (and readme) I have credited @John Dowson but did not include the WASM module since I didn't know if I was allowed to, instead I added the link to this forum. It would be easier for the users though if I could include the WASM module in my zip file. Would that be ok? Edited March 28, 2021 by andhog
John Dowson Posted March 28, 2021 Author Report Posted March 28, 2021 4 hours ago, andhog said: Now to my question (that I would probably have asked before), what kind of license is the WAPI and module released under? I haven't really thought about this, but its open source, no restrictions, use an adapt as needed. 4 hours ago, andhog said: I've uploaded it to flightsim.to (pending approval) and in the info (and readme) I have credited @John Dowson but did not include the WASM module since I didn't know if I was allowed to, instead I added the link to this forum. It would be easier for the users though if I could include the WASM module in my zip file. Would that be ok? 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.
Recommended Posts