Fragtality

Yeah it was only the Test-Case that FSUIPC7 keeps running and the Plugin is restarted - you didn't mention wich one you prefer^^ I surely added something to the FSUIPC7.ini to enable it (see my previous Post), but I'm not sure if that enabled it xD Here the Logs when FSUIPC7 crashes! Steps: - Loaded MSFS via the FSUIPC Shortcut (Plugin is running) - Loaded a Flight - Stopped FSUIPC7 - Started FSUIPC7 => Crashed FSUIPC_WASM.log FSUIPC7.log PilotsDeck.log

Same Behavior with 7.3.5/0.5.9 😕 I've started MSFS/FSUIPC without the Plugin running and started it after the Flight was loaded. I hope the FSUIPC and WASM Logs are as expected? I've changed LogLevel to Debug in the FSUIPC_WASM.ini and added that to the FSUIPC7.ini: [WAPI] EnableWAPI=Yes LogLevel=Debug FSUIPC7.log PilotsDeck.log FSUIPC_WASM.log

Hi! I'm currently integrating the WASM Module in my StreamDeck Plugin/PilotsDeck via Paul's C# Client and it works great so far. But only if FSUIPC7 or my Plugin are not restarted when a Plane/Flight is loaded (no Problem in the Main Menu). When I restart my Plugin it will crash with a "Access Violation". When I exit FSUIPC the Plugin will load but FSUIPC7 will crash when I try to start it again. From what I can tell it happens when the WASM Module tries to load/setup the Lvars, because the last line I receive in my Plugin is "EVENT_LVARS_RECEIVED" (FSUIPC running, StreamDeck/Plugin restarted). The other way around (StreamDeck/Plugin running and FSUIPC restarted) the last line in the FSUIPC7.log is "Connected to MFSFS".

You're welcome, thank YOU for your Feedback 🙂

*bump* Some Moons and Versions have passed, we are now at 0.6.5: https://github.com/Fragtality/PilotsDeck/releases/tag/v0.6.5

Sorry but this Answer is confusing. So the Virtual Buttons are only really usable (e.g. assignable in the FSUIPC UI) with a registered Version. But basically with a free Version it is still possible to write to this Offset(s). How they are intended to be used is really simple: My StreamDeck Plugin writes to this Offset(s) to trigger the Buttons, so a User can have their Mappings/Bindings within FSUIPC (instead of directly assigning a Control/Lua/Macro via StreamDeck), if he/she prefers that.

Thanks

I would need to know if the "Virtual Buttons" (Offsets 29F0/3340) are usable with a free Version? Does that count as "access to Offsets" (=free) or "Joystick control facilities" (=registered)? So Offsets & Controls are "free", Lua is only available when registered. Correct? Therefor I'd assume Macros and Lvars are also only available with a registered Version (since using the same Offset), right?

Sorry for the late Answer, didn't get a Notification. I've send you the inis via PM. As reported, the problem somehow went away with a fresh OS/P3D Install and new/fresh Install of the newest FSUIPC Version (.13). Regarding your Answer on the three Configuration Parameters (LuaTrapKeyEvent, SetForegroundOnKeySend, KeyboardFocus): These are not existent within the new ini File (currently in use in the new/fresh Installation). But the strange thing is, I only added/altered these Parameters in the attempt to troubleshoot the old Installation (and therefore old ini-File)

