Tippis

That's just repetition — it doesn't answer the question. You're overgeneralising from your own experience. What you have at the moment may be absolutely dire for you. There is no “we“ in any of that, because we do not have that experience — I and many others with me have seen immense improvements with the new system, and you have to include that into the “we” equation. You may have a fiasco, but we certainly don't given those improvements. And since those improvements are there, it is indeed the way to. It just has a bit further to go before you see similar improvements on your end. Between resignation and not doing anything and having some kind of improvement, the latter is the way to go and that is the road we're now on. Just because you and some others are plagued with smudgy black squares doesn't mean that everyone is. Digging your heels in because the first iteration isn't working for you will just mean that your (lack of) input isn't taken into consideration moving forward and whatever is causing your issues won't be addressed. So, for starters, what kind of display are you playing on? At what resolution and with what kind of scaling and AA settings?

They already did that with the old system. That's part of why it has to go. The new one will reduce that ability.

In what way? Before this, you were able to spot aircraft at absolutely impossible ranges. That is being remedied with this new system. You would also get wildly varying, and very counter-intuitive, results depending on resolution — e.g. lower resolutions could see things more easily. That is also within the scope of being remedied by the new system. It was unrealistic, backwards, and very silly in every way. The new one is in the process of being tweaked, which is in and of itself an improvement even if the current result for you isn't the best for you. But that is not universal. Hardly, since it is a step along the progress to a vastly improved spotting system that the game has been in dire need of for close to a decade.

It varies with the player and their setup, and as such needs to be handled like any other graphics option. Otherwise you end up with a situation where the server enforces disadvantages on some players and enforces advantages on others, which is arguably the worst outcome possible. It would be like the server deciding that, no, you can't play in 4K or in VR because you might (and it is might, not will) see things others will not. If it is left to the player, it just becomes a matter of whether you believe others gain something from it and if you feel you need to get something to “compensate”. Not everyone sees these “large black smudgy squares” you're talking about. Others see very tiny, heavily aliased dots that fade in and out smoothly as the contact becomes more or less visible. That is as intended. They're meant for spotting, not identification — you do that much further in, when the dots are no longer in play.

…and thus your entire complaint is about a problem that doesn't actually exist. If liveries already aren't included in IC, then it's already not a problem. If they are already included in IC, then it's already not a problem. Either way, it's already not a problem. You're imaging an issue that doesn't actually exist, and it is not an argument against making it possible for users to choose how much space they want to waste on texture bloat. There's no difference. If the solution works for one, it inherently works for the other and it simply becomes a matter of what livery you choose for your plane. If you pick one where you know that the other players might not see it — custom or official or otherwise — then that's on you. Your choice does not turn others into cheaters or exploiters. It wouldn't be required in MP for the same reason as why it already isn't required in MP. The game already has a graceful fallback for when some other player's livery doesn't exist locally on your system. And yes, it would be counterproductive to just make an uninstaller — the better solution is to make an installer. Which already exists. It's called the module manager, which handles the whole business of downloading optional content. Again, inventing a problem that is already solved. The issue you envision doesn't exist because the game doesn't work that way. No more than forcing downloads on people just because others are allegedly worried about cheating (for which a solution already exists if it ever was demonstrated to be a problem, which has yet to happen).

Oh the irony… If by “orange” you mean “green camo”. But that's not how liveries work, and especially not how they'd work if it was handled by a livery manager. The whole point is that the player would be able to only have one of the two installed, using less drive space if they so desired. There would be absolutely no need for them to have them both when only one would ever be used and it was up to the player to decide which.

Amortising costs is almost the exact opposite of subscriptions, so…

My standard 2¢ on that matter: asset costs should be amortised over their relevant modules. If they sell a cold-war plane, some reasonable percentage of the price tag should go towards the development of assets for that period. Same with terrains, although that would arguably be more a matter of making regional assets. Not to mention that some of the assets that go into terrains in particular should just be unlocked as static objects at the same time so they can be used to liven things up and create a bit of region-appropriate variation. Paid asset packs will never work properly because of the inherent lock-out they create, and because of how this lock-out reduces the value of the package for mission-makers since it can only ever serve to reduce the audience for their missions. And then the vicious circle starts: few missions = less reason to buy the pack = smaller audience = few missions. There's a reason why they ended up changing their mind on how the Supercarrier and its assets would work for people who didn't own the module.

