Hippo

Thank you for your post, all very interesting and sensible. Wrt to the above, if I'm understanding you correctly, you're setting your QP / PCL at a lower res in its software, but then running at a higher resolution (at least as high as the headset's recommended for barrel distortion correction) in the foveated area? If so, I didn't think to try that, and didn't even know if it was possible. I'm currently running a lower spec PC and will give it a go - thanks. If you can spare the time, it's always interesting to know hw spec + settings + fps obtained for the types of mission you normally run.

No worries, only kidding. 1. I sold the PC in my sig. a few months ago. 2. My testing was limited to missions like that uploaded in the linked post. 3. I attempt to hold 72 fps (no ASW) and try to get just below 100% gpu util with a demanding mission such as (2), so that I can have plenty of headroom for more normal loads. Bearing (1), (2), (3) in mind: 3080Ti, i7 8700k -> i9 13900k - no benefit whatsoever that I could discern. 13900k, 3080Ti -> 4090 - major benefit. There was no way I could hold 72 fps in the mission with those settings (see linked post) until I got the 4090, the gpu util would always hit 100% and ASW would kick in. I found that if I wanted 72 fps on a mission like that in the link, with those settings, I needed a 4090. I don't know how people with, say, a Crystal Light (or eventually Super!) or similar higher res headsets can run without reprojection or lowering rendering resolution from optimal. I was running QP at 5408 x 2736, PCS is 12840 x 7412 at 100%. If, as is very likely, I'm missing something, I'd be very grateful to be informed by the knowledgeable folks on here.

You presume incorrectly sir/ madam: I do use QVFR and will not consider a headset without eye-tracking; if you're interested to see how I tested and my settings, you might consider clicking on the link in my previous post.

I see that this appears to be the general consensus on here, but how are people coming to this conclusion? I would say the opposite: I find that it is the GPU that maxes out when I try (tried - I sold my PC a few months ago) to hold 72 fps with my Quest Pro / 4090 / 13900k, high VR rendering resolution and in-game graphical complexity. I would have chosen to upgrade the GPU rather than the CPU, and going 3080Ti -> 4090 was a substantial improvement. I do tend to run single player missions with not much going on, and test that way, so maybe that's it? Unfortunately it doesn't seem that the 4090 -> 5090 uplift in rasterisation performance is going to be particularly substantial. I did manage to sell my 4090 for around 80% of what I paid for it. If a reasonable price can be obtained for the 4090 then the (supposed) improvements in upscaling quality and performance could make it worthwhile. I'm looking forward to seeing the results of real world DCS VR testing.

Yes, I'm aware, although I can see why the way I phrased my 3rd question might have made it seem like I wasn't. What I really meant was "what would happen if reprojection and MFG were enabled at the same time"? With my 4090 I found that I didn't use frame generation for any "normal games" as I didn't need it. In VR, no games that I'm aware of seem to use it. I guess what I'm getting at is, supposing we ignore reprojection, shouldn't this tech enable games to be rendered to a VR headset at many multiples of traditional rendering fps? What it would look like wrt artifacting, etc, is another question, but shouldn't it at least work? Are there any VR games out there that support it? Again, care to expand? From a quick Google found this: Is it only because of latency?

Thanks for replying. Care to expand on that?

Would this feature make it possible to get high enough frame rates in VR so as not to require reprojection? Is this a feature that requires DCS native in-game support? If so, does ED intend to support it? Can such a feature be enabled at the same time as reprojection?

I've only just noticed that I can be in e.g. the triggers editing screen with a trigger in the list highlighted and that if I type a letter e.g. "S" it takes me out of that section and takes me to ship placement!!! I think that before my original request can even be considered the whole mission editor needs a complete redesign to bring it into line with basic GUI standards that have been around for decades. I'm sorry if as a ME dabbler I'm preaching to the ME veteran choir. I'd better stop there as I can feel my blood pressure starting to rise.

As is standard on most GUIs, it would be extremely useful if when a drop down list is highlighted the user were able to start typing the required entry to get to it quickly. Since some lists can contain tens (or even hundreds) of entries it can be extremely time consuming to have to use the mouse wheel or scroll bar to find the entry the user is looking for. Also, the ability to use the TAB key to step between fields would be extremely useful too. Please. Thank you. P.S. For the love of all that is holy, UNDO functionality please.

See attached track, it's only when I'm around 2.2 nm from the Shilka that I get a warning on the RWR. According to this page, Shouldn't it be showing up on the RWR from further away? shilka.trk

I apologise to all as I'm obviously not explaining myself clearly. I would like to able to see the tracer during the day from, e.g. 10 nm away as in the attached mission, as can be seen in the dawn (1st) screenshot. It's only for effect and to add atmosphere to a mission. The tracer is not visible at all to me from the same distance during the day (2nd screenshot). I agree that I can see the tracers when I'm directly over the AAA, but that's not what I'm asking. EDIT: using "SPAAA ZSU-23-4 Shilka Gun Dish" instead of "aaa zu-23 emplacement", I can see the AAA but it's still extremely faint. I wish it could be much brighter and easier to see, but not if it's unrealistic.

Well, I suppose it might be my eyesight, but I definitely can't. Same mission at the same point, but different time of day, tracers easily visible at dawn, but I can't see them at all during the day.

I am setting up some AAA in a mission just for visual effect, so several "aaa zu-23 emplacement" around a mission target with fire at point set to trigger when an aircraft gets within around 10 nm. If the mission is at night / dusk / dawn then I get just the effect I want, with the tracer fire easily visible from around 10 nm away. However, during the day I can only see the tracers when I'm pretty much over the target. It would be very nice if the tracers were just as visible during the day; I admit I have no idea how realistic or not this would be. aaa_test_01.miz

What people are willing to accept in terms of fps in VR varies hugely. For example, I'm not prepared to accept running continually with reprojection, so want to hold a true 72 fps at optimal render resolution on my Quest Pro, and I have to turn down DCS settings to achieve this with a 4090 / 13900k with quad views foveated rendering (strictly speaking had, I'm currently running a lower spec rig). So, for me, the answer to your question would be a no for the Light, and no *!*! way for the Super. Other people appear to be prepared to accept frame rates of 30 fps (with reprojection) for the sake of the visuals, so they might be ok with the Super. For me a lot of the load comes from having to run AA as I can't bear the jaggies and shimmering without it. The Pimax chap suggested (on YT, iirc) that with the Super's very high resolution AA won't be necessary; I am Super-sceptical regarding this assertion, however, were it to be valid it would help enormously with performance.

