Tippis

Yes please. You didn't even bother to skim the OP, did you?

For the in-game, it would make a whole lot more sense if it followed the nomenclature of the coalition the player was part of. With the way internationalisation and localisation already works, and with how there are already multiple options to change things like cockpit and voiceover languages, this could be a surprisingly simple thing to deal with. The mission editor is a different matter because there are a couple of different logics that could be applied. Having them be named consistently and correctly is a good start, but then what? Do you want them to be grouped by system/component? Purely alphabetical? What about components that are used in multiple systems? If we were to dream big, having an underlying tagging and searching system would get rid of most of that issue. That and/or just a sort toggle in the unit list.

Hell, just being able to self-designate a coordinate in CA would go a long way towards making artillery just that bit more useful. The sad part is, unlike with JTAC, I think most of the actual code is already there to make artillery viable. It's just the connection between one unit (or player) being able to transfer target coordinates to another unit (or player) that is truly missing. Even it were just the ability for one side to give a grid reference and for the other to go “ok, I'll mark in on my map” to start the targeting calculation. Sure, there could probably be tweaks made to the time to ready or the control precision and all that, but the interlinking is… well… the main missing link at the moment.

Again, it's not incomplete. It's outright wrong. That is the only excuse you need to change it to something completely different, i.e. something that is right. You're not getting what's on the box at the moment, and worse than that: because this thing isn't what it says it is, all those other planes also end up not being what it says on the box. So yes, changing it into something completely different — namely a functional and reasonably accurate JTAC — is the right way to go. The control issue that annoyed you is merely a player convenience in all of that: the AI will always be stupid. Making it possible for a player (be it in a commander role or directly from the aircraft, and again, there's already a way to lock out and separate those two roles and functions) to dictate what gets hit and what gets deprioritised might not be according to doctrine, but it is in accordance with good gameplay and useful mission design. Sure you do. Sometimes the bathwater turns out to be reactor coolant and the baby is already lost. Junk needs to go. The longer it lingers, the longer it stinks up the place. Again, we have already seen this effect in how the antedeluvian JTAC code has made a bunch of planes — even very recent ones — inaccurate for no good reason. Building on top of this junk pile will only ever create more junk. It has already happened and keeps happening. There is exactly two salvageable components: the lasing functionality (which is already fully detached from the JTAC function so nothing is lost there anyway) and a handful of voice clips. This would also offer them an opportunity to go through and optimise the whole thing and make it ready for everything else that is to come, such as the aforementioned dynamic campaign. It was built for a single function with no real eye to the future. It was overburdened from the get-go. Oh, and no, it's not really running. There's a reason why there are numerous JTAC scripting packages out there: because you simply cannot rely on the built-in JTAC to work for anything but the most basic single attack with the most compliant player. And that's not what people want from their missions these days. Again, it's a very simplistic script that cannot handle the dynamic situation it's intended to handle, and any deviation from that script on the player's part breaks and locks up the whole thing. You can't LShift+R a dynamic multiplayer mission just because you accidentally missed a step and now the JTAC won't give you the time of day for the rest of time. At a minimum, allowing the player to break in and reset that script — i.e. telling the JTAC what to do because it's not smart enough to do it on its own — would alleviate a heap of problems. It's still junk that keeps infesting other modules, though, so that's just kicking the can a few inches further down the road. No-one is saying that this wouldn't be a pretty significant task to undertake. In fact, that's fundamentally the whole problem: this is a function that was made incorrectly from the start and which has caused other modules to be made inaccurately. If a revamp is done at all (and it must be done at some point) it needs to be done from the very core, uprooting every darned silly thing the nonsensical JTAC code has imposed on other modules so that those modules can finally be made to work properly. It will be scary, yes, but so was multithreading. This actually already exists. They're not used much because they only really work with the A-10 (again showing how ancient all of this is). Part of that is because only the A-10 has a nav system capable of holding all that extra information, and part of it is because other planes handle IPs differently (eg the VRP and VIP modes in the F-16 or the different types of attack points in the Viggen). There's also the issue that, as other modules have come out and desperately tried to avoid dealing with that old stuff, they have implemented semi-duplicate functions in the form of per-flight mark points or target points or whatever-points to feed into their systems in a sensible way. And of course, none of that interacts in any way with other modules or with the game world, so the IP function has gotten pushed even further into obscurity over time. The level of pre-programmability varies and that makes it difficult to generalise, but yes, showing some of them on the map would be a good first step. As long as you could dictate which ones should show and/or for which flight. But that also highlights the problem: it's something that would have to be expanded to every module out there, and that's no longer a simple task. Especially since it would need to optionally override, sit alongside, or just outright replace some of the flight programming that's made in the mission editor. And honestly, if anything, that functionality should probably be tied into a much larger unified DTC functionality, which as luck would have it would also solve the issue of having umpteen different ways of setting laser codes and other weapon ground parameters.

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.