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