pilotjohn

Ok, so it looks like this "should" work as expected (e.g. there's no update between the two sequences), but it doesn't because 208C only shows a value of 1 regardless of whether the control sends 1 or 2 as the param. The aircraft switch behaves correctly (Auto vs On) but 208C always reads 1, never 2, and 0 when off. I'm not sure if this is a sim/aircraft issue or whether the value is reflected incorrectly in this offset. Any thoughts? Resetting the flag is a great idea, I should have thought of it, thanks.

I tested with lower sequence numbers: 360=P65,9,C65930,0 -{MAGNETO1_BOTH}- 361=P65,9,C67059,1 -{ENGINE_MASTER_1_SET}- 362=D208C<2 P65,9,C67017,2 -{TURBINE_IGNITION_SWITCH_SET1}- 363=D208C=2 P65,9,C67017,1 -{TURBINE_IGNITION_SWITCH_SET1}- And the result is the same. It appears offset values are modified immediately after #362, so pressing this button always just result in the ignition set to "1". The flag idea works (thanks for the pointer), but it's less deterministic from a user standpoint (not predictable where the toggle state will land when switched off). So is the only other option then a Lua?

What would the pause help with in this case (assuming both actions are actually being executed).

They are in the INI (placed next to #42, #1042 etc.), but there is 2043 (for example). I'm basically trying to group button actions using this method. I have >200 "base" assignments (made in the UI), and to pick the right sequence when adding additional controls I would have to find the next highest one. So I'm using this schema, where additional actions for a given base are +1000 +2000 etc. In this case #41 is MAGNETO1_BOTH, #1041 is ENGINE_MASTER_1_SET. I'll verify that #3042 is being used. This works across many planes/types that achieve same functional result (e.g. some sort of ignition on). I'll look at this, thanks.

I have the following to try to toggle between auto/on for ignition (off is separate). 2041=D208C<2 P65,9,C67017,2 -{TURBINE_IGNITION_SWITCH_SET1}- 3041=D208C=2 P65,9,C67017,1 -{TURBINE_IGNITION_SWITCH_SET1}- The above doesn't work because offset 208C is updated immediately with the state (2) after sequence 2041, so 3041 will always trigger. Any chance you could add a "break" option to this syntax that would stop process or ignore sequences after the break? The other option would be to treat the "state" as atomic across all sequences (or at least per button), but I imagine that would likely break lots of legacy stuff. Or, do I have to use a Lua for this?

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.

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.

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.

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).

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 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)?