Hippo

There is already a set of bindings for this sort of thing. I use them for the radio menus and for the ESC menu (although, for some reason the "Command Menu Select Item" doesn't work in the ESC menu, but <space>, which I have set to "Weapon Fire", does work to select). Very handy, especially in VR, as I can navigate (almost) all menu selections from my HOTAS. Why ED didn't apply these bindings to the parking menu I don't know, it would have seemed pretty logical to me. They work in mysterious ways.

I'm afraid I somehow managed to miss that this was mentioned in a newsletter, and I apologise for that. Still, I think something this consequential should have been explicitly mentioned in the patch notes. Had it been, I wouldn't even have started this thread. But, then, what exactly is going on here? On the surface it would appear that all that should be needed is to simply disable the deck crew for non-SC owners. That this wasn't done would suggest that maybe things aren't quite so simple? How much time is being spent on having to develop what are in practice two different products? Whilst I bought the SC years ago, and with regard to several comments made here, I think there are many valid arguments that can be made against having to buy it, and certainly wouldn't dream of telling people how they should spend their hard-earned cash. Personal lesson learned? Don't ever create missions using the Stennis again. I suppose that for dedicated mission creators who would like to support the widest user base possible, this sort of thing will remain a considerable inconvenience.

Does missing the newsletter absolve someone from missing the point?

The "feature" that is being discussed in this thread is that there is no deck crew whatsoever on the Stennis. I suspect that this is not the feature you are "very impressed" with. Might I suggest you start a new thread if you wish to heap praise upon another feature, as per the forum rules: BTW, I am very pleased for you that you are enjoying the new deck crew. On a carrier that isn't the Stennis, obvs.

You should probably work on your lack of patience, it would save everyone having to read a post that is of no relevance to the points that were raised.

I just checked and I'm not seeing the "backwards" lights either, i.e. I can definitely see the iflols datum green lights from the stern. However, I don't see the ball yellow light (from either side), and unless I'm virtually over the carrier all the lights are way too dim or just not visible as I stated earlier. Surely all the lights should be clearly visible when asked to call the ball? They're not. Will try to provide a track later when I have more time. I'm using the Stennis. Thanks for your time and patience.

Thank you. So hopefully just a simple recently introduced bug that can be fixed quickly? I hadn't flown these carrier night missions for some time and was just trying out the new update features.

This is what I can see at 0.8 (I'm asked to call the ball at this point) and 0.3. See also link. I am running at 4k on a 43 inch monitor.

Understood. On your side, please try to understand that some users might have painstakingly created numerous missions so that they can practise every stage of carrier ops and that it's a bit of a let down when a major new feature like this arrives and they excitedly load up those missions to find... an empty carrier. At the very least it should have occurred to someone to mention this "issue that needs tweaking" in the patch notes.

I wish ED would just admit that the Supercarrier should always have been part of the core product and would now just include it for free (I bought it years ago, btw); otherwise we'll just continue to have more nonsense like this going forward. I would be more than happy to pay $50 - $100 every couple of years for the core DCS product so that efforts were concentrated on improving that.

A feature not a bug, then. Yippee ki-yay. Because there's nothing I like more than having to go and edit over twenty missions that now don't work as expected thanks to an update. I was really looking forward to this update and it's turning out to be an elephant-sized dropping of a disappointment.

Entirely agree. I have a night carrier landing mission I made years ago when fog worked properly, it was great: just before the ball call the carrier lights would appear out of the fog beautifully, it all worked wonderfully. Fast forward to today. Supposedly we have fog again, so I load up the mission... to find that the lights on the carrier can hardly be seen even on a clear night. Is this a recent change? I don't remember it ever being this bad. Too often DCS is just depressing, improve one thing, and something else FAQs up...

Is it just me or has the deck crew disappeared from the Stennis following the deck crew update?

Might I be so bold as to request that, when making changes such as this, a full explanation is provided in, at least, the change log? Something more substantial than "VR. Added options for Quad View to VR settings"? It's what a professional outfit with an eye to detail and customer satrisfaction would do. Or maybe provide an on-line version of the manual which is kept fully up to date with live changes? See also: fuses.

That was it! Thank you so much. I forgot that there are quite the number of steps necessary to get this working when I replaced my PC and reinstalled everything.

Has anyone else experienced this? It never used to happen to me before. What happens is that a small section along the bottom of my view always remains blurry no matter how far down I look with my eyes - as if the foveated region won't go all the way down. This only happens when using Link, it all works fine if using Virtual Desktop. I can't say for certain but I think it might be that the config file in %localappdata%\Quad-Views-Foveated is not being read. Supplemental question: I notice there are quad views foveated rendering options in the settings within DCS itself. Does anyone know if these have been documented by ED?

null

Whilst I am very grateful for DCS, ihmo it has become a pyramid scheme focused on releasing module after module to bring in funds; how else to explain many, many reasonable requests for essential features and functionality, like yours, being ignored for years?

This might get looked at in five years' time, but only after the launcher gets animated cows. Because... priorities.

You're probably not going to like this answer, but you might consider getting Virtual Desktop and giving that a try. No, it's not necessary, and it's not free, but It's another option available to you for when you suddenly get new, unexplicable issues in DCS VR following an update (as I have had happen to me in the past) or a change in phase of the Moon. And It has an option to lock ASW on.

Saw this launcher, disabled it immediately and hope to never see it again. Then wondered to myself why it is that with so much essential stuff that has needed doing for years waiting to be done, ED would waste expend time and effort providing something that was neither needed or wanted. (Imho)

Another vote for the Quest Pro from me. I don't know where you are but at this price it's an absolute bargain.

I've been having variations on this issue for months now. It's doing my head in. I've just updated my original post: Common factor 13900k / 14900k ?

Back in October when I first posted about this, I tried using Virtual Desktop instead of Oculus and at the time it seemed as if VD didn't have the issue. Because of <reasons> I shortly afterwards took a break from DCS, until now. I've been using the Apache with VD for over a week, and I'm now getting a very similar issue again. Start up DCS and (around 75% of the time) the PC will lock up, in DCS I will either see a black screen, or when I get to the main menu pauses that last 1-2 seconds during which the PC is unresponsive. As suggested above (thanks to all replies) I can eventually get back control by alt-tabbing out and turning off affinity for core 9 (first core = core 0) in task manager. The issue only appears to manifest in the interface screens (never in cockpit) Sorry to sound like a bit of a git, but this is really an extremely frustrating issue, which I'm rather surprised isn't affecting more people. I'm as sure as I can be it's not my PC, I don't get issues with any other games or software, just DCS. Looking at the replies on here, it seems that all who have also seen the issue seem to have i9-13900k CPUs. Have DCS testers checked if they can duplicate this issue with this CPU? It seems to me that all is not quite right with multithreaded DCS.

Thank you for bringing up @recoilfx 's (and recoilfx for making it) comment. I did some more (quick and limited) testing and perhaps the increase in performance from QVFR wasn't as great as I first thought. I tested with DLAA + QVFR, DLAA only, and MSAAx4 only, with these settings and mission (up to end of first turn) and see the results below. Only with QVFR can I maintain 72 fps throughout. The GPU util is visibly lower with QVFR, but not by as much as I was expecting. I can't hit 72 fps at all with MSAAx4. CPU core 28 (and perhaps 11 and 12) is visibly busier with QVFR. Core 9 or 10 is usually the main(? most busy) core. There is no shimmering with DLAA, whereas it is quite visible and distracting with MSAA, including flickering ground shadows. @recoilfx I'd be interested if you could point me to a mission and settings where you see worse performance with QVFR vs no QVFR.