Tippis

Yes it is. You see, the two are doing the exact same thing. And what you're describing, with your focus on “hardware detection” (which is not what this method does) and “presets” (which is not what's being used here) is a very different thing. It does not correspond to your conception of something massively complex matching system that takes an enormous amount of effort. You mean like the example provided, which is run on command (the “behind the scenes” mentioned is from the programmer's perspective, who doesn't have to care about the scoring system to call the functionality) and which runs a “track” (that's how you do a benchmark) and then automatically changes the settings (which is a feature found in many games). You're the one who brought up some perceived need for a track replay, remember? He was simply using your suggestion to hone in on a possible easy implementation. The point is, how you said it's never done is in actual fact how it is commonly done, to the point where, as the example shows, it's a built-in feature in many engines and does not actually require a ton of work. Your core assumptions and the conclusions you draw from this are just factually incorrect. The functionality already exists in the game. This is why you — in particular — should be very wary of relying on your assumptions. The return on QoL features is increased QoL, which helps sell products. That sounds more like a bind thing, though, as opposed to the actual game settings — since those would have to cover both since there is nothing to stop you from flying both in a single sitting. What settings are you envisioning that this would entail? I suppose, if the profiler was quick enough, it could apply “high altitude detail” vs “low altitude detail” on demand, but again, that would also run afoul of those instances where you'd want both and where you do both in the same session.

Or, if you like, an example in the wild. Again, that's not what he said, now was it? He simply quite correctly stated that your having not seen it doesn't really matter and that if if your anti-suggestion was infeasible, it could be done in other ways. And as mentioned, whether you have seen it or not doesn't really matter. Arguments from incredulity (and from ignorance) are considered fallacies for a reason.

Clearly not, since you haven't noticed the wizards some of them use. This is just you making faulty generalisations from too small a sample. That's not actually what he said, now was it? Nope. They're calculated by running a wizard that checks the performance off of a benchmark and applies settings — in bulk or individually, depending on how much effort the developer can be bothered to put into it — based off of the score. You can certainly collect data through game testing as well, but that is not the only way and it's not until pretty recently (relatively speaking) that that was even an option. Just because some games use that methodology doesn't mean all of them do — some other games do the very thing you claim they don't, and your argument from incredulity only ever ends up trying to contradict reality. As always. Your whole tired old stance that it's not something ED could afford doing relies on it being done in a very specific way, and on the notion that it cannot possibly be done in other ways even though there is a decades (plural) long history of games doing it in other ways (also plural).

…and you realise that suggesting that something that was pretty commonplace 20 years ago — and which never went away — equates to “no game does this” demonstrates a fundamental lack of experience or understanding of the functionality and of the area in general, right? And that we're not five years in the future? It's exactly what he's asking for. Same as the myriad of other games that do just that. Would you like to venture a guess as to how those hardware stats are calculated? LMAO no. If you did, you wouldn't be in this forum, shooting down every single idea that is put forth towards that goal and argue against any request that would make it less of a niche game. Oh, and once again, if you don't want things to go off topic, why do you always ignore the OP and instead drag the discussion that way rather than follow the suggestion the moderators have offered you time and time again in relation to ideas you don't like…?

Your lack of experience with first-person shooters from, oh, the late '90s and onwards is not an argument against anything. You'll find “recommended settings” detection in any number of old Bethesda games, in a bunch of modern UBI games, in a number of games with built-in time demos (Crysis series, Serious Sam, hell even the OG Unreal flightcastle scene was effectively this). Good thing that it wouldn't really be, then. Your “fact” is anything but — it's simply yet another one of your reality-defying assumptions and has no bearing on, or basis in, anything except your contrarian urges and desire to keep DCS from ever evolving, improving, or developing in any way. In actual fact, games do this, showing that it's quite feasible, contrary to your fallacious argument from incredulity. As for the OP, you sort of can do those things already, but it requires a fair amount of Lua fiddling and/or USB reassignment and/or registry editing. As such, it's also immensely brittle and will not last very long. So yes, some good old customisation and just drag-and-drop sorting would be a significant improvement.

Because “hard” is not the same thing as “bad”. Quite the opposite in some instances. You use Vulcan, in particular, because it allows for optimisations that are not available with higher-level layers. This does not inherently translate to “looking better” but to cleaner code, more headroom, better balancing, or just easier interfacing with other parts of the engine. For DCS, in particular, it could go hand in hand with some future CPU optimisations (multithreading being the most hyped one), which would yield improvements in areas that have no relation to the visuals… only everything else. So in other words, there is no such thing, just like he said? What a weird way to try to contradict someone: by just saying “no” and then saying the exact same thing they did, as if it this somehow refutes the (very same) thing they said.

Viggen. Only half-kidding, since its implementation is actually a pretty darn solid foundation for how such functionality could work in practice. Of course, it would then have to be tied into some kind of cross-client and/or cross-session data save/load mechanism, or even be tied into the F10 map (since it's getting more and more popular to let modules load data from there and it's already a shared resource).

Four days is not a long time. Not everyone is quite as forum-obsessive as you and I. Good!

Not even in context, no. This is a VR zoom vs pancake zoom topic, which is what the rest of us were discussing when you started making incorrect assumptions about how it works, using broad and general language about what “defines” VR — in DCS and in general (as well as how pancake zoom works). Just because you were wrong and got corrected doesn't mean it's off topic. It just means your contributions were incorrect and got corrected. If that's too much to bear, there are solutions to that problem but trying to backseat moderate is not one of them… Again, you can't really chastise others for supposedly going off topic when you're the one who started off on that tangent. Now, do you have any actual input on the OP's idea and line of reasoning?

That's not what you said, now was it? So no, that's not fixing anything. That's just you trying to save face by adding new things to something you got wrong in the first place, when your sweeping, unqualified assertions based on hearsay and assumption turn out to be wrong again… as always. After all, that's your whole shtick in the wishlist forum: troll a thread with uninformed nonsense until the thread gets shut down, thereby saving DCS from ever changing. Oh, and incidentally, even if that had been what you said, you'd still be wrong and the comparison illustrative explanation would be applicable. Guess what? How other games use VR is still on-topic since it informs how VR in general works, and those rules also apply to VR in DCS. DCS uses VR the same way everything else does. If you were actually interested, such illustrations could help you overcome your confusion about the topic at hand — you know, the topic that you haven't really offered much in the way of an opinion on…

So what? So I know how VR works, in general and in DCS, and how its zoom function works, also in general and in DCS? And I understand how it works in relation to how pancake zoom works — you know, the topic of the thread? Is that where you're going with this? GEVR was brought up as an example of why your assertion that “VR is by definition life” is incorrect, same as pretty much everything else you've said. You don't really get to chastise others for going off-topic when that's all you've brought to the discussion.

That's not what I said, now was it? You might be confusing everyone else with yourself, there… Outside of inventing issues that don't exist, have you even offered any argument for or against the OP's idea or line of reasoning?

So there is no reason not to make it make more sense.

Have you tried ever making any kind of complex mission? Sound is indeed a large part of it.

No. You're making sweeping statements based on nothing but assumption and hearsay about a topic that you have admitted you don't know anything about and which does not affect you in even the slightest. Consequently, those statements are pretty much universally incorrect rendering your input on the topic largely pointless. Of course you could. See above about assumptions, hearsay and the consequence of those. Ah, Sharpe-speak for “my attempt at dragging the discussion off-topic by injecting nonsense in the hope that this will ensure that no options are ever added to the game is being torn apart by being wrong at every turn — I have to try to reverse it somehow!”

And that is not really the case in VR any more than it is in pancake, “by definition” or otherwise. It’s a matter of intent and design in both cases. FoV exists in VR in exactly the same way it does in pancake, and for a very simple reason: because VR is also pancake, only twice. It’s a flat image projected on one screen for each eye. You can apply FoV to this just fine (whether the brain likes it or not is a different matter). As discussed above, that’s how it works in DCS. You should know by now that your assumptions rarely match up with reality. Doubly so when you’ve participated in threads discussing that exact shortcoming in this very game… Also, you might be interested to learn that it’s not fully up to the sim to set the IPD, so it simply can’t be the norm. “I got beaten; nerf the other guy” is a mainstay in any MP discussion.

…and also not hear the sounds you want to hear as you design your mission.

That's not what I wrote, now is it? It doesn't have to, but actually, the monitor size is pretty trivial for it to find out. Why and how this is the case has been explained to you extensively. [Citation needed]. Because again, and I'll come back to that word, that is commonly the end result of putting the slider at the 50% position. …and guess what? It can trivially be made to be correct on both using the method described. That's the beauty of the most simple bit of trigonometry: screen size is not a factor in the ability to make it a 1:1 FoV, and ultimately, if you need max zoom to replicate a correct on-screen size of things, then you 1) should probably consider consulting an optometrist as a first step to deal with your persistent tunnel vision, and/or 2) your display arrangement is very poorly thought out and needs to be fixed. As you well know from a different thread where you argued against an option that didn't affect you and that you didn't understand, it's actually the other way around: a lot of things in DCS is out of scale and people want to use IPD settings to make it life-size. You really need to stop using your imagination as a data point.