Introduction PilotsDeck is a Plugin for Elegato's StreamDeck with the Ability to trigger Cockpit-Controls in different Ways and especially reading & displaying a Control's State on the StreamDeck as Text, Image or even Bar/Arc. It is lean & mean, flexible, completely Open-Source and Free-to-Use. It does not do any fancy Stuff like a PFD - it does exactly what is needed to support smooth Flight Operations 😎 StreamDeck-wise it behaves like any other StreamDeck Plugin: it runs alongside other Plugins and you can Drag, Drop, Copy, Paste the Actions like any other Action in the StreamDeck Software between your Folders, Pages or even different StreamDecks. The Action Configuration is done through the standard "Property Inspector" of the StreamDeck UI and it is saved in the StreamDeck Profile. You can create, export and share Profiles with the Plugin's Actions to share their Configuration. It can also switch StreamDeck Profiles based on the current Aircraft loaded (which is a bit tricky since not intended by the StreamDeck Software). The Plugin supports different StreamDeck Models: Mini, Standard/15-Key, XL, Mobile and Plus. Other Models might work, but an indented Support for Non-Display Models is not planned. The Plugin runs only on Windows. There no Plans for Linux or macOS Support (the first is not supported by StreamDeck at all, both do not run or support all Sims and some essential .NET Libraries are only available on Windows). Simulator-wise it supports all major Platforms on Windows - MS Flight Simulator, X-Plane and Prepar3D. For MS Platforms it connects through FSUIPC to the Simulator, for X-Plane it connects directly via UDP Sockets. Either way it will connect automatically as soon as a Simulator is running. All Variables and Commands these Connections allow are usable with the Plugin. You can can directly connect to another Sim without reconfiguring anything. Not all Variables and Commands require a registered Version of FSUIPC, but a registered (bought) Copy of FSUIPC is recommended to use the full Potential. If you only fly in X-Plane, FSUIPC is not needed at all. It is designed for advanced Sim-Users which "know how to do Stuff": it does not make any unnecessary complicated Stuff, but doesn't have Features allowing to do anything without knowing anything 😅 If you know how to read Control-States for your Plane and how to trigger these Controls, you can quickly define an Action for that on the StreamDeck. If you don't: be eager to read & learn. 😉 I'll try to give some Background in the Readme, but you have to take it from there! Predefined Profiles/Integrations are available for FSLabs A320X, Fenix A320, ToLiss A321, FlyByWire A32NX and QualityWings 787 - which are maintained by myself. But there are also User-Contributions for MadDog MD-82, PMDG 747-8 (P3D) and PMDG 737-700 (MSFS). All Profiles are for private/own Usage only - don't reupload or share them elsewhere. Note: PilotsDeck is 100% free and Open-Source. The Software and the Developer do not have any Affiliation to Flight Panels. Buying from Flight Panels does not support my Work in any Way. Creating own Profiles is something anyone (knowing how a Plane can be interfaced) can do! Supported Simulator Versions X-Plane 12 / 11 / <=10 Requirement: None - does not use XUIPC Flight Simulator 2020 / X / 2004 Requirement: FSUIPC 7 & MobiFlight WASM / FSUIPC 4 / FSUIPC 3 Prepar3D v5 / v4 / v1-3 Requirement: FSUIPC 6 / 5 / 4 Supported is understood as "technical and basically supported by the Connection Method". Support in Terms of ensured Compatibility, Fixing Issues and giving Support exists only for the latest Version of the three Major Simulators: X-Plane 12, MSFS2020, P3D v5. I'm happy if it works for older Versions, but I won't make any Effort for them. It is time to go back to the Future! 😅 And yes: the latest Version for Prepar3D is still considered v5, since v6 was just DOA with nearly every Addon-Dev announcing to not support it. Supported Sim-Commands & -Variables Here a quick Overview of what you can send to the Simulator ("Command") or from what you can read Values from the Simulator ("Variable"). One of the Things which make the Plugin flexible: Variables can also be used as Commands. For Example to move a Cockpit-Control by writing a different Value to a Variable. How Commands and Variables are configured and the different Options how they can be executed is described under 2.1 - Defining Commands & Variables. MACRO | Command | MSFS*, P3D, FSX Execute any Macro known to FSUIPC SCRIPT | Command | MSFS, P3D, FSX Run any Lua-Code known to FSUIPC CONTROL | Command | MSFS, P3D, FSX, FS9 Send any SimEvent defined by its numerical ID (also known as FS-Controls, Control-Codes. Numerical Variant of a K-Variable/K-Event) LVAR | Command & Variable | MSFS, P3D, FSX Read from / Write to any L-Var ("Local Variable") OFFSET | Command & Variable | MSFS, P3D, FSX, FS9 Read from / Write to any FSUIPC Offset VJOY | Command | MSFS, P3D, FSX Toggle/Clear/Set a Button of a virtual Joystick from *FSUIPC* VJOYDRV | Command | ALL Toggle/Clear/Set a Button of a virtual Joystick from the known *vJoy Device Driver* (if installed, not required) HVAR | Command | MSFS Activate any H-Variable in the Simulator CALCULATOR | Command | MSFS Run any Calculator/Gauge Code in the Simulator - either direct RPN Code or as Template for Increasing/Decreasing L-Vars or triggering K-Vars XPCMD | Command | XP Send any Command known to X-Plane (as command_once) XPWREF | Command & Variable | XP Read from / Write to any X-Plane DataRef AVAR | Command & Variable | MSFS Read from / Write to any Simulation Variable (also known as A-Var) * = MSFS does not support Mouse-Macros !! Please mind that the Command Types Script, Macro, Lvar and vJoy can only work with a registered Version of FSUIPC! !! Both vJoy Command Types are independent of each other and are two different Things! "VJOY" can only be assigned within FSUIPC (and not in the Simulator). The "VJOYDRV" can be assigned by anything which understands a Joystick Button (Simulator, FSUIPC, Addons, ...). Available StreamDeck Actions All Actions work on the Keypads (the normal/square StreamDeck Buttons). The Dial/Touchpad (aka Encoder) on the SD+ is only supported by some Actions (the ones which make the most Sense). On Keypads you can assign two different Commands, based on how long you hold it: A Short/Normal and Long Press (>= 600ms). Only one of the available Actions can be put in StreamDeck Multi-Actions. On Encoders you can assign five different Commands for each Interaction: Left Turn, Right Turn, Touch Tap and a Short & Long Press on the Dial. The Actions can be put in StreamDeck Encoder-Stacks, but will then lose their Short/Long Press Function. How these Actions can be configured and customized is described under 2.3 - Action specific Options. Display Value (Keypad) Display a Sim Variable as Number or Text (display "ON" instead of "1"). You can scale/round/format the Value as needed and customize the Font-Settings. Only for Display. Display Value with Switch (Keypad / Encoder) Like before, but this Action also send Commands. Dynamic Button (Keypad) This Action dynamically changes the displayed Image based on a Variable (in Addition to sending Commands). Different Values trigger different Images. Korry Button (Keypad) Intended for Korry-Switches in the Cockpit: the Action displays two "Sub-Images" independently of each other. They are shown/hidden based on their own Variable, but will not change the Image based on the Value. Can be adapted to other Use-Cases. COM Radio (Keypad / Encoder) Intended for Com Frequencies: the Action shows two different Variables which can be independently scaled/rounded/formatted but share the same Font-Settings. Can be adapted to other Use-Cases. Display Gauge (Keypad / Encoder) This Actions renders the Value dynamically on a Bar or Arc. Size, Color, Position and Font-Settings can be tweaked. It can optionally send Commands. Display Gauge (Dual) (Keypad) As before, but it renders two Values dynamically on the same Bar or Arc. Profile Switcher (Keypad) This not a "real" Action like the others, it is only there to map Profiles used for Switching. Installation & Requirements The best Way to Install and Update the Plugin is via the Installer: Download, Execute and click Install! It will check the Requirements, informs & links what it missing and installs the Plugin in the correct Location if the Requirements are met (the StreamDeck Software will be automatically stopped). It is highly likely that you need to Unblock/Exclude the Installer & Plugin from BitDefender and other AV-/Security-Software. It's the number one Reason for "the Plugin is not working"-Issues. If it still does not work right or at all, please check 3.3 - Troubleshooting. The Requirements for the Plugin to run: Windows 10 or 11 (updated) StreamDeck Software v6 .NET 7 x64 Runtime (.NET Runtime and .NET Desktop Runtime) installed & updated IF used for MSFS/P3D/FSX: The latest Release of the FSUIPC Version specific to your Simulator (e.g. FSUIPC 7 for MSFS2020) IF used for MSFS: The latest Release of the WASM-Module from MobiFlight installed in your Community-Folder Optional: If you want to use VJOYDRV Commands you need Version v2.2.1.1 for Windows 10 and Version 2.1.9.1 for Windows 11. It is not checked by the Installer (since it is not a Requirement for the Plugin). The full README is on GitHub - please read it to understand how you configure Actions. If you still have Problems or Questions, feel free to contact me on any Platform/Forum 🙂 Here Example Images of what it can look like:

