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

Hello, I have tested a number of functions: start(), end(), reload(), getLvarList(), LogVars(), getLvarValue(), getLvar() and setLvar(). I used the source files posted on march 9th and the release 0.2 posted today and made an app inspired after "WASMClient.cpp". My IDE is Embarcadero C++ Builder. I got a few errors at compilation, maybe the compiler is less permissive? I can give you details, if you wish. I made a few modifications and compiled and executed successfully. The only concern is setLvar() that does not work in debug mode, and works in release mode, although the logging is the same; I tested this with the King Air and the Lvar "XMLVAR_YokeHidden1", set to either 1 or 0: [DEBUG]: Control sent to set lvars with parameter 65560 (10018): lvarId=24 (18), value=1 (1) [DEBUG]: Control sent to set lvars with parameter 24 (18): lvarId=24 (18), value=0 (0) ("does not work" means that the yoke visibility does not change). Also, I am curious to know why getLvar() has a single prototype that returns a double, and setLvar() has several prototypes. Thanks for your work, Dan

I solved the issue, but I answer first. Done. FSUIPC7 works in either case. There are differences in the logs; here are samples: FSUIPC started last: 32063 EV_KEYUP received: 0x25 (%) 32063 KEYUP: VK=37, Waiting=0, Shifts=0 32063 .. KeyUp received from FS but not programmed FSUIPC started first: 31484 KEYUP: VK=98, Waiting=0, Shifts=0 31484 .. KeyUp not programmed -- passing on to FS 31484 **** keyUp sent via SendInput or 31469 KEYUP: VK=16, Waiting=0, Shifts=0 31469 .. KeyUp received from FS but not programmed I discovered that FSUIPC window class name is "FS98MAIN" which is also the FSX window class name. Since I try to have my apps compatible with FSX, FSW and FS2020, the handle needed to bring FS window to foreground was found using FindWindow("FS98MAIN", NULL), then FindWindow("FSWMAIN", NULL), finally FindWindow("AceApp", NULL). So when FSUIPC7 is started first, my apps find the FSUIPC7 window instead of the FS one. So, I reversed the order of the FindWindow()'s and this solved the issue, since now, the right window is found. The FSUIPC7 log file now looks like when FSUIPC was started first, even when it is started last.

Hello, I have a 6 degrees of freedom device that I use to control the eyepoint with my own software. Because the relevant SimConnect features (SimConnect_CameraSetRelative6DOF(), EYEPOINT_UP and alike, PAN_UP and alike) and FSUIPC features (such as Eyepoint Right, Pan Right) do not work anymore, I had to modify my app (w.r.t. the FSX version) so as to emulate keystrokes. To do so, I first use SetForegroundWindow() to bring the MSFS window on foreground, then use either SendInputs() (or the older keybd_event()) or a Teensy microcontroller to send the keyboard messages. This works, provided my software has started before FSUIPC7. When FSUIPC7 has started first, things are messed up: the MSFS window does not stay on foreground, keystrokes are lost, and sometimes the About window of FSUIPC7 opens (note that some keystrokes include the ALT key). Can you understand the issue, does FSUIPC7 hook the keyboard or something similar? FSUIPC 7.02, MSFS 1.12.13.0

I forgot to mention that my first attemp was to get the log file in the root of 'C:' and that it failed. It actually worked in the root of another drive, in my case 'M:'. file=M:\SimConnect%01u.log

Thank you for yor fast answer. I found the FLT path line and moved SimConnect.ini to xxx\LocalState. I got the expected logging (both console and file, since I had written 'console=Yes'). Note that the log filename did not increment at each MSFS startup until I added 'file_next_index=1'. Thanks again.

This FAQ post explains how to get SimConnect logging, it gives the folder name where to place the required SimConnect.ini file. As for MSFS, it is "USER\AppData\Roaming\Microsoft Flight Simulator" (USER replaced by the actual Windows login account name). However, such a folder did not exist in my system. I created it and placed the required SimConnect.ini file in it. I did not get any logging. My MSFS version is 1.12.13.0. Could the folder name have changed since the post update? Or could it be a matter of misspelling?

