Jump to content
The simFlight Network Forums

Fragtality

Members
  • Posts

    188
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by Fragtality

  1. For all still interested: I made some good progress with my Plugin now. It is hosted here on GitHub 🙂
  2. 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? 🙂
  3. 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!
  4. 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
  5. 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! 🙂
  6. Both latest Versions, I knew I forgot something 😅 P3D v5.1 HF1 (5.1.12.26829) FSUIPC v6.0.12
  7. 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
  8. @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).
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.