activex

Ah, Okay, thanks for the explanation. No worries. I don't have any plans to run it on different platform other than Windows. The important thing is to know the source of the warning (ie. why). I'll leave the warning as is for now.

Hi; I am using the latest nuget 3.3.9 referenced in my .net standard 2.0 library When I build my library in VS I get this warning: Severity Code Description Project File Line Suppression State Details Warning NU1701 Package 'FSUIPCClientDLL 3.3.9' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8, .NETFramework,Version=v4.8.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project. FlightSimLibrary F:\DEV\Current\Libraries\FlightSimLibrary\FlightSimLibrary.csproj 1 Although when I run any application on .net 8 that uses this library everything works fine this warning pollutes my build and would like it to be gone. What's the reason for this warning?

Using rotor break control it worked perfectly. Thank your for solving this problem for me.

Norm, Please keep us posted on the progress of this issue. I have exactly same problem. lk

Yea, I understand that the issue is with PMDG, ... I thought I post this out here maybe people with work around will see this post and post the solution.

All; Since the latest updates from PMDG 737, the offset (0x0BC8-parking break set/reset) doesn't work properly anymore for controlling/setting parking break sw on the throttle quadrant. Previously, setting this value to 0, park break off, and then back to 32767 park break on while holding the rudder pedals worked fine. Now, when you hold the rudder pedals, you have to write to the offset multiple times (exactly twice) and you write the values in opposite logic: 0-park break on, 32767-park break off. I also noticed that writing this offset now triggers rudder pedals break. I have no idea what's the correct way now to set the throttle park break sw on the throttle. Any help be appreciated.

Ah okay, I thought there was some logic you added to behave this way. Thanks for clarifying.

Hi there, I noticed that the offset (MCP_VertSpeedBlank=0x65D2) is not working exactly as I expected. This offset returns true only if V/S mode is off and therefore V/S display is blanked out. But if you enable V/S mode (via V/S button) and the display is still blank (ie because the value entered is zero) the offset returns zero indicating that the V/S is not blanked out but in reality it is. Why is this implemented like this? lk

Disregard, offset works. I had to map it to a float (instead of int) because it uses ranges of: 0-0.5. Now it works.

Hey, This case is for the PMDG 737. They have an lvar (switch_343_73X-spd brk armed status) which is invisible (ie. at least through the Behavior debug Window/Local Variables in MSFS) until the function is triggered and its value is changed and that's when the offset appears visible in the Behavior debug window. I have mapped this offset in my FSUIPC7.ini file as: 5=L:switch_343_73X=SD0xA010 After the offset became visible, I tried to used "Wasm->reload " and it does reload the lvars because the status message says it loaded 1925 lvars (from the previous number of 1923) and also appears in the FSUIPC window when after I ran Wasm->List lvars and has the correct value. Either way, when I try to read/write my offset, nothing happens (reads return 0. writes do nothing). Offset is writable as I verified through the debug window in MSFS. Question: Since this offset is added later at the stage, is this why it is not working. FYI: I know the purpose of the Wasm->reload option and let me give you feedback on it when working with pmdg 737: It almost never works. I am always forced to reload the sim when I make changes to my ini file. Not sure if that's FSUIPC or PMDG or MSFS.

Paul, Can you please confirm that: If I call the FSUIPCConnection.Process("abc"), the method will only look at the offsets that are within the group "abc" and exchange data for these offsets. Other offsets that are not within that group or are group-less are ignored. Is my understanding correct? lk

Excellent, thank you. "thrustInput1Offset.GetValue<short>();" - This is still using static typing so it is limited in use, ... The static typing is an issue when you are setting the value SetValue<short>(). For GetValue it usually doesn't matter because you have to cast the returned value back to specific data type unless you are displaying it.

The SetValue() and GetValue() methods should not be visible when using the Offset<> class. " - No, the design is fine. I need to use Offsets polymorphically, therefore, just fix the methods, don't change the design.

Hi, Problem: Writing an offset using SetValue() method ignores the value passed in as parameter. Consider this code: var thrustInput1Offset = new Offset<short>(0x089A, true); //write int value3 = 9000; var convertedValue = Convert.ChangeType(value3, typeof(short)); thrustInput1Offset.SetValue(convertedValue); // <= The internal value of the offset is not changed after this call FSUIPCConnection.Process();

Disregard. Looks like the "0x089A" offset is write only offset.

All, I have installed FSUIPC 7.3.1.1 (using non-registered version) and I am running SU11 (Canada changes). I am using FSUIPCClientDLL 3.2.21 (latest). I selected/loaded Cessna Citation CJ4. The following lines of code tried to read current thurst input 1 value for the cessna aircraft. Instead of reading the value, it returns always zero. FSUIPCConnection.Open(); var thrustInput1Offset = new Offset<short>(0x089A); FSUIPCConnection.Process(); var thrustInput1 = thrustInput1Offset.GetValue(Type.GetType("System.Int16")); Console.WriteLine($"thrust input 1={thrustInput1}"); FYI, this offset worked before, now it stopped working. I did quick dirty test on offset "0x3AE8" (General engine 1 throttle lever position) and this one works.

Interesting... when I had this issue I did reload the MSFS couple times just to ensure that having the 737pmdg (as previously active aircraft) did not alter the in-game state somehow. I'll keep you posted if something comes up.

Updating from 7.3.8 beta to 7.3.8 release version fixed the issue. Therefore my CRJ MCP integration works now. Thanks.

