jaxx

Is there even a standard location for flight saves? When saving/loading I get a standard file selection dialog and I can save to/load from anywhere.

Yes, there's something really wrong with the SimConnect connection (e.g. vPilot has the same issues). More than the reduced FPS it's basically unusable due to stutter, as you can see in the attached screenshot (please ignore the fact that I'm lying upside down in the streets of New York 😁). You can see on the graphs on the left side the moment FSUIPC connected. Average FPS drop from 40 to 20, but it's much worse than stable 20 FPS. On the right side the "Manipulators" graph was a steady, green block before the connection. Other than that FSUIPC is working really well for what I tested so far. The one special hardware I have that uses FSUIPC for its displays and buttons seems to work just like in P3D. I really hope Asobo fixes the SimConnect issue fast.

I'm not sure what you mean by this, as far as I know Windows only allows one window/application from having the active focus?

Hi, what's the best practice to spoof reads of an offset variable? Some fixed gear planes report always "gear down" and I don't want the gear down indicator on my panel lit when using those planes, so at the moment I have the following in the profiles' lua of the affected planes: function spoof_gear(t) ipc.writeStruct(0x0024, "1UW", 0x0BEC, "1UW", 2, "1UW", 0) ipc.writeStruct(0x0024, "1UW", 0x0BF0, "1UW", 2, "1UW", 0) ipc.writeStruct(0x0024, "1UW", 0x0BF4, "1UW", 2, "1UW", 0) end function cleanup() ipc.writeStruct(0x0024, "1UW", 0x0BEC, "1UW", 0) ipc.writeStruct(0x0024, "1UW", 0x0BF0, "1UW", 0) ipc.writeStruct(0x0024, "1UW", 0x0BF4, "1UW", 0) end event.timer(1000, "spoof_gear") event.terminate("cleanup") I found offset 0x0024 and its usage in the offset list and I'm not sure if using a timer there is the best way, but the spoofed values always reset after a few seconds. I know there is event.offset that fires when an offset changes, is there also an event that fires on an offset read where you could spoof the read result? In the documentation I didn't see something like that... jaxx

No, it is still using SerialFP, but something has changed since I first used it years ago. I remember it needed some manual tinkering with the COM port configurations and it was not easy to set everything up (I can't really remember what I had to do exactly to get it running). But soon after that when I used a newer software version it worked out of the box without needing any manual configuration. I also don't have to do this VRi-device configuration from the FSUIPC advanced users guide, it just works. That's why I thought those were for that old manual configuration (of course I can't speak for other device models).

Maybe I should clarify what the device does. It is an VRinsight M-Panel. From what I can see from the FSUIPC logs it writes offsets (the values from the "FSUIPC5 Offsets Status.pdf" documentation) to FSUIPC when I press a button, dial in a number etc. But they (the natively supported offsets) are hardcoded and I cannot change them. In the configuration utility I can choose either a standard keybind (like ALT+X) or a "FSUIPC Control": All custom IDs/Values set in that way will be written to FSUIPC using the "3110" offset ("Operates a facility to send any ‘controls’ to Flight simulator."). The GUI also prevents entering any ID below 65535 and the configuration file generated by the GUI is a binary file, so not easy to edit without the GUI. Sidenote: Even in the default/hardcoded state it does not use dedicated FSUIPC offsets for every action, some are just send via offset "3110", just like the custom changed ones. PS: I've also seen the VRinsight specific documentations for lua but I don't know if they are applicable (at least for the M-Panel) as they seem to be based on the deprecated method of directly configuring VRi devices with COM ports etc. in FSUIPC. The drivers (at least for the M-Panel) work out of the box with FSUIPC for many years now. Jaxx

Thanks for your answer, but I'm not sure how to do this with the restrictions of the configuration drivers of the hardware (from VRinsight) I use. For 1: How would I link it to the buttons of the device, it will only let me set a 5-digit decimal greater than 65535 plus a single value that is send as FS Control to FSUIPC. (Only other options would be normal keyboard shortcuts and there I see a greater risk of some key-bind conflicts with the flightsim or anything else). For 2: Basically the same problem as with 1, as far as I understand the offsets are not the same as FS controls, and even if they were the range you provided would be less than 65535 in decimal and the VRInsight software would not accept that value. EDIT: Do you mean intercepting the default Offset codes the device sends to FSUIPC when there is no custom config? The software sends the control codes through offset 3110 (not only the custom ones I made, it also uses it this by default for some actions and for some actions it uses "native" offsets. When I now listen to those offsets manually, like with event.offset, will it suppress the default action for this?

Hello, is it a problem when I use undocumented FS Control IDs as trigger events for Lua scripts? I have hardware that I can configure to send any 5 digit decimal >65535 on button presses, dials etc. But some planes I have only really work well when using L:Vars (e.g. the A2A Comanche with its 3-position gear switch does not really work with the FS control gear up/down events from the 2-postion switch on my hardware. When I use the standard FS Controls those don't seem to get suppressed when processing in lua. Is it ok to use undocumented FS control codes for this (e.g. 78001), or are those used for internal stuff and will cause problems? Like doing this: function gear_up(controlnum, param) ipc.writeLvar("L:LandingGearLeverPos", 0) end function gear_down(controlnum, param) ipc.writeLvar("L:LandingGearLeverPos", 2) end event.control(78001, "gear_up") event.control(78002, "gear_down") Is that ok? I mean it seems to work fine, but I don't know if there are any side effects. Thanks Jaxx

I think I have the problem described in this thread as well wit my VRInsight M-Panel, or at least a very similar one. The autopilot buttons (only the on/off buttons) stop working after a while (not really reproducible for me), everything else continues to work just fine. I get the same "DATA_ERROR" messages in the log. After reading this thread I've noticed in the log that by default it sends the controls with 4 byte writes, whereas if I manually map e.g. <FSUIPC_CTL:66103/0> & <FSUIPC_CTL:66104/0> for AP ALT ON & OFF in the VRI Keymapper to the buttons it sends 8 byte writes: Error: 1373344 WRITE repeated 1 times 1373344 WRITE0[848] 07D0, 4 bytes: 01 00 00 00 .... 1373344 Exception 20 "DATA_ERROR", Ref 4079, Index param 1 on write SetData for "AUTOPILOT ALTITUDE LOCK" 1373844 Exception 20 "DATA_ERROR", Ref 4081, Index param 1 on write SetData for "AUTOPILOT ALTITUDE LOCK" Default write: 767000 WRITE0[3332] 07D0, 4 bytes: 01 00 00 00 .... 767000 *** EVENT: Cntrl= 66103 (0x00010237), Param= 0 (0x00000000) AP_PANEL_ALTITUDE_ON 767516 WRITE0[3332] 07D0, 4 bytes: 00 00 00 00 .... 767516 *** EVENT: Cntrl= 66104 (0x00010238), Param= 0 (0x00000000) AP_PANEL_ALTITUDE_OFF Manually mapped write: 948203 WRITE0[4480] 3110, 8 bytes: 37 02 01 00 00 00 00 00 7....... 948203 *** EVENT: Cntrl= 66103 (0x00010237), Param= 0 (0x00000000) AP_PANEL_ALTITUDE_ON 951750 WRITE0[4480] 3110, 8 bytes: 38 02 01 00 00 00 00 00 8....... 951750 *** EVENT: Cntrl= 66104 (0x00010238), Param= 0 (0x00000000) AP_PANEL_ALTITUDE_OFF If I understand this thread correctly the problem should be solved if I don't use the default but map every button manually so they are using 8 byte writes? Or is the new version you are working on supposed to fix this exact issue?

24€ before tax. Which, depending on your country, including ~20% tax is around 29€.