RafaPolit

Thanks, yeah, makes sense. I was thinking the same thing, but 1.3 on the ODT gave me just a tad under-resolution to what I'm used to in VD in ultra with whatever sharpening algorithms they use. Running 1.2 and 1.2 on both gave me closer to what I am used to and it's starting to "saturate" the max 72Fps. If I put 1.3 x 1.3 I'm probably going to start a fire either inside my PC or in my eyes, so I'd probably avoid that.

These are the settings that are, currently, working decently good: I have a Ryzen 5900X, 3080Ti, and 64GB of DDR4, DCS running on dedicated NVME. I'm still tweaking things, so, if you have suggestions, counter ideas, anything, all is welcome.

Thanks, actually all these help a lot. Maybe I am playing with too many variables. It may be a good idea to remove some moving parts. I disabled OXRTC, it seems to get a little more jerky. Also, What I would IDEALLY want is to have all settings "identical" in OXRTC and DCS so as to "swap" between VD and Link, and just adjust the parameters locally on the others. That way, I only need to remember "two sets of settings". One for VD and one for Link, and not a combination of: when in VD then OXRTC with these values and DCS with these others, but when on Link I have to change this and that here and there. So, it's looking a bit better at this point, which is fantastic. Thanks so much for the help. Quick additional question: Pixel Density (ODT) vs Render Resolution (in Link app)... are they the same? Should I set BOTH? Do you prefer to tinker in one over the other? As I see it PD seems to be doing some oversampling while keeping the resolution, but I may be wrong? Thanks for any insight.

Thanks, found the "Use Air Link", it's disabled, yes. I don't have OTT, I'm using the Debug tool, as OTT says it has problems with W11. But I think that I can, at least, confirm I have a valid configuration system as I can modify the FOV and present the HUD overlay, etc. I'm going to run the Pixel multiplier from the Oculus App (with the slider) putting it a 70Hz and 1.2x which gives, roughly, the same resolution that kablaboman reported earlier.

These help, thanks a lot. I'll first need to ensure that my changes in the Oculus Debug Tool are actually making changes at all, as yesterday I set up the FOV to 0.3 x 0.3 and still could see the entire screen of FOV. So something is not right. After that, I'll look into the settings, albeit some of them are "not possible" in the Debug Tool, mainly that Encode Resolution. As to your questions: 1. Yes, official cable, I get 2.4 on the speed test, so yeah, perfectly fine (I think! ) 2. That is a good hint, no idea where in the Launch window will that reside, but I'll make sure. I know I did try the Quest Air Link at one point, but quickly moved away from it. Another annoyance I have is that the PC never detects the Quest 3 if I attach the cable to the Quest while already connected to the PC. For some inexplicable reason, it only works when I have it previously attached to the headset and I connect the PC end afterwards. I makes no sense to me and sounds more like Voodoo than it does science, but it's perfectly consistent for me. No idea why, but makes it hard to go fishing behind the PC every time I want to connect the headset. Thanks again for the feedback, I'll keep on reporting my progresses (or lack of in this case )