The FSUIPC beta 7.3.0.8 - breaks my previously working MCP with Aerosoft CRJ. I have confirmed this by rolling back to previous version of 7.2.1.2. The way I communicate/control the MCP in the CRJ is via CRJ LVARS and I have these mapped to free offsets in the FSUIPC7.ini file. Then I read/write these offsets. Everything works perfectly and I have been flying my CRJ for past year with no issue. I upgraded to FSUIPC beta 7.3.0.8 so I can fly the PMDG 737 with my MCP. I finished the 737 MCP interface and it works with this beta but using this beta for my CRJ MCP integration doesn't work anymore. Specifically, any of the mapped offsets (to LVARs) in the ini file stopped working, I still can read/write the L/R course but I am using standard offsets for it. What changed????

@Paul HentyThanks, your examples work. @Jon Dowson I did enable the broadcast option, but somehow the change got overwritten once I launched the sim. Nevertheless, I fixed the ini file and the offsets I tried seem to work now.

Hi, I am using the FSUIPC .net wrapper and have FSUIPC beta 7.3.0.8 installed. I have latest version of PMDG 737-700 installed I have this code (to enable Hdg Mode): const uint MOUSE_FLAG_LEFTSINGLE = 0x20000000; FSUIPCConnection.SendControlToFS(PMDG_737_NGX_Control.EVT_MCP_HDG_SEL_SWITCH, (int)MOUSE_FLAG_LEFTSINGLE); But it does nothing. NOTE: The following works just fine: FSUIPCConnection.SendControlToFS(66587, 39201) So does this: FSUIPCConnection.SendControlToFS(FsControl.AP_HDG_HOLD_ON, 0); // or FSUIPCConnection.SendControlToFS(FsControl.AP_HDG_HOLD, 1); I would like to know why using the PMDG 737 NGX control enum it doesn't work? Again, using FSUIPC beta 7.3.0.8. FYI- On another note: The unlocked mapped offsets from PMDG 737 don't seem to work. When I try to read current heading (offset: 65CC), I get 0 back. I am referencing Offset Mapping for PMDG 737-700.pdf, dated JULY 2022. lk

So I tried it, there's quite noticeable response improvement, when I write the values into the CRJ (as I rotate the encoder and watch the display change in the CRJ cockpit, in the sim), I would say pretty comparable to writing standard offsets. The important thing here is that when benchmarking I should be observing the changes inside the CRJ cockpit, not on my MCP hardware since that is affected by the hard-coded encoder delay (in my code) explained below. I am stating this because initially I was looking at the hardware displays when turning the encoders. Quick question: How much of a performance hit to my FPS is there if I use the setting LvarUpdateFrequency=Frame (as opposed to other settings)? In my case, I only have like 30 offsets total that are mapped to lvars. Are these only offsets that get monitored (my/user defined offsets), or internally there are other offsets? I haven't noticed any FPS degradation, but I thought I ask. I noticed in your ini file acronym "CDA", what does that stand for, what is it used for? So that fixes that, one still remaining item that I have on my list is to see if I can find some writeable offsets for hdg/speed/alt/vs so I don't have to simulate encoder turns. To turn an encoder in the CRJ, I have to set the lvar to 1, put a small delay, and reset it back to 0 (simulate a push button hold/release). That delay has to be long enough so that CRJ can detect the release. 10ms works best (best trade-off between performance and CRJ seeing the reset). Thanks for the help.

I did not mention that for encoders only: When I change a dataref (Xplane) or offset (MSFS), I read the value from the sim immediately and update the MCP display immediately. I do this for both sims, Xplane and MSFS. As long as I have direct access to the offset (or dataref) it is very responsive. The timer is used more for LEDs on buttons and if state changes in the sim (for example, turning off FD, turn's of other modes) or even changing hdg/alt/speed in the sim (not via hardware) I sync those changes back to the hardware. 500ms in this setup works fine. Not using WASM monitoring, I explicitly read the offsets using my own timer. Unless, the offsets I read are being populated by WASM monitoring this will not make any difference. I can try though. My bet is still on the fact that I cannot write CRJ offsets and have to trigger a change using an offset for an encoder (which requires you to simulate a button press, set it to 1, then reset it back to 0, and the reset action needs a delay otherwise it will not work).

I am using a polling timer (every 500ms) and I am reading the lvar mapped offsets + standard offsets (using the same timer, the offsets are sitting in the same collection). The mapped offsets seem to take longer to get populated or it could be a side-effect if writing of the offsets is slow. I do observe when I write the offsets (lvar mapped + standard offsets) that the changes in the CRJ aircraft (like displayed hdg) appear slightly slower when changing an lvar mapped offset compared to standard offset. In summary: Same code, same polling timer that iterates over 2 different types of offsets (standard, vs lvar mapped) sitting in the same collection, lvar mapped offsets are slower to read/write. Maybe it is the CRJ code that's slow receiving/updating itself or something else..., I would decrease my polling timer interval but I don't think I will see the difference since the standard offsets respond fast, so I am thinking the problem is somewhere else. UPDATE There's 1 major difference that I do differently when writing standard offset vs lvar mapped offset: Since the CRJ lvars are mostly read-only, I have to use the encoder (knob) on the mcp to trigger the change and then I read the changed value back (in the lvar offset) and update the display on my MCP. For the standard offsets, I write them directly with the actual value. That's probably why it works faster.

Update/ FYI I will not be using the "MSFSVariableServices" class for now since it crashes with the CRJ but to update you, John has fixed the FSUIPC code and it works fine with the mapped offsets (to lvars) using ini file. I noticed that reading the mapped offsets (that are mapped to lvars) is quite slower compared to reading standard offsets. This is not much of an issue with the buttons/LEDs (not as noticeable) but you notice the slowness when I am refreshing the hdg/speed/alt displays on my Goflight hardware, it is so sluggish. Also, turning the encoders is kind of sluggish when sending data back to the CRJ (ie updating the lvars). I wonder if this is because of WASM.