To some extent, you can use CombatFlite to do this, but it's not necessarily less resource intensive aside from the install size (which, of course, can be a pretty huge difference in and of itself). But splitting the ME off as a lightweight install option would definitely be sweet since it would always be 1:1 in step with current DCS functionality.

That's not really a solution, no. Especially not to the problems described in this thread.

LMAO no. I know you love making up these random nonsensical statement without even the slightest connection to any known reality, but come on! At least make it sound like you've at some point in your life actually launched DCS and looked at the view from the cockpit. In the real world, where the rest of us live, 1:1 FoV is actually commonly achieved by having the zoom slider set to the middle position with a monitor at regular, ergonomically approved, standard distance. You can quite trivially calculate the correct view if you have an aircraft with a known-size mil reticle (e.g. the 50 mil reticle in the F-5) — just multiply that size with the viewing distance to get the size the reticle should be on-screen, break out the ruler (again, eg. the aforemoentioned 50 mil reticle × 90cm viewing distance = 4.5cm) and adjust zoom accordingly. If you're particularly pedantic, you could even adjust the monitor position to make sure it matches the zoom axis centre position this way. It's not so much the looks as the the angular compression — something our eyes can't do without the aid of outside help, and the brain is unfortunately very good at determining when you're using those to make the world look wrong… so it doesn't. The issue in VR is that the brain has a very hard time grasping that you're essentially doing the same since it looks like you're just using your eyes. As for how VR zoom looks, let's take these comparisons from a different thread where you made some other but equally catastrophically uninformed assumptions as to how DCS works in VR and in pancake mode. Not it is not. If it works out that way, it's by intent and design, not by definition. It entirely depends on how the world is scaled and how that scale is adjusted or derived from IPD settings. This is why in, for instance, Google Maps VR, you can be a giant stomping around in a toy-sized city, or, with the flip of a switch, you can hang precariously 300m above a regular-sized city. Or why you can cross the entire solar system in thee steps in various space simulators.

The only difference is that VR users can't zoom in as much as pancake uses can and thus can't see as much detail, and that the perspective shift makes the entire world perception go wonky.

+1 …and waypoints. Anything that goes on the map and is selectable, really.

So you think that one of the main purposes of the game should not be realised? That a myriad of missions should not be played as intended and that relevant content should just be jettisoned because of your two worthless cents? Nah. That's an unusually laughable take even from you. Learn to read. Use that newfound skill to read the OP and what the actual problem is and why this fix would help immensely in improving the game as a whole and the content designed for it. I know you break out in hives at the mere thought of DCS seeing any kind of improvement, but at least try to come up with a rational, logical, or just remotely intelligible argument why that should not happen. Obviously, yes — this is such a simple and obvious QoL improvement that it's almost shocking that it isn't in already.

In fact, not only is it supported, there was (and possibly still is) a bug whereby DCS's favouritism of IPv6 over IPv4 for the purpose of connecting to a server caused issues with running multiple servers and clients on the same network.