Unfortunately the Workload in my normal Job is pretty high this Week, just came out of the last Session for today. So I'm slower than I wanted to be 😕 (But hey, it pays the Bills^^) Depending on how big the urgency is: the "PilotsDeck-latest.zip" I just uploaded has most of it included already! Besides some further Optimizing/Testing/Polishing the only thing left is to add the Images with the "native" Resolution for the XL. (And obviously document all that in the Readme^^) So if you wish, you can start with that! When the Release-Version includes these Images, there is nothing to reconfigure. The Plugin automatically loads the right Image for the specific StreamDeck (so Actions can easily move between different Decks and adapt automatically). The vJoy Syntax is: <joystick>:<button> (numbers as documented in FSUIPC). You can add a ":t" after that for a toggle-type Button, without it the vJoystick's Button will be set as soon as the StreamDeck Button is pressed and will be cleared when it is released. But only with the ":t" you can have a Second Command ("Long Press") for that Button. Couldn't find another way to safely differentiate if user wants to press the vJoy Button as long as he wants or if he want's to fire the "Long Press" Command 😉 (It uses the 29F0 Offset for the technically intrigued) The Profile Switching is more or less the same as currently documented. The Difference is now, that "Use Default" and "Default Profile" are per connected StreamDeck, the Profile Switching can also be enabled/disabled when the Button of the Profile Switcher is pushed on the Deck and the Profile reinstallation does not require to leave the PI anymore. I've added all Executables to Plugin-Manifest (XP, 2020, FSX, FS9, P3D - hopefully spelled right). The other Setting (in the .config) does not exist anymore. So it should theoretically "just connect" without fiddling with the Configuration. I'd recommend to only have one Sim opened 😄

