Tippis

It's a bit unclear what you feel is missing. The new cinematic camera can do a lot of what you had to do manually with the F11 camera before, and of course, the free cam itself is still around (with proper WASD controls and even a “sprint” button to move around really quickly). The old controls still work, but have become a bit more complex with the new options they've added. Are you looking for specifically a speed matching function so you don't have to fiddle with the mouse wheel to stay in place? Is it the ability to look off-axis (without using headtracking, which sort of provides that by default)? Or is it the behaviour while the game is fully and/or active paused that you want changed?

The goal isn't really to make it fair and balanced, as such, but to make it less a product of your hardware, because ultimately, if it was possible to make the display system a complete non-factor. Spotting being entirely a matter of player skill — being able to see things properly with their own eyes — rather than due to the hardware they're using would be the most realistic outcome. It's part of the simulation: not just the planes, but the pilots flying them who should be seeing the same thing and therefore that's what ideally should be presented to the player. Now, it will obviously be impossible to make your display and settings be 100% irrelevant, but any move in that direction is still a move towards better realism and towards that simulation of perception you (and many others) are dreaming of. Player acuity isn't really a part of what they're trying to deal with here — that would require very different mechanics and be part of the player display settings anyway. To an extent, the ability to modify dot labels could be seen as that, but that's not really a feature they're advertising. It's not about taking the player out of the equation, but about making the hardware factor as invisible as possible. Sure, why not? The setting is there exactly for that reason, and whether it defaults to on or off is more of a customer-statistics choice if anything. Now, the reason it isn't on by default for most of them is probably because the assumption is that most players will have more complex controllers.

It's called "first iteration of a system". It needs tweaking, and as such it needs input to get the tweaking right. This is not a matter of a superior attitude but about explaining how you'll be better off offering constructive input rather than digging your heels in and demanding to go back to a worse system. The one about the previous system offering a level playing field, you mean? The problem is that it didn't. it just offered a system that was unequal in every every direction and often in a way that was completely counter-intuitive (like getting benefits from having a worse system and downgrading your graphics). Now, if you weren't familiar with those flaws, then I suppose that might have felt like something better but in actual fact, you were worse off for not having noticed the advantages others gained towards you. Now that you've ended up on the side that accidentally gains advantages with this new system, you obviously want those to be gone, and that's admirable. But going back to where others gained them without anyone being able to do anything about it is not really a way forwards. Continuing to improve and tweak this new system is. This is why I'm asking for your actual, constructive, input. Unfortunately, this means that your problem is less likely to be addressed. That is your choice of course, but it is an unfortunate one if you truly want there to be a fair and equitable system.

That is the solution you've clamouring to get away from ever since you learned that under the old system, other people had an advantage over you than what you had over them. Coincidentally, we had spotting dots before -- they were just worse than the current ones in a number of ways.

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.