activex

I tested the new FSUIPC executable, and works now as expected. I also used the new "F" specifier and it works correctly. All the CRJ lvars I am interacting with now work. Just one question: I noticed that reading of the lvars (via mapped offsets) is quite slow, like 5 times (or more) slower than using standard offsets (which are read instantaneously). Is this something that has to do with WASM? I know WASM technology, and the byte code should execute quite fast, but is there maybe marshalling or IPC involved? Can I do something about it, to increase speed? Btw, the attached zipped file of the FSUIPC and the executable inside it did not trigger windows defender. Not sure what changed but it just works.

Are you doing this on a windows box? Is it Windows 10 updated with recent updates? I want to try it, but this should be more concerning to you, if I am getting it, so will other Windows users. I am going to retry the system and try to download it again. Re-started my system, same problem, please advise on your environment. Can you post it zipped, I want to see what happens if I try downloading the archive. If same thing happens, it might be good to confirm with Microsoft that is false positive for your customers. Also, interestingly, your current version of FSUIPC doesn't trigger windows defender.

Sorry, I am cautious ... This is my work machine. Did you scan the executable on your system? If yes, what software did you use. Cleary, if Windows Defender flags it as a severe thread (trojan),- it has reason for it. It found virus signature in that executable, and I don't think that's by chance. Maybe rebuild the executable again?

I did, I simply reported trying using FLT64 and my results. Is this executable infected (it has trojan, is your computer infected)? See attachment

Still doesn't work, Lvar is discovered in FSUIPC, but doesn't see changes in the offset. Attached logs, and model behavior window screenshot. I did try reload function and tried again, doesn't make a difference. [LvarOffsets] 1=L:ASCRJ_VAR_AP_SELHDG=0xA000 I used the reload function when making changes to the ini file, does the reload function reload just the Lvars or also settings in the ini file (for example, when I change data type on my mapped offset and would like to use it without restarting the sim)? FSUIPC7.ini FSUIPC7.log

It doesn't work even using FLT32 but ... I did get the following offset log below when I moved the dial initially (for the first time): 137953 Monitor IPC:A000 (FLT32) = 39780386527510528.00000000 138110 Monitor IPC:A000 (FLT32) = 0.00000000 After that, moving the dial has no effect. I also discovered this (when testing the offset as FLT32) (not sure if that was a fluke): If you start your CRJ cold & dark, FSUIPC will be missing some of the Lvars (including the ones I reported). NOTE: Lvars are missing only in FSUIPC, they are still there in the sim (I can view them using Model Behaviors/Local Variables window). FSUIPC will not see Lvars even if you change the state of the aircraft from cold & dark => ready for taxi. To get the lvars in FSUIPC, your aircraft must start in state ready for taxi. (I did not bother testing the other aircraft states). That probably explains why you can't see the Lvars. Definitely something wrong with FSUIPC not being able to discover all CRJ.

Dang it ... It is hard to get it to crash in other aircrafts ... seems like there's something with the CRJ that makes it crash. I'll let you know if I find a better test case.

Can you install the FBW a320 and try some functions on that? This aircraft is more complex and has lots of lvars.

Okay, not too familiar with FSUIPC options, FSUIPC is really new software that I started using. I will do that.