Not really, no. For one, it's a vanishingly small set of aircraft that don't come in dull grey colours as default. You even managed to get which ones they are wrong. For another, that would be a user error, not a cheat. You pick your skin. Or possibly, if you're doing airquake, the mission-maker picks the skin. Either way, you would know that the skin you picked might not be seen by everyone else, same as if you had picked any other custom skin, so the bonus you get for yourself is not universal. This is already the case. It is already not an issue. It is just you forgetting how skins work and then blaming others for your mistake. …and that's assuming that they deliberately choose to make the all the camo liveries optional, rather than including one or two as default or, as has also been suggested, just having them be lower-resolution. So you're inventing a non-issue based on a presumed implementation that would be inherently stupid, and thus wouldn't be the sensible one to implement to begin with. If this were true, then your complaint is irrelevant anyway since people would already be changing them out to something much more visible than what you pick on your end. Optional downloads can already be handled just fine by IC. It is already not an issue. If you pick a skin that you have installed locally and isn't covered by IC, then see above: it is just you forgetting how skins work and then blaming others for your mistake.

It depends a bit on what different outcomes you want to be possible. If you mean that it should be truly random as to whether the group is activate, then ONCE / NO EVENT > FLAG IS TRUE + RANDOM > GROUP ACTIVATE will be a useful combination, but this may mean that the activation never happens because that's just the way the random die rolls. It is also tricky to dial in the RANDOM value because doing it this way means it's something that will be evaluated every second, and even at low percentages (say 10%), it is likely to happen within the first minute. Even at 1%, it may still happen too quickly for your taste simply because of how often the check happens (in a quick test or three, it happened within 5 minutes every time), so you need to make the trigger a bit more elaborate to slow it down a bit. So even in this simple case, it becomes a question of how soon is too soon, and how much variation do you want? If you want it to be certain that the spawn happens, and want to control the time frame within which it can happen, and just make it random exactly when in that window the group is activated, you're going to need to mix in at least a little bit of Lua scripting to set the random time on mission start and store that activation time in a user flag. The rest can then be done in the mission editor trigger editor by creating a time counter using REPETITIVE ACTION > FLAG INCREASE that ticks up every second, and then check that counter against the random spawn time using ONCE > FLAG IS FLAG > GROUP ACTIVATE to get the group going. …but that's also a bit brittle. With a bit of unlucky timing and/or lag, the check may skip a beat and just run past the “FLAG IS FLAG” moment and then never trigger. This can once again be helped by slowing the counter down a bit to make sure there's more room for the flag check to work properly. Ultimately, to get the most control in terms of minimum and maximum wait times, and being sure that it doesn't bug out, you probably need to resort to a full Lua solution, at least for the randomisation part, although it can still trip a flag that you can use the regular ME trigger logic to catch and activate a group from. So, tl;dr: how certain do you want to be that the random event happens, and how much control do you want over the allowed variation in randomness?

Do you have a good reference for or description of what the different parameters represent? Is it some kind of progression of map size scale factors up to the max distance, or something else?

So it makes all the sense in the world to have a graphics setting that gets rid of that bad effect.

…such as? I suppose the base assumption that PvPers want a fair fight might not be as grounded in reality as one would wish, but aside from that?

