Jason Fayre

Hi Paul, I'm wondering if we might be able to get a function for parsing simconnect menus with the dll? One of the functions of my software is to read simconnect messages and menus via text to speech. For example, something like the menus that GSX displays. Multi-line messages are split by null characters, and the length of the message is stored in another offset. These offset start at 0xb000. Just wondering if we might get a convenience function to parse the messages into an array of strings. If not, have you found an easy way of dealing with these?

Hi Pete, All I can say is that the same code I use to read simconnect message offsets that works in p3d under fsuipc 5/6 doesn't work for my users in version 4. I don't have the specific reference to the bug in fsuipc 5, but I remember it existed. I'll look around. Is it possible that the offsets only work via widefs, and not locally in version 4? I have a widefs key, so I can try using that with my software and see if it works.

Hi, One of the features of my Talking Flight Monitor software is the ability to read SimConnect menus with text-to-speech. This works great in p3d with fsuipc 6. However, it doesn't work with FSX and fsuipc version 4. If I enable the NewInterceptTextMenu option in the ini, the simconnect menu offsets still don't appear to work. I know this was a bug early in fsuipc 5 that got fixed. Any chance we could get this working in version 4? I still have some users that want to use fSX and this simconnect feature is really helpful. Thanks!

Hi Paul, I've run into an issue. The ValueChanged property doesn't appear to work on string type offsets. For example, offset 0x3d00 for the aircraft name. When I attempt to test if that offset has changed, it appears to read true all the time. I'm defining that offset as: private Offset<string> AircraftName = new Offset<string>(0x3d00, 255); I'm checking if it has changed like this: if (AircraftName.ValueChanged) { Tolk.Output("Current aircraft: " + AircraftName.Value); } At this point, my software just reads the aircraft name constantly. I can get around this by storing the old name in a variable, but just wanted to point this out in case there is a bug somewhere. I'll need this in several places, since one of the things my software does is read Simconnect text messages out of the fsuipc offsets. Thanks!

I think I got it! Looks like I need to specify the type of the offset on my method definition. private void ReadToggle(Offset<uint> instrument, string name, string OnMsg, string OffMsg) This would assume that the instruments I need to read are all uint. I think a lot of them are, but some may be Byte. Is there any way of making this function work with multiple offset types?

Hi, I apologize for the newbie question. How can I pass an offset to another method? In my mainTimer_tick method, I need to check a bunch of offset that are toggles. Rather than write the code for every offset, I want to put the code in a method. The method checks to see if the offset has changed, then sends a message through text to speech via the Tolk library. There's something simple I'm not understanding about how to pass the offset instance to my method. Right now, I get this error when building my project: Error CS1061 'Offset' does not contain a definition for 'Value' and no accessible extension method 'Value' accepting a first argument of type 'Offset' could be found (are you missing a using directive or an assembly reference?) tfm C:\Users\jfayr\source\repos\tfm\MainWindow.xaml.cs 144 Active In my tick method, I have the following method call: ReadToggle(AvionicsMaster, "avionics master", "active", "off"); And here's the ReadToggle method: private void ReadToggle(Offset instrument, string name, string OnMsg, string OffMsg) { if (instrument.ValueChanged == true) { if (instrument.Value == 0) { Tolk.Output($"{name} {OffMsg}"); } else { Tolk.Output($"{name} {OnMsg}"); } } }

Awesome! This appears to be working. Thanks!

That would actually be really useful! A lot of the instruments I'm reading are toggles, so this would be really helpful. One more question. For reading things like flaps and landing gear, I wwant to detect when they start changing, then read the value once they finish moving. So, for example, when you press F7 to extend flaps, I only want to read the value once they stop, so you don't hear updates as they are moving. I know how to do this by checking the offset, then sleeping a bit, then checking again. Once the old and new values are the same, read the value. The problem with this is that I believe this would block anything else from speaking until the flaps stop. Can you think of another way of doing this?

Hi, I'm just learning c#, so I apologize for the newbie question. I've looked at the WPF template, and basically got my head around how this works. My application is an accessibility layer so that blind flight sim users can get speech feedback for various instruments and aircraft states. In addition to reading many offsets (over 100), I need to keep track of the previous state of the offset. So, for example, I need to keep track of the previous Autopilot altitude, heading, speed, etc. offsets so I can let the user know when they change. Does anyone have any code snippet or technique for doing this? I know I can just store the previous value in another variable, but wondering if there is a more efficient way of doing this. I know this is more of a c# question than a fsuipc question, but just wondering if someone can throw me any suggestions.

