Tippis

We'll see. I've given them my files, but I suspect others have as well. For anyone interested, they are here: A-10C_MFDs.zip and A-10C_2_MFDs.zip for the A-10C and A-10C II respectively. Use your favourite mod manager to plonk them into the module's Input/Joystick directory and everything is opened up.

I can do you one better. These are the files needed for the A-10C, cleaned up and modded to include all the relevant inputs (so no axes and no FFB): A-10C_MFDs.zip …and these are the same files for the A-10C II: A-10C_2_MFDs.zip They just need to replace the existing ones in the modules' input/joystick directories, and will retain the same default binds while opening up all other controls to be bound as well.

Just noticed this old thing while doing the rounds as well, and this is the same problem. For various reasons, this ancient annoyance just popped up for me and I feel it needs to be addressed at some point. The problem is that the A-10C module comes with a pre-defined bind template specifically for the MFDs, and this template blocks out all other bind capabilities. No other functions are available to be bound and the UI reflects this by greying out binds that do not specifically match the button config. A “left” Cougar MFD can only ever be bound to left-MFD fuctions. A “right” Cougar MFD can only ever be bound to right-MFD functions. No other binds are available because the module hasn't defined them for these input devices. If, like many do after the Hornet and Mudhen came out, run with triple or quad MFDs, the A-10C module still only sees those as 2x Left MFD and 2x Right MFD, and all those extra buttons can't be used. This can be bodged by hard-modding the module and adding all other binds to the templates, but of course, this gets wiped by every update and require a mod manager to maintain (not to mention that if you're not careful, your “incorrect” binds will be wiped as well). This is a long-standing error in how the module has been made to match specific input hardware, but done in a uselessly restrictive way so that you are not allowed to use that special-supported hardware in any other way than what the module programmers imagined. It is actually pretty trivial to fix — just about every other module that detects and default-binds the MFDs can handle it just fine so it's already a solved problem. ED just needs to do it for the A-10C as well.

That is not the problem. The problem is that the A-10C module comes with a pre-defined bind template specifically for the MFDs, and this template blocks out all other bind capabilities. No other functions are available to be bound and the UI reflects this by greying out binds that do not specifically match the button config. A “left” Cougar MFD can only ever be bound to left-MFD fuctions. A “right” Cougar MFD can only ever be bound to right-MFD functions. No other binds are available because the module hasn't defined them for these input devices. If, like many do after the Hornet and Mudhen came out, run with triple or quad MFDs, the A-10C module still only sees those as 2x Left MFD and 2x Right MFD, and all those extra buttons can't be used. This can be bodged by hard-modding the module and adding all other binds to the templates, but of course, this gets wiped by every update and require a mod manager to maintain (not to mention that if you're not careful, your “incorrect” binds will be wiped as well). This is a long-standing error in how the module has been made to match specific input hardware, but done in a uselessly restrictive way so that you are not allowed to use that special-supported hardware in any other way than what the module programmers imagined. It is actually pretty trivial to fix — just about every other module that detects and default-binds the MFDs can handle it just fine so it's already a solved problem. ED just needs to do it for the A-10C as well.

They are very obviously not dot labels and they can already do the thing you claim they can't. The problem is that you don't understand what the various dots we have are, what they represent, or how they work. Nor do you understand how monitors work. It's these technical details that keep tripping you up when you say that the system you claim you wanted but then didn't but then it was fine but then it wasn't doesn't work like you want to. It's because you keep wanting new things, and none of them actually relate to the issue at hand, and none of the arise from any of the technical aspects you complain about. And you always complain. You never offer any kind of constructive input or… you know… feedback. The only constant has been that you are deathly afraid of some hypothetical advantage that someone might gain over you in a vanishingly small and utterly irrelevant PvP scenario, which itself goes counter to your previous claim about how everything was absolutely fine in PvP because of the advantages you gained over others. You're not providing feedback, though. To do that, you'd have to know what on earth you're talking about and at no point in the entire history of spotting discussion in DCS has anything you've said every been even remotely related to reality. Every single claim you've ever made has been uninformed and objectively, factually wrong. You refuse to do the research. You refuse to learn how anything works. You refuse to actually use reality rather than your own imagination, and you always end up proving your own point wrong. That is not feedback. That is just plain old trolling.

It fixes exactly what it is supposed to fix, and while the original is old:ish, it's still aeons ahead of the even more antiquated system DCS is trying to use and iterate on. That system has been abandoned by everyone for very good reasons. If you can come up with something more feasible and easy to implement, please elaborate. The fact that you call this "the only solution" in response to a post that explains that it isn't is interesting too...

DCS needs it too if it wants to be a good simulation of air combat. Your dislike for proven systems that solve this whole problem is not sufficient reason to keep DCS in the dark ages.

They exploited the old system. You know this because you were one of them, and your screenshots of the excessive visual range some people could get out of the system where others didn't was a crucial part in nailing shut the coffin on that system. Ironically - as always - because you tried to argue that this excessive visibility meant the system was working fine and actually people just needed to git gud. The fact that you could see things that far out and that this was obviously nonsensical and unfair just didn't hit home for some reason... that we can all guess. Then you realised that the same system could be exploited to your disadvantage, and suddenly it was the worst thing ever and you campaigned hard to have it changed. Remember that? It really doesn't, but not for the reason you want to suggest. It doesn't prevent "the easy exploit" because your imaginary exploit doesn't actually exist. So there is nothing for the setting to prevent. Quite simple, really, and as such you will undoubtedly not be able to grasp what is happening. Actually, it did. That was why it was so popular and why even "serious" servers concerned about game fairness and integrity would shut off IC to make sure it was still possible to use. The problem we have now is that only the basic concept of that mod was integrated into the game, but they skipped over any of the tweaking that had done with it and instead started from scratch. To be fair to ED, though, they kind of had to because of how it now integrated in the actual rendering loop. No, it wasn't. You know this because you were consistently part of the topic, trying to shut down any conversation that threatened the new system and your ability to exploit it. It's pretty trivial to dig up the 8+ year-long thread of Why485 and others trying to explain basic graphics and gameplay to you, starting with how and why the impostor system didn't work and how and why the new dots were only barely better. The topic wasn't dormant. It was just not going your way at any time and you desperately tied to shut down the conversation. That obviously didn't work because here we are. You're still not getting your excessive-visibility exploit back, and if it turns out that one of the settings re-enable it, guess what will happen? That setting will be banned from MP if not outright removed from the game. So be careful (once again) what you wish for.

The player isn't in the game. The virtual pilot is. You cannot simulate the player. You must simulate the pilot. This isn't about what the player sees — that's indeed on them — but about what the pilot sees that should be offered up to the player for them to notice or not. The game must offer up a realistic selection of details of the game world that matches what a pilot would* see in that situation. That may (hint: will) involve excluding details that the player might spot because the detail level our display systems are capable of exceeds what the pilot's vision can handle (eg. distant targets, or just very small ones). It may also include adding details the pilot would not see IRL, at least not in that particular manner, but which need to be conveyed to the player to give them cues the pilot would have but which can't be displayed properly on our systems (eg. glint, fine-grained parallax, proper contrast against the background). That last part also includes countering the effects varying FoV and display resolutions. You seem to be confused what I'm promoting here, and what part of the problem I'm trying to address. It's not about using in-game tricks to compensate for the player not seeing things — it's about using making sure that, when the player does or doesn't see something, it's on them, and not because the game isn't showing them the right thing. * “Might” is probably the better modality here, veers into issues of what should be filtered and what should be left out. If we're going to do the thing where we rely on the player to spot or miss things, we need to interpret it as “everything the pilot could possibly see”, under the assumption that the pilot is at all times looking in every conceivable direction the player could look at. This is not how the pilot sees the world — they're only looking at one thing at a time, after all — but it is how we must render that world to give the player the ability to look at whatever they want to look at. It's not that the player should be given perfect information. Quite the opposite. It's that the player should be given accurate information that they can then succeed or fail to process and make use of. To create this accurate information, the pilot must be part of the simulation, same as how we simulate the plane to give the player an accurate behaviour of that horrid lump of metal, except this simulation must extend to the entire drawn field of view rather than just the focal point in the middle. We must simulate what the pilot could see so we know what they player must not be allowed to see as well as what the player must be given a chance to see. Hence why we need dots — so we can filter out long-range targets and not show them to the player even though the display system can draw them. You may not like it, but it's the only way to combat pop-in at higher resolutions. Hence why we need scaling — so we can cue aspect changes and show them to the player even though the pilot would not see targets vary in size like that. You may not like it, but it's the only way to convey the proper cues on conventional current hardware. That only works if the game and its options create a situation where targets are “correctly spottable” (for the lack of a better description) and can be sensibly adjusted to begin with. They never have been in DCS for various technical and political reasons. Part of that is the insistence on showing naive geometry and trigonometry to draw targets way outside of what the in-game pilot should be able to pick up and showing them to the player as if it was the most natural thing in the world to have targets show up at 40nm+ ranges, and using very simplistic cues that flicker on and off to make targets disappear and/or reappear when they shouldn't. Or to oscillate between the two states to make them show up like pixel fireworks when they should be barely noticeable. Some of those are just bugs that need to be fixed. Some are missing settings, so you can't actually do what you're suggesting. And some of those shouldn't be adjustable and just be part of the core simulation. To fix this, the rendering of contacts need to be made realistic, and potentially new options need to be added to tweak that rendering in line with all your other local settings. FFS, this is a new level of astonishing achievement in ignorance, even for you. You are complaining about a problem that doesn't exist because its supposed downside has already been solved, and you are calling it an exploit that some people don't care to use this setting?! GTFO. Nothing. If something breaks, you fix the mission to not have such dependencies. Like everything you've ever complained about, it's a solved problem and you're just not informed enough on the topic to have any valuable, rational, coherent, or useful input. You're just looking to invent new imaginary problems that don't exist so you can complain about “exploiters” because you don't know how anything works.

In other words, a full-spectrum simulation of pilot's vision. Because that's the RL view, done as best as possible. We're dealing with a simulation. The end goal is a good simulation covering as many aspects as possible. Vision is one of those aspects. That much should be obvious. That's not what your screenshots show, though. Don't you think it's about time you learn how resolutions work? It really isn't. You just think that “exploit” means “thing that is not what I want”, when in the real world, it's getting an unintended and undue advantage from flaws in the system. That's not what's going on here. Instead, what's happening is that people get to choose (or not) their visual setup to match their hardware and room setup, fully in line with how the system is intended to work, and by all accounts working better now than ever before. That is the very opposite of an exploit. Just because you can't exploit it to get an advantage over others like you want to doesn't mean others can and will do the same to you. It just means it's the same for everyone, which again makes it inherently not an exploit. What you can imagine is of absolutely zero relevance to anything, and doubly so to this topic where you have demonstrated your inability to imagine that people see different things — in particular, that they don't see giant squares. This is particularly hilarious in view of how you have shown that you also don't see giant squares. You have consistently failed to produce any evidence of any such effect happening. You can keep crying about your hallucinatory giant squares and your imaginary exploits but none of those actually exist. Until you start complaining about real things, your opinions and imagination is invalid, wrong, and devoid of any value or contribution to the conversation. Just be happy that you got the option you were clamouring for, even though — as predicted — it ends up not doing the thing you want, largely because you don't understand what it is you're actually asking for and can't articulate a problem that your desired solution should solve. That's not what happened, no. That's just more imagination on your part.

Sharpe will never be happy as long as it does not let him give an advantage over others that they can't control. Every time he has flipped on this issue, it can be traced back to him realising that what he just asked for does the opposite of what he wants by giving others the same advantage he has, or by removing his advantage over them. He then pivots to some new fundamental misunderstanding of how the game or computer graphics in general work in the hope that this will give him an advantage instead. Personally, my preference is for there to be no setting at all. It's a core part of the simulation. You shouldn't be able to turn that off, same as how you can't turn off drag or gravity. It's the same level of integral part of what is going on in the air. The end goal here is a full-spectrum simulation of pilot's vision, with all this entails in terms of offering whatever cues and shortcuts elementary 3D graphics can't provide on its own. This means dots, scaling, forced fading, over- and undersaturation of colours, and any of the myriad of things that will help convey the cognitive process of perception as opposed to inherently incorrect naive maths. It's called contrast. Another basic part of graphics you will no doubt fail to grasp because of how very simple it is to understand and somehow try to make the foundational part of yet more accusations of exploitation. There is no exploit. Give it a rest. There is only you remaining wilfully ignorant about how computer graphics work. Just because you don't get the advantage you want, doesn't mean others are exploiting. Especially not when your own “evidence” shows that things have improved massively over your old preferred state where you — and not necessarily others — could trivially see targets at 40nm. That was an exploit. And you exploited it gleefully and to the fullest. And stop playing in portrait mode.

So it's working as intended then. For the bajillionth time, you try to make a point but instead accidentally prove yourself objectively wrong. You have shown that it is not an exploit. Congratulations, case closed. You do understand that players being able to pick their own settings is a good thing, right? And that just because they don't use the same settings you want for yourself, that doesn't mean they're doing something wrong. Right? …right?

No. Just an in-game setting. It is how all mission settings work. If that's the nonsensical notion of “exploit” you have, then you need to ban yourself from all MP servers because you run at whatever resolution you've set because the server allows you to play at that resolution. Are you willing to stand by your definition and do that? Or admit that it you're just trolling? Those are your only two options.

Most likely, you're affected by the dot culling bug, which gets triggered reliably, but unevenly depending on what else is spawned in and in what order, in the direction you're looking. For bonus funpoints, the dots are culled front to back — i.e. you lose closer-in targets first, so things you are meant to see, you don't, and things you're meant not to (or at least struggle with) show up very clearly.

So don't use a lossy format. Simple.

You can, if you do it right, but it's a bit of a bug… some might even say an exploit.

And fixing that is exactly what the spotting dots do. They're already an improvement even if the end result sill make them show far too far out and even if the end result skews towards the too obvious. But you're not getting your 40nm spotting back, nor are you getting back your precious advantage over others who don't see targets that far out — the tweaking continues and we'll end up in a state where you will have to play on a level playing field. Sucks, huh?

…in pure measurements, but those don't matter. It's what you see that matters. That's what the graphics need to simulate. That's where scaling has a place in simulation. Again, if we want to have an actual simulation, we can't rely on something as simplistic as just trigonometry. That is not how we perceive the world. It's the same mistake as all the old nonsense about our eyes only see [some random number] frames per second, so that's what the monitor should display. It's a cognitive process. We want to simulate a signal processing machine operating on bad data. Trigonometry will not yield a realistic answer. …in 15-20 years when we can also assume that everyone runs on >90°-coverage displays with sub-MoA pixel densities, raytraced, HDR, eye tracking and foveated rendering and player distance ranging — even in pancake — and are absolutely not allowed to change their settings in any way. But what about here, now, and also any time the player can choose to change their settings? Whenever we need to have a hard cap on how far out targets are rendered (and this will always be the case) because otherwise targets are drawn, and thus can be seen, when they shouldn't be. Or they will pop in and be tremendously obvious, when they shouldn't be. There are no good or even viable ways around this to create a realistic result other than a solution that uses scaling for intermediate distances and non-geometric rendering at the extreme limit of vision. It is also vastly more trivially implemented than all the other rendering techniques to hide distant targets, and more tweakable to reach that realistic outcome. It also solves the problem of leaning in and having a zoom function — an infinitely less realistic feature than scaling could ever possibly be… but where's the campaign to get rid of that? If realism is your goal, and you want it now rather than in DCS 7.0, you need to overcome this false notion that we should forego realism because the numbers feel wrong. …both of which could be solved with a spotting simulation that didn't try to rely on a single solution to solve a multi-levelled problem. …and that's exactly why it's a ultimately a bad idea to let people turn off the dots, ironically enough. And let's not forget that you were all in favour of such an exploitable and unequal system when you were on the beneficial end of the equation, and have been campaigning hard against all attempts to make it equal and non-exploitable.

No. Smart Scaling was intended to make the aspect of small-to-medium objects more realistically identifiable. It is not a spotting solution — it's a simulation of perception to accurately convey cues used for tracking an already clearly visible target. Scaling is not about making objects visible — the objects are already visible so that would be pointless. As long as you assume that is about object visibility, you are objectively wrong and any everything that follows from that assumption — all claims, arguments, and options — are incorrect and absolute nonsense. Zoom does not do what scaling does, nor does scaling do what zoom does. That's why zoom is a separate thing that exists alongside scaling (and why proper scaling algorithms take zoom into account and-counter-scale to remove the effect). It would help your case if you read up what scaling is and what it does so you don't make such silly mistakes out of sheer ignorance about the topic. …which is exactly how it woks for everything else that isn't a background object. An aircraft carrier is not a background object, and as such would be scaled to match as well — not that you'd be able to notice at the distances where it's really active. You'd know this if you had any idea what smart scaling is; what it does; what its design intent is; how it works; or… anything about it really. Graphics in a simulation should obviously… you know… simulate what you see. Otherwise the result is unrealistic by very definition. Why is this even a question? Not quite. It is now becoming a resolution problem in the opposite direction, where naively using “real” angles and scales creates a hugely unrealistic outcome because the game renders — and the display shows — far smaller details than you should be shown. As such, the rendering pipeline can't just throw pixels on the screen where they “should” be according to maths; it has to simulate the limits of perception to not put pixels in where they shouldn't be seen. Scaling is an increasingly more necessary part of that package unless you want to create jarring transitions from one state to another, with the target popping in and out of different degrees of visibility, and unless you want to introduce harmful differences between different display systems and setups. It is obviously not the only solution, but there is really nothing else that can do the same thing in its particular range band.

He doesn't. He only goes by his own fantastical assumptions and dreams because those are better demonstrations of how the thing works than the thing itself, somehow. He even admitted as much when after a long slugfest, it was eventually dragged out of him that he actively refuses to read the research and look into the matter, because once again, he uses fantastical assumptions to fill in the gaps and reading actually looking it up would obviously reveal those assumptions for the nonsense they are. You will never convince Sharpe that reality doesn't match his fantasies, and as such, any argument based on reality and facts will not work on him. The general rule is, if Sharpe says something about scaling, it is false. He has no idea what it is, how it works, what it looks like, or what its purpose is. He doesn't want to know. He just knows that he's against it because people suggest it as an improvement to the game, and will invent any number of increasingly absurd falsehoods to “support” that position. As amply demonstrated in this and other (merged) threads, he also doesn't understand how resolutions work, or monitors, or basic trigonometry, or angles… so the same general rule applies there as well. Just look back a few dozen pages and watch him trying to argue that 4000 is 3000 and 50 is 60, because if they aren't, his attempted argument falls apart.

Getting the AI to not see through the airframe and terrain was a major milestone. Fog and cloud is… aspirational, let's call it.

It can. We know this because it has been. You would notice them. It's the system that wouldn't be noticeable — the contacts would. That's the whole point of the system. The rest is just you not bothering to understand what dots do and why they exist. There is a point to having them. You just refuse to understand it because you want to get your exploit back and a functioning system won't give you that. It's about time you give up. That's the only way you win and to get your exploit back. But that's not the end goal. The goals is for you to lose and for the game and all its other players to win. That's why it is the worst idea imaginable to get rid of the system.

The same way it would any other display: by asking. The game knows what resolution it renders to. Again, they're not magic.

The same is true for pancake mode. It's still a matter of rendering resolution vs display resolution vs display size (or more accurately, expected frustrum coverage). A display is a display is a display — the difference VR makes is that expected coverage, but it is ultimately no different than what you have to do to get the dot suitably (and equitably) sized for regular monitors.

…aside from how it's actually pretty much a solved problem where DCS is lagging behind other games and one of the main obstacles in making the game better is that it rests on a positively antiquated code base with some pretty bad design decisions built into its foundation.