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.