scuba82

Excellent ! Thank you for the fast reply!

Not 1:1 related to you issue but maybe worth to mention: The ESP32-S2 and S3 boards seem to suffer from Bug related to serial communication. E.g: https://github.com/espressif/arduino-esp32/issues/10323 When sending and receiving data over it's native USB serial interface the USB connection will stall. We've run into that issue while using a ESP32-S2 as a F/A18-C UFC controller. (sending and receiving data) Since you're only receiving DCS-BIOS data in your DED project you shouldn't be affected.

Hi, I noticed an issue in Cerberus North, Mission 9 since DCS Update 2.9.14.8222. The flight members B,C,D are constantly orbiting around WP1 and won't follow Steep to WP2 as commanded. On rendevous point (with Tornados WP3), "D" is ordered to fly on mile ahead. This trigger seems to work and he is leaving the orbit around WP1 and is trying to catch up and take his position. I also played this mission before the update and everything was working back than. So I guess something has changed in the update. Thanks

Unfortunately no, and not many seem to be interested in this issue.

I've tried to use another (dark) color for the passthrough square, in hope to have at least a "not so visible" dark border around my passthrough area. However that didn't work since other, similar dark colors got transparent too. Now I noticed that there is a "similarity" ruler within the visual desktop passthrough configuration. My assumption is that not only the definded RGB value gets replaced by the passthrough overlay but a range of colors controlled by the similarity ruler.(?) Turning the ruler all the way to 0 didn't work at all in my initial tests (nothing got transparent) but I'm going to test some other combinations later. Update: Seems as that my suggestion works. The color of the passthrough are is R:5,G:5, B:5 and similarity is turned to 1÷

Unfortunately I still have the same issue and no reaction so far.

I have to bring up this topic since I was running into the same issue and have found a solution. My Setup: - Debolestis Board with 2 Shift registers. (CD4021BE ) - Thrustmaster Warthog base (2019) The issue: Every "single" button press is detected without any issue. As soon as I activate two buttons at the same time (no matter which 2 buttons eg. Both Trigger stages), the buttons "11" as well as "hat switch up" are recognized as pushed too. The solution: Adding a 100nF capacitor between VCC and GND on the second CD4021BE (which has no cap) solved the issue for me. I can only explain it to me that the second shift register doesnt get enough power from the warthog base and falls into an inconsistant state, reporting the wrong pin states. Hope that helps someone @debolestis

Although in VR, I'm exporting several viewports to individual monitors. To restrict the mouse pointer to the dimension of my main screen, I use the "VR-Mirror" directive. However, having this option set, Kneeboards are no longer displayed correctly in VR. When activating the Kneeboard the Kneeboards border, as well as the change page buttons are visible, but there is no content within the border. At the same time the Kneeboards is correctly displayed on my main screen (VR-Mirror). If you need any logs or screenshots I would be happy to help.

Not exactly what you're asking for but there's a fork of DCS-BIOS which enables the wifi functionality of esp32 MCUs. https://github.com/pavidovich/dcs-bios-arduino-library . With it DCS-BIOS (on esp32) can comunicate over Wifi only so there's no need for an USB connection or port forwarding via socat.

@Tonester thank you for mentioning the "Input Command" thing... In my case the "Input Command Injector" Mod from Quaggles was causing the issue. After uninstalling the mod and repairing DCS the menu works as expected. I've totally missed that there is an updated version of the MOD available which solves the issue and totaly works with 2.8.

Maybe already reporter: the Axis tune menu seems to be broken. By klicking in the button, while having an assigned axis selected, the Menü doesn't pop up... at least for me..

Yesterday evening a tested the deadzone on the "not sticking axis" and can confirm that even that solves the issue for me on the warthog throttle along with the deltasim slew stick upgrade. So to summarize the issue, we have no clue why this is happening but have come up with two possible workarounds: 1) Set a small deadzone on the non sticking axis 2)Set a cure >=9 on the center position of the non sticking axis @Roastie@Ramsay thank you for your tests

Funny... you seem to have discovered the same thing but come up with an inverse solution to mine... That seems to partially negate my hypothesis... I have to test the bigger deadzone with my setup as well to see it also does the trick... I've also noticed the "stickiness" of the cursor when it's locked to an IR source but guess that has nothing to do with initial issue of not beeing able to slew in one direction.

Thanks for testing and sharing the video ramsay. Gonna investigate further on this and maybe also try some other input sources.

The slew sensor upgrade seems to be too good/precise for the harriers IRMAV cursor . There seems to be a bug where the IRMAV cursor won't move in vertical directions while there is no input on the horizontal axis at the same time. With the original TM slew sensor this behavior seems not to be that obvoiuse, since it's much harder to keep the horizontal axis still while moving the vertical one. I've posted my discoveries in this thread Slewing problem with IRMV in Harrier and would highly appriciate if someoine could test it too and give a short feedback if the issue occures for you at all respectively if my workaround solves the issue.