Matthew Twomey

Ok, found the issue. This particular plane is starting with AP on and I hadn't realized that. In addition to that, it behaves strangely, visually, as described here: https://forums.flightsimulator.com/t/flight-controls-move-in-reverse-when-on-autopilot-roll-axis/429656 So once I moved to the extents of the controls, it breaks out of AP and things go back to normal. So easy fix (check check AP status once I start).

I have a strange issue and I'm not positive if it's fsuipc related or not. I'm coming back to MSFS, FSUIPC after a long break and have reinstalled everything. I have controls in FSUIPC assigned directly to flight functions (not pass through as normal axis). However, very often when I first start a flight - the controls act "wonky" - ailerons have wild reactions, elevator trim is set to a really high value, ...etc. If I move all the controls to their extremes, things "snap back" to a normal state and everything is fine for the duration of the flight. Anyone have any ideas what might be causing this or how I might fix it?

This would be my guess. I have also been through much experimentation with rotary encoders and Lua and FSUIPC (https://forum.simflight.com/profile/109385-matthew-twomey/content/ is one thread). I don't know about the specific use of Lua in FSUIPC, but generally speaking - it's incredibly fast, so it makes sense to me that you saw similar results in C.

Well, unless / until you're familiar with most of the controls you might not really know what letter a given control starts with. For example, looking for landing gear controls I might type "gear" or "land" or "up" or "down" or "raise", ...etc. For lua scripts - they all start with Lua and there's several sections of them - so typing "buttonScript1" would narrow it down quite a bit. If I wanted to see any controls with "radio" in the name, I could type "radio". In general - just having it match anywhere in the name and filtering the list to matches would be quite useful and _really_ useful for new users especially.

Lots of controls in there - might be a good enhancement to find things quickly or at least narrow them down if we could type in that box and have them "live filtered".

That works, thanks.

Thanks John. I read those those threads and did some more testing tonight. A 1 byte read to 0x0B49 is exactly what I needed!! Thanks - this reads 1 when FLC mode is engaged on the G1k/C208 (just pointing that out for anyone else that comes along). By the way, is there a "live" document somewhere out there of offsets / controls for FSUIPC 7? I realize as the SDK gets refined on the MSFS side, these might be getting updates, changes, additions as we go along.

I've been working with the c208 / g1000 on this project.

Is it currently possible to get Airspeed Hold status from 0x07DC in MSFS? I'm trying to read this to detect the status of FLC autopilot mode, however it just always reads zero when testing?

@John Dowson - yep, works. Thank you!

Ok - thank you sir!

For #2, if it's a valid test - I can confirm that I can certainly play sounds from other Windows applications while MSFS is running and producing sound. For example I can watch Youtube videos with audio, use the media player, ...etc. I Can also play the wav file(s) in question.

1. [[STRING]] is quoted literal format for Lua. It works fine and avoids the need to escape anything, you can read more about it on lua.org. None the less, I've tried it several ways including a regular escaped string. 2. What is the best way to check this? -Matt

I can't seem to get the sound working in FSUIPC7. Here's what I'm doing: ipc.log(sound.device(0)); sound.path([[C:\]]); s = sound.play("click2"); if (sound.query(s)) then ipc.log("Sound played."); else ipc.log("Sound not played."); end Here's the result I'm getting: (and obviously no sound is playing) I have a 1 minute long wav file (named 'click2.wav') right in C:\ (just to make sure there were no path spaces issues). Windows can play the file fine, but I've also tried several different files.

Yep +1 on this, just ran into it myself. Using the map-to-key for now.

Ok - this seems to take care of it: handle, rd, rdf, wr, initreport = com.openhid(0x04D8, 0x8A3D); initreport = com.readreport(handle, 0); for i = 0, 3, 1 do local state = com.testhidbutton(handle, i, initreport); if (state) then ipc.log(i .. ": on"); else ipc.log(i .. ": off"); end end ipc.log("val1: " .. com.gethidbuttons(handle, initreport)); I'm not sure if that com.readreport is the right approach, but it's working. If anyone has a thought on this, please share.

Looking for the easiest way to get the button state from a controller in a lua script that I'm running as "Auto" when FSUIPC starts up. My code is working, but things don't fall into place until I put some input on the controller I'm mapping. As soon as I provide any input - everything starts acting as expected. I tried using the initreport from com.openhid, but I may not be doing this right. Here's what I'm at with this: handle, rd, rdf, wr, initreport = com.openhid(0x04D8, 0x8A3D); for i = 0, 3, 1 do local state = com.testhidbutton(handle, i, initreport); if (state) then ipc.log(i .. ": on"); else ipc.log(i .. ": off"); end end Regardless of the actual button state (actual physical switches in my case), all buttons come back as false, until I trigger any button - at which point they all immediately start reporting correctly. Is there a way to force it to "scan" the controller, or maybe I'm just doing it wrong?

Ok. I'll take a look. I've been flying the c208 with a g1000 and it does it in the sim, but I'll have to defer to other as to if it also does this in real life. I've found a suitable workaround to this issue for now (posted here in case anyone stumbled across this thread and would like to do something similar): currentAlt = ipc.readSD(Offsets.AutoPilotAltitudeValue) / 65536 * 3.28084; ipc.control(66124, currentAlt + amount * 100); Although you can't write negative values, you can send them via the control. So this method will read the value from the offset, modify it, then send a modified value via the control + parameter. (code is inside one of my modules, so ignore the variable references).

Why? Because I want my physical rotary knob to behave like the rotary knob in the simulated cockpit!? I'm trying to simulate that control - and that control in the cockpit spins clockwise and counter-clockwise. When you spin it counter-clockwise past zero, it continues to a negative value. When I spin my physical control, which writes to that offset, it breaks as soon as it would go negative. If I wanted a control that didn't work like the one in the cockpit this wouldn't be a problem - but I'm trying to create a physical control that acts like the control that the simulation is presenting me in the cockpit.

Yes, I'm connecting a rotary encoder to that autopilot altitude select dial. I have custom acceleration setup for it, which makes it feel much more natural than assigning it directly in FSUIPIC - so I'm driving it via a lua script. It works great, until I spin it down below zero, then I run into this problem. Can you clarify why FSUIPC log monitoring reports this value the way that it does? Why does it print out a FLT32 value? 5239984 14272 Monitor IPC:07D4 (S32) = -1997536 5239984 14272 SimRead: 07D4="AUTOPILOT ALTITUDE LOCK VAR" FLT32: -30.4799995422 I don't really have much evidence that it doesn't allow it at this point, honestly it seems more likely to be an issue with FSUIPC. Or maybe a case where some other flag is getting set somewhere when it goes negative and FSUIPC isn't aware of it.

I may have shown you the wrong screenshot, but I've have been debugging this for hours and have tried all manner of monitoring, tracing, and debugging via lua script. It is still probably the case that there is something I am missing - however, I've tried what you've suggested and it appears you can not set a negative value this way. Monitoring the decrement to -100 shows this: 5239984 14272 Monitor IPC:07D4 (S32) = -1997536 5239984 14272 SimRead: 07D4="AUTOPILOT ALTITUDE LOCK VAR" FLT32: -30.4799995422 Writing negative values to this address doesn't work. ipc.writeSD(0x07D4, -6553600); --doesn't work ipc.writeSD(0x07D4, (-100 / 3.28084) * 65536); --doesn't work I may be still be missing something - but it doesn't appear to function as writable at least as described in the documentation. Any other ideas on how this can be done?

Something very strange going on with writing to this offset it seems. I can actually read the offset and immediately write it back and things get messed up. I also tried reading all 4 bytes individually, saving them, then turning around and writing them back - that also seems to cause issues. The only case that seems to act as expected is writing positive values (as either signed or unsigned 32 byte values): ipc.writeSD(0x07D4, 400 * 0.3048 * 65536); That does set the altitude to 400.

So interestingly, 0x07D4 monitors as NAN when I set it to -100 using the aircraft dial: 1843968 Monitor IPC:07D4 (FLT32) = -nan 1843968 SimRead: 07D4="AUTOPILOT ALTITUDE LOCK VAR" FLT32: -30.4799995422 The SimRead does seem to reflect the correct value, however. If I try to set 0x07D4 to -30.4799995422 using ipc.writeFLT(0x07D4, -30.4799995422) - that sets the alt to the max value 99500.

I'm trying to set the autopilot altitude selector via lua by using ipc.writeUD(0x07D4, value). I can't seem to set it to a negative value, like I can with the knob in the cockpit. I've tried several approaches, writing to it as a signed number, generating the 2's compliment, ...etc. I must be missing something simple here? Thanks, -Matt

Just as an aside, I was also looking into this and I ran across this older thread and saved it, it's interesting reading: