Tippis

That's not an explanation. That's just evasion. So presumably, you can't actually explain or you would have. That would also explain Sharpe's obsession with some mythical hypothetical in-cockpit planning tool as being the clincher as to whether the mission editor should be expanded with one of the most obvious mission planning features ever.

The reason they can AAR is because they have planned their fuel usage and because they know how long they can stay up; how long they have to chase down the tanker; how long it takes to get back. You keep saying this. What are you basing this on when we know for a fact that fuel planning is a core component of a mission package? You keep harping on about some supposed non-existence of a largely irrelevant on-baord system but what on earth does that have to do with the planning tool discussed here? Is this just another case of your never having actually used this part of the game and just throwing out random guesswork about it because you once again don't want to see DCS improve in any way? More to the point, why shouldn't DCS include something that is both entirely in line with how things work in the real world and is also a fairly easy thing to implement in the editor? Where does this opposition to making the game more realistic and fully-featured come from?

Yes. For two reasons: one is the more obvious one, where a longer total stick length + a fixed deflection cone means that, at the very tip, any given movement in absolute terms yields a smaller input angle so it's a lot easier to moderate small movements. It may be difficult to get a good feel for the difference between 0.5 and 1cm deflection, but with an extension, you might instead be dealing with 1cm vs 2cm and suddenly instinctively feel the difference more. It also helps smooth out any shakiness and jitter in how you can maintain your grip at a given angle. This leads to the second one: an extension gives you a longer lever to fight against the springs or other mechanisms that are trying to return your stick to centre. The less you have to fight that centring force, the more subtle and delicate you can be in your control, and that's on top of already having a better feel for the difference in position because of the longer throw. A 10cm extension on a 15cm stick (which admittedly is on the very low end) means you've almost doubled your throw and thus doubled your precision and halved how much force you need to put into it. On the longer end of things – a 25cm stick — you're still seeing a 40% increase, which is significant. The actual length becomes a balancing act between getting more of those two benefits and ending up with a stick that is half-way up your nose, where it either becomes unergonomic to handle or just gets in the way of whatever other controls you have clustered around your setup. You still want to end up with the grip in a comfortable position so a longer extension means you need to find a lower mounting or placement point, and before long, you get to the point where you can't use all that extra throw because your chair or knees get in the way, or you keep banging your knuckles against the table at full forward deflection. Going above 10cm will very quickly require trickier solutions to deal with all those issues so between that and the still-significant improvement in precision, it's a pretty good sweet-spot.

Another immediate suspicion, since it's just two specific aircraft, check that you don't have accidentally bound some other device to the same axis — DCS loves doing that automatically and with no regard for what's sensible and not — which could lead to the situation that the other device in in a default resting state that gets translated to full stick deflection, and then this gets propagated back to the FFB stick. This doesn't explain why it only happens on hot starts, granted, but still, double check the full range of axis binds on all devices in those two aircraft and see if you have a conflict. Similarly, you might have a button press conflict where some forgotten switch somewhere activates the “roll left/right” button binds, and it gets reflected back to the stick that way.

Exactly. So your notion that you can categorically state that it is “not very helpful” is just inherently false. Such a statement relies entirely on it being a fixed and static number for a specific aircraft for a specific map and a specific loadout, all of which are catastrophically nonsensical and incorrect assumptions. That's not a problem. In fact, that's kind of the whole point: you assume that it will happen and you need to make sure that the flight range for the setup covers the probable combat area by a wide margin to allow for said combat to happen. Hell, if it's well implemented, you don't even have that issue because you could just designate a set of WPs as “combat areas” and the calculator would mark up the fuel cost by 800% (or something) — everything else is already in there and easy to calculate. The reason you can't tell is because — as is always the case — you speak from a position of complete ignorance of DCS, of the modules involved, and the topic at hand in general. Because yes, they do. Hell, even in the one plane you supposedly have some fleeting experience, there is a bingo setting. Guess where you get that number from? In others, it is continually calculated in exactly the way you assume it isn't, on the fly. Just because you aren't familiar enough with the aircraft you fly doesn't mean their actual proper use does not include something else you're also not familiar with.

