Tippis

That's a pretty neat idea as a compromise. The only worry I can think of is the rendering workload on something that is already pushing the limits of performance. Do you happen to know off the top of your head how much this effect (especially if it needs to be applied in a limited fashion along a geometry boundary like that), would cost in terms of processing power?

Ding ding ding! Nor should you care so much about having it implemented since, not only is it pointless, but you're not affected anyway. And yet, here you are, trying to dictate how others must play the game… And no, it's not just VR users trying to make this happen as you yourself prove so amply. Look at it the other way. This is not a cheat by any definition of the word. It may in a vanishingly small fraction of circumstances give one specific advantage to a small number of players, but that is completely drowned out by the far bigger advantages gained by far larger number of players if far more common circumstances. So it would be utterly idiotic prioritisation of work — which you're also very fond of arguing over — compared to those much more important cases. You always trot out the “not worth wasting ED's time on” argument when it's something other players want that would benefit them; now it's suddenly completely fine to waste their time on something that would not benefit the other guy, but which would benefit you. And of course, going after the actual larger, and thus worth-while issue, would mean addressing your advantages and nerfing you, and that must definitely not happen, right? It must be the other guy who gets shafted, even if (especially if?) it makes them sick because of it. …and it would be just as trivial to avoid while having the far more important benefit of not making the player ill, which is an even worse idea. I understand that you desperately want to nerf a different group of players than the one you belong to, but guess what? You have no point of reference and your baseless opinion of what is and isn't a good idea is inherently worthless. Also, no, it wouldn't be a problem because you could just choose not to use it if it was correctly implemented. But again, you don't want it to be correctly implemented — you want it to be forced on others because they must always be dictated to conform to you, never the other way around.

What problem? Realism isn't a problem — it's a balance between usability and presentation, and the same balance has to be struck with all control methods. A design choice is not a problem, it's just… well… a choice. It becomes a problem if it makes the feature useless because it elicits an adverse physical response, like hard limits would. Game balance isn't a problem — whatever advantage can be had is utterly minute compared to the advantages you get in pancake mode, so it really just evens out. If anything, it's pancake mode that is in desperate need of fixing for balance purposes. And it certainly isn't a problem in in the sense of being a bug — it works like this for a very good reason. You may not like that the balance has been struck this far towards usability, but that doesn't mean it's broken or unintended. So it's not actually a capital-P “Problem”. It's more a case of you being unhappy with the implementation for one reason or another (in your case, it sounds mostly like immersion, but I may have read that wrong). In that case, the work-around may indeed be the solution to your problem. It may not be the solution to the problem, which I understand if you feel is frustrating, but that would be because in that situation, there is no “the problem” to solve, only your personal one that you, personally, have to work around. And you can work around it. If you want an option to take the problem-solving off your hands, that's fine and all, but this is where DCS' limitations become troublesome and we have to be very careful about how that is being implemented. And this is where it matters whether we start messing with it or leave it as something the player has to deal with on their own. It's a simulation. It needs to take into account that it's not the real thing and accommodate the various techniques and methods used to deliver the experience in spite of that, and there will therefore always be compromises. Such compromises are not neglect — they're unavoidable and necessary. It is also a game and thus needs to accommodate the player without inconvenience them or make them physically ill. This is also not neglect — it's good game design. If you want to put a period on anything, it's on those two facts. Since you're declaring physical restraint out of scope of the conversation, you only arrive at one possible solution: live with it. Learn to handle it. There is no neglect. There are only the inherent limitations of the medium, and the best practices to deal with those limitations. Making a significant portion of the users ill is not good practice. The option I'm arguing against would affect those who don't want it as well, and it would affect them in a very bad way. Notice how often it's about a server dictating client-end behaviour and about limiting movement. That's what I'm against. You'll also notice if you read carefully that I'm not arguing against fading or similar techniques — only cockpit limits and moving the player's head around, and taking the VR experience out of the player's hands. You're confusing me with SharpeXB. Once you've been around this topic long enough, you'll notice the vast majority of arguments in favour of making people ill comes from people who wouldn't be affected by this option, exactly per your complaint here — they're just people who want to nerf the other guy because they got beat in PvP and imagined that this largely irrelevant advantage that some VR players may occasionally have must absolutely be at fault for that humiliation and therefore the advantage must go. They themselves must all keep their advantages, obviously — just nerf the other guy and all is good in the world. There are a small handful of players who want it for immersion purposes, and that's fine and all, but that's not where the support for the idea is really coming from. It's mostly the nerf-the-other-guy crowd. If you want to talk about maliciousness, look there… You're assuming that it will be a fully player-controlled soft or no-limit option. That's fine. What I'm taking a stand against is the contingent of people who want something very different from what you want.