Did you mean WFTL? When Flying Too Low?

Whilst I dare not disagree, I would humbly suggest that having to do it at the start of every mission can get a bit old. Anyway, isn't the ability to crush a bug in DCS insignifcant next to the power of the Force? Thank you for your time and patience, I look forward to the forthcoming improvements you mentioned.

I expect that you will find my lack of faith disturbing, but my point about the BIT advisory showing up is that it would have been cleared by the pilot by the time these stages of a sortie were reached. No? I would've thought they're handled in a similar to way to a caution: acknowledge/ resolve then clear.

When a mission is started in flight or at takeoff, the BIT and P/INS advisories appear. This behaviour is not correct as they would have been cleared by the pilot before these stages of a sortie were reached. The BIT advisory bug has been there for ever and I've had to put in triggers in my missions to clear it at mission start. More recently, the P/INS advisory bug has been introduced and it is necessary to turn the INS selector every time I start a mission. This, in the realm of first world problems, is extremely irritating. I'd be really grateful if this could be fixed.

I sometimes find ED's choices bewildering to the point of intense frustration. They have provided the deck crew parking with its menu; I am immensely impressed with and grateful for what has been achieved, but how can it not have ocurred to someone to think, "hang on a minute, if the ESC menu can be controlled with keystrokes / bindings shouldn't it be possible to do the same thing with this little parking menu, y'know for interface consistency?" Considering the amount of time and effort that must have been spent on the deck crew, I think it would've been pretty trivial to include control bindings for the menu. Sadly, ED do this sort of thing a lot. I'll be off to the F-18 wish list forum later to ask for another minor irritation which was introduced a few months ago, and should not have been, to be removed. Or maybe even the bug forum if I'm feeling particularly rebellious. Round and round we go.

My guess is he means these. I haven't tried them so can't comment.

ME

Not a big deal as I can get around it by zooming in until there is separation, but it seems like odd behaviour. I notice that if I place a unit icon (I was using an il-76) or its waypoint over the threat circle (yellow) ring of a ground unit (I was using an SA-10 group), the unit icon or waypoint becomes unselectable. Is this intentional? Or maybe I'm doing something wrong? In the image, I'm unable to select WP3 or WP0 (by clicking on them with the mouse, and so am unable to move them).

Uh-oh. It's very possible I might be wrong about that. I happen to use the arrow keys for those commands and use TARGET to program my Warthog to send keypresses (I don't bind buttons). It's possible that using the arrow keys might be the reason this works for the ESC menu and I just got very lucky with my choice of key bindings. I haven't tested. Sorry for any confusion. If the bindings don't work in the ESC menu, then they probably should. If it is the arrow keys and space that make this possible then perhaps the same control combo could be used for the parking menu. I didn't realise they had that dual functionality, thanks for mentioning that, very useful.