Tippis

Doesn't really matter, now does it? More specifically, you have no idea about VR, and as such, you have no understanding of the topic at hand and of the simple fact that the ability to remove the distortions would create more realism, greater visual parity, and — to really tickle your favourite bone — be far less dev-time-consuming to implement. Again, I understand that you've realised there is yet another thing that other players suffer that you do not, and that as such, they must under no circumstances be allowed to have an improved game experience that removes that handicap.

The Type 093 shows that there's at least something in the code that lets submarine submarine to some extent. It seems intuitively likely that if we can have a sub that fires ASMs, it should be possible to fit others with cruise missiles. The targeting logic (and more relevantly the mission tasking) is admittedly a bit different, but it is at least possible to make them defeat other units in the game, so that's a promising start…

I think you're confusing him with yourself. You're the one who took the topic down this route. Just because he's shredding your entire line of thinking doesn't mean that he's off topic, especially not when it's a topic you introduced by immediately throwing your argument-from-incredulity fallacy into the mix. Just because you have no use for this QoL improvement of the game doesn't mean it's not worth-while. Quite the opposite. It only highlights how useful it must be if you're this scared of its implementation.

…and thus therefore doesn't matter in the slightest relative to the visual distortions created by its being there. It is a minuscule to the point of utter irrelevance compared to the lack of proper forward vision, such that if you actually wanted to make an argument for balance and realism (as opposed to your standard stance of “nerf the other guy but never touch anything I benefit from”) you would be fully on board with the option. The fact that you aren't shows that realism and MP balance — as irrelevant as that is in the grand scheme of things — are things you desperately want to avoid for some incomprehensible reason.

So it's much the same where it's the overlap between fast-moving and (relatively) static elements that gets the processing to go haywire (you can occasionally see the same along thin cockpit structural elements). Remove one or the other and the rendering confusion goes away, and that's really all the OP is asking for. The option would be nice. All options always are, especially when it comes to tweaking the visual appearance of the game.

What are you looking through in those cases? And does it matter for the general operation of those planes?

How would it not, when it's the presence of that moving propeller that makes the rendering artefacts show up?

Likewise.

There you go then. So the OP's suggestion is the one that remains as a workable, non-geological-time-scale, universal and non-vendor specific solution. As a bonus, it has no ill effects that need to be managed (well, unless they do something silly like add another 4k shader/texture of nothing… ). Exactly. So the whole notion that it must somehow be controlled in MP, unlike every other graphics and display setting, is bunk. Anyone with even the tiniest shred of programming knowledge.

That would be the only other viable option. And I use “viable” very generously here. But no, that's not my solution. It's more in line with the kind of nerfs and reductions in quality you are so keen on imposing on other players, except in this case, it would be imposed on you instead. What's good for the goose is good for the gander, right? …then we'd be several years into the future, not now, where this can solve the problem quite quickly and handily with no ill effects.

A standard feature that anyone can use and which provides none of the supposed advantage suggested by the ones who complain about it without having actually checked it out. And in this case, everyone can see through this particular part anyway so somehow it manages to be entirely irrelevant twice over. That shouldn't even be possible. But more to the point, graphics options aren't controllable in MP for very obvious reasons. Same applies here. Not even close. It's no more an exploit than changing your resolution or refresh rate, both of which affects what you see and how in-game assets are drawn and animated. The real problem is that pancake mode users do not suffer from the visual degradation. This idea would eliminate that discrepancy and make the game same for both. Based on your history of posting, this is why you're against it: because it makes things more equal and removes an disadvantage from players that aren't you, and other players must at all cost retain all their relative disadvantages to you. I guess another reason in line with your standard line of argumentation would be that this would actually improve the realism of the VR view, and you've been quite adamant in your argument against those kinds of changes in the past…

Given that the engine can already handle placeable (of sorts) dynamic lights — illumination flares being the most immediate example — it seems like a fairly simple middle way of doing it is to add exactly that: a placeable dynamic light. Even with the limitations of this lighting, eg. lack of shadow casting and only some things properly receiving and being lit up by that light, it would let mission makers decorate their low-light missions to a much higher degree while also being in control over the performance hit (which they have to consider anyway as they add units and scripts and the like). It would allow for something as simple and obvious as static fire effects actually lighting up their surrounding at night, while at the same time not having any performance impact at day or making airports seem a bit more alive when in use without having to have ever airport light on the entire map suddenly become a potential drain.

Night Falcons (TFR and all) or go home. So there.

It really wouldn't. Same as how other graphics options aren't controllable in MP for very obvious reasons.