Hi Paul, Thanks for that. As I was reading up on UWP, I thought that might be the case. ok. WPF it is then. I really don't want to deal with SimConnect. I'm just learning c# and SimConnect makes my head explode.

Hi John! I will give this a shot. I have since modified my lua scripts to use the key offsets at 0x3210, but this would simplify my code a lot. Thanks so much for adding this!

Hello, I've decided to port an application that I've written in Python with the pyuipc library over to .net. I'm trying to decide which UI framework to use. I think I would like to use UWP if possible. Do you have any templates for using the fsuipc .net library with uwp? Thanks!

Hi John, Using the auto sections is how I was doing things originally. However, since this software is distributed to others, I was trying to avoid having them modify their ini files. the ipcReady method seemed like a cleaner way to do this. Will monitoring for the aircraft name offset in ipcReady work?

Hi, I'm just getting around to looking at this now. I thought that ipcReady.lua ran any time the aircraft changes. This doesn't seem to be the case. It runs when I load an aircraft after starting the sim, but changing the aircraft doesn't cause it to re-run. Is this the expected behavior? If so, I'm guessing I need to set up an event in ipcReady.lua to monitor the aircraft name offset? Right now, I just have a series of if statements to check for the various aircraft.

Hi, I've been digging through the FSUIPC manuals, but can't find any specific reference to the ipcReady.lua script. I've got various lua scripts for the A2A c172, c182, Bonanza and Cherokee. I want to have those scripts launch automatically whenever those specific aircraft are loaded. I know I can use the Auto facilities in the ini file to do this, but I want to avoid my users neding to modify there ini files. So, my plan is to do a check in the ipcReady.lua file for the aircraft name and do an ipc.run for the specific scripts when the aircraft is detected. My question is, do scripts that are run with the ipc.run facility terminate when the aircraft changes? For example, if someone has the Bonanza loaded with my script, then they change to the C182, will the Bonanza script terminate and the c182 script run via the ipcReady script? My scripts are all event driven, so they will keep running and waiting for events. If these won't auto terminate when the aircraft changes, what's the best way to do this? Can I add something to my ipcReady script that will kill any already running scripts? Thanks!

Thanks Pete! Your absolutely right, I was counting the bits wrong. It's working now. One more question. Do these offsets get cleared when the aircraft changes? I have a different set of keys depending on the particular aircraft the user has running.

I'm trying to figure out how to write a dword into offset 3210 for a test key using a lua script. If I wanted tab+b, would I write it into the offset as ipc.writeUD(0x3210, 0x00000842) 08 being the hex representation of the bit 4 set in byte 1 and 42 being the hex representation of key code 66 in byte 0. If so, it isn't working. I've got an event set to fire when offset 0x3213 changes to indicate the key has been pressed, but it isn't triggering. I could have this all backwards. I'm not at all familiar with manipulating things like this.

Hi Pete, I guess what I'm looking for is a way to scan for available hotkey slots in the 3210 block in a lua script. Then I need to figure out how best to detect them using events. I think I know how to do the event part using event.offset on one of the bytes, but maybe there's a better way. Sorry for the newbie questions. Lua isn't my strong point yet.

Hi Pete, Sorry for the confusion. The general key assignments tab is the one I was talking about. Ok. I'll re-think my hotkey strategy. I'm adding keys for several events that don't normally have keys, so I was trying to come up with a scheme that wouldn't require my users to remap keys in the sim. I'll probably just switch back to using keys defined in FSUIPC. It just means people will need to add a block of info to there ini file when I install my software. Could it also be an option to use the offsets at 3210 to define keys? In reading the documentation, I'm not totally clear on how to use those. Do you have an example of how to check for a hotkey from a lua script? I assume those keys are trapped? Thanks for all your help!

Hi Pete, Yes, if I assign Tab+g in the FSUIPC hotkeys dialog, the key works and doesn't get passed on to the sim. If I assign the same key via a LUA key event, the event triggers, but also activate the landing gear. I'll try just assigning G in the FSUIPC hotkeys dialog, but I'm fairly sure I'll see the same thing where FSUIPC traps the key as expected. Assigning g as a hotkey via lua passes the key through as well as triggering my event. Thanks!

Hi Pete, Thanks for looking at this. I'm trying to use the lua events to assign keys in my software so I don't need to ask users to make a bunch of modifications to their fsuipc ini files, adding macros, etc. Here is what I found: 1. Adding g without any shift as a lua key event does trigger the landing gear. 2. Adding Tab+g as a FSUIPC hotkey triggers the fsuipc key action, but the gear doesn't activate. So, the way lua and regular FSUIPC hotkeys are behaving is definitely different. If this isn't going to work through LUA for assigning keys, do you have any suggestions on the best way to make my hotkeys, lua scripts, and macros portable? If I go that route, people will need to manually add all the correct profile entrys to their fsuipc ini files. I was trying to avoid that. Thanks!