[citation needed] By your own calculations, it must by necessity be an exceedingly small number. So those “more players” would come out to… what? Four? Seems about right, doesn't it? They get their very tiny advantage that affects pretty much no-one; you get yours, which affects a far larger number of people. Again, [citation needed]. It's not a bug for much the same reason as being able to look behind you while only turning your head 10° is not a bug: it's inherent to the implementation and is there for a very good reason. There is nothing to “fix” — just something to accept. As for it being a simulator, that applies to all the advantages you enjoy as well that also should be removed, but which I've seen you adamantly defend as being absolutely necessary for… no particular reason. So why should their inherent feature of the control scheme be “fixed” in a way that causes a vastly bigger problem than it solves, but other must remain the same even though they give you vastly bigger advantages? Is it perhaps because they give you that advantage and not someone else? What was that you said, again — if you feel at a disadvantage when playing against VR players, get VR yourself. You'll quickly notice that the thing you're so deathly worried about doesn't actually provide the advantage you're assuming from your position of ignorance and complete lack of experimentation and experience… It's actually pretty darn easy to keep your head inside the cockpit by virtue of how VR (and body mechanics, and just good old gravity) work. As far as immersion-breaking goes, putting your head through things is something you quickly learn not to be all that bothered by when it happens, and ends up being far less ruinous to the experience than when the entire world suddenly moves for no reason and your sense of proprioception is telling you that your head has effectively detached from your body. That effect is so immersion-breaking, in fact, that it elicits a physical response. If you're lucky, you can train your way out of it, but that is not a certainty. So if immersion was the most critical factor, cockpit limits would be right out. They'd also be right out from just plain old VR design best practice. That only leaves game balance, which is largely immaterial since we're talking about a niche within a niche within a niche within a niche (and really within yet another niche on top of that), where what minute advantage this brings to VR players is completely drowned out by the larger advantages pancake players have with their view control schemes. And even then, there are proper ways of hobbling the view of that niche5 that end up not actually limiting where the head can go to begin with.

For the sake of comparison... ...which one lets me spot an attacker or a target more easily? Which one allows more control? Which one requires more effort? Which lets me actually see more in any practical sense?

Neither generally nor specifically speaking, no. That's not how DCS works. We've been through this and it has been explained to you in full. External views and labels are not server settings. A cockpit view limit would conceivably fall into the same category, except it cannot because this would be bad UX design since it's not actually a gameplay setting so much as an accessibility one, and the server can (and should) never have anything to do with those. And quite clearly from this thread, not everyone wants to play by the same rules seeing as how there are so many here trying to come up with pretty silly excuses for their own failings and trying to use those excuses to nerf the other guy while at the same time refusing to take a close look at their own (far larger) advantages and arguing that those be nerfed instead even though they'd affect far more people and balance things even more sensibly...

And no-one ever said otherwise so we can safely conclude that you have no intelligent, cogent, informed, or even remotely relevant argument since you had to resort to these kinds of laughably pathetic strawmen. Works both ways. Not playing in VR is a choice. If you feel it puts you at a disadvantage, and that's important for you, use VR. See how that works? Oh, and if handicapping the other players isn’t a reasonable solution, why are you arguing in favour of exactly that — and far more literally? The limit isn't there in VR for a very good reason: because it breaks the first rule of VR design. Meanwhile, the lack of limits for other view control schemes is a vastly bigger problem since they are vastly more common. So why is this complete non-issue so important to fix break? We have been through this. That's not how DCS works. LMAO. No. That can never happen. And if you're using that as your impossible goal. you do understand that this will mean all the advantages of TrackIR must forcibly be banned from multiplayer as well, right? I'm going to venture to guess that you don't actually want that since those are your advantages that you rely on… You've got one thing right though, for once: this cannot be easily solved. VR-breaking limits on head movement is an easy (but inherently incorrect) solution, so let's just get that one off the table since it's causes far more problems for far more people than it could ever hope to solve.

Because, since it's a non-issue, not a cheat, and not a bug, there's no need to forcibly induce nausea in a significant portion of players by some hamfisted non-fix. We know for a fact that the “solution” advocated here causes problems — whether it fixes anything is unknown. So the question isn't one of concern but of figuring out if there even is an issue to address here that is worth actively causing that known problem and alienating those players. And if it's an insignificant portion of players, then guess what? It's right back to being a non-issue that ED should not waste an ounce of time and manpower on, especially next to all the unrealism, bugs, and cheats afforded by other view control systems that should be attended to first since they have a vastly larger impact on everyone. And let's not hypocritically kid ourselves by saying that they don't have just as many advantages that they can exploit that VR players cannot.

