jaxx

Have you tried not using LogLVars and instead simply accessing the LVars directly? Very simple WindowsForms example: MSFSVariableServices VS; private void Form1_Load(object sender, EventArgs e) { VS = new MSFSVariableServices(); VS.OnLogEntryReceived += VS_OnLogEntryReceived; VS.Init(this.Handle); VS.Start(); } private void Button1_Click(object sender, EventArgs e) { VS.RefreshData(); string text = VS.LVars.Count + " LVARS\r\n"; foreach (FsLVar lvar in VS.LVars) { text += lvar.Name + " = " + lvar.Value + "\r\n"; } MessageBox.Show(text); } private void VS_OnLogEntryReceived(object sender, LogEventArgs e) {}

I have written a small class that handles the connection starting, connection error handling etc. Reason is my app is constantly running and making requests and should not be impacted if the sim is not running or starting or shut down in between. With the FSUIPCConnection I could just check if the connection is open, if not try to open it and if there were an error (e.g. FSUIPC was not running) I would get some kind of exception and the app would wait a bit and try again. With the new MSFSVariableServices there seems to be no immediate failure (e.g. when start fails), instead the information is only then received in the log entry message events. Hence why I wrote this handler class. Usage is quite simple, when you run code through the "Try"-methods it will make sure the connection is available, start the connection if it's not and give a result if your action was successful. In case of an error it will try to stop the connection so on the next request it will try to start it again. Examples: // Initialize the wrapper. You still need your handle (e.g. this.Handle from Windows.Forms // or from a custom Messaging component in a console app) and optional a handler for messages VariableHandler variables = new VariableHandler(handle, msg => Console.WriteLine(msg)); // As a connection start is implicitly ensured before each action this is enough to perform // an initial start (e.g. if you want to allow for time to gather the data before your first // real request): variables.Try(vs => {}); // Reading all LVars: variables.Try(vs => { vs.RefreshData(); Console.WriteLine(vs.LVars.Count + " LVars:"); foreach (FsLVar lvar in vs.LVars) { Console.WriteLine(lvar.Name + " = " + lvar.Value); } }); // Do a refresh: variables.Try(vs => vs.RefreshData()); // Reading a single LVar: if (variables.Try(vs => vs.LVars["LVAR_NAME"], out FsLVar lvar)) { if (lvar != null) { Console.WriteLine(lvar.Name + " = " + lvar.Value); } } // Force a connection stop (something that should not be necessary usually): variables.Try(vs => vs.Stop()); This is not a higher level abstraction layer, as you still work with the normal MSFSVariableServices object through the "Try"-methods, but you don't have to care about managing the connection or handling an Exception that occurred because you sent a request after the sim has shut down etc. It's not much but I think it could help someone having similar problems. VariableHandler.cs

Could you share how you are using the DLL from C#? Because I still cannot read or log data via the DLL...

You're still having a default assignment for C5 configured (11=PC,5,C65759,0 -{FLAPS_DECR}-). Also do you want to use a button flag? From your description it seems you want a shift-function while button 134 is hold, not toggle a shift with a single press? 11=CP(-C,134)C,5,C65759,0 -{FLAPS_DECR}- 22=CP(+C,134)C,5,C67187,0 -{BATTERY1_SET}-

I tried with the new DLL and still can't read L/Hvars through it. But I tried writing and that works for what I can see. log L/Hvars functions -> No vars found get list/values functions -> nothing get Lvar (name, id) functions -> returns nothing/0 set lvar functions -> works! set hvar function -> works! createLvar -> works! createAircraftLvarFile -> works! So I'm not sure what it could be that writing works, but I can't read through the DLL, and the writes without the reads are not really usable, as you need to somehow get the ID from the name (which for testing I could only do through the WAPI Client). For reference, this is the C# wrapper I'm using around the DLL: FsuipcWapi.cs

Could it be another tool that connects through FSUIPC? I know that for example Landing Rate Monitor has the option to play clapping on good landings.

I don't think I'm qualified to answer that, C# is not my main language. I can use it well enough to write standard applications, but don't know how it would behave in such cases.

Thank you. I tested and can confirm that fsuipcw_createAircraftLvarFile will trigger the creation of the file in the work directory and it contains the Lvars, so at least my setup is not completely wrong. One more thing, would it be possible to provide an alternative the following methods? extern "C" FSUIPC_WAPI_API void fsuipcw_getLvarValues(map<string, double >&returnMap); extern "C" FSUIPC_WAPI_API void fsuipcw_getLvarList(unordered_map<int, string >&returnMap); extern "C" FSUIPC_WAPI_API void fsuipcw_getHvarList(unordered_map<int, string >&returnMap); C# cannot work with C++ std maps. A struct-array should work or a callback function that is called for each key-value pair.

Of course, as I said, the test client is showing the lvars.

Thank you, I had a short look. Do you have any tips on how to call the methods? I call: - I call fsuipcw_init with the event id from the FSUIPC_WASM.ini (0x1FFF0) and a logger callback - Then fsuipcw_start -> logger callback receives " [INFO]: Connected to MSFS", so it looks the general setup is correct - Then fsuipcw_logLvars -> " [INFO]: We have 000 lvars: " So it seems I'm missing something, using the test client I can verify there are lvars present (and I made sure not to run the test client and my code at the same time in case they conflict). Any suggestions on what I'm missing?