Yes, because there is only exactly one — no more, no less — aircraft in DCS and only one map size and only ever exactly one loadout that would assure that this ridiculous asumption was true. Oh wait…

Cars and buses already exist. Airliners have been suggested since forever but would probably run afoul of all kinds of licensing and IP issues, so it's the Yak and little else — more for business and legal reasons than for not being a good look. For actual people… well, there's the airshow crowd static, I guess? But if you start digging around, most of it is actually there aside from the people. The only unarmed model I can think of off the top of my head is the MANPADS commander models, which could conceivably simply be skin-swapped, but that would leave them pretty much entirely static and with some very weird luggage by their side.

No. My argument is that DCS, like all software, will at some point need to have its guts carved out and replaced with something new to better fit the hardware and software environment that has evolved around it since its introduction. This does not mean abandoning anything — it means laying the foundation for further developments that everyone (in particular third party partners) benefit from. As much as it has to. It's simply the cost of doing business and staying alive. …and there are a lot of potential DCS players that would replace them because they can now make use of and benefit from their modern systems; they will be able to enjoy facets that suddenly become possible that were missing from DCS and kept them away; and they will, invariably, end up dragging the old players back in since they are already invested. Can't keep an old dog down and all that. That's a whole lot of assumptions you're making to justify not staying with the inevitable game update that will (and must) happen at some point in the future. Again, we already have an example of this, and it does not actually line up with what you're assuming. If you actually enjoy ED's product and the genre in general, why would you not be willing to pay a license transfer fee of some sort to keep playing the same thing (even though it will now be considered a low-fi product)? And to do that, they must at some point rip out the guts and replace them with something that actually works in the current (to say nothing of the future) environment in which the game exists. See, there are three options at play here: They embrace obsolescence, the game ends up being unplayable and dies a painful but pretty stupid death. They are unable to evolve because your assumptions are true, and the game dies a painful but ultimately entirely sensible death. They are able to evolve because your assumptions are not true, and the game putters on and maybe even grows as it becomes more approachable and palatable to a larger audience. It's sunshine, lollipops and rainbows everywhere. The game in its current state — core limited, static-world based, single-sortie focused, small-scale and equal-priority-processed (i.e. every single thing in the world is given the same level of simulation attention, with no ability to step up and down in simulation fidelity), and with its ever-increasing patchwork of mutually incompatible bespoke solutions for things that should have centralised APIs and hooks — is an evolutionary dead end. If they don't want to change that, then so be it. The game will become increasingly niche to the point where it can no longer bear its own maintenance and development cost. This will ultimately kill off the game and the company (at best we arrive in something akin to BMS). If they can't change that, then so be it. The harsh realities of the market will kill off the game and the company. Or they bite the bullet and create a modern game to replace the current DCS. How much of the old DCS can be retained as legacy support is a matter for discussion, and much like in cfrag's analogy above, there is some value of maintaining that support. But that's not actually the core game itself. More bespoke patchwork solutions to try to fill in the ever-increasing gaps will not turn that particular ship around. Quite the opposite. To do the various things that more and more people expect of a current game, and also the thing that more and more DCS players come to expect of it, they need to go in a different direction.

It really isn't. The failings of the module are many, well-documented and well-proven. It is not a personal opinion — it is just fact. The Gazelle is not a well-modelled aircraft; it does not behave like a helicopter, much less like the actual Gazelle; and it even just outright and blatantly breaks the laws of physics on a number of points related to the most critical component of the whole thing: how it flies. It is also not a personal opinion that, given this history, it is probably best to try before you buy their next offering — it's just rational consumer behaviour. What might pass as personal opinion is the characterisation of it as a UFO, but then, with the aforementioned errors in mind, that's not a wholly undeserved label, nor is the apprehension many felt when it was this particular developer that were given the go-ahead to develop this particular module. But those are consequences of the observed faults and errors, and neither of those are the basis for the suggestion to moderate anticipation and to not spend money on something that we have no idea how it will turn out. Again, those are just standard good consumer reflexes given the history of the developer.

