Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by pilotjohn

  1. It was simply my view, and you suggested maybe moving UI was a more straightforward way. I responded with my analysis (and why I chose what I did). I didn't say it's right, it was simply a design choice and reasoning of pros/cons. There can be many implementations. I'm sure there are benefits to you approach I missed (my use case is specific). I also pointed out an even further simplification that's possible (e.g. direct SimConnect), for which a UI is actually necessary. Take it or leave it. "Thanks, but this doesn't suite my needs!" is not a collaborative process. If you understand my re
  2. Cool, I've thought about this, but it didn't make sense for my use case. I just needed vJoy off my system. But generally in my view it's less advantageous to do this, and here's my reasoning: 1. FSUIPC already has a very reach UI (list drop downs for all events, params etc.) 2. FSUIPC already has a rich configuration language when the UI is not enough (e.g. advanced options like multi-actions etc.) 3. FSUIPC has profile specific actions 4. All of this is centralized in one place What was missing is a way to trigger them from non-joystick devices, which you coul
  3. Great, thanks. For one of my specific use cases, the CJ4 mod broke the events based autopilot controls (e.g. I can't use heading toggle for example), but apparently it should be controllable via Lvar. I have not yet seen the list to Lvars for this, so I was curious how it would be obtained (especially for aircraft which are DRM protected).
  4. I saw the mentions of upcoming to support for Lvars through a WASM module. Is there a beta test for this? Where can we follow progress or watch for release? Also, will there be a way to investigate what Lvars are available in an aircraft?
  5. Sounds good, thanks. No hurry, just thought it would be cleaner to not mix topics. 🙂
  6. The "repeat while held" rate seems to be different between physical (those coming from the OS) and virtual (device IDs 64-72) joystick buttons. As I switched to triggering FSUIPC through virtual buttons from Stream Deck (instead of using vJoy), the rate at which events are sent to MSFS (for example, MHz increment on COM1) appears much higher for virtual buttons. This makes it hard to do step increments. I have the repeat set to 25,10 (40ms with 400ms initial delay), but the "initial delay" also seems to be ignored.
  7. If you'd like to use Stream Deck buttons to trigger FSUIPC functionality, you can use FSUIPC's native "virtual joystick", without the need for vJoy (which can create issues for certain games and devices), from this plugin: https://github.com/IslandJohn/StreamDeckFSUIPC. If there's interest, I can add triggering of offsets and controls directly, but I didn't see a need to move the UI for those things from FSUIPC.
  8. Everything seem to be working, except for one thing... the "repeat while held" for the FSUIPC virtual button seems to be a lot faster than for physical/device buttons. Is this by design? Can this by adjusted? Because it takes about 0.06 seconds for a press-release cycle, it's hard to stop at the right spot or do one step increments (like frequency). I'll just start a new topic on this.
  9. Ack, thanks. I'll post this Stream Deck plugin to User Contributions if it ends up working out (and I'll probably add actions for direct offset and controls as well). This will provide Stream Deck integration for FSUIPC (which Spad.Next is adding). Maybe it can be evolved by others to provide bi-directional updates (e.g. change the button image based on offset changes - I have no need for that but other probably do).
  10. Thanks, yeah connecting may be the issue... I'll have to test on my sim rig. I did think about this and may do it. The immediate issue I'm trying to solve right now is to get rid of vJoy. If I start sending offsets directly, I loose the "UI" in FSUIPC so I was planning to just start with buttons. I also use some custom Lua for very non-standard things (like fuel selector, and ignition/magnetos), so I prefer to keep "config" for functionality in one place. If this works out, I'll add a generic "offset" plugin action, where you can just set the offset, size and value. I think Spad.Next i
  11. Is the "Button Assignment" window supposed to react to these externally triggered offset changes? I assume yes, but want to make sure. And does it matter whether FSUIPC is connected to MSFS or not in this case (I know for physical devices it works without MSFS connection)?
  12. Ok, so I have the plugin working, and FSUIPC connection succeeding (and failing when appropriate), but FSUIPC Button Assignment window doesn't seem to respond to button changes. 1. Are "Offset" instances registered globally by the client library during construction? How does Process() know to deal with them? 2. Is BitArray appropriate for offset 3340 (as I use it here)? I have a Process() set/clear bit Process() as implemented here, but FSUIPC does not show a button press (even when I hard code 0 for the bit). Logs show things as expected (and so far experimentation reveals only
  13. Thank you both. I'll see how this works out. Hopefully I can just get rid of vJoy.
  14. Brief questions... 1. I'm not sure if StreamDeck creates a separate instance for every panel or button (and how it actually instantiates the plugins). Is there are a large overhead for (potentially) creating lots of connections to FSUIPC? I assume Open() is at some global/singleton level per whatever process it's running in. So I can do IsOpen checks for each event, and just reconnect as needed. 2. Since I have to read 3340, is Process() synchronous? That is, can I do this in the StaremDeck events: Process() (to read), flip bits, Process() (to write)? While 29F0 seems useful, I
  15. Since they're not visible when FSUIPC starts up, will they be auto-assigned letters when they are first received?
  16. I think that will work. So these virtual buttons will be assignable in the Buttons tab (what device letter do they show)?
  17. I'm looking to adapt StreamDeck vJoy Plugin to send virtual button offset changes to FSUIPC directly. It seems this should be trivial by simply replacing calls to vJoy acquire and button setting (e.g.here) with FSUIPC equivalents. Is this correct?
  18. I'm trying to trigger button-like functionality from an external process in FSUIPC. I don't want to go through vJoy as a layer of abstraction anymore (both because vJoy drivers are somewhat buggy with many devices installed, and because it creates these extra peripherals that some programs can't deal with). I can write a StreamDeck plugin in C# that could call an FSUIPC API/RPC. It sounds like these virtual buttons Pete mentioned might be it, but ideally there's a C# library I can use.
  19. That sounds interesting... how can this be triggered by an external process? Are there C# libraries for it? Would they be assignable in the "Buttons" interface (that is will they show up as some device letter)?
  20. The GUIDs look the same for the same device, but the numbering changes (e.g. the device order). This was causing re-lettering for some reason (e.g. YOKO+ went from D to R for example). This only occurs with HidGuardian, and so far only noticed it in FSUIPC (USB Game Settings, Joystick Gremlin did not have the issue). MSFS seems to be a mess with their QA, and introduces these random issues that I have to try to work around. I'm not sure how they're not catching these, as it really manifests itself within the first 15 minute of me trying an update. With the CTD in Controls when
  21. With latest update of MSFS, there's a CTD with Controls if you have more than 10 devices. I tried fixing this by using HidVanguard/Guardian to "hide" devices from MSFS, but allow FSUIPC to see them. This would have worked except for 2 things: 1. The order of devices returned by HidGuardian seems to be random so FSUIPC always reassigned letters (this was fixed AutoAssignLetters=No) 2. Some of the devices (VirtualFly) didn't show up on launch, and letters using them were marked as "missing". However when I went to Axes, they were recognized by FSUIPC, but this caused a refres
  • 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.