Thanks! Yeah, I'm in contact with them regarding the problems with VD, I just wanted to mention this here to avoid suggestions like: "just use VD!", which I would agree myself, but it's "a work in progress". They are replying in the support discord for the Beta version (which is the one I'm using), but veeeeerrrrrryyyyy slowly. Thanks for the resolutions.

Good evening friends. I have been playing VR for a while now, always using Virtual Desktop for the Quest 3. Up until recently, this worked really nice, but as of 5 days ago I get screen freezes on the Headset (while the game inside the PC still runs perfectly normal). I'm trying to resolve the issue with VD support, but it is coming slow (read here, almost no replies or help whatsoever). In the meantime, I have been trying to switch to Cable Link for a "better" experience... and it has proven all but smooth (or working at all!). I've seen many videos on the subject, each broadcaster claiming better results than the other and almost all giving contradicting advice, so it's hard to have some solid feedback. Here are my goals and where I'm failing: 1. Resolution I have DCS VR multiplier set to 1, I would like to first stablish my base resolution. With VD I set it to Ultra (I used Godlike before), and the in-game sharpness / resolution is UNMATCHED by anything I can setup in Meta Quest Link + OculusDebugTool with even slower framerates. What would be the equivalent resolution to VD "Ultra" on Meta Quest Link? As a side note, Meta Quest Link appears to be working, for some reason changing the values on the OculusDebugTool.exe (which I'm sure worked at some point), now seem to take no effect. I'm running it as admin and restarting the service after changing values, but I have been unable to make changes from the tool. Oculus Tray Tool seems really old and not updated, plus it says has issues with W11... is anyone still using this? What are my alternatives? 2. Weird "frame ghosting" effect With Quest Link cable connected, I have an issue where, at one point during the first few minutes of streaming the game, one or both eyes would enter a "laggy" status. It kind of looks that the frames render 2 or 3 at a time and they are all presented simultaneously. So, if I move my head kind of quickly, a particular know will actually show itself in three consecutive locations simultaneously.... but FPS seems to be 3 times slower, although the metrics don't show this condition as true. The weird thing is that, when I thig bug finally occurs, if I close the game and return to the "grid world" of the Quest Link software, I STILL have that issue on the eye (or eyes) where this phenomenon was present during game. It is never triggered outside the game, but it survives the game closing and it perdures as long as I don't close the Quest Link app on the headset. As soon as I do, and I return to the app, movement is "smooth" until I get back into the game and into a plane, and the problem begins anew. Maybe this is sliced encoding, or something similar... I believe I have reprojection disabled, but, again, I have this feeling that OculusDebugTool is not having any effect, so I would like some pointers to help figure that out as well. These are my two main problems at this point, I'd appreciate all the help I can get, or pointers to where to read or videos to watch. Thanks in advance, best regards, Rafa.

Yeah, for that VERY particular example, it works if you do it reversed, but since it's not the "right" way to do it, the notion makes sense (and is probably true for other scenarios, not that just one in particular)

Well, people can do their jobs in a manner that upsets frustrated customers even further (I have had this problem several times here in these forums) or they can do it graciously and being extra helpful and patient. Given the amount of vocal people in this community that would complaint for everything, think they are entitled to everything and that fixes should happen NOW... I still believe thanks are in order here, even if the person helping out is being paid to do so.

After a few hours just "battling" with the Jester UI in VR and the new paradigm model, I'm warming up to the process. It's a learning curve. Still, there are things that are done in "sequence", that are useful: - Connect Air to Engine - Move the switch to ON - Start air flow The problem, to me, resides in the fact that interacting with the cockpit is not possible while the wheel is open. So you have to close it, reopen it (luckily it stays within the context of what you were doing), but if you have a "clear" area not selecting anything with the mouse, why is interacting with the cockpit not an option when the wheel is open? I understand not allowing the mouse to click something in the same spot as a wheel item, but maybe there is a middle ground here? (This is happening in VR, not sure it's affecting the non-vr gameplay)

Yeah, well, at this point, even more essential is to get the devs back into developing the model... but yeah, would still be nice to have.

For those having issues, I want to stress that Zabuzard's fix of: Selecting checkbox under VR of "use DCS resolution".... basically works, with a very important BUT: the size of the window or "boundary" if you will that allows the wheel to render is then commanded by the 2D size of the Screen Resolution configured in the main settings tab. If you have opted, like me, to go as low as possible because you are using VDXR or SteamVR or whatever other process, then this will render a really small boundary that, still, cannot accommodate the wheel. So, what did work for me was to set the 2D screen resolution to 1920x1080, which now fits the wheel + manual, and not modify the UI numbers or offset, leave them in default. Lower resolutions to that still clipped it for me unless I started tweaking with the manual UI numbers, and then it gets pixelated and off-center very easily. Hope this helps. Thanks Zabuzard for sticking in with us.

Have you changed the RESOLUTION of the 2D screen (main settings pane) to something like 1920x1080 or so? VR users usually have that set to "as small as possible" for Headsets that use USB or WiFi connections, and that is messing up with the display. With that and no UI resolution settings (+ the check that Zabuzard mentioned) did it for me for the time being.

Ok, I did more testing... this is "almost" true... the problem is that: you still need a certain minimum resolution set to the 2D window (which, for everything else, you don't) So, if you have set your window to 1200x800 or something really low to save on resources, the wheel will still be cut-off. So there is a "minimum" screen resolution, which means you are still relying on fixed sizes and pixels available, instead of rendering "inside" that container.

ps. To "see" the boundary box, you can bring up the manual and drag it around. See it "disappear" at certain points.

This doesn't really solve the problem, or we are lacking some controls. I described the "additional" problems this brings in a different topic, as it appears to be a different thing: https://forum.dcs.world/topic/349241-vr-boundary-in-which-jester-wheel-and-manual-get-rendered-is-fixed-in-3d-space-and-size/?do=getNewComment

The Jester Wheel is giving a lot of issues in the first few hours for VR pilots. When many are concentrating in the Wheel, I believe the problem resides elsewhere: - The container window that can display the wheel, map and scratchpad, has a fixed size in 3d space - This window spans, in my setup, from around 45° left-of-center, to 10° right-of-center. It also goes really high up (maybe 45° of elevation) to an (in my opinion almost useless) 0° of elevation. This means that the window takes NO ADVANTAGE of anything below the horizon, making for a very small area to render - The HB offset, instead of displacing the offsetted boundary, displaces the INTERNAL components inside: so, the wheel is offset, yes, the manual is as well, but the rendering limit is soon reached and things start disappearing behind the boundary very fast - The UI Resolution configurable in the Special area is very unintuitive... it appears to be a combination of size plus aspect, which makes it impossible to tweak. In theory, for a particular height, increasing the width should keep the same rendering global size, but move the items to the left... but it's not behaving like that. - Also, the rendering resolution, in VR, inside that window, is absurdly low and text is rendered very poorly, which compounded with the font decision (which is really difficult to read, not sure what was the reasoning behind that), makes for a difficult to read text - Also, the option to render the Wheel where you opened it (as opposed to centered) is not respected AT ALL in VR - Calibrating all this by having to quit the mission and reopen it, makes for a SNAIL SLOWWWWW process. One tweak, two or three minutes to enter the plane to see it wasn't perfect, rinse and repeat. And that is for the wheel and its internal radial boxes... the questions from JESTER, which are rendered UNDERNEATH all this, need to actually get to an INS Alignment, taxying to be able to see if it actually fit. As "hunches"... - not sure if something here is feeding from the actual screen-size of the main config, which, in VR, has nothing to do with the size of the rendered window? - Maybe if the offsetting actually moved the "container" or "boundary" instead of offsetting the content (or have both?) could aleviate this issue, as well as providing identical controls for vertical positioning? - Why is this window prevented from rendering further down, wasting almost 50% of the available field of view of the pilot? Thanks for this marvelous module that flies beautifully... but this window is a really pain point at this point. Best regards, Rafa.

There is definitely an issue, Iron Mike has posted this in the HB developer shoutouts channel: Still, this doesn't really work. The controls are all but intuitive, the "window" where this items can get rendered is "fixed" in the world, and the HB offset only moves the ITEMS inside the container, which, when centered, make the manual an other items disappear. The 'container' (the area where this overlaid layers can be rendered) is, for me (Quest 3 with VD a Ultra and DCS VR multiplier at 1) is considerably offset to the left. You can see this by dragging the manual around and seeing where it "stops" rendering and disappears behind this boundary (which I'm calling window). When setting the manual resolution to around 1100 x 800, I get the round wheel PLUS (and this is important, because they were originally not rendering) the ADDITIONAL QUESTIONS that Jester makes like Alignment and Flight Height, Fuel status, etc. Once this is offset around 300px to the right, I get the wheel centered, but the manual is now clipped by default and needs to be repositioned. My biggest complaint is... Why is this "container" or "boundary" positioned like that and why does it have this "fixed" size which makes no sense and renders the content very poorly (no where near the capabilities of the headset). It also ends almost at the top level of the radar window, which sub-utilices almost half of the available field of view. It has been a very, very frustrating few hours just battling with this. Once in the air, the F4 is a dream to fly and feels like a "real airplane". The Jester wheel and manual placement needs almost rewriting for the ground up, in my opinon.

The repetition of the (custom A key) upon "seeing" with your head to an item does work. Everything else about the wheel: the degrees of turn, the disappearing boxes, the poor resolution, all are problems... but clicking again that button does seem to work. And the long press to close the wheel is a welcome UI change.

If you see the OP picture, 22K is high enough for fusing, and the F-16 is really not that great any higher than that, so I'm assuming this is not the case here.

I think it's more difficult to understand since the only possible part, as of first access, would be the southern one. So both purchasers of the "smaller" package and the "whole" package would get the same thing upon release, which makes it difficult to understand. Once the three areas are out, it would make more sense: I want to buy just area A, or just area B, or C, or all the areas. And, if you buy one and then want to expand, you can always do it, but it will cost more than purchasing the entire thing. Where I do agree it's even more confusing is that the price difference from one area to the whole package is not that significant, so going for the larger one at this point in time seems to be the no-brainer option. Which is probably the intended outcome from ED as well, which is also a good thing.

Happened to me today, with a GBU-12 and with the Laser not armed. Maybe that is something that could 'trigger' the LOW?

Thanks for this. The problem is that, if you jump ahead, then the Tanker is no longer reachable through the F6 menu, and, as you egress, you can no longer contact it, so now you need to restart the mission and start at RTB, instead of moving forward normally. Also, I did a take where I just moved forward and reached the carrier with what I had at optimum range, but now nothing happens between WP7 and 8, you don't hear the hilarious situation with Saint and the field (which is a masterpiece, I have never laughed out loud on a mission before), so there are more complexities around jumping ahead than meets the eye. I have had other issues like the Tanker just heading back RTB on the first refuel jump, after the friendlies depart him, he just turned south and I had to refuel while backtracking all I had already moved forward, no idea what caused that, that was a textbook "right" approach. But that's maybe for another report. At any rate, it's a great mission which is probably hard to cover all the cases. Thanks.

There's one additional thing that has worked for me now at least two times: If you move south-to-north, entering from the friendlies post and exiting town through the smoke of the JDAMed complex, and you do it right down the deck at 100ft or 150ft above the ground (this is, literally, at rooftop level) - and at mach > 1.0 although I haven't tested it slower - then the SAM does not fire, you don't get SMOKE's warning, you don't reply with "sh*t, that guy just shot a SAM at me", but as you egress to the north and climb up, you are called to the awareness of the car moving west, and all seems to advance as expected.

Thanks for the answer. No hurry at all, I hope you and your family all well and that the issues were not serious. So, I did disable easy comms for good for my entire DCS experience, I think I'm now to the point where that makes sense. And it works "mostly" as expected, but the first call on Radio 1 and Radio 2 comms check are wrong. Radio 1 comms check is made through radio 2 with a reply "check", and Radio 2 comms check channels through radio 1 with no reply from smoke.