Non sequitur. Just because DCS will eventually meet its end doesn't mean the end of Eagle Dynamics or the need to play WT. It's far more likely that we'd see the people move over to whatever ED does after that, much like how they moved over from LOMAC. Or Flanker. They've been through this before. So has every flight sim out there. The genre is still around and doing better than ever, if anything exactly because of the thing you're saying must not happen. There very clearly is, or we wouldn't be here today. And the only way for that market to keep existing is if there at some point comes something new — something to replace the antiquated and limited foundations of DCS. You can't keep a market alive by embracing obsolescence, especially when it also rely on increasingly antiquated and unavailable hardware structures. Customers who have grown accustomed to spending money on modules will not be particularly shocked by having to spend money on new modules or on transition feeds — we know this because it already happened just fine. So you haven't got a single shred of something that could even remotely be construed as the tiniest fragment of an actual intelligent or coherent argument against anything I'm saying and instead have to rely on this catastrophically uninformed and nonsensical strawmen and ad hominem fallacies in a desperate attempt to feign the appearance of having something relevant to say. That's fine and all, but I don't think you'll win any friends by suggesting that the community should be reduced and the market needed for keeping the game alive and in development to go away. It's sort of inconsistent with what what you're trying to say, after all…

While I understand your enthusiasm, you really should be tempering it. The experience with the Gazelle for those who do have it is that unless and until Polychop can prove that they are actually able to deliver a proper helo sim, one should not wantonly throw cash their way. It's an interesting helo, but only if it actually works and plays well. This should probably be a day one two week trial, to see if they learned their lesson from the UFO, and only then be considered for actual purchase. Often in these instances, some counter argument to the effect of “they deserve to be paid for the effort” or “if everyone did that, they'd be out of a job” comes up, but unless that effort actually results in something worth-while; unless the job is actually done right, then no, they don't actually deserve it and they should be out of a job. Very mean, I know, but without that incentive there will never be a quality product.

Yearly bump.

Strawman harder. At no point did I say that there was no new code. What I said was that “[a] huge part of what we have now is problematic exactly because it did not need a rewrite; because it is legacy code that has stuck around since the Lock-On era. None of what we have now was not achievable — some of it was just a bit tricky due to that legacy or due to early design decisions that didn't account for needs that would pop up in the future.” If you want to address or refute what I actually said rather than whatever that silliness you invented was, then please go ahead. You should. That would help immensely with the eventual, inevitable recode from scratch that needs to happen if we ever want more advanced things. Old modules could go the way of FC3: become a set of legacy products that carry over as expressly simpler (relative to the new standard) models and simulations, and if any third parties wanted to maintain or update those, they'd be free to. Or they could salvage parts and build a new module for the new standard. After all, that's how we ended up with FC3 and its later additions and updates in DCS. Good thing nothing even remotely like that was suggested then, other than by you, just now.

Not really, no. A huge part of what we have now is problematic exactly because it did not need a rewrite; because it is legacy code that has stuck around since the Lock-On era. None of what we have now was not achievable — some of it was just a bit tricky due to that legacy or due to early design decisions that didn't account for needs that would pop up in the future. The DCS map format is one of those things. It is simply not designed to take stock of what has been destroyed. It is even less designed for transferring that state. There are functions to randomly blow things up, but those are incredibly computation intensive even on a small scale, to the point where you can easily crash the entire game if you try to apply all the necessary destruction at once, say at the beginning of a mission. Just one problem: there is nothing about that aspect of a dynamic campaign that suggests its easy to track the rest of the world, and more to the point, there is very little to suggest that they're already doing a dynamic campaign that actually even does those very simple things…

That would require an even larger rewrite of everything from scratch than what the OP is suggesting, and that's already a full rewrite. No, if a dynamic campaign ever comes to DCS, it will not do that. Maybe in whatever game ED decides to produce next as a follow-up to DCS, with none of the legacy or baggage.