Not only “can”, but must. Each such setup is tied to a specific aircraft, and they are all stored in the same place, as mentioned on the previous page: your %USERPROFILE%\Saved Games\DCS\Config\View\SnapViews.lua file, where you can manually go in and tweak things down to the microradian and micrometer (I'm not even kidding). The file contains comments and parameter names that are rather self-explanatory, except for which direction is which of the x/y/z axes. Off the top of my head (and don't trust this without verifying through experimentation), x is forwards, y is up, and z is left/right.

It's mostly just one of those cases where specific tasks are available only to specific units, and in this case, that's augmented by how those specific units are only available to specific countries. Much like AWACS-style units have the “AWACS” ongoing task to… well…make them do AWACS stuff, there is an EWR task for ground units. It will make those units appear as a comms menu option and makes them talk over the radio much like the AWACS do. But it is only available to the handful (two? three?) of EWR radars that you'll find on the red side among the air defence units, and I think that originally, the only official documentation for how to set them up and use them was in the MiG-21 manual(!), so don't kick yourself too hard — they're not exactly the most immediately obvious thing to even find, much less set up properly. With pseudo-nationalities such as Task Force Red/Blue, UN Peace Keepers, and USAF Aggressors, you can always make sure you have those units available with any kind of coalition composition, but you still need to intuit that the functionality even exists and is tied to those specific air defence units to begin with.

…sometimes, but not always. And is lacking in limits in other ways. The point remains the same: any perceived advantage you can get from this is cancelled by some equivalent advantage in other view control schemes, and all such advantages are largely irrelevant anyway, so it all comes out equal in the wash. And the high prevalence your (unsourced) “data” proves means that such limits are not the right way to go to “fix” this non-issue anyway.

[citation needed]

Nah. Others can do it as well — it's just not as trivial. As always,. you should probably stay away from VR topics since you have no experience with it.

They really should just ask to implement Scratchpad natively into the base game. It's a bit trickier to use for anything but copying coordinates from the map in VR unless you happen to have a stand-alone numpad, but it's still entirely workable, and for pancake mode, it's 99% of what you ever need.

Yes. This would also be acceptable.

Legen… …wait for it… …dary!

