Tippis

Sure it is. Just because similar issues exist elsewhere doesn't mean it's not a problem with the incorrect JTAC implementation. It's not just incomplete. It's inaccurate in a way that infects the accuracy of the things that are supposed to be the one thing the game gets right: the aircraft modules. Arguably, it's not even an approximation because of how wrong it is. And if you're going to go “so what” about that, then you've just pulled the rug out from under your own objection. Even if it would be “a major shift of the JTAC role, normally a facilitator of air strikes on behalf of his CO” to allow player control over the JTAC (thereby giving it the ability to prioritise targets and execute some kind of intent)… so what? You do when it becomes clear that there's nothing there to salvage. I suppose some of the samples could be retained…

Not even. That's the problem: the mission builder has very little control over the JTAC, and giving any control to anyone, including the pilot would be an infinite improvement. They'd need slightly different controls, sure, but still — either would improve things to no end. And that's before we get into the whole “battlefield commander's intent” part, where a completely different player than those two would need to given controls they don't have. Not really. It was meant to give the A-10 the means to run through a very rough and inaccurate outline of the procedure to run in on a target. The F-5s, M2k etc all came later and exposed how backwards and wrongheaded JTAC was, since it would dictate to you what laser code you should use. Which, as that whole business was done correctly for those modules, meant that JTAC didn't actually work properly with those planes. It only works (and I'm being very generous here, given how easily it breaks) with the A-10, and some later modules, that all model the whole thing incorrectly. Sure you can. Because in one fell swoop, you expose just about everything that is wrong with the current system and why it needs to be ripped out by the root and replaced with something useful. As it happens, part of that usefulness (especially in light of the slow movement towards more continuous, not-just-a-single-flight — to say nothing of larger-scale campaign — experiences) can only really be served by giving the means to offer the player a level of control that, realistically, perhaps they shouldn't have, but which needs to be there. With CA, players are already more than pilots, and that's all fine and good. They (and also the mission makers creating content for them) just need to have the tools and options available to them to actually make use of what's available. It's just a matter of implementation how that control is afforded, be it via F10-map unit controls or via radio commands or via some other mechanism. But ultimately, it needs to be there. If the level of control bothers you, then the game already offers the ability to take it away — role restrictions, unit control restrictions, and CA control options in general, can be set with checkboxes. Too-much-control-problem solved. If it doesn't bother you, then having the option is almost by very definition better than not having the option. Thus: it is already something that it shouldn't be. Any change to it — I'm tempted to even include its complete removal — will make it better. e: In fact, let me break it down to make it less abstract and show why I hold this position. On the one hand, I can have Inaccurately modelled planes, carrying Inaccurately modelled weapons to accommodate Inaccurately modelled JTAC that offers no real interaction and can't be controlled. On the other hand, I could have Accurately modelled planes, carrying Accurately modelled weapons but to accommodate those, I would need Inaccurately modelled JTAC, but it is interactive and can be controlled. I can see no cogent reason why the former should be preferable over the latter, even if the latter meant I had a bit too much influence over the JTAC rather than the other way around.

It is already hired help. The problem is that it's a very poorly paid one that delivers a service of matching poor quality. That's all the current implementation is meant for: as a highly simplified way to get the player through the basic outline of a run-in procedure. These simplifications are why tons of modules have been infected buy the ass-backwards way of managing laser-guided weapons, where the planes have to have fantasy systems to compensate for the shortcomings and brittleness and incorrect dictates of the JTAC script. So yes, if it turned into something actually helpful to the flow of the battle, then that would be a huge improvement. Being a hired help is what it's there for.

It already is something that it's not IRL. Any change to that will inherently make it more realistic.

No, it was clear what you meant. What I'm saying is that you run into the problem of what the dot is suppose to be: a representation of the smallest thing you can see. If it were any larger (e.g. because you changed your FoV to make it not-the-smallest any more), it shouldn't be a dot but rather transition to using the 3D model. With a bit of fudging, you get a small sliver of room to play with — maybe it's arguable that at below, say, 4×4 pixels, it may just as well be a blob because the 3D model won't reveal any additional details anyway. But you still run across the same boundary issues: how small should the dot be at its smallest? 1px? Then resolution will matter and cause the problems we had with the old system, where you benefitted from having a lower resolution. How large should it be before it transitions to the 3D model? 2×2? 4×4? Then you run into the problem with close-in displays (eg. VR) where the blobbiness will be very apparent just before the transition, and you may end up recreating the issue many are having where it's easier to spot the blob at a long distance than it is to spot the 3D model at medium distances. How should it deal with smaller-than-smallest situations, irrespective of how small that is? You then need to play with colour fading as a function of how visible that smallest dot should be, and we get the current issues where the fading doesn't properly take the background into account. It's not that what you're suggesting doesn't work — it's that it would only work or make any real difference within such a small band of contact sizes, between “should not be rendered at all” and “should not be a dot”, and we're talking about single-digit pixel numbers between those two boundaries, that it's questionable how much it would solve compared to how much it would introduce new (or reintroduce old) issues.

Yeah, it's not a huge error — ± a percent, or three which is why it seems to fit a curved monitor's “real” width. And I suppose it makes sense since the main point of the tool is to get that three-screen, slightly wrap-around effect right, so maybe it just uses the same assumption of an implied curvature for the single-screen calculation as well. That or some rounding error when converting to or from radians. …of course, there's also the issue with getting the accurate FoV in DCS and having it accurately scale with the real aircraft. That last part in particular has already shown to be an issue, and the first bit has an annoying tendency to break when you try to get fine control over it

You should probably try to figure out your setup, then, so you don't have to sit a meter and a half away from your screen. Among other things, it seems to be assuming you have a curved screen.

It's not 16×16 on any device, for starters. It's more like 2×2 + a small fade zone that may be dependent on stuff like AA settings (and AA “aggressiveness” for the lack of a better term). The problem seems to be partly in that extra zone, where it gets overly dark under some circumstances, and then made worse still depending on whether the screen does any post processing on its own. If you have a system where physical and effective resolution differ (like how some high-DPI modes or good old “retina displays” work), that might inflate it further, of course depending on where the scaling happens. As for changing the size of the dot as a function of zoom, that would work… to a point. You'd still quickly run into the problem we had all along, where the minimum size would now vary according to what the screen is capable of, so your minimum size would be smaller than mine, letting you see things more easily, and someone running at a lower resolution would get larger dots still. So we arrive back at square one with what this revamp is trying to get away from. You'd also introduce the opposite problem where it would run the risk of being absurdly large before it switches over to rendering the full model. The range of sizes that would make sense for this adjustment is very narrow, especially compared to the range of FoV adjustments available to us. We're dealing with a detail that is pretty much defined by “being the smallest thing possible”, so making it smaller or larger as a function of zoom doesn't offer much wiggle room. The problem is also that for such a calculation to work equitably, it would have to also figure in the real world FoV of the player, which means it would have to depend on being fed some parameters of the user's physical setup — raw pixel density of the screen you're using and the distance from that screen. Depending on how good (or willing) the display drivers are as far as reporting things like your PPD modes, they would also have be set manually by the player. Otherwise, once again, your on-screen 0.2° dot will be of a different size than mine, and correspondingly easier or harder to see. And thus, we arrive at a better, but similar situation where the player can simply lie about the parameters to make the game show dots larger. Now, granted, that's such a minuscule problem that it might just be worth ignoring, but some insignificant portion of the player base will be all up in arms over the perceived PvP imbalance such an improvement would cause, and… well… we'd have this thread all over again.

You don't need zoom to simulate that on a monitor. In fact, just about any modern monitor is able to display that kind of visual acuity at the default FoV. Again, this is you claiming things without any understanding or experience of the issue at hand. What you're saying here is simply not true. It's just something you assume based on… who-knows-what. You understand that, by saying this, every single complaint you've had in this thread and every thread that preceded it, is null and void. According to you, you need to stop whinging.

You don't have to. You just get a different advantage than the other guy. But again, that was always the issue wasn't it? As long as it was you who had the advantage, the other guys' disadvantage was just them doing it wrong. When it was discovered that they had an advantage of their own, it was suddenly the end of the world. So you are in favour of the new system, then, since this particular issue has been improved significantly. It's far less of a joke now than it ever was. But then, it doesn't actually make multiplayer a joke to begin with… you're just over-generalising from one particular use case and perspective.

No, that's not actually what was said. But you already know this. You are just so absolutely against this methodology that you are — by your own admission — clueless about that you must lie at every point to try to paint your baseless fantasies about it in a bad light. The point of the image was to show to you that even if your ignorant and baseless assertions about how it would look were true — and they aren't — you conclusion would still be wrong. So either way, you'd be wrong. At no point have you ever been able to demonstrate that your claims and fantasies have any correlation to any known reality. Wrong. The trouble is that you falsely believe that it works that way because you refuse to read up on it or look at any implementations on it, and instead rely on your baseless assumptions. You have no idea how it would look because you have never seen it. It really isn't. Scaling is an alternative to the current solution which would be a very viable way of implementing what's needed in case people are not happy with how the dots turn out. You know, the point of the thread: feedback. The more you fight against every attempt to improve spotting in DCS, the more likely it is that the devs end up reversing their previous stance (and remember, that stance was in part based on them misunderstanding their own code…). Nope. Computers don't work that way. To add to this, it's also worth nothing that he's not against people having advantages in PvP. As long he's one of those people. It's when others have advantages that he doesn't that it suddenly becomes a problem. This is why he was so very adamant that the old dots were fine, and why he used the ridiculously unrealistic spotting distances to prove that, actually, it was just everyone else being bad for not spotting things (you may have noticed this argument come up again here). But the second he realised that this system actually provided others an advantage (due to their hardware and software setup) that he didn't have (because his hardware and software setup gave him a different advantage), it was suddenly the most horrible thing ever and must be changed. Just not to anything that works. Because then he would lose his advantage.

No you wouldn't, because that's not how scaling works. You'd know this if you had actually tested it or read up on it or done anything other than make up guesses based on pure imagination.

Unless you're deep into the mess of nested OR conditions (where the grouping and order of evaluation is already very murky), it's usually easier to just set a condition that cannot possibly be true. This has the benefit that the testing happens when it should happen, it just doesn't trigger the action, whereas if you change the trigger type, you might end up with no testing at all. For the most part, this shouldn't matter, but once you start doing performance tweaking and mix in scripts, it can turn out to make a difference to a surprising degree. But yes, if the purpose is to not have a test at all, then a separate dummy trigger type would indeed be handy.

The problem with the old system was that no-one was on the same song sheet to begin with, so forcing the spotting off wouldn't actually achieve that goal — it would just lead to a different kind of “I don't know what the other guy sees” than if you let the clients choose. To an extent, you'd probably want the exact opposite: the ability to force it on so you can at least be a bit more certain of the outcome.

Everyone gets to pick their preferred solution. No-one is left out. Seems about as good as it can be. Not to mention that we're still on the first iteration and it has already delivered vastly improved visuals and realism if you set it up that way.

Even back in 2.8, to truly turn the dot off, you'd have to inject something into the rendering pipeline to suppress the dot drawing. Why485 should be able to explain how his mod works in more detail, but I think – and he'll have to correct me if I'm wrong – that it mostly just adjusted the dot to be a lot more reasonable because to go deeper would not just be tricky but trigger all kinds of tampering alerts.

It sort of does when you're tying to point out problems on a per-pixel detail level and the format you choose inherently creates noise on that level and therefore might show flaws that don't exist, or fail to properly represent other flaws that do. In addition to what Why485 said, the difference was also a combination of the render distance (which basically set a hard cap on the drawing), the FoV (sort of set a variable cap on how small an object could be represented) but also the screen resolution. It was in large part the interplay between the two latter, and especially the engine's over-eagerness to start drawing dots at even the slightest hint of potential visibility, that caused issues. Something that, at a given FoV and resolution would be a sub-pixel object would still be rendered because it was under the hard-cap drawing distance, and it would have to be significantly smaller than that pixel for the engine to just say that, no, it shouldn't bother with it. That's how we arrive at the situation where lower resolutions would show contacts more clearly: the pixel was larger, the engine was very keen on still drawing sub-pixel objects (thereby ballooning their size to the minimum available: 1px), and with the ability to zoom, it was rarely the case that a given contact was small enough to be ignored until it hit the hard-cap maximum range.

And that is exactly why you shouldn't use jpeg as your format. It almost makes it seem like you're running with dot labels on. PNG is the way.

You really need to stop using jpeg since it heavily distorts the visibility of pixel-level details.

When I can only fully agree with Sharpe, you know something has gone wrong And no, it wouldn't really make sense to have them create a vastly more complex game that can use pretty much none of the previous parts, and then give that away for free in the vain hope that anyone cares about not flying their planes their flying-planes game. Lol SC.

It would also help if every variety of “N bombs on an M-size rack” wasn't listed, and you could instead either add racks separately that then folded out in more slots to fill, or if each slot already had a rack display where you could click in how many you wanted to fill with a specific ordnance.

Not really, no. If you have a desire to only ever look at aircraft up-close and in complete detail, you need a bigger hard drive. But that's no different from any other optional liveries you might want to add for purely aesthetical reasons. Doesn't really matter, now does it? Optional liveries are optional and DCS already handles those just fine. Coincidentally, it could handle the base liveries the same way of those were made optional, making the whole argument against this largely pointless.

We really don't. Beta is almost categorically more stable than stable because it received updates sooner and stays broken for a shorter time. “Stable” isn't stable in the sense that it doesn't wobble as much — it's stable in the sense that it doesn't change as often. But that kind of stability only matters if it's a huge faff to stay updated, and it isn't. DCS isn't a mission-critical 24/7 99.9% + redundancy uptime service.

Nice! It's not entirely clear whether the table references fighters or bombers, and with bombers taking up about twice the number of “divisions” along each axis, that makes a bit of a difference. Still, as a baseline it works well enough since modern fighters sit somewhere between the two. Translated into units we're more familiar with, we get: Distance Features visible <5.4nm Small black dots <4.3nm Silhouette in the form of dots <3.2nm Silhouettes with no details <1.6nm Contours of plane and fuselage <1nm / 6500' Shape of plane and fuselage; contour of tail <0.5nm / 3300' Signs, racks, chassis, tail <0.27nm / 1600' Racks, braces, struts, ID marks [Citation needed] Especially since I sincerely doubt you have ever seen DCS without dots and are just guessing based on… absolutely nothing. Because no, no it's not. Without dots, you see far more than that at ranges far beyond the 10km listed. We know this because you've already described it and taken screen shots of it. You describe them as very visible at 5nm, when they should be small dots or just outright invisible. You have a screenshot showing silhouettes at almost twice the listed distance. You're seeing tail and chassis details at what your screenshot name suggests is 7nm(!) which is seven times more than it should be. The dots are not even a factor here — you are already looking at a 3D model so you'd see the same thing if you managed to cajole DCS to not show any dots at all. You then go on to call that realistic, and now you claim that it matches the old spotting tables in spite of being off by at least a factor of 2×. Cripes.

Yes. Bombs generally can't — it's something dialled in on the ground. DCS has had this backwards since the dawn of time.