It's a neat idea, but not entirely realistic. It would require pretty much a complete rewrite of every module and also the entire game. Some of that could/should be fixed if they ever get around to creating a DTC interface, but the last time anything was said on that topic, they stated that this would not be a standardised or universal API or function/feature-set that would tie into all aircraft, require each module to have its own bespoke solution. So that limited scope would still be pretty much a rewrite of… well… everything.

That's fundamentally your problem. DCS doesn't particularly care about how high-end your system is. It simply doesn't use it — it can't. “Top” hardware for DCS would be things that follow a design and setup principle (high frequency, non-parallelised) that went out of style a decade ago. Or more, really. Any modern high-end system will go the exact opposite route and will not really provide much in the way of benefit for your DCS performance, outside of maybe having more VRAM. The game even has a bunch of funny rendering quirks where you get objectively better results by lowering visual quality, especially related to sensors and spotting. Ultimately, until DCS gets a full rewrite from the core up to actually match how hardware works these days, you need to give up the expectation that more — and especially “better” — hardware will solve things because the effects will be marginal at best. Instead, dial things down to where you get a good balance between performance and looks. In particular, make sure that you don't accidentally set the “sim awareness bubble” too high so your system has to handle and consider more units and decorations and the like in its already full processing pipeline.

Non sequitur.

There is very little to suggest this.

Harsh but fair

Weeeeeeeeeell… no. In DCS, anything outside of an onboard system on a full-sim aircraft is usually very simple. In the case of anything related to EWAR (including most sensors), it's very very simple. SAM systems are essentially just a handful of sensors (very simply modelled) that are hooked up to a (very simple) decision tree depending on 1) whether a potential target is detected by the simple sensors, b) whether its general position relative to the launcher suggests that it's (very naively calculated) within range, and iii) whether it will simply fly out of range because during the missile flight time. On top of this, there are the missiles themselves, which have a pretty bog-standard simplified flight model, occasionally with some fancy characteristics such as a lofting profile and whether it pulls any kind of lead or not. Oh, and whether they should trigger some kind of on-board warning system or not — in some cases, they don't even have any guidance of their own, even in instances where they should. Any kind of countermeasure is just RNG, very simply modified by the missile's and/or underlying sensor's susceptibility to countermeasures, measured as a scaling factor to be applied to the RNG. This is why chaff is just radar flares, why CM programs don't matter — just dump to get more dice rolls — and why blinking ECM always works eventually — again, more RNG dice rolls = more opportunities for the missile to fail. PK is comparatively complicated to use as a basis for any of this (except maybe to tweak the CM-factor). Depends on how far down the upgrade path you want to go, from my understanding. Then again, they could always just do what they did to the SA-24, where it's exactly the same in every way as the SA-18, except that the in-game unit is called Igla-S. The system itself is pure copy-paste.

Given how utterly simplistic the various representations of all air defences are, that's not much of a problem, really. You can derive just about all of it from public numbers and it will not be any more or less realistic than even the most ancient and well-known systems.

Yes, but it's a functionality built into Windows via links and junctions (and in this instance, junctions in particular) rather than something DCS or its installer can be made to do. The tricky part is that, unless you know beforehand exactly what specific directories in the DCS install will be called, you can't prep them for the install and update, and instead, you have to let them install normally, move a particularly resource-hogging directory to a better location, and then link to it using its proper name. This little song and dance, then, will need to be performed every time you install something new that you don't yet know where it will be placed or what it will be called. So between the install and the final move and relinking of the directory, you're still going to need that free storage space (although it's entirely possible that you can make that a bit less resource intensive as well by moving and linking in the download directory that the updater creates). So, basically: Let the thing install. Move the offending directory to a more pleasant location. Use the mklink command(s) as shown in the article above to link the moved directory back into its original position. Hopefully, DCS will be none the wiser, especially not if junctions are used.

It would essentially have to be a relative position axis specific to the HMD overlay, complete with curves and everything, where the “input” is the camera yaw angle.

Ka-28 / 31. Or just Z-19 (but good luck on that one)