No. Of your two images, only one is of server settings. The other is the mission setting and thankfully, the bug where “non-enforce” settings would be enforced anyway by what the mission-maker had set has been fixed. And even when that bug was in play, it was still mission settings, just not ones controlled by what was set in the mission editor but what was in the options.lua file that was (horribly nonsensically) packaged in with it, and which was a copy of the mission-maker's local setting. The server's setting didn't really matter because those would only apply to the server's presence in the game world and would be overwritten by the mission settings anyway. I was being very specific about this for a reason. …and let's not even get into the logic mess of the “ignore forced settings” setting they've added. This is an integrated and coherent system: if it's a setting that enforceable on the mission status, then it's what gets fed to — and enforced by (or not) — the client as they load into that mission. So adding it would be pretty simple as long as it is saved with all the other settings… and it would be. But that's if it even needs to get enforced to begin with, which is highly questionable since it's a graphics option, and there's not really any restrictions on those for a very good reason. Since the base advantage would be with the ones who don't need that setting, any enforcement would mean you're straddling people with an unfair advantage in a situation where you most likely want the opposite effect. Well, unless you really crave an unfair playing field and then we're having a very different discussion. You only need an option to enforce bad vision on some players if your intent is to forcibly maintain an unfair unfair advantage for others. Different aircraft see different thing, and those differences are not inherent in the airframes but in the misguided (or just badly implemented) aesthetic preferences of the module maker. If player fairness was the end goal, those who got saddled by arbitrarily bad views because of their airframe of choice should be allowed to be on par with those who aren't. “Just don't fly the plane” isn't a really valid solution here, and I can already see someone readying that one coming a mile away — it just acknowledges and reinforces that there's a problem that shouldn't really be there to begin with. If you pick an underperforming plane for your own amusement or interest, that's one thing, but “sorry, ground crew used 40-grit sandpaper to clean the windows” shouldn't be part of it. Well, unless you really want to in case you could turn that on as well. But that extra handicap should be your choice, not something the mission forces on you because it wants to favour other people. None of the enforceable options are really live. Hell up until very recently, none of the options were even not enforceable (but that was a bug, as mentioned). They just sit behind different levels of settings and control layers and they're applied when you load the mission. For the client, it's just about all all in gameplay options page (and special page for some stuff hidden in the flight setup controls for… reasons), and I can't off the top of my had recall any of the mission-enforcable options that can be changed without exiting all the way back out and go to the full preferences menu. Maybe labels (and not as in you can turn them on or off, but as in you can change the type)? But those will in most cases be enforced regardless.

No. For one, servers can only restrict a select few things: client integrity, ping, trial accounts, and data exports. Of those, at most the client integrity opens up for actual exploitation. For another, the things that can be restricted in missions are not exploits by very definition. They're game features that you may want to equalise among players for whatever reason — challenge perhaps, or in some cases the lack thereof, since it varies from setting to setting — but playing the game as designed is never an exploit. Funnily enough, introducing this option would make that exploit go away, not introduce it. The imbalance you're trying to protect against is the one that already exists. By letting everyone see clearly see their cockpits, you arrive at an equitable situation that can't be had at the moment without modding that breaks IC and which is therefore far closer to actual exploitation than having a legit option could ever be. If you want to fly with realistic limitations, wouldn't it be fair to also allow your opponent to do so? Some can already see cleanly through their cockpit glass. They would not be affected by letting everyone else do that as well… well, aside from having their unfair advantage be removed, but that's a way of being affected that is positive for everyone involved as well as the game as a whole. This is already the case. What is being asked here is for that option to be exposed in the UI.

What it needs is to not make spawning the start of the process, but rather the mission planning, where you create flights and packages — live and in real-time — and those get assigned to available starting and parking spots. Only then do you get to pick a planned flight to slot into and appear at the assigned, and until then, the plan is non-blocking — you've got a suggested booking of a slot, but nothing actually gets locked in until the spawn happens. This means that the entire ME needs to be a real-time affair that can be accessed before you even get to the flight picker. Coincidentally, this would also tie in well with a much-needed universal DTC system so the planning isn't completely locked into what's in the mission file, but rather in part (or fully) set up by that live planning phase.

It's the other way, really. People who aren't affected already have that advantage — this kind of option would just bring the rest into parity. And more to the point, since it's an option, you can freely choose to have the same perceived advantage if it feels so threatening. It is neither unfair, nor is it unrealistic since looking past these kinds of close-range defects is something the brain is fully capable of. It's the current situation that is unrealistic. If the option was properly exposed, it quite literally, objectively, couldn't be an exploit.