Not everyone, and certainly not you. That's the problem with speaking from a position of ignorance. You were asking for something that was a pretty significant reduction in functionality and value compared to what the OP was suggesting. However, since you weren't familiar enough with the topic (or with the OP's suggestion), and instead of listening to what people were telling you, you got stuck in this contrarian loop where your point must absolutely be the correct one, in spite of it not actually making sense the way you wrote it. Maybe you thought you were being clear, but in actuality, you were using a very ambiguous language in regards to a design decision where precision was needed. You say this a lot. Yet, you still continue almost every time. Let's see if it actually sticks for once.

Indeed it does: the point is that your concern was dealt with from the very start and was never a potential problem. It was just something you made up to be argumentative and contrarian, but didn't notice was a particularly dumb hill to die on since you hadn't read the OP and what it really asked for. You don't have to notice anything of the kind since that's just one more thing you've made up from your admitted small biased sample. That is not “most all” servers — it's “the small selection of servers you play on”, which is a very different and utterly irrelevant thing. It is also clearly not as obvious as you now want to suggest since you spent the entire thread being confused by it and not understanding where the setting should go. Oh, and as pointed out above, making it a mission setting is also not a particularly good thing compared to what the OP is suggesting, even if it's still better than trying to make it a server setting. So no, it does not belong in the mission settings. It belongs where the OP is suggesting it should go: as one of the starting WP options along with parking slot, starting time, and those kinds of things.

You sort of can, but it requires a far more complex setup of the orbit track where, rather than using the “orbit” waypoint action, you set up the entire orbit and its repetition manually. You can then add in a whole bunch of triggered “go to WP” actions to tell the tanker (via comms menu or something) to immediately go to one of those waypoints along the track and proceed from there. It's a very laborious way of doing it, though, and it also often makes the tanker behaviour through turns a bit aggressive, which was the whole problem to begin with. Not to mention how much players (especially if you do it in an MP environment) can end up screwing themselves and each other over by spamming navigation orders at the poor AI.

Aww… spoiler Indeed. The only downside I can see is exactly the trap SharpeXB fell into: there's already a fair amount of confusion (especially on the client end, but us server managers get it mixed up too in casual talk from time to time as you point out), and having to also remember specific waypoint options adds another layer of “what option are you talking about?” But in relation to the benefits such a deep flexibility would bring, that's such a minute downside that it's barely worth mentioning. The implementation side, as to whether it should be a ˘hot / cold / client choice” selection box, or whether it's the same as we have now but with an added “allow override” checkbox is a matter of balancing backwards compatibility against clarity and ease of use against flexibility. Given how seemingly easily they got the different “start from ground” tasks going, it certainly looks like a simple override switch would be the quickest variant, even if it's perhaps not quite as “clean” as just rationalising the number of startup variants.

Nah. But I suppose that answers the question: you have no interest in learning how DCS works or in being capable of contributing to these kinds of threads, since you will steadfastly cling to your position of wilful ignorance so you can make very silly complaints about imaginary issues with improvements to the game. Still, at least it was nice that you finally came around to supporting the OP's idea, because it's a pretty good one.

No. It's not semantics in much the same way as confusing a drill and a hammer is not a matter of semantics: they may both be tools to insert metal bits into wood, but the purpose, method, and outcome are very different. Same thing here. There is a pretty clear separation and distinction, and it matters. I'm explaining to you that your entire complaint never mattered from the very start, since it was already something the OP's suggestion handled. I'm asking if you understand why this is, since you keep bringing up this irrelevant point about “server options” to still try to project an air of objection to the idea, even though in practice, you are full on board with everything the OP said. Every post you've made in this thread has been unnecessary, simply because you're confused about how DCS operates and how it handles its various restrictions and options. If you want to blame that confusion on semantics, then sure, fine, that's nonsense but you do you. And in that case, rather than remaining confused and trying to deflect that problem, you could just ask for clarification. We might be able to explain to you the distinctions and why they matter. You've chosen to be contrarian because you don't get what the OP is saying because you don't understand how DCS works, and rather than trying to remedy that, you're constantly trying to shift to new (deliberate?) misunderstandings to not have to admit that you cannot come up with any kind of reason why this shouldn't happen. The bottom line here is that your clamouring for a server option is at the same time both unnecessary and not what you actually want. You can stop squirming. This idea already satisfies everything you need. So, again, would you like to know what it is that control the things you incorrectly attribute to the server? Or would you like to guess a few times first?

No. That's not the server controlling anything. Something else is. Can you guess what? As a hint, there's a reason why I have consistently and at every turn asked you to read the OP since it already explains who sets up these things, and where. In a very funny twist, in that picture, you've managed to get the whole thing entirely backwards: you've marked the things that aren't server options, and have skipped the things that are. The problem you're running into here is that you have only ever been a client. You have never looked behind the curtain. You have not tried to deal with the kinds of issues, considerations, design constraints, and even outright resource limitations that this thread revolves around. I can tell this from how you talk about the different puzzle pieces involved (and, more tellingly, which ones you don't talk about). You're only assuming that things work a specific way because you're drawing from some experience — personal or vicarious — from completely different and unrelated games. DCS is not those game. DCS does not operate the way they do. What you need to realise is that those of us who have done all that know a fair bit more about the inner workings of DCS, and especially its multiplayer component, than you do and that when we tell you how things actually work, you need to stop trying to contradict or refute that based on nothing but guesswork and… well just general contrariness. We know these things. You don't. If you want to contribute in any meaningful way, listen and learn; ask a question about the things you don't know or understand; respond with facts, not assumptions. Otherwise, you're just a troll. So… would you like to know what it is that control the things you incorrectly attribute to the server? Or would you like to guess a few times first? No. The server doesn't decide any of that. Again, that's a very different function — same as before. Guess which.

…and as mentioned, this idea will not in any way affect that in any way. See, now I'm starting to doubt that you actually read the OP again. You almost had me convinced there for a while. Nope. You can see the full list of DCS server settings in my earlier post. You'll note that those options do not control any actual gameplay (unless you count voice chat). In many games, there are server settings like what you describe, but DCS servers do not work like that. This is why making it a server option is a strictly and categorically worse idea than what the OP is suggesting, and would more than anything cause the kind of problem you're needlessly trying to prevent. You may think the DCS server works like that, but as has been demonstrated repeatedly, what you think, and how things actually are, are two very different things. This is where you need to learn to listen to those who have actual experience with the matter at hand and not rely on your own guesswork.

Does this happen if you set it to go off on a timer rather than (presumably) on a MISSION START trigger?