nilpointer

I'm wondering (as I've not found another reference) if the behavior of the in-cockpit controls with SRS is a known issue? Counter intuitively the INT (VOIP) mapping works as one would expect with SRS by keying the INT mike when it is not in Hotmic mode, however the COMM PTT (VOIP) mapping does nothing and instead the Stick PTT mapping is used to key the SRS mic for whichever radio is selected, the main issue being that it also triggers the comms menu at the same time. Any tips or is this to be fixed?

Does anyone else also jump into read these threads and just wonder how civilization hasn't collapsed already? I mean I'm guilty of the odd (private) meltdown because my favourite video game sometimes doesn't work as well as I might like all the time (which is just the nature of software development) .... but you know this really is all such low stakes, imagine for a moment all the other things you can fill your time with while you wait. I know there are a million other things I'd rather do than pretend I can possibly understand the complexities of a situation without anything like a full picture or a specialization in contract law. Plenty of other aircraft to pass the time or just go and breathe some fresh air and stare at the sky

Appreciate all the informative replies here from @mbucchia and @actually_fred For me this is close to a final nail in the coffin of DCS, it’s sad to hear how unimportant this is.

Unless I'm missing something, which I'm confident I'm not an even bigger ticking time bomb is that foveated rendering and eye tracking are not natively implemented by DCS. Not only have the many users of supporting headsets become reliant on @mbucchia to provide the high level of goodwill he already has, but should there ever be some additional change that renders QVF unusable we're back at square one. I love DCS but have also grown weary of the dice roll of it working between patches on the thousands upon thousands of dollars of hardware.

I have seen a number of posts that seem related but as yet I cannot seem to find a definitive answer. The throttle cutoff special options seem intended for throttles with an IDLE detent. I have a CM3 which as others have said allows 0% to be set on the detent and button bindings behind. The issue here is that by having 0% at the detent the throttle is actually perpetually in cutoff when the special option is set to the lowest setting of 3%. To try and avoid this I used the virpil configuration software to set the detent to 3% however at this detent the engine RPM is now just sufficiently enough above the 0% throttle setting (in jet is around 73/74% RPM) to make landing significantly harder to slow the jet down using the "by the book" technique. Can someone please explain how these settings are intended to be used.

Still an issue it seems, just noticed this again taxing behind someone today.

I have a functioning fix PR for this, working with @ctytler to get it merged, but you can pull the branch and build it now to use.

@ctytler I have a small PR if you approve to fix an issue with enumerating module clickable data with unpack. I did get a little carried away with updating the solution though but compiled and working locally. Update to MSBuild/V2022 and clickable data collection fixes by mcphailtom · Pull Request #124 · enertial/streamdeck-dcs-interface (github.com)

Anyone else seeing this same issue? I am also getting this since the last patch, I can only assume this might be due to a change in the exports for these aircraft?

Wondering if there has been any further clarification on this one? We have noticed the same thing flying BFM sets and radar assisted trail, though it's not a "huge" issue it does seem to me (albeit a layman's view) that it would still be pragmatic to get lock warnings from the TEWS irrespective of their likelihood of being friendly.

Highly recommend also trying the new Virtual Desktop Beta (1.29.3) instead of Link

Keen to hear if you have a favourable outcome. I was previously using your KISS methodology (which I subscribe to also) for my Link setup and getting pretty ok results, but the new VD is really exceeding my expectations and I find it much simpler to use than my "mostly works" link cable setup. As an added plus I can plugin to power and eliminate the battery drain issue. It is worth noting a couple of things: - Like you I am using a 4090 - My router is 3ft from my flight setup and my PC is ethernet wired to said router as well I've spent another 2 hours since last posting just trying all of the variations of VD graphic settings with DCS settings and testing the outcomes against a few benchmark flights and I remain a little torn. With everything high + DLSS + VD Godlike I can reliably keep my 72fps through most flying conditions. The latency is up + 40ms but it's not really noticable to me. My switching down to VD Ultra and keeping DLSS I can get that latency down or go to DLAA which does improve clarity slightly, but I would already say that for me with DLSS on the clarity of MFDs on VD already exceeds that of Link. Unfortunately as is oft evidenced reading this forum there is such a wide array of setups that it is really often hard to tell what works for one may not always reliably replicate for someone else on a similar rig. I definitely am impressed though.

