ldwater

Personally if you're investigating hand tracking, especially with DCS you should also consider usability and how hand interactions in VR work. If you check the hand tracking feedback (for DCS) a lot of it is very mixed because something that sounds ideal in theory ends up being a pain in practice. Mostly because: 1) The distance between your 'virtual' hand and the virtual switch you are selecting can create additional 'unwanted' movement, meaning you often have to lean forward, backwards, twist etc. With a VR controller you can hit switched on the other side of the cockpit by using the 'laser pointer', but if I have to move my physical hand over to the location which is virtually away from me its not ideal. 2) A lot of buttons can have multiple functions, like a push up, down, middle or a twist left or right. Its often quite difficult from just a hand position to know which one of those inputs is performed. 3) Reaching out to a busy cockpit can sometimes result in you pressing 3 switched you did NOT want to press, and only 1 you did. You need to be able to have a separate gesture to know if the user wanted to action the switch is at their hand position. Preferably you'd want a hybrid approach so that your real hand can be used a VR controller and / or a mouse with the same / similar functions so that users gain the benefit of using hand tracking to enable them to interact with their virtual environment without having to keep picking up the VR controller and swap between that and their HOTAS. Something like a 'finger gun gesture' as the pointer, and then maybe hand clasp as the 'action', with a left / right twist as turn left / right etc. I've been using PointCTRL for about a year now and it is excellent in its simplicity in that it does everything you need in terms of cockpit interactions without being forced into awkward physical actions or having to keep picking up a cumbersome VR controller.

How about over the headset? I use a Razor blackshark headset: https://www.amazon.co.uk/Razer-BlackShark-Multi-Platform-Cancellation-Hyperclear/dp/B089SSFV85/ I removed the old headphone things on the HMD because the sound quality and distance to my ears was horrible, and this headset fits over the existing ear mounts of the headset really well (as in the frame of the headset fits around the headphone mounts of the HMD). Along with a great mic, good cup size its great for long sessions without squashing your ears.

Yeah well that is my problem because I tried that but it seems like they use different values for the various parameters you enter. I tried setting it up based on my previous settings and nothing even got close to what I had in the stand alone QV. I even had some crashes / unplayable gameplay when using > 150% resolution in the Pimax Play version, where in stand alone it worked just fine. Does anyone know where the Pimax equivalent QV settings file is stored so I can compare it to the stand alone QV? It seems like Pimax took the idea, but not the implementation as the foveated 'style' looked very different to me.

I'm really late to this topic, but I can see that it says that destroyed units are 'removed' from the mission file, but would it be possible to replace them (like for like) with a destroyed static as well? That means you can easily migrate the mission file from one sortie to the next and know both the remains of existing groups but also have persistent wrecks that would accumulate over time.

Hey, Recently I decided I should upgrade Pimax Play to see if I can check out the upscaling features & the integrated Pimax XR & Quad Views, and while the installation seemed to work fine I found that the performance & settings of the integrated Quad Views was lacking, so much so that I disabled it and went back to the stand alone version. Looking at the integrated QV settings and the QV companion settings they are not comparable and some of the settings (such as the sharpness & thickness settings at the bottom) are missing entirely. Can anyone recommend how to migrate the settings from the stand alone QVs to the Pimax Integrated version so I can test as close to 'like for like' as possible. Thanks!

Thanks for the feedback. I'll keep my distance for now