There's “large map” and then there's large map. What you have there is some 3500 km across. This should be compared to the maybe 800-900km we generally see in the largest of DCS maps, and even then, a huge portion of that consists of empty or low-detail voids, but the map stretches out simply because one of the corners have a bit of detail to it and the whole thing needs to be a rectangle. All other corners go unfurnished and unpopulated. Any longer distance and the decorated area needs to be more narrow, or just be a lot of empty sea for convenience's sake. Cut that down to a 16th and you get something the game can possible handle and present in a meaningful and interesting way.

The point is, their call can change and has done so before based on the input and requests of the player base. While there are certainly all kinds of reasons why they might or might not want to do [whatever], that's not a reason for people to stop requesting it.

Nope. Especially not when contrary opinion is objectively wrong. We've been down this road before, remember? It ended with you accidentally admitting that you did in fact see the same thing everyone else did but just ignored it or conveniently “forgot” that it works that way for [reasons].

No, you were just wrong, as always, because as always, you didn't bother to read what you were responding to and instead, as always came up with some nonsensical statement that doesn't correspond to any known reality. As always. …and those resources should be prioritised towards making things better. Like DCS. In spite of your wanting to keep it as bad as possible in as many ways as possible, especially in the ways where it would benefit the most from improvement and fix things that should be working properly irrespective of other priorities.

Try reading the OP. It's not very hard.

Then you have no reason to respond It is perfectly clear and there is no intelligent argument against it. Your absolute and persistent insistence that DCS must under no circumstances ever be allowed to evolve and be user friendly and offer a good learning environment does not qualify. Quite the opposite. We all know you will now stop at nothing to troll this thread into oblivion because it is so completely in opposition to your wishes of a horrible user experience, but you could you, just once, do what the mods have told on multiple occasions in cases such as this? Hmmm? Arguments from ignorance or incredulity are fallacies for a reason. Your lack of experience does not change how things actually play out in the real world. The OP's suggestion is solid and fully in line with ED themselves state that they want DCS to be. It touches a number of common topics that have been left with half-complete, bare-bones, or just outright missing functionality, to say nothing of ancient modules that are still sold as completed products but with unfinished (or just outright missing) manuals and with no real learning aids available to cover that gap.

Good thing that no-one suggested that, then. Well, except for you, just now. OSes have had this for decades. It is not new and, for even more happy funtime, size is not even that much off a factor. That's the benefit of having a computer rather than some semi-stale and obsolecent video disc media. The point remains: you don't need some obscure BR-disc based supa-sekritt test pattern. It's ubiquitous and universally available and built into any system that matters. The thing you claimed as a necessity is anything but, on top of also being one of the worst examples.

The internet. Or just the OS since it's built in these days. Lol no. Video on BR is inherently low quality due to compression and (commonly) a fixed size for the signal. The good news is, you don't need video — that's just how it's done if all you have is a simple TV (or projector) and a simple BR player, doubly so since such displays generally have pretty darn poor image tuning capabilities to begin with in order to be user friendly. If you have a computer, and especially if you have a proper monitor, there is no need to settle for something that simplistic and inaccurate. (Oh, and also, while you can indeed get proper calibration off of a BR disc, the thing that it does is not “video” — it's a BD-J app that does similar things to how your OS colour and image calibration works. It does this by being proper software running on your BR player.)

Lol no. You just a properly set up image and some instruction for what to look for — no disc or USB needed. A Blu-Ray is not a good point of comparison because of how low-quality, inaccurate, and simplistic those test patterns are compared to what you can do on a computer.

For just the radio message and the nine line, yes, you're probably right. The tricky bit isn't getting the information — it's keeping information out. Now, granted, since the AI JTAC has always been spectacularly brittle and inflexible and incorrectly done, it's been ages since I actually saw it used in an complex multi-target and multi-package environment so I can't recall off the top of my head if it cheats with comms as well and only magically radios to the sender, or if it actually broadcasts the message at a frequency to anyone tuned in. It's that latter issue that would require some extra fiddling in that case. Curiously, this could actually benefit from having to do a manual kneeboard update: if the script only picked the very last transmission, the pilot would determine whether it was for them or not and whether it should be copied, as opposed to it happening automatically and creating the potential for information overflow.

For the frequencies part, at the very least, that functionality already exists in a handful of modules so pretty much all the work there is already done — it just needs to be moved up from module-specific to universal kneeboards. If you're particularly enterprising and semi-familiar with Lua, you can probably make it happen right now by copying the existing keyboard scripts for those modules. The tricky part is anything that is added dynamically, where there would have to be functionality to trigger kneeboard script updates at will — again, there are modules that already show that it can be done live, but it is probably a bit trickier and also involves having to add some kind of bind or menu command to handle that. This would also be required for anything JTAC-related, but for that, there would also be the added problem of figuring out which JTAC you're talking to and/or which targets are relevant to you. If not, you'd end up with more coordinates than could fit on a page and with very little to separate them (since JTAC callsigns don't have all that many options) in any slightly complex mission.