d147

I was using v7.4.1 and saw FSUIPC constantly opening its window at startup saying that v7.4.2 was available. I did update as any request to a forum should be based on observations made on the most recent version, and so, the window does not appear anymore. However, it should happen again when a new version is available; unlike other members, I do not like this automatic window opening, I am not favorable to frequent updates to my system, and so, I have to close the window manually at every startup. I understand and accept that other users are happy with that, but could you consider a more flexible option such as an ini file entry letting the user choose whether the window should show or not (similarly to the ShowSplash entry), or a badge on the tray icon ? Note that my concern is only the automatic opening of the window, the text on the window saying that there is a new version is actually a nice feature.

I have installed MSFS Add-on Linker. The junctions it creates or erases according to the pre-selected aircraft(s) are actually an efficient way to reduce the number of LVars. Switching from the DC-6 alone to the Connie alone gives me 1961 LVars at the first run, 1912 at the second run (instead of 1926, previously). The DC-6 gives me 1724 LVars and works better; now, I understand why some LVars I wanted to use were missing when the 3066 limit was hit, and why they were not missing when I re-started the game with the same aircraft as that one loaded at the previous FS session. Thanks again!

Shame on me, how could I miss the comment after "#define MAX_NO_LVAR_CDAS 21"? I assume this value cannot be modified to solve the issue. I'll try MSFS Add-on Linker, thanks for your patience and advise. I used the 3 files provided to patch your plugin, and yes, my 552 characters calculator string works as expected, no more crash. Thanks a lot for your reactivity!

Hi John, months ago, I participated a little in the debugging of the WASM client API, now I use it extensively, mainly through the the function "executeCalclatorCode". Currently, I use FSUIPC 7.3.6 (as reported in FSUIPC7's log file) and my client based on the github version 0.5.10 released "10 days ago" = end of May. I also use "FSUIPC7|WASM|List Lvars" so as to track the Lvar changes. I found 1 problem and a potential one: Problem 1: "WASM.h" (version 0.5.9) says that the MAX_CALC_CODE_SIZE is 1024 by default. I passed 415 characters to executeCalclatorCode without any issue. But when I try to pass 552 characters, I find the relevant line in FSUIPC_WASM.log, but it is the last line even if other executeCalclatorCode calls come afterwards. And eventually, MSFS crashes. Note that I get the same result by passing the long string to "FSUIPC7|WASM|Execute Calculator Code...". It is not a major issue, since I have a workaround, i.e. split my calculator code in 2 independent and shorter strings. I would prefer to know the real max size, and where it comes from (FSUIPC, MSFS, aircraft loaded in the sim, ..?). Potential problem 2: "WASM.h" says that it allows for "3*1024" Lvars. When I load Red Wing's Super Constellation in the sim, "FSUIPC7|WASM|List Lvars" gives 1926 Lvars (so does my own client), which is fine; this number stays stable until I shutdown MSFS. When I restart MSFS and load PMDG's DC-6, I get 3066 Lvars, among these are Lvars belonging to the previous aircraft. I am aware of this behaviour, but since 3066 is very close to 3*1024, I might hit the limit some day. May I safely change MAX_NO_VALUE_CDA from 3 to, say, 4, recompile my client and use it with the current FSUIPC7_WASM.wasm?

Same for me with 1.15.8.0!

Too bad, it looks like they do not make (enough) non-regression tests prior to release.

I can confirm this also. So do I. I have installed the updated SDK, SimConnect.dll and SimConnect.h have not changed. Maybe WASM?

I have re-tested my app using FSUIPC_WAPID.dll and FSUIPC_WAPI.h posted earlier today. I had missed the new way to enumerate Lvars and Hvars, rather than using map's. Everything is OK now. Thanks a lot, and thanks also for the new FSUIPC version.

Hi, I have tested FSUIPC_WAPID.dll posted on April 7th with FSUIPC-WASMv0.4.9, focusing on the King Air's Lvar "XMLVAR_YokeHidden1". I used 2 cases: 1: using fsuipcw_init() with a NULL value as the 1st argument. fsuipcw_getLvarList() returns an empty list fsuipcw_getLvarIdFromName() returns 0 fsuipcw_getLvarFromName() returns 0.0 2: using fsuipcw_init() with a valid window handle as the 1st argument. fsuipcw_getLvarList() results in a runtime error (as already mentioned previously) fsuipcw_getLvarIdFromName() returns 1 fsuipcw_getLvarFromName() returns a correct value reflecting the status of the yoke (hidden or not) To write a value, my successful workaround: first, enumerate the IDs and Lvars using fsuipcw_getLvarNameFromId(), incrementing ID starting at 0, until the name is either found or left equal to ""; "XMLVAR_YokeHidden1" is actually found. then, use fsuipcw_setLvarAsShort() with the found ID; this actually changes the status of the yoke. So the second case actually allows to read and write a Lvar through FSUIPC_WAPID.dll.

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

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

Hi John, 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

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

Hi John, Got it, thank you! Nice, so does my app normally. 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. 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; 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. 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

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