pilotjohn

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

Since they're not visible when FSUIPC starts up, will they be auto-assigned letters when they are first received?

I think that will work. So these virtual buttons will be assignable in the Buttons tab (what device letter do they show)?

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?

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.

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

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 there are more than 10 devices, I was trying to fix it by hiding the devices from MSFS but not FSUIPC, but that introduced these other issues. It seems I just won't be able to touch the controls until next update. 🙂 Thanks for taking a look. Not to start a separate thread, but StreamDeck support would be nice (since then I wouldn't have to use vJoy and the StreamDeck vJoyPlugin), and it would eliminate 8 devices. 🙂 I would be willing to fork/adapt the vJoy Plugin to support FSUIPC directly somehow. Do you have suggestions on how an external program can trigger FSUIPC functionality similar to button pree/release? Specifically, how could I cause an input to trigger an assignable event in FSUIPC? FSUIPC only seems to have Keys, Buttons, Axes. Keys is not a good solution because there's just not enough of them to not interfere with something else (e.g. its management is a nightmare when you have 100+ assignments). Ideally there would be a "virtual' section/tab, where I could simply send some device ID and button ID (or just some binding like a string) externally, and assign things the same exact way that I assign them in Buttons. Is this viable? That is, essentially duplicating your button handling code, and create a new tab where some external API (REST, or some library you can provide) could be used to trigger assignments. Then I could change the vJoyPlugin in StreamDeck to send these "virtual" events which FSUIPC would react to (e.g. press/release events or something). Do you have any other suggestions?

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 refresh, and the devices received new letters. Is there a possible fix in FSUIPC for #2 (some different scanning behavior on startup that is similar to when I open Axes?). That would resolve the issue. Also, scanning after opening Axes should still maintain the letter mapping (even if they were missing on start), although this would not fix the problem (since I would need to visit Axes every time). Logs and ini attached. Thank you. FSUIPC7 HV issue.zip

I've seen some of those... I think "barber pole" might be it. 🙂 Missed that. Thanks.

Is Vne and Vno available? I couldn't find them.

So far this is working out well... steep(er) turns at higher speed were basically difficult because any little movement caused lots of elevator authority (so it was all about movement not force required). Now, if I increase the slope, steep turns at speed require force to maintain altitude, which is what it's really like. Thanks for putting this together.

Tested on the elevator side and it works. It was a simply test manually increasing/decreasing slope during steep turns at different speeds, and I think it's accomplishing what I'm looking for (appropriate force required). I'll have to hack up the script to do the same based airspeed.

I wish this would be exposed via SimConnect instead.

This is my hypothesis and what I'd like to be able to test out (that force required is a better feel than range of movement required - or at least some balance between the two). This is why loadcell based brakes are better (they based on force applied), but then again those are you feet which have less motor precision. Anyway, it's the non-stop tweaking to get better feel. 🙂 I expect only to use a range like 2-8 or 4-12, so these are pretty big steps, but if it works it's a start.

Yes this would work thank you. I assume any writes would be temporary until a profile change, or aircraft change? Any way to make this more than 5 bits (e.g. -15..15) granularity?

This actually does happen in aircraft that have hydraulics controls (it's just a force multiplier), like smaller jets/turboprops, or anything that is not fly by wire. While I don't have any real time in anything with hydraulics, I have many hours in full motion (Level D) sims in both types, and you can definitely feel the control forces change based on speed in all non fly-by-wire systems (I'm sure there are some fly-by-wire that also simulate it). This curve looks to me like a sigmoid, and I thought the setting was some constant in the function, which is why I was hoping for smoother transitions than integer steps. Yes, I think this would work, but depending on the "steps" it may lead to some abrupt transitions.

Unless you have a force feedback yoke, the feel of the yoke is predetermined along its range. However in the real aircraft this is not, but is based on airspeed (air flowing over the surfaces). More specifically, force goes from a very flat and linear along the entire range at no airflow, to very high ramp up in forces past trimmed position at high speeds. While I do think that both range of movement and force is important, I'm wondering if one is more important than the other for "feel". Currently, all yokes assume that the range of movement should be the same regardless of speed. However, I'd like to be able to adjust this based on speed. That is, I would like the control surface deflection in sim to be driven by force rather than range (but still have full range of yoke map to full range in sim). This could be achieved by adjusting the calibration curves. Feature request: Allow the calibration curve for axes to be adjusted (via an offset) by speed and allow them to be floating point values. This would allow me to tweak the curve so that deflection amounts are based on force rather than range of movement. It's not perfect, but it's one approach. This is similar to what you implemented in Conditional Axis Sensitivity. WDYT?

Ok, thanks for looking. It seems like they should just hook it up to either Ignition or "Both Magneto".

Yes... the DA62 has 3 fuel selector positions for each engine (0 - Off, 19 - Left main, 20 - Right main). Using these controls via FSUIPC works and the selectors respond correctly in the aircraft. And if selected from the aircraft, the offsets are updated correctly. If I send something that is not one of those, it is ignored by the aircraft, but the offset is updated (as watched by an event). Yes, it is. 🙂 Attached is my Lua. It read the current selection, then tries to increment it by one, waiting 1s for it succeed and be done, otherwise continue incrementing (until, for now, it aborts at 20). The odd thing was that it *always* succeeded. That is, I wrote to set the tank, and received the updated offset, even when it was invalid for the aircraft. Upon triggering the Lua again, the read value for the offset was most recently written "invalid" value. If I "ipc.write", I should not expect an event unless the sim sends it to FSUIPC, correct? fuel_select.lua

Well, scratch this idea. It looks as if I send a tank select X, even if X is not bound to anything in the plane, the offset gets updated with X. So I expected the offset to NOT be updated unless the event actually triggered something in the aircraft, but that's not the case.

Yes it's both on the DA40 (guarded switch on the panel) and DA62 (switch next to each starter button). Setting magnetos to "start" works on both aircraft, but the engines will only start if the ECU switches are on. And there seem to be no controlling these "remotely".

Is this based on the registered sampling rate of FSUIPC or something else? Can I rely on some upper bound for this to happen? Also, are events dispatched on a single thread per Lua? Would an event.timer and event.offset callbacks ever happens on separate threads, or can I assume that while one is executing the other won't?