Hello, I'm trying to define some key events in a lua script. The keys are working, but the keypresses are also being passed on to the sim. This is fsuipc 6.0.8 and p3d v4.5. My event line looks like: event.key(71, 24, "heat_dec") This fires when I press Tab+g, but the landing gear control in the sim also triggers. I thought fSUIPC was supposed to trap these keys? Am I doing something wrong? Thanks!

Hi, The Lua script is just monitoring l:vars for changes using the event.LVar system. The writes to 0d70 are coming from my Talking Flight Monitor application. The flow goes like this: * user presses a hotkey in my software to trigger the switch (in this case, the cabin fan switch) * my software writes to 0d70 to trigger the macro to toggle the switch * the lua script detects the change in the cabin fan l:var and writes the result back to 66c6. The lua script isn't actually flipping the switch, the macro does that. I know I should be able to do this all in my software, but I've had strange results with l:vars periodically reading 0 when I read them from my software. This is ok for values I can anticipate, since I can just read the result again. It doesn't work so well for toggles though when the result is just 0 or 1. I still don't understand why I'm getting better results when defining the key directly in fsuipc to fire the macro. I'll take a look at the virtual button offsets and see what I can do.

Hi. I logged offset writes and this looks interesting. Every time the call goes through correctly, the switch gets toggled and my lua script writes the state of the l:var back to 0x66c6. When it fails, the offset write to 0d70 succeeds, but the switch never moves. Here's my log. You can see several examples of the attempt. Every time it succeeds, you will see a write to 66c6 right after the 0d70 write. ********* FSUIPC6, Version 6.0.8 (7th May 2020) by Pete & John Dowson ********* Prepar3D.exe version = 4.5.13.32097 Running inside Prepar3D v4 Module base=7FFE32860000 Windows 10 Pro 64 Bit reported as Build 19631, Release ID: 2004 (OS 10.0) Reading options from "C:\Program Files\Lockheed Martin\Prepar3D v4\Modules\FSUIPC6.ini" Checking the Registrations now ... User Name="Jason Fayre" FSUIPC6 Key is provided WIDEFS7 not user registered, or expired 219 System time = 25/05/2020 08:22:21 219 FLT path = "C:\Users\jfayr\Documents\Prepar3D v4 Files\" 234 Using DialogMode 453 FS path = "C:\Program Files\Lockheed Martin\Prepar3D v4\" 906 ---------------------- Joystick Device Scan ----------------------- 906 ------------------------------------------------------------------- 1453 ### Checking Prepar3D.cfg 1453 Controllers are set to ON, using RawInput within P3D 1453 ------------------------------------------------------------------- 1469 LogOptions=80000000 00000005 1469 ------------------------------------------------------------------- 1484 SimConnect_Open succeeded: waiting to check version okay 1484 Opened separate AI Traffic client okay 19859 Running in "Lockheed Martin® Prepar3D® v4", Version: 4.5.13.32097 (SimConnect: 4.5.0.0) 19859 Initialising SimConnect data requests now 19859 FSUIPC Menu entry added 19875 ... Using Prepar3D with Academic License 19969 C:\Users\jfayr\Documents\Prepar3D v4 Files\bonanza.fxml 19969 C:\Users\jfayr\Documents\Prepar3D v4 Add-ons\A2A\SimObjects\Airplanes\A2A_Beechcraft_35_Bonanza\bonanza.air 61375 ### The user object is 'A2A Beechcraft V35B Bonanza N228Q' 61391 ### Mode is NORMAL 62297 ### Mode: PAUSE on 89016 Loading Complete ... 89063 ### Mode is NORMAL 91359 Aircraft loaded: running normally now ... 91453 User Aircraft ID 1 supplied, now being used 91844 System time = 25/05/2020 08:23:52, Simulator time = 07:56:12 (11:56Z) 91953 Aircraft="A2A Beechcraft V35B Bonanza N228Q" 98078 -------------------- Starting everything now ---------------------- 98188 WRITElua 66C0, 1 bytes: 00 . 98203 WRITElua 66C1, 1 bytes: 00 . 98219 WRITElua 66C2, 1 bytes: 00 . 98219 WRITElua 66C3, 1 bytes: 00 . 98234 WRITElua 66C4, 1 bytes: 01 . 98234 WRITElua 66C5, 1 bytes: 00 . 98250 WRITElua 66C6, 1 bytes: 00 . 98250 WRITElua 66C7, 1 bytes: 00 . 98359 WRITElua 66C8, 1 bytes: 00 . 99531 Advanced Weather Interface Enabled 181484 WRITE0[18856] 330A, 2 bytes: D2 07 .. 227609 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 227625 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 227625 00 00 00 00 00 00 00 00 ........ 227734 WRITElua 66C6, 1 bytes: 01 . 279297 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 279297 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 279313 00 00 00 00 00 00 00 00 ........ 355844 WRITE repeated 2 times 355844 WRITElua 66C6, 1 bytes: 00 . 397828 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 397828 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 397828 00 00 00 00 00 00 00 00 ........ 398734 WRITElua 66C6, 1 bytes: 01 . 406734 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 406734 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 406734 00 00 00 00 00 00 00 00 ........ 406906 WRITElua 66C6, 1 bytes: 00 . 411750 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 411750 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 411750 00 00 00 00 00 00 00 00 ........ 412078 WRITElua 66C6, 1 bytes: 01 . 413641 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 413641 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 413656 00 00 00 00 00 00 00 00 ........ 414078 WRITElua 66C6, 1 bytes: 00 . 415469 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 415469 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 415484 00 00 00 00 00 00 00 00 ........ 416109 WRITElua 66C6, 1 bytes: 01 . 417563 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 417563 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 417578 00 00 00 00 00 00 00 00 ........ 418219 WRITElua 66C6, 1 bytes: 00 . 419625 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 419625 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 419625 00 00 00 00 00 00 00 00 ........ 420156 WRITElua 66C6, 1 bytes: 01 . 421609 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 421609 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 421625 00 00 00 00 00 00 00 00 ........ 449734 WRITE repeated 2 times 449734 WRITElua 66C6, 1 bytes: 00 . 451375 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 451391 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 451391 00 00 00 00 00 00 00 00 ........ 505875 WRITE repeated 4 times 505875 WRITElua 66C6, 1 bytes: 01 . 507203 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 507203 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 507219 00 00 00 00 00 00 00 00 ........ 507844 WRITElua 66C6, 1 bytes: 00 . 511984 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 511984 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 511984 00 00 00 00 00 00 00 00 ........ 513000 WRITElua 66C6, 1 bytes: 01 . 514828 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 514828 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 514828 00 00 00 00 00 00 00 00 ........ 515000 WRITElua 66C6, 1 bytes: 00 . 516906 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 516906 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 516906 00 00 00 00 00 00 00 00 ........ 517094 WRITElua 66C6, 1 bytes: 01 . 518953 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 518969 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 518969 00 00 00 00 00 00 00 00 ........ 519063 WRITElua 66C6, 1 bytes: 00 . 522875 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 522875 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 522875 00 00 00 00 00 00 00 00 ........ 523203 WRITElua 66C6, 1 bytes: 01 . 525031 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 525031 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 525031 00 00 00 00 00 00 00 00 ........ 525234 WRITElua 66C6, 1 bytes: 00 . 527281 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 527281 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 527281 00 00 00 00 00 00 00 00 ........ 528250 WRITElua 66C6, 1 bytes: 01 . 530656 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 530656 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 530672 00 00 00 00 00 00 00 00 ........ 531313 WRITElua 66C6, 1 bytes: 00 . 532656 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 532656 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 532656 00 00 00 00 00 00 00 00 ........ 535391 WRITE repeated 2 times 535391 WRITElua 66C6, 1 bytes: 01 . 536828 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 536828 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 536844 00 00 00 00 00 00 00 00 ........ 537438 WRITElua 66C6, 1 bytes: 00 . 538766 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 538766 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 538766 00 00 00 00 00 00 00 00 ........ 539469 WRITElua 66C6, 1 bytes: 01 . 540969 WRITE0[18856] 0D70, 40 bytes: 62 6F 6E 61 6E 7A 61 3A 4C 3A 56 65 6E 74 43 61 bonanza:L:VentCa 540969 62 69 6E 46 61 6E 53 77 69 74 63 68 00 00 00 00 binFanSwitch.... 540984 00 00 00 00 00 00 00 00 ........ 558594 Sim stopped: average frame rate for last 467 secs = 19.3 fps

Hi Pete, How do I enable the specific logging for this? Also, it doesn't seem to matter regarding time interval between invocations when using 0d70. I have tried sending commands more than a second apart and it is still dropping commands. If I define a key in fsuipc to trigger the macro, I can hit the key quite rapidly while in the sim and the switch toggles every time. Thanks!