I'm looking forward to this, I tried to wrap the module into a dll, but my C++ knowledge is decades old and I couldn't get anywhere.

Are you sure you're using the 7.1.0 beta version? I have the same device and could configure that through the GUI just fine The resulting entries in the ini were: 60=PA,30,C66023,0 -{MAGNETO_OFF}- 61=PA,31,C66024,0 -{MAGNETO_RIGHT}- 62=PA,132,C66025,0 -{MAGNETO_LEFT}- 63=PA,133,C66026,0 -{MAGNETO_BOTH}- 64=PA,134,C66027,0 -{MAGNETO_START}- Do you maybe still have the LUA scripts active for the alpha/bravo buttons? I don't know, but maybe those could interfere?

@airway38 It shouldn't go into the joystick calibration screen, as this will not use the EX1 axes. You could add the offsets you have mapped to the axes to the Offset logging and monitor in the console if they change according to your axes.

I think I also mentioned it in another thread a few days ago, I'm using the beta as well and so far no problems. Was flying every evening this week and everything works, no crashes or bugs and configuration of the >32 buttons is working as expected. 👍

I'm using the 7.1.0a beta and no problems with the rocker switches on both the Alpha and Bravo. I can assign every button and switch via the normal button assignments with that version: 53=PB,135,C66072,0 -{PITOT_HEAT_ON}- 54=PB,136,C66073,0 -{PITOT_HEAT_OFF}- Before I was using my own custom lua scripts for those, but now I could shift everything of the Alpha/Bravo inputs from lua to standard configuration (except some custom logic I have left in lua to detect if I'm dialing the input dial slow or fast).

Have tested both issues and they are fixed for me! Also I can confirm that setting the transponder code via offset now works again. I assume that was already fixed in the original version, but I didn't get to testing it until now. Thank you very much! Jan

Thank you :) Yes, that's from the dev menu. I just added it because I thought that selecting a plane there might cause MSFS to trigger the ready-to-fly state again, but it doesn't seem so.

Same effect after switching aircraft through the aircraft selector while FSUIPC is running. When I don't start a new flight, no axes work. Edit: And the offset logging seems to be a problem when saving from the GUI, when I edit the type in the FSUIPC.ini directly it stays that way, until I do a save in the Log->Offsets dialog, then it reverts back to S8.

I have two problems in version 7.0.7: Some functions are not working when FSUIPC is started when the flight is already loaded. For example axes are no longer processed (I can monitor the axes changes in the assignment window, but in normal usage nothing is sent to the sim). Maybe this has something to do with this from the change notes: update to starting/stopping [Auto] luas: now started when ready-to-fly As I can see the ready-to-fly flag is false/no when starting FSUIPC after the flight has loaded. Though the problem I have is with axes, not with lua. In Log->Offsets... I can no longer change the type. I can select any type, but it reverts back to "S8" when clicking OK. Edit: Just to clarify, I didn't have the problems in the last version (I think I had 7.0.6 before) and the 7.0.8 beta seems to have the same problems.

I'm not sure if I did something wrong, but compound buttons seem to no longer work (existing ones that worked before and new ones), even when they are in the old <32 button range (none of those work): 55=CR(+A,6)A,4,C65615,0 -{ELEV_TRIM_UP}- 56=CR(+A,7)A,5,C65607,0 -{ELEV_TRIM_DN}- 57=CR(+A,11)A,9,C66279,0 -{RUDDER_TRIM_RIGHT}- 58=CR(+A,10)A,8,C66278,0 -{RUDDER_TRIM_LEFT}- 65=CP(+B,20)B,12,C65892,0 -{AP_ALT_VAR_INC}- 66=CP(+B,20)B,13,C65893,0 -{AP_ALT_VAR_DEC}- 67=CP(+B,19)B,12,C65894,0 -{AP_VS_VAR_INC}- 68=CP(+B,19)B,13,C65895,0 -{AP_VS_VAR_DEC}- 69=CP(+B,18)B,12,C65879,0 -{HEADING_BUG_INC}- 70=CP(+B,18)B,13,C65880,0 -{HEADING_BUG_DEC}- 71=CP(+B,17)B,12,C65663,0 -{VOR1_OBI_INC}- 72=CP(+B,17)B,13,C65662,0 -{VOR1_OBI_DEC}- 73=CP(+B,16)B,12,C65896,0 -{AP_SPD_VAR_INC}- 74=CP(+B,16)B,13,C65897,0 -{AP_SPD_VAR_DEC}- Only pressing button A4: 407578 Button changed: bRef=0, Joy=4 (A), Btn=4, Pressed 407578 [Buttons] 55=CR(+A,6)A,4,C65615,0 407578 .... Condition (+A,6) = FALSE 407766 Button changed: bRef=0, Joy=4 (A), Btn=4, Released Pressing A4 while holding A6, same output, I would expect condition true: 412562 Button changed: bRef=0, Joy=4 (A), Btn=4, Pressed 412562 [Buttons] 55=CR(+A,6)A,4,C65615,0 412562 .... Condition (+A,6) = FALSE 412687 Button changed: bRef=0, Joy=4 (A), Btn=4, Released EDIT: For comparison the output from 7.0.7 (same config): 29703 Button changed: bRef=0, Joy=4 (A), Btn=4, Pressed 29703 [Buttons] 55=CR(+A,6)A,4,C65615,0 29703 .... Condition (+A,6) = TRUE 29703 Repeating flag set: bRef=0, Joy=4, Btn=4 (RepeatDelayCtr=1) 29703 FS Control Sent: Ctrl=65615, Param=0 ELEV_TRIM_UP 29781 Button changed: bRef=0, Joy=4 (A), Btn=4, Released

