RafaPolit

It still doesn't allow you to interact with the screens in any way that I have found.

I was coming to report the same problem. I have not tried Jeremy's approach of entering VR with the flatscreen mode. Seems really unintuitive and probably the sign that something else is wrong, so this is probably still a bug to report.

I agree I'm not the owner. He, however, owns the module. Buying the upgrade must, definitely, apply for the discount. The fact that I'm buying it instead of him should make no difference if HE is already the owner of the module. That's why I mentioned that me having bought the original gift should not be relevant to the equation. Since this is the Customer Support forum, I thought that that is what I was doing!

I believe that this scenario is a "the highest discount is applied", not a "compound" discount system. If the modules where at full price, you would get the 10% discount from GS. Since the modules you have picked are 40% and 30% off, you get the "highest" discount between 10% and 30% or 40%. It's not "10% on top of what you already had".

Did you update DCS? Now it goes through a separate launch screen and all, where you get the chance to download the new modules / purchases.

Good afternoon. I previously bought, as a gift, FC3 for my nephew. I want to upgrade his subscription to FC 2024, yet, when I try the add-as-gift option, I am invoiced the full amount of the package, not taking into account that the target account already has the license which will entitle them to the discount (without even taking into account that the person that did the original purchase was also me, which shouldn't be relevant). How can we resolve this? Thanks.

Just to fully understand: is the VBR function / radar NOT WORKING? Or is it that it was at one point in time enhanced and then it reverted to the F-15 one? I'm trying to add this mod to a mission for my nephew to fly (as he doesn't have any full fidelity modules and this one is a nice "in between" in terms of cockpit interaction), but in my initial tests I was flying head on for 50 miles with a mig-21 and didn't get anything on my radar correctly aimed and the height correctly set. Thanks for any insight.

Currently, the visibility of objects is determined by distance to aircraft, regardless of the resolving level of the watching medium. While hiding (or lowering the LOD) a tree located 10 miles away is perfectly correct for viewing out the window, while watching through the Lantrin or Litening or Atflir POD should consider the higher resolving capacity of the gadget and render the objects as if the plane was much closer. This produces advantages and disadvantages that may affect gameplay negatively: - for spotting far objects, it really makes it a lot easier if there are no trees to occlude the objects, which gives an unfair advantage to those looking through the pod against those trying to mask their location with tress or similar objects - conversely, if you are planning an attack and drop a stand-off weapon on such enemy, it could very well be that the item is inside a forest and you wasted the amo hitting a tree that you never saw existed! And no, these two scenarios do not compensate each other, they just create frustrations on both sides of the coin, so the rendering on the on-board CCDs should better mimic the behavior of longer reach with higher resolving (resolution) capabilities. Thanks, Rafa.

This seems to be the sweet spot for me at this point, having the Link app at 1.0x: I have two items that I am on the fence about: - Any advice on Sliced Encoding? - Any advice on Adaptive GPU Performance Scale? Other than those, I am more or less happy with this and having DCS with DLSS Quality. This matches my VD settings, which I am happy about. Some planes / helos can do without DLSS and only DLAA, the Apache is particularly harsh and I can even go for DLSS Performance. So I have that setting to play with. Seems like a good balance. I really like to thank you guys for providing guidance and feedback. Best regards, Rafa.

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