pilotjohn
-
Posts
377 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by pilotjohn
-
-
43 minutes ago, pilotjohn said:
I installed FSUIPC in C:\MSFS Stuff\FSUIPC7
In that directory there's a FSUIPC6 Documentation folder, which has the PDFs I mentioned.
That folder does not have this generated text file.
And there's no FSUIPC7 folder my Document folder.
I'll try to reinstall and see what happens. This was a partial rsync/copy from my old MSFS PC.
That was the issue. I guess if the folder doesn't already exist, it won't be created. Reinstall (and creating that folder) fixed it. Thanks!
-
I installed FSUIPC in C:\MSFS Stuff\FSUIPC7
In that directory there's a FSUIPC6 Documentation folder, which has the PDFs I mentioned.
That folder does not have this generated text file.
And there's no FSUIPC7 folder my Document folder.
I'll try to reinstall and see what happens. This was a partial rsync/copy from my old MSFS PC.
-
Hmm... I downloaded and used the latest beta you mentioned, but I don't have an FSUIPC7 folder generated in my Documents. I also searched the entire drive for that file, and it's nowhere to be found. Do I have to enable it somewhere?
-
Thanks, I'll check it out. How/when are new controls added? Also, could this drop-down be made searchable (although with this generated list that's less needed)?
Do they automatically get an offset, and how would I know where to read their status?
-
I recently noticed that ENGINE_MASTER_1_TOGGLE is available in the UI, but not listed in documentation (offsets or controls/events). Are there updated docs or a way to get the full list?
This was a very useful addition (I don't know when it happened), that allows toggling the engine master on airplanes like DA62 (works) and DA40 (also tested and works).
-
Sounds good, good luck with the project
-
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 reasoning maybe you can help me see something I didn't (and vice versa). I certainly know my approach may be too minimal as suggested before.
-
51 minutes ago, Fragtality said:
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? 🙂
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 could solve by:
- vJoy (problematic on my system and MSFS - I was using this)
- FSUIPC's virtual joystick facility (removes a layer of abstraction)
If I solve this via the FSUIPC joystick facility, the value add of the plugin is something FSUIPC doesn't currently provide:
- Triggering of these already-existing facilities from something that is not a joystick
- The ability to expand to something FSUIPC does not currently do like long-press and double-press (when/if I need it) for which the UI can be relatively clean
Moving the configuration to the plugin actually has disadvantages in my view:
- First, it's a lot of boilerplate UI re-implementation (which is going to be worse than FSUIPCs due to limitation)
- The advanced logic (which doesn't have a UI in FSUIPC) will be hard to do in the limited UI space of Stream Deck
- Add profile specific use cases and now you're also reimplementing conditionals
- It would split my config (and if I want to move a button from Stream Deck to a joystick, I have to reconfigure instead of just re-assign)
The only limitation I see is the number of virtual buttons available in FSUIPC. I have 6 panels and may run out if I add long/double press (but hopefully Pete and/or John are willing to expand - they're very responsive and helpful in general)
Lastly, if I were to go down this path despite all the above, I would likely just skip the FSUIPC layer and use SimConnect. But, there's already several projects for this.
Of course your mileage may vary and maybe I missed a value proposition. I tend to be very pragmatic.
I'm not against it, just don't have a need. What I will likely implement, as mentioned, is different triggers based on long press and double press.
-
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).
-
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?
-
Seems to be working now. Thanks for the fix!
-
Thanks, no hurry. Please enjoy your "vacation". 🙂
-
Sounds good, thanks. No hurry, just thought it would be cleaner to not mix topics. 🙂
-
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.
-
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.
-
1
-
-
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.
-
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).
-
1
-
-
1 hour ago, Paul Henty said:
Yes they are registered globally when they are instantiated. They are processed whenever the group they are in is processed. Offsets are updated with new values from FSUIPC unless their value has been changed. In this case the new value is written to FSUIPC.
Yes, that's the easiest way to handle such offsets.
It might need to be connected.
I've tried your KeyPressed and KeyRelease code here (not via Stream Deck though as I don't have one) and it works fine.
I would try with FSUIPC connected. It might ignore IPC requests until its connected.
Thanks, yeah connecting may be the issue... I'll have to test on my sim rig.
1 hour ago, Paul Henty said:If it still doesn't work, check what is actually being sent to FSUIPC by enabling the "IPC Writes" logging in the Logging tab. Use the option to send the log to a console window to check in real time.
Have you considered adding the ability to send controls (events) directly to FSUIPC from the stream deck? e.g.
try { if (!FSUIPCConnection.IsOpen) { Logger.Instance.LogMessage(TracingLevel.INFO, "Opening FSUIPC connection..."); FSUIPCConnection.Open(); } Logger.Instance.LogMessage(TracingLevel.INFO, "Sending control " + (settings.ControlNumber).ToString()); FSUIPCConnection.SendControlToFS(settings.ControlNumber, settings.Parameter); } catch (Exception ex) { Logger.Instance.LogMessage(TracingLevel.ERROR, ex.ToString()); }
This would bypass the need to do any button mapping.
e.g. sending control 66079 (with parameter 0) would raise the landing gear.
Control numbers are listed in "The 2016 List of FSX and P3D Controls.pdf" in the FSUIPC Documents folder. Most controls don't need a parameter value so 0 is sent.
Paul
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 is adding support for Stream Deck, and this would essentially provide that for FSUIPC.
Thanks for you help.
-
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)?
-
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 1 connection to FSUIPC per the one mobile device I'm using for testing).
Any thoughts about what I may be missing? Caveat: FSUIPC was not connected to MSFS during testing (since I was doing this on a VM).
-
Thank you both. I'll see how this works out. Hopefully I can just get rid of vJoy.
-
Thanks! I'll see how all this goes.
-
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 think I prefer to think of the virtual buttons as 288 independent items so I can group them by StreamDeck panel (I have 6 of them with 15 buttons each, and grouping each into a "device" wastes buttons). Anyway, not important. 🙂
-
1 hour ago, Pete Dowson said:
Yes, they are assignable -- that's really the point of them. They appear with Joystick numbers 64 to 72, each with 32 buttons 0-31.
Pete
Since they're not visible when FSUIPC starts up, will they be auto-assigned letters when they are first received?
Updated List of Controls/Events?
in FSUIPC7 MSFS
Posted
Right, and that works (I've used it), but you can't for example search for "ign" to find controls that have "ignition" in them unless it's the beginning.
The text file with the list works fine.