Okay, ... I think I got it to crash on a stock aircraft. Select the "Cessna CJ4" (the one that comes with the sim, not the FBW one. Use my code that I have provided in previous post (On changed event should iterate over all Lvars not (LVarsChanged) collection, just like posted in my sample. Then, .. in the CJ4 cockpit, under lights there's a "Panel Lighting Brightness" knob (center knob, under dimming labelled "Panel"), start turning it left and right (from min to max), keep doing it until you get a crash. If it is not crashing, stop the app (not the sim), and start it again and repeat the process. Sometimes the crash is not induced. If that doesn't work, try an aircraft with lots of lvars, maybe a320 by FBW. Then try changing switches back and forth, those that are mapped to lvars and in rapid succession. Since this is a memory thing, it might hard to reproduce, but if you can get the CRJ, it should happens for sure since that's what happens to me. UPDATE: My observation is that the crash is induced as the Lvars are changed constantly and therefore changing any controls that read/write LVars will cause/may cause a crash.

John, the screenshot was taken after the log, so I went back and did this test in the right order, and yes, the screenshot values match what's in the log. I included also the ASCRJ_FCP_xxx_INFO offsets for HDG/SPEED (IAS) since they mirror the other offsets. ID=1535 ASCRJ_FCP_SPEED_INFO = 40.000000 174625 [INFO]: ID=1536 ASCRJ_FCP_SPEED_MODE = 0.000000 174625 [INFO]: ID=1537 ASCRJ_FCP_HDG_INFO = 220.000000 174625 [INFO]: ID=1538 ASCRJ_FCP_ALT_INFO = 10000.000000 174625 [INFO]: ID=1539 ASCRJ_FCP_WHEEL_INFO = -2.116344 174625 [INFO]: ID=1540 ASCRJ_FCP_WHEEL_MODE = 0.000000 174625 [INFO]: ID=1541 ASCRJ_MCDU_KYBD_TOGGLE = 0.000000 174625 [INFO]: ID=1542 ASCRJ_MCDU2_KYBD_TOGGLE = 0.000000 174625 [INFO]: ID=1543 ASCRJ_VAR_AP_LAT_ACTIVE = 5.000000 174625 [INFO]: ID=1544 ASCRJ_VAR_AP_LAT_ARMED = 0.000000 174625 [INFO]: ID=1545 ASCRJ_VAR_AP_VERT_ACTIVE = 2.000000 174625 [INFO]: ID=1546 ASCRJ_VAR_AP_VERT_ARMED = 0.000000 174625 [INFO]: ID=1547 ASCRJ_VAR_AP_VERT_ARMED_2 = 0.000000 174625 [INFO]: ID=1548 ASCRJ_VAR_AP_LOC_CAPTURE = 0.000000 174625 [INFO]: ID=1549 ASCRJ_VAR_AP_GS_CAPTURE = 0.000000 174625 [INFO]: ID=1550 ASCRJ_VAR_AP_ALT_HOLD = 0.000000 174625 [INFO]: ID=1551 ASCRJ_VAR_AP_ALT_CAPTURE = 0.000000 174625 [INFO]: ID=1552 ASCRJ_VAR_AP_USE_MACH = 0.000000 174625 [INFO]: ID=1553 ASCRJ_VAR_AP_SELMACH = 0.550000 174625 [INFO]: ID=1554 ASCRJ_VAR_AP_SELIAS = 40.000000 174625 [INFO]: ID=1555 ASCRJ_VAR_AP_SELALT = 10000.000000 174625 [INFO]: ID=1556 ASCRJ_VAR_AP_SELVS = 0.000000 174625 [INFO]: ID=1557 ASCRJ_VAR_AP_SELHDG = 220.000000 That out of the way, why is it that the FSUIPC software using the mapped offset doesn't display the correct value in the title bar, it is always zero (see attached images). The title bar always displays zero. Maybe it is datatype issue, if yes, can you tell me what datatype to try (the short form of the datatype to use in ini file and monitor offset screen, which one to select)? [LvarOffsets] 1=L:ASCRJ_VAR_AP_SELHDG=SD0xA000

I believe the handle is used to pump messages (ie notifications) that contain Lvar information to user's app. I haven't read the sim SDK but that's just my past experiencing working with WIN32 api and one of the uses of the window handle. Thanks for looking into this.

Sure thing. I would not bother you if these Lvars did not exist. Here's the requested info. I did also mention that I can retrieve the value correctly using Paul's api which uses your WASM module "FSUIPCConnection.ReadLVar("ASCRJ_VAR_AP_SELHDG")" <= works, that proves it must exist. I was using the CRJ700, but they are there also in CRJ550. See attached files. FSUIPC7.log FSUIPC7.ini

John, As per Paul's suggestion, I used the Log => offsets option, entered my offset A000 (S32) - Display to FS title bar and I get a zero value display all the time regardless of me changing the heading and observing the Lvar "ASCRJ_VAR_AP_SELHDG" being changed (in the sim). My ini file again: 1=L:ASCRJ_VAR_AP_SELHDG=SD0xA000 This is not the only Lvar like this, "ASCRJ_VAR_AP_SELIAS" same problem. On the other hand, these worked no problem (they are mostly flags, and toggles): [LvarOffsets] 1=L:ASCRJ_FCP_HDG=SD0xA000 2=L:ASCRJ_FCP_HDG_LED=SD0xA004 3=L:ASCRJ_FCP_HDG_CHANGE=SD0xA008

Sorry, I had to fix the offset (Initially typed it wrong in the log and had to edit my comments here) ... now it is 0. Back to John? Curious, why the other offsets I worked with work and this one doesn't? This is really confusing now. These work: [LvarOffsets] 1=L:ASCRJ_FCP_HDG=SD0xA000 2=L:ASCRJ_FCP_HDG_LED=SD0xA004 3=L:ASCRJ_FCP_HDG_CHANGE=SD0xA008 I tried another that displays similar info "ASCRJ_VAR_AP_SELIAS", same issue. In summary, the flag offsets and toggle offsets work, the ones that display specific values don't. 2) As a side note: I tried today the new MSFSVariableServices class. I composed the following app (see code below), it initializes fine but then no events are ever triggered (beside the log event) neither any Lvars are discovered. Did this ever work for anyone?? Log messages suggest start up worked but nothing happens after. Lvars log: [INFO]: **** Starting FSUIPC7 WASM Interface (WAPI) version 0.5.1 Lvars log: [INFO]: Connected to MSFS LogLvars() produces: Lvars log: [INFO]: We have 000 lvars: But ... if I do this from FSUIPC, it logs all the CRJ lvars to log file just fine. UPDATE: Changed call from _LvarsSvc.Init() to _LvarsSvc.Init(this.Handle), Works now but we have some Band news, read-on: 1) How did I get it to work: Remember that window handle param for the Init() method? Well, if you don't pass window handle to the Init() or just pass 0 nothing happens (as described above). Looks like the window handle is required. Once it is passed, I can see the Lvars and can iterate over these (sometimes) but what's the bad news? See next point. 2) The values changed event fires and causes intermittent crashes (but mostly it crashes): Here's the console trace when it crashes: The program '[18140] MSFSLvarsWinformsApp.exe' has exited with code -1073741819 (0xc0000005) 'Access violation'. By debugging it, it appears its happening here: Lvars_OnValuesChanged event The crash happens on 3rd iteration (sometimes later) and it appears that the memory violation happens every time on the same memory address. protected override void OnLoad(EventArgs e) { base.OnLoad(e); _Setup(); } protected override void OnClosing(CancelEventArgs e) { base.OnClosing(e); _Teardown(); } private static void Lvars_VariablesReadyChanged(object sender, EventArgs e) { // Show the variable status in a checkbox var ready = _LvarsSvc.VariablesReady; } private static void Lvars_OnValuesChanged(object sender, EventArgs e) { Console.WriteLine($"Values changed...."); foreach (FsLVar lvar in _LvarsSvc.LVars) { Console.WriteLine($"Lvar {lvar.Name} (ID {lvar.ID}) = {lvar.ValueChanged}"); } } private static void Lvars_OnLogEntryReceived(object sender, LogEventArgs e) { Console.WriteLine($"Lvars log: {e.LogEntry}"); } private void _Setup() { // Lvar service events _LvarsSvc.LogLevel = LOGLEVEL.ENABLE_LOG; _LvarsSvc.OnLogEntryReceived += Lvars_OnLogEntryReceived; _LvarsSvc.OnVariablesReadyChanged += Lvars_VariablesReadyChanged; _LvarsSvc.OnValuesChanged += Lvars_OnValuesChanged; _LvarsSvc.Init(this.Handle); // <= Required, without no events are fired, nothing happens _LvarsSvc.LVARUpdateFrequency = 6; // Get new lvar values 10 times per second (Hz) _LvarsSvc.Start(); } private void _Teardown() { _LvarsSvc.Stop(); }