My left throttle lever has a mechanical detente, but no micro-switch associated. My script polls the lever raw value cyclically: -- get left throttle joystick axis data, and current gauge lever 1 position joy1 = ipc.axis(4, "S") -- left throttle lvarEngine1ThrottlePosition = ipc.readLvar("L:Engine1ThrottlePosition") -- 0 = max, 50 = idle, 100 = full reverse -- reverse ? if joy1 < -14000 then -- reverse asked for desiredReverse = joy1 * aRev + bRev -- 50 = min, 100 = max if desiredReverse > 100 then -- saturate desiredReverse = 100 end if lvarEngine1ThrottlePosition < desiredReverse then -- increase reverse ipc.keypress(113) -- send F2 to engage reverse end else -- no reverse if lvarEngine1ThrottlePosition > 50 then -- decrease reverse ipc.keypress(114) -- send F3 to stop reverse end end where aRev and bRev are calculated once forever out of the polling loop: -- slope and offset (for reverse) for throttle 1 lever in the range [-14000, -16300] aRev = - 1 / (-14000 + 16300) * 50 bRev = 14000 * aRev + 50 Note that this allows to adjust the reverse thrust linearly (marginally interesting, I admit).

First, I found a workaround: rather than using 2 mixture levers assigned to Mixture1 and Mixture2, I used only 1 lever, assigned to Mixture. This actually controls the 4 VC levers, and surprisingly, even when applying a joystick calibration. There is something odd with the 2-lever configuration, maybe Pete can explain? Then, I went through the FSUIPC and Lua documentation, which made your reply clear to me. I solved the issue by making a Lua script that acquires the 2 lever positions and controls 2 Lvars per engine "L:MixtureRatioLeverX" and "L:MixtureRatioLeverXPosition". Now, I can see the VC mixture levers moving by pairs, and also the fuel flow gauges react accordingly. I was quite amazed by the power of these Lua scripts and Lvar’s. So, I went on with them, and I solved another problem: the throttle levers could not control the reverse (although they are properly calibrated), only F2 keystrokes work. This time, I could not find a control Lvar, but, alternatively, I could acquire a Lvar "L:Engine1ThrottlePosition" that ranges from 50 to 100 in the reverse area; the Lua script simply sends F2’s until the lever position and the Lvar are consistent (and also F3’s when the lever goes back to Idle). Thanks again for your helpful reply, thanks to Pete for the power of FSUIPC+Lua+Lvar’s.

Hi, Thank you for your quick and extensive reply! As you suggested, I first upgraded the B377 installation. Unfortunatly, it did'nt change anything regarding the mixture levers. So far, I have not used the Lua FSUIPC interface, nor plain Lua (I rather code in C++). I have to go through the documentation and make tests, trying also to keep the calibrations and mapping as they are currently, for the other aircrafts. It will take some time before I can come back and keep you informed. Thanks again.

My configuration: - Win 7 x64, FSX SP2, paid FSUIPC 4.939. - 2 mixture levers controlling the pots of a USB joystick embedded in a home-made pedestal, no specific driver. I have always been using the 2 mixture levers by assigning them to Mixture1 and Mixture2 in FSX and calibrating them in the relevant FSUIPC tab (section 4 of 11: Separate mixture controls), with the checkBox 'Map 1->12, 2->34' checked. This is fine for all 2 or 4-engine aircrafts I know, except for the A2A Boeing 377 StratoCruiser; in that case, the virtual cockpit levers won't move. I made some tests: - remove assignments from FSX and make assignments in FSUIPC => same. - uncheck 'Exclude MIXTUREn_SET' => same. - reset FSUIPC calibrations and uncheck 'Map 1->12, 2->34' => lever 1 controls mixture 1, lever 2 controls mixture 2, mixtures 3 and 4 not controlled, as expected. - reset FSUIPC calibrations but leave 'Map 1->12, 2->34' checked => lever 1 controls mixtures 1, 2 and 4, lever 2 controls mixtures 2 and 4, mixture 3 not controlled. Note that while the virtual cockpit levers don't move, the pedestal levers actually have effects: for instance, moving a lever back and forth, I can almost stall an engine and then hear the crew announcing that the oil pressure rises. Also, I spied the SimConnect variables 'GENERAL ENG MIXTURE LEVER POSITION:i' and could see noisy values, presumably due to conflicts between the pedestal and virtual cockpit lever positions. Can someone help?