Great to hear. In that case, if you don't want any special handling like I did in my second example for the reverse thrust, you can just do what I showed in the picture of my last post. Use "Send to FS as normal Axes" to "Throttle1 Axis Set Ex1"/"Throttle2 Axis Set Ex1". The result sent to the simulator will be exactly the same. When you don't manipulate the value in the LUA script, doing axes->offset->lua->"Throttle1 Axis Set Ex1" is the same as just axes->"Throttle1 Axis Set Ex1", but the latter has much less overhead.

My solution is under the assumption that you have to reverse the axes (like, the value reported from the axes in the forward position is negative and at idle is positive, but the sim expects it the other way round). Maybe with your hardware this is already working correctly, then you can simply use the control directly from the "Axes Assignment" without the need with the offset->lua workaround: Or alternatively don't reverse in the lua scripts, change (-1) - value -> value in the first lua or (16383 - value) -> (value + 16384) in the lua example with reversers. Also don't forget to calibrate the axes inside the aircraft on the pads options page and make sure you don't have the axes assigned in the MSFS settings.

I adapted my solution a bit to also get the reverser working with the Honeycomb Bravo reverser levers. I map the full axis to only the positive range (0-16383): function throttle_1(offset, value) -- 67103: Throttle1 Axis Set Ex1 ipc.control(67103, math.floor((16383 - value) / 2)) end function throttle_2(offset, value) -- 67110: Throttle2 Axis Set Ex1 ipc.control(67110, math.floor((16383 - value) / 2)) end And then set the reverser levers press and release to set and release the reverse throttle: [Buttons.CRJ] 0=W66C2>16300 PB,10,C67110,-16384 -{THROTTLE2_AXIS_SET_EX1}- 1=W66C2>16300 UB,10,C67110,0 -{THROTTLE2_AXIS_SET_EX1}- 2=W66C0>16300 PB,9,C67103,-16384 -{THROTTLE1_AXIS_SET_EX1}- 3=W66C0>16300 UB,9,C67103,0 -{THROTTLE1_AXIS_SET_EX1}- Works more reliably for me than using throttle decrease for the reversers. The "W66C0>16300" is just there to prevent any reverser action when the throttle is not near the idle position. You have to enable "Reverser Axis" in the CRJ cockpit options for this and calibrate the "rev max" to when you have pulled the reversers switches.

The throttles need a bit of a workaround, as most simple solutions like going through FSUIPC calibration don't work (e.g. using FSUIPC calibration will control the engine throttle somehow, but the throttle lever will not move and the CRJ detent calibration does not work either). From what I tried the only thing that works correctly is the controls "Throttle1 Axis Set Ex1" (67103) and "Throttle2 Axis Set Ex1" (67110) (have not found much documentation on those control numbers, seems they were used for something completely different in FSX/P3D). But when you for example use "Send to FS as normal axis" to "Throttle1 Axis Set Ex1", the axis is still reversed and FSUIPC seems to only support reversing when using FSUIPC calibration. So my solution is to send the axis to a user offset and then map the reverse of that offset to the control with LUA. With that I have working levers and the CRJ detent calibration also works: FSUIPC.ini (CRJ specific parts only): [LuaFiles] LuaPath=lua 1=CRJ [Profile.CRJ] 1=CRJ [Auto.CRJ] 1=Lua CRJ [Axes.CRJ] RangeRepeatRate=10 0=BR,32,F,x020066C0,0,0,0 -{ FSUIPC: offset word set, offset 66C0 }- 1=BV,32,F,x020066C2,0,0,0 -{ FSUIPC: offset word set, offset 66C2 }- CRJ.lua: -- init throttle at idle on startup ipc.writeSW(0x66C0, 16383) ipc.writeSW(0x66C2, 16383) function throttle_1(offset, value) -- 67103: Throttle1 Axis Set Ex1 ipc.control(67103, (-1) - value) end function throttle_2(offset, value) -- 67110: Throttle2 Axis Set Ex1 ipc.control(67110, (-1) - value) end event.offset(0x66C0, "SW", "throttle_1") event.offset(0x66C2, "SW", "throttle_2")

Do you have MSFS running and a flight loaded? If I remember correctly you can only assign new axis when you're in a flight.