Should be ready in the next 2-3 days, want to add/improve some other things 😉 (crispier display on the XL, profile switching when multiple decks are connected, easier way to change the sim - I can't test but could eventually run with XP/2020).

I just realized how "ignorant" your analysis was. To be fair, I myself was also ignorant. At least I don't go ahead and write lengthy posts on things I didn't bother with. You say this was "collaborative" - I can't judge if it was generally. But personally: it is not a style I'm compatible to. It didn't encourage me in any way to bother with your problem any longer, I just stumbled on the realization by accident (was looking for something else in the Offset Document). The thing is: Would I have spent some more minutes on your Code, especially on what FSUIPC Facility you're using there, I could have come to the conclusion, that basically you need/want to write a specific Value to a a specific Offset. Would you have spent some more minutes (time at all?) to look into the Readme, you could have come to the conclusion, that my Plugin does allow to write any value to any offset. So this virtual Joystick Facility is/was only a subset of my Plugin's capabilities all the time. I just need it to make it usable within the FSUIPC UI (does not send any Command while Sim is not ready) and if and how I can combine the keyDown/Up Mechanic (Set/Clear the Button) with my already built-in Long-Press Mechanic. Already made a quick test without that ready check - works straight away! Don't know what it is worth for ... although there where some requests to have "something" for the StreamDeck, People seem to don't care anymore. But at least I adhere to my "Design Goal" of the Plugin being a flexible and customizable tool a potential user can use it their way - although the two Users that are indeed using the Plugin and love it for its capabilities don't need this Facility.

Uhm ... okay?! 🤔 Thank you for your Insight on your Use-Case. I now know that it has to be this Approach because of completely different Premises. It would have been completely fine to just write "Thanks, but this doesn't suite my needs!"

For all still interested: I made some good progress with my Plugin now. It is hosted here on GitHub 🙂

Hey @pilotjohn, I'm currently working on a StreamDeck Plugin myself. It's on Github, you can try it if you want here . It doesn't present / create any virtual Joystick Buttons that would be assignable in the Sim - the Assignment is done directly in the StreamDeck Plugin ("this StreamDeck Key fires Offset/Lua/Control/Macro/Script XY in the Sim"). Don't if that fits your use-case, but maybe it is a more straight-forward way? 🙂

Maybe you'll find more help in the FSLabs Forums 😉 Have a look for the Copilot lua script in the Downloads section there. (You can disable all automatic functions and just use the lua interface) Also for the LINDA Module for FSLabs to get a List of Mouse-Macros. Both way much easier and more powerful (imho) than the rotaries!

That is still the Case 😉 When P3D is open, go to (focus) another Window on the second Monitor, execute this simple script via Joystick Button Assignment - then the focus is switched back to P3D and the mouse-input is blocked. Sometimes for everything but P3D, sometimes for everything. It's more noticeable if I hit the Button a few times in a row (for testing purposes). When I repeatedly click or alt-tab (quantity depends on how often the button was hit) everything is back to normal. This focus steal/blocking behavior is most noticeable when P3D is not focused. But I also noticed, this "something" happens even when P3D is focused. When I hit the Button a few times in a row while P3D is focused, any other window is blocked - the focus is instantly switched back to P3D. My first Impression was also, that this happens when the lua is started (or compiled). But I think it has something to do when the lua ends (just done some more testing as I wrote)! When I run a little Loop via Button Assignment (logs a Message, sleeps for some Seconds), the focus steal/blocking happens when the loop has ended. Regardless of where the focus (inside/outside P3D) was when this Script was started. When I "tail -f" the Log, as soon as I see "finished", the Focus is stolen from Notepad++ and I have to click multiple Times on it to regain it. Here's the Code: local ticks = 0; while (true) do ipc.log("tick") ipc.sleep(300) ticks = ticks + 1 if ticks == 15 then break end end ipc.log("finished") Nothing to be sorry for 🙂 What I actually tried to say with my last Post was that this Problem is not as critical as before - so look into it when it suits you best 😉 And that it doesn't matter where a Script is started, because it can also happen with ipc.macro or ipc.runlua. What I'm trying to achieve in special, does not matter anymore. Thanks to Paul I found a great Workaround. I stumbled over this while programming a StreamDeck Plugin which communicates (bi-directional) with P3D via FSUIPC (and Paul's C# Client DLL) - that is what I try to achieve in general. Since a Workaround is found for the Goal to repeatedly run lua-code, this odd behavior is not a Showstopper anymore for the Plugin development 😃 So to summarize: There is certainly some strange behavior, it would be cool if it could be fixed, but it does not stop anybody from anything 😅 Kind Regards Daniel

I have moved the repeated Calls of the Lua Scripts inside FSUIPC it self (Auto loaded Script which uses event.timer) - so that they don't have to be invoked from the outside. Roughly the same result, regardless if they are called via ipc.macro or ipc.runlua. Roughly meaning, that Mouse-Input to the Sim is still blocked, but not the whole OS and there is sometimes a chance to get some moment of control to at least gracefully close P3D. Since I'm already inside a Lua Script there is no real need to call another Script anymore and I can mitigate this Blocking. Luckily this Bug/Effect is no Showstopper for my App anymore! 🙂

Both latest Versions, I knew I forgot something 😅 P3D v5.1 HF1 (5.1.12.26829) FSUIPC v6.0.12

Hello! I've found a strange problem when FSUIPC runs Lua Scripts: it changes the Focus to the Sim and blocks globally (whole OS) every Input. I have to repeatedly click on something that either the Sim or any other Program can receive input again. It only does happen when the Sim is not focused. It does happen regardless if the Script is invoked by a FSUIPC Button-Mapping or externally called (e.g. FSUIPC SDK for C#). The Script can be as simple as local lightPos = "PSEUDO" I did not notice it much while flying, just wondered why I sometimes have repeatedly click something in the Sim. But now I'm writing an C# Application which constantly polls FSUIPC and some of the code runs a Script. This results in an effectively blocked PC, nothing reacts anymore. Key-Input does not help, since the Focus is directly stolen again. Maybe this related to other cases? https://forum.simflight.com/topic/91608-msfs-fsuipc-7-issue-with-os-and-sim-app-focus/?tab=comments#comment-554500 https://forum.simflight.com/topic/91067-p3dv51-simconnect-menu-window-focus-issue-resolved/?tab=comments#comment-551143 I've tested the Configuration Parameters from the second Thread, but they do not affect this behaviour. I've tested SetForegroundOnKeySend+KeyboardFocus both set to No and both to Yes. Also I've tested LuaTrapKeyEvent Yes/No (seperate). Kind Regards, Fragtality

@W4rl0ck Yes, it is possible - I programmed a prototype myself months ago (but on hold since then). Have you already tried multiple Buttons/Controls? Are you using ReadLVar / SendControlToFS Functions for the interaction? I'm asking because my prototype had issues when multiple buttons where assigned (e.g. Lights, TCAS, APU). Maybe some kind threading-issue with the library I used (StreamDeckLib).