nilpointer

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