I too was very sceptical after trying VD last week as well for the first time. But I will back up whomever posted earlier, it is a completely different story. I reset my baseline and started up VD and it is amazing. 4090 like you, I just set Godlike and bumped the bitrate to 200 and nothing else required.

Just to second someone else's post, I just tried the new VD beta after days of attempted link tweaking... absolutely night and day.

Can someone more familiar with VD explain how this works so well. Like everyone else I have been spending days tweaking my settings to try and find something I like. I literally fired up this new VD beta, set it to Godlike and ramped all the sliders right and I open DCS to find comparitively crystal clear visuals compared to link cable, silky smooth frames and almost no visual artifacts that I can discern so far. Worth noting that I previously had reset everything to baseline and was running my Quest 3 with a 1.3PD in DCS itself on a 4090. I intentionally turned the PD back to a baseline of 1.0 before starting VD and it is an order of magnitude better already. Can I assume that the VD graphics settings adjust a PD of their own?

Response from another thread this is also being discussed:

Interesting! Thanks for the reply @mbucchia

Noticed there is also another release of QVF (1.1.3) since I removed, this will of course be worth checking as well

A completely unintuitive solution has solved a bunch of the issues I was seeing post patch this morning. I'm running a Quest 3 with 4090 and was seeing pretty consistent performance prior to the patch with settings set very high and 4x MSAA. Subjective of course but like everyone I have a few goto dense area flybys I use to test to my own taste. Prior to the Patch I was using Quad-Views-Foveated with a custom config set to 1.25 inner and 0.7 outer in fixed mode for the Quest 3. Oculus settings were basically all defaulted with a dynamic bitrate on link and ASW turned off. Pre patch I was pretty consistently maintaining 72fps with occasional dips. Post patch I updated Quad-Views-Foveated to incorporate today's fixes and tried out a variety of settings with DLSS/DLAA with very poor results. Against my better judgement I uninstalled QVF set my Oculus Desktop PD to 1.5 and turned on DLSS Quality...... I'm back to buttery smooth. It seems very counter intuitive to me, though I have no doubt there is some explanation. Wondering if @mbucchia might be able to shed light on this at some point

So I was kind of sceptical this would have an effect... and I'll be honest I have not done exactly the same but there is clearly something to this. Prior to patch I have been running the usual OpenXR Toolkit + Quad-Views-Foveated for my Quest 3. On a 4090 this was giving me a solid 72pfs (Quest 72Hz mode) without motion projection in a few areas I use to benchmark my personal experience. Post patch I was choking and stuttering with the same settings and many combinations of DLAA/DLSS etc. I did update QVF this morning to no avail. Low and behold I just removed it all and am back to buttery smooth framerate with everything cranked up. Wondering if @mbucchia has some thoughts on this?

So far for me DLAA and TAA are pretty much a tie for performance and largely indistinguishable (to me at least). DLSS is a blurry mess

By disabling Open XR do you mean OpenXR toolkit? or OpenXR itself?

100% this, he provides nothing more than thinly veiled clickbait. It's also fairly apparent from many of his videos that he just harvests "tips" and settings from others and doesn't really have much basis for the recommendations other than someone else's work. Almost every post of his has one of these hyperbolic titles asking "Is this headset *insert brand here* the new leader for flightsims"

I notice that per this original post the error still exists in the current version of the manual.

same driver. I've had this happen in the past, though I've never quite pinpointed the catalyst. Oddly enough I had already done a clean install of the same driver but that had no effect. DDU (Display Driver Uninstaller) is a very useful utility for these occasions, however it is a shame such a thing needs to exist.