Jump to content
The simFlight Network Forums

pilotjohn

Members
  • Posts

    377
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by pilotjohn

  1. I think that will work. So these virtual buttons will be assignable in the Buttons tab (what device letter do they show)?
  2. 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?
  3. 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.
  4. 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)?
  5. 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?
  6. 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
  7. I've seen some of those... I think "barber pole" might be it. πŸ™‚ Missed that. Thanks.
  8. 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.
  9. 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.
  10. 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.
  11. 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?
  12. 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.
  13. 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?
  14. Ok, thanks for looking. It seems like they should just hook it up to either Ignition or "Both Magneto".
  15. 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
  16. 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.
  17. 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".
  18. 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?
  19. Thanks... if I send a control (say Fuel Selector 2 Set 16), is there some deterministic delay for the offsets getting updated? My plan is to create a generic fuel selector toggle script which when run will read the current tank value and increment it until it "works" (meaning the change is reflected in the offset) or it reaches to the end. I'm wondering if there's some upper limit for the "wait to see if it worked". Specific question, for which you may not have the answer, is why I see an event (fuel selector 1 off) when I switch something in the cockpit (mouse), but if I send that control, it doesn't actually cause the event to happen. On the DA62, sending fuel tank selector controls with appropriate values (like left/right main) work, but "off" is ignored.
  20. Thanks... yeah, I use battery master toggle (which works for the battery), but this is the engine computer for the DA40/62 (which are like car engines in that regard). I would love to bind them to my generic "ignition" switch but alas, it doesn't seem like that will happen.
  21. I'm working on a generic fuel selector toggle Lua (each button press cycles to the next "working" non-off tank setting). My plan is to set the next tank state and see if it worked (if so, great, otherwise mark as inop and try the next one). I see there are some offsets to read... FUEL TANK SELECTOR:1 RECIP ENG FUEL TANK SELECTOR:1 .. 4 TURB ENG TANK SELECTOR:1 .. 4 Before I go down this path... Are these really different? Is there a reason why there's no generic fuel tank selector 2..4?
  22. Apologies for the naΓ―ve question, but if there are no events being triggered by a switch, is it possible to trigger the functionality some other way (Lvar)? Specifically the DA40 and DA62 have master switches for the ECU which I would like to bind to button. Has anyone managed to do this yet?
×
×
  • 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.