I was trying to provide a feedback, maybe a bit too strong. I retracted my comments, apologies if I offended you. True, but as it turns out, your help (+ my feedback) helped Paul to fix a bug. So, your support was valuable with his API. Sometimes, 2 parties need to get involved to fix an issue. I will not post anymore C# related code.

Paul, I am going to reach to you one more time with the following problem. John sent me over here because I am using your api. I am trying to read now this Lvar: ASCRJ_VAR_AP_SELHDG (verified, exists, it is read only) Here's the setup: [LvarOffsets] 1=L:ASCRJ_VAR_AP_SELHDG=SD0xA000 Here's the code: var offset = new Offset<int>(0xA000); FSUIPCConnection.Process(); var result2 = offset.Value; It always returns 0 although the heading is other than zero. Your code on the other hand works: var result = FSUIPCConnection.ReadLVar("ASCRJ_VAR_AP_SELHDG"); Same console app, I open/close connection as usual. I am lost why some lvars work, others don't.

Okay will do. The statement simply read an offset of 0xA000 into result variable. Of course, I verified it in the sim and also stated that I can read it using Paul's api function (that takes that very lvar string), so it is 100% legit. I do understand the difference between read vs write lvars, I never bothered you with that, my main issue so far were about setting up the ini files with offsets mapped to lvars and then reading these offsets. As for me, I find it nearly impossible to work with this SDK: 1) There's no logging to troubleshoot any mapping issues, there are no exceptions being thrown, etc. 2) I discovered already 1 bug, in Paul's DLL and there maybe more, either in his DLL or somewhere else. What's frustrating about this whole experience is that even if you follow the documentation and the stuff just doesn't work. Not sure if it is your code or Paul's code that's giving me issues and there's no way to tell. I would like to thank you for your help and yes, go ahead close this topic, I will see if Paul can help me.