As far as I know the companion app (https://www.digitalcombatsimulator.com/en/files/3332882/) is just an editor of the quadviews config file in: %localappdata%\Quad-Views-Foveated Looking to make sure that this config file is still available or something similar so I can re-apply my QV settings..

Hey all, I'm an OG Crystal owner and I've been holding off upgrading Pimax PLAY due to the hassle (and potential problems) with using the integrated Quadviews over the old separate install. I'm currently on Pimax Play v1.30.01.01 and I'm really happy with my VR config at the moment. I really don't want mess with it if I don't have to, but it seems like the new version of PLAY is being pushed out and was wondering if its worth just taking the hit and upgrading, but before I do that I wanted to get some feedback from those who have already done it. - Does the integrated Quadviews still support the Quadviews companion to allow fine tuning? Again I'm really happy with my current Quadviews config and don't want to reset to default and have no way of changing it. - Are there any other advantages (or disadvantages) of upgrading that I should be aware of? I know I'll have to do it eventually, but I'm really looking for a compelling reason (like upscaling) to do it to make it worth the jump. Thanks!

Hey all, Anyone know if a way I can capture the 'X:Cockpit parameter in range' ME trigger in a lua script? I'd rather have a script which I can refine and implement into multiple missions rather than have to re-create multiple ME triggers.. Thanks!

Yeah I'm the same, I'm keeping clear until these types of issues are resolved as I simply don't want the hassle of having to uninstall stuff to find the new stuff doesn't work and have to re-install it all over again. I'm confused as to why XR toolkit wasn't also rolled into PLAY simply because a lot of the guides online for Pimax headsets include the XR toolkit, even if its just for the FFR option. If XR toolkit doesn't work with new Pimax PLAY then it seems like a step backwards rather than forwards, for what is essentially to provide a 'bundled' install rather than installing separately. I'd love to see improvements and new features added to PimaxXR and Quadviews rather than just adding them to PLAY install and then keep clear of them because they 'weren't written by us'

I'm using the standard Pimax controllers. Other airframes it works as it did before, but since the patch it seems to be just the AH-64 pad that doesn't work the same anymore

I'd also be interested in knowing at what level the DFR / eye tracking is handled, as at the moment Quadviews is dependant upon the GAME being able to handle the eye tracking, instead of the hardware. So for example I would be playing two OpenXR games, DCS and Automobilista 2. With the hardware enabled eye tracking, and the GAME enabled eye tracking Quadviews would run exactly as intended in DCS. However with Automobilista 2, hardware eye tracking would be wasted because the GAME didn't support / use the eye tracking functionality, and therefore not be able to provide DFR. It would be great if the Pimax Play app would be able to provide DFR as close to the hardware level as possible to ensure the maximum amount of compatibility and performance without having to rely on individual games providing eye tracking support in order for DFR to work.

Will there be any sort of guide to help those who currently use PimaxXR and Quadviews separately to migrate over? I would assume that the companion app (https://www.digitalcombatsimulator.com/en/files/3332882/) would need to be re-configured to point to a new directory or would that functionality be included in the new Pimax play version? Its a shame that Mbucchia isn't involved directly but at least they are giving him the credit he clearly deserves and taking it on 'in house' should hopefully give it the attention (and budget) to expand upon his excellent work.

Hey, Figured this was a VR bug since its related to the VR hand controller. I'm using Pimax Crystal and since the last hotfix patch the AH-64 scratch pad (the keyboard & a few other elements) is no longer clickable using the controller trigger button. Normally (and with other airframes (ie, OH-58, CH-47)) I can hold the underside trigger to bring up the pointer, and press the top trigger to push a button. For the AH-64 this is no longer possible on some cockpit elements and I have to use the thumb stick 'down' to 'click' a button. It seems really inconsistent because I can do this normal (under trigger + top trigger) clicking for the MFD buttons, and some other cockpit objects, just not the scratch pad. This change is really messing with my muscle memory Also note that I've NOT changed my button mappings, and as it works on some objects I don't believe its a mapping issue.

This issue needs more prioritisation now that the 'dynamic spawning' essentially loads into the F10 map first, forcing VR players are into this situation.

Hey, Would be really good if we can improve the interface with an F10 menu option to allow for the direct entry of: - Free form text - Coordinates (multiple / specific formats) My scenario is: Scouting a location and want to pass on coordinates to an AI group to engage. At the moment you need to use something like mark points + map to work, which is both cumbersome and immersion breaking An ideal option would be to provide a scripting function which when called would display an on screen keyboard (to allow functionality to both 2D and VR setups) and return the data back to the function to be passed on.

Thanks, I had guessed but wanted to be sure. The next best thing for me would be some sort of keyboard that you can use with the F10 menu option so you can just type the coords in and send. Oh well..

Hey all, Is there anyway I can get the coords of the player lased target? For example: I'm in the KW scouting a location and I want to relay coords to an AI artillery in waiting to fire on my target. I want to be able to lase the target and be able to relay that target location information to the AI. Obviously if the artillery was a human I'd be able to do this over comms and just tell them the coords directly and they would input them at their end and job is done, but with an AI it seems very tricky to be fully dynamic (ie, no preplanned locations) The easiest way would be to directly grab the current lased target location info and pass it on to the AI group to do its thing. I've tried other approaches like having to type in the coords via the F10 menu (which takes AGES) and using target / mark points, but I want to avoid using the F10 map if possible (to preserve that precious immersion ) Thanks in advance

I'd check the obvious thing like num lock, or change the num key to something else in the toolkit just incase it doesn't register those keys for some reason. I use the arrow keys since they are easy to 'feel' for on the keyboard. The fact that the XR toolkit menu shows means that its running, so you just need to find a key combination that works in DCS

Any update on Steam pre-orders? I want to get the module but it sounds like I'd miss any pre-order discount since its on Steam..?

Out of interest could you share your DCS graphics settings? I have a similar rig, except its a 3080 instead of a 3090 and I'm getting around 45 fps in the AH-64 (which I am mostly happy with btw). Thanks!

I had something similar since the new version, but its something that seems to be a consistent issue with DCS in VR that I generally learn to live with. I did delete the shader cache files which seemed to help, worth a shot: "C:\Users\Username\Saved Games\DCS.openbeta" fxo and metashaders2 folders.

Same here in the AH-64. Both during the day and night. Very distracting in VR!

Yeah I'd also like to know what the difference between 'set' and 'toggle'. For me they seem to do the same thing?

Same here. No significant change to performance one way or the other, but I get the CPU bound message when my CPU is at ~20% and GPU at 100% Not sure if its just an incorrectly reported bottleneck or its not utilising the CPU cores as well as it could.