Excellent. Problem solved. Not that it was really a problem to begin with. Actually, that's why mission options are a great thing (and that's what this would be — it wouldn't be a server option because those are used for very different things). And if playing at an equitable setup where your artificial advantage is removed isn't to your liking, then maybe you should stay away from PvP altogether… But this isn't about you, now is it? You have already made clear that you wouldn't use this option anyway so your continued non-use is hardly relevant. The performance of your system doesn't dictate the performance on other people's systems. Right… ["views"] = { ["cockpit"] = { ["mirrors"] = false, ["reflections"] = false, ["avionics"] = 0, }, -- end of ["cockpit"] }, -- end of ["views"]

Pretty much, yeah. It would be a lot of work to arrive right back at the initial request since it wouldn't be addressed by a mere visual change. Quite the opposite.

Nah. If people want to be able to see out of the cockpit, that's not something the server needs to be bothered about. It would probably be better to allow people to set up their view options to match what their hardware is doing, much like how you can pick a resolution and detail levels, and post processing, and display type. As a bonus, that kind of thing can be done quite literally by tomorrow, as opposed to hopefully some time before 2025. There are literally no downsides to having an option, especially one that already exists but simply isn't exposed by the UI. Zero. Your personal preference is part of that zero.

But they do allow players to alter those files at will. And again, an “improvement” on some modules doesn't actually address the problem, nor does it remove the need for a switch. If anything, it might actually increase the need for a toggle. Not to mention the amount of work that would be needed in comparison with the far more simpler and efficient way of making a sufficient solution for everyone's needs.

It wouldn't, by very definition. If it were, the following things would also not be allowed in MP and should be removed as options: Playing in VR Playing in pancake Playing in a simpit Playing on multiple monitors Playing at any resolution above 720p Playing in a user-selected aircraft Using in-game voip Using out-of-game voip Using chat Everything else you can do in the game, really If disabling canopy reflections was an option, it would be… [drumroll] an option. Your decision not to use that option doesn't make others' opposite decision an exploit. If you feel you are at a disadvantage for picking an option, you are free to picking the other one. You are not the arbiter of what is an exploit and what isn't, and your dislike for any given option is wholly irrelevant in that determination. Your aesthetical preferences are also irrelevant. Fixing almost every aircraft in the game does not remove the need for the option, no matter how much better you think it looks. Those that don't like the look of canopy reflections would still not be served, and they'd be denied a trivial and useful option for such an utterly pointless reason as your unfounded PvP paranoia and personal preference. Oh, and since you love invoking the heavy burned on ED to make any change happen, you realise that the non-solution you're asking would take years to implement, whereas the actual solution can be churned out in a single afternoon (most of which is spent on coffee breaks), right? You're contradicting your own position, again. As always.

It does, but the Tobii software is… not mature. It's not a “pause” as such, but rather a “stop sending any kind of axis signals”. And it does so while still blocking other inputs. Going for a different software layer can solve some of the lacklustre capabilities of the default software, but that means having to kill and restart the software itself to access any of the (often rather neat) systems integration outside of gaming. But all in all, this is more of an issue that needs to be solved by Tobii, along with the myriad of other deficiencies in their software, rather than something that DCS should have to fix on their behalf.

…which just further highlights the need for fix. The effect of turning it off is, if anything, a relief and mods to that effect have been popular pretty much from day 1. Better still, if there was an option, you could choose not to exercise it if you felt that the result would be “rather awful”. If people in MP see it as an exploit, then they still don't matter and they'd be objectively wrong even if they did. The game needs every option it can conceivable get, because there will always be a desire to turn something off for any number of reasons. The only “done right” variant that wouldn't create that would be if the reflections didn't exist to begin with. That is, “done right” would be “rather awful” according to your tastes. And that is exactly why more options is better than any attempt at one-size-fits-all.

It really doesn't. Even with a better solution in place, you would still come across situations where you'd want to turn in off. And just because it can be turned off doesn't mean there won't be situation where you'd want it to be on and see a better solution. There is zero connection between a quality option and an on-off option. …except for the ones who don't think it's well done. And the ones who think it's ugly. And the ones who want their frame time to be as small as possible. And the ones who still can't see through it properly, which was the problem all along.