John, 1) I am stuck on reading current AP heading select (using Lvar: ASCRJ_VAR_AP_SELHDG). I simplified my example and still it is not working. Here's the ini file: [LvarOffsets] 1=L:ASCRJ_VAR_AP_SELHDG=SD0xA000 Here's the code: var offset = new Offset<int>(0xA000); FSUIPCConnection.Process(); var result2 = offset.Value; Please note: I got other Lvars to work but this one doesn't work. I know the value can be read because this code works (Paul's api call, he uses doubles for Lvars across the board): var result = FSUIPCConnection.ReadLVar("ASCRJ_VAR_AP_SELHDG"); 2) If I omit the datatype in the ini file, then it defaults to double (8 bytes)? Therefore, is this valid entry? [LvarOffsets] 1=L:ASCRJ_VAR_AP_SELHDG=0xA000 In that case I presume I have space out my offsets 8 byte apart. I did try using a double in the above example with single offset, no luck.

Thanks John. I needed to verify with you that the offsets defined in the ini are not just purely logical HEX representation but instead represent and are mapped in physical address space.

John, ... 1 more question: When mapping multiple lvars to multiple offsets, when I select the free offset value, do I space the offset value based on mapped data type? For example: [LvarOffsets] 1=L:ASCRJ_FCP_HDG=UB0xA000 2=L:ASCRJ_FCP_HDG_LED=UB0xA001 First offset is at A000 2nd offset is next byte over A000, therefore A001 But, if [LvarOffsets] 1=L:ASCRJ_FCP_HDG=SD0xA000 2=L:ASCRJ_FCP_HDG_LED=SD0xA004 First offset again starts at A000 but 2nd offset should be at A004, next 4 bytes over A000 (since first offset occupies 4 bytes in size) So, does the datatype matter on the offset selected or no?

Yeap, ... I did confirm that the hdg mode Lvar in the CRJ (when you push the hdg button on the MCP) only goes high (value=1) when the button is pressed and immediately is reset back to 0. I have to do this all manually with the offset so that the CRJ notices the trigger. Thanks for the rest of explanation and support. After playing with this long enough and your support and John's I have a starting point to make my MCP work with the CRJ lvars.

