Copprhead

There seems to be a big difference performance wise. https://youtube.com/c/WoonasArtTM There's a post(can't link it, but it's from February 25th 2021) in the "community" category of the channel that suggests a 10%fps increase, noticable lower CPU frametime and better visuals by reducing in game PD and increasing SteamVR SS.

@shu77 have a look at the following topic, where different devices and approaches are discussed:

Good to know, so I don't waste any time on them Just added the missing features (destinguish clicks for left and right hand ) and applied (almost) correct position and rotation offset values. Ready for a test flight Hands on throttle and stick: Flat hands pressed against each other:

@frenzon thanks you for the ideas. The "click device" is still a weakness of the concept. Also because it's an initial hurdle to get a suitable device. I've choosen the finger mouse because it is very cheap and I knew that I can capture the clicks, which is uncertain for things like "volume up/down" on Bluetooth remote devices. It turned out to be quite complicated to capture, distinguish and remap click events from multiple connected mice, but its possible and instruction for that will follow later. The finger mouse has 2 buttons and a wheel. One button I use to grip, the other is grip+trigger (so I don't have to press both buttons to flip a switch) and I plan to use the wheel for rotary controls. There are "bluetooth ring remote control" (google it) that are also cheap and much smaller, but I'm not sure if it's possible to capture and remap the buttons.

Good news and bad news. After I added controller rotations for all axis I encountered the problem that DCS refused to use my virtual controller and always switched to the phyiscal controller. As I can't influence what DCS is doing, the whole concept of the virtual controller is on the rocks! Now the good news: I managed to "hook" (https://en.wikipedia.org/wiki/Hooking) my own code between the calls of the OpenVR interface and the actual driver of the pyhsical devices. By this I don't need to add a virtual twin of the controllers, instead I can directly manipulate the controller information that the driver is reporting to SteamVR. The new concept is much more stable and less of a workaround. At the moment I verified that I can influence the controller position and orientation and press/release trigger and grip when certain keyboard keys are pressed. And as there are only 2 controllers, DCS is no longer confused. Next steps are to make these things configurable and add logic to distinguish between trigger and grip of left and right controller. Current source code is added to github. Basic driver code is based on the driver of https://github.com/pushrax/OpenVR-SpaceCalibrator Hooking library used is https://github.com/TsudaKageyu/minhook Inspiration for the hooks necessary to emulate trigger/grip is from https://github.com/matzman666/OpenVR-InputEmulator

In SteamVR View you can see the physical and the virtual controller. The WMR Controllers are the physical ones, the Vive Controller is the virtual controllers with the offset.

It obviously depends on the strapping solution you use whether the controllers are more or less in the same place. Offset depends on the physical controller, a Index controller needs a different offset than a WMR controller. You might want to use the right physical controller on your left hand or mount it upside down. Whatever is more comfortable to wear. Maybe some 3d printer parts could help there, but for the proof of concept I just used what I had available. Also having a correct offset is more like a bonus than a necessity. Your brain can quickly compensate small errors in the offset, especially as you see the 3d hand models. It took me some days to solve the math behind the offset calculation, so at first I used it without any offset and now I have a hardcoded offset with more or less correct position but still a somewhat incorrect rotation. Finding the correct offset is also a bit try-and-error as you don't not the neutral position of your controllers. Some "calibration" procedure should be possible to automatically detect the correct offset.

I don't have PointCTRL so I can't really answer that. The virtual VR controllers interacts with the cockpit just like your physical controllers does when you grab it to flip a switch. It just gets rid of the grabbing part. With the VR controller you're not pointing with your hand, instead the actual position of your hands are tracked in 3d space including the pitch, roll, yaw orientation. You see the hands moving in the cockpit. Tracking is done by your VR system, so if your system uses base stations you don't have to look in the direction of your hand to use it. The only additional hardware you need is something that allows you to initiate the "trigger and "grip" action. You could use voiceattack or some buttons on throttle/stick that you can press with the opposite hand. You can use both hands at the same time (maybe useful for RIOs?) However the use of VR controllers has some drawbacks: You need to have enough space around you to actually move your hand to reach all switches in the cockpit. You can't just put your throttle and stick on a table in front of you as your hand would constantly bumps into the table. Ideally your throttle and stick are located were they are in the aircraft you're flying, so they don't block your hand. In my opinion the DCS implementation of controller interaction could be improved, mainly regarding the grip and click action for two-way switches. The mouse implementation seems to be more flawless in that regard.

An OpenVR driver that allows the hands-free use of your regular VR controllers, so that you can keep your Hands On Throttle And Stick (HOTAS). Your hands are the most intuitive way to interact with a virtual clickable cockpit in VR. A regular VR controller is a good way to click buttons, flick switches or rotate a knob. But when it comes to flight controls the use of a physical joystick and throttle are vital for precise flying. But it's tedious to constantly switch your hands between the VR controllers and the physical joystick or throttle as you can't hold them at the same time. True hand tracking would be the solution, but unfortunately, this is in most cases not (yet) reliable and for most of us also not an obtainable solution. hotas-vr-controller is an OpenVR driver that allows modifying the position and the orientation of your regular VR controllers. This makes it possible to strap the regular VR controllers to the back of your hands or your lower arm, while the virtual hands still appear in the correct position and orientation. In this position, it is not possible to use the normal buttons of the VR controllers. Instead, hotas-vr-controller captures mouse clicks to emulate the grip and the trigger inputs of the VR controllers. "Finger mouse" devices (small mouse devices typically used for presentations) can be worn on the index fingers of both hands to trigger these actions. This configuration enables a fluid transition of your hands between a physical joystick or throttle and the hand interactions with the virtual clickable cockpit. So far it's only tested with a HP Reverb G2, but it should work with any OpenVR compatible tracked device associated with the left hand or right hand and with a grip and trigger input. Visit https://github.com/Copprhead/hotas-vr-controller to download the latest release!

I have the same issue. Is there a fix?

In the F-14 cockpit the "Canopy Jettison Handle" reacts to the "grip" command and protrudes the panel so it's very easy to touch it while "grabbing" a different botton/switch. With fatal results. Is it possible to disable this handle (e.g. by modifying a lua file) so it doesn't react to the VR controllers?

It's not released yet.

I'd double check that the correct version of the c++ redistributable is installed.

Install c++ redistributable, link see post below.

@MadMaxter just saw the Reapers interview from 2 month ago where you stated that adding the radio is not possible without SDK. Most likely you are already aware that the A-4E now has a working radio.

It's displayed but the ball in the overlay is not showing the correct glide path, just like the LSO is giving wrong instructions. The ball on the physical IFLOLs on the carrier is showing correct glide path though. As said, it's a known issue for F-14 as the SC expects a Hornet. So A-4E is most likely affected as well. It's nothing the aircraft can fix, it needs to be fixed in the SC module. BTW the module is a true masterpiece.

I've heard the F-14 has the same problem for this reason and also that the IFLOLS overlay is not correct for everything but a F/A-18.

"Bio" talks a bit about ground clutter, pulse doppler and notching in this video:

You're missing the necessary "C++ redistributable". See this post: It's a bit unclear which version you need as the linked page list several packages. You need "Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019" in the x64 variant. Direct link: https://aka.ms/vs/16/release/vc_redist.x64.exe

You need to delete the "Saved Games\DCS.openbeta\Config\Input\A-4E-C" folder. It contains the old key bindings and some are not compatible with the new version.

Anyone knows if you still get a SC discount if you buy the F-18 and if that discount can be combined with the current sale?

If giving commands by voice is an option for you, give VoiceAttack a try. The free demo version allows 20 commands, enough to assign the f-keys and one to open the comms menu. It takes you some minutes to configure but allows you to keep your hands on the stick and still operate the radio in thight situations. In addition to the comms commands you have still have a couple of commands left, e.g. I use then to open the F-14 Jester menu and for some F-14 checklist commands.

I didn't realize that the new version features a radio, aerial refueling and proper catapult launch implementation!

I had exactly the same issue. Yes, it's caused by the old key binding file. You need to delete it, of course only the files for the A-4E. It's not in the "Mods" folder but in the "Input" folder parallel to it.

Really looking forward to this