True but the hdg mode in CRJ doesn't work that way. When you push the button on the MCP of the CRJ aircraft (inside the sim) it sets the Lvar to 1 and resets it back to 0 (happens very fast, it is difficult to spot this visually in the model behavior window). It is programmed this way so that the lvar always starts with "0" value regardless if the hdg mode is on or off. At least this is my observation and it works this way when manipulating the mapped offset programmatically (set the offset to "1" to trigger the toggle and then set the offset back to 0 - ready state). I'll check out the user guide, Thanks for pointing me the right direction. Just one thing I spotted (see ERROR entries) in the log file when FSUIPC was shutting down, excerpt from FSUIPC7.log. I had no errors using FSUIPC or interfacing with my mapped lvars to offsets. Should I be concerned? 149610 [ERROR]: Error clearing lvar value data definition with id=16 149610 [ERROR]: Error clearing lvar value data definition with id=17 149610 [ERROR]: Error clearing lvar data definition with id=4 149610 [ERROR]: Error clearing lvar data definition with id=5 149610 [ERROR]: Error clearing lvar data definition with id=6 149610 [ERROR]: Error clearing lvar data definition with id=7 149610 [ERROR]: Error clearing lvar data definition with id=8 149610 [ERROR]: Error clearing lvar data definition with id=9 149610 [ERROR]: Error clearing lvar data definition with id=10 149610 [ERROR]: Error clearing lvar data definition with id=11 149610 [ERROR]: Error clearing lvar data definition with id=12 149610 [ERROR]: Error clearing lvar data definition with id=13 149610 [ERROR]: Error clearing lvar data definition with id=14 149610 [ERROR]: Error clearing lvar data definition with id=15 149719 [INFO]: SimConnect_Close done 153250 MSFS no longer running - exiting 153250 === Hot key unregistered 153250 === Stop called ... 153250 === Closing external processes we started ... 153766 === About to kill any Lua plug-ins still running ... 153922 === Closing global Lua thread 154703 === About to kill my timers ... 154907 === Restoring window procs ... 154907 === Unloading libraries ... 154907 === stopping other threads ... 154907 === ... Button scanning ... 155016 === ... Axis scanning ... 155125 === Releasing joystick devices ... 155125 === Freeing macro memory 155125 === Removing any offset overrides 155125 === Clearing any displays left 155125 === Calling SimConnect_Close ... 155344 === SimConnect_Close done! 155344 === AI slots deleted! 155344 === Freeing button memory ... 155344 === Closing my Windows ... 155344 === Freeing FS libraries ... 156360 === Closing devices ... 156360 === Closing the Log ... Bye Bye! ... 156360 System time = 12/08/2021 22:11:06 156360 *** FSUIPC log file being closed Minimum frame rate was 46.2 fps, Maximum was 109.4 fps Average frame rate for running time of 136 secs = 64.6 fps Maximum AI traffic for session was 14 aircraft Traffic deletions 0 aircraft Memory managed: 5 Allocs, 4 Freed ********* FSUIPC Log file closed ***********

Thanks, that's great explanation. When you probably were responding to my comments, I changed them on you by making a subtle discovery about the hdg toggle in the CRJ. I am going to just repeat it here for correctness: In order for the hdg toggle to work consecutively, the lvar must always be reset to 0 before setting it back to 1 again. Therefore, I have to explicitly set the offset to 0 (ie. clear it) for the whole thing to work, and I need to put a time delay "Thread.Sleep(10)" between each Process() as indicated in my updated code above. Can you comment on the required time delay? Is this MSFS thing or the CRJ thing or offset thing, or?

John, I got the code to work, the problem was that my lvar section in the ini file was named "[LvarOffsets.crj]", when I changed it to "[LvarOffsets]" it works. So I guess the question is when I suffix the name with a profile name, how or where do I have to create the profile? I am new to this. I would also make a correction about the CRJ hdg toggle. By looking at it in "model behavior" window, in the sim, you need to always clear it to 0 before setting it back to 1 to have the toggle behavior. This was not apparent from just using the WASM set lvar option.