Tippis

No. Try again. Read what I actually write (and what the OP is suggesting).

No. That's not how DCS actually works. But we can now safely conclude that you approve of the OP's idea since it would allow mission designers to do exactly that. In fact, it seems like such an obvious thing that should be in the game that you're just flat out assuming that it's in already. There's nothing to suggest anything of the kind. Mission designer's intent, remember? Or did you already forget about the non-reason you tried to use to oppose this idea for no rationally explained reason before flip-flopping and showing that you really approved it after all? And again, your feeling exposed in such a situation is not relevant. To anything. Well, tbh, it's really yet another argument in favour of the OP's idea… But on the off chance that you're just tripping over yourself again because you forgot to read the OP and didn't understand what he's asking for, do you have any actual reason to be obstructive in yet another wishlist thread — any kind of argument why the game should not be improved with this added capability for the mission designer to offer a wider difficulty scope and intent?

No. Learn how DCS works, please. It's because DCS cannot do anything else. The mission designer's intent (this has nothing to do with the server) is limited by what DCS has on offer. Also, if you were to read the OP for once, you'd notice that this wouldn't change anything about intended mission design. This would simply allow the mission designer (it has nothing to do with the server) to intend more. Or not. It's an option. The intent is not altered or forced or subverted in any way. So, again, just to make the very simple logic clear to you: the intent of the mission designer (this has nothing to do with the server) is limited by what options DCS can offer. By increasing the options on offer, the mission designer (this has nothing to do with the server) can in turn offer a wider array of intended ways to play the mission they're designing. Whatever intent they had before, they can still have. If they have a different intent, with this kind of option, DCS could be made to accommodate that intent as well rather than be limited. And you do like the mission designer's intent (because, again, this has nothing to do with the server — that's not how DCS works) to be realised, right? You're not just using a very specific and very narrow intent to hide behind because you can't think of any actual reason why the game shouldn't be made better, right? Right? This has nothing to do with the server. Who cares. That is you making narrow-minded and wholly false generalisations from your own personal and irrelevant preferences. You might not want to cold start near the AO. The OP does. Others might. And what was that line of yours? Oh right: “that's how the mission designer intends it” (it has nothing to do with the server), so no, you won't get zapped on the ground. Or maybe you will, and that's the whole point of doing it? Either way, it does not matter — the whole point of this kind of option is that those who want to start close can; those who don't, don't have to, and if that's the designer's intent, the client gets to choose. This are all good things. Why are you so dead set against improvements to the game? And why can you not understand that your preference is not universal or normative?

No. You can only assign hot-start slots to valid hot-start locations. You can only assign cold-start slots to valid cold-start locations. You can only pick hot and cold start as assigned and as required by the location. The point of the discussion — and I can't believe we have to go back to this old chestnut with you — if you would just read the op, is to have an option to transform one into the other and to allow the client to pick whichever they want. …you have never actually bothered to investigate the matter and just go by what others provide without understanding why they provide that and how they're limited in what they can provide. What servers you have seen is irrelevant. That is not the point. Your experience does not matter because it is entirely from the wrong perspective — from the wrong side of the equation. That is not the preference. Again, read the OP. The preference discussed here is not just hard to find — it is impossible because DCS simply does not provide it. Hence the OP asking for it to be provided.

…and this would not change that. In fact, it would allow them to do so ever more. No. Allowing the player to choose exactly where, when, and how to start the mission is a very common capability in sims. In fact, a fair few of them don't even have “slots” to speak of. DCS is just unusually stingy and lacking in options in this regard, and shouldn't be taken as representative of the the genre. Hence the desire to expand and improve on its capabilities and make it a better game. And again, if you read the OP, your concern is just not relevant because it inherently does not exist. That's what the whole thing does: it completely removes and invalidates all such problems. It's kind of what always happens when you give players and mission-makers more options, after all…

Ka-29 or Mi-28.

You're missing the point of what the OP is asking: an option to let the players choose cold starts in situations where they currently can't. And the mission-maker would still be able to control whether they want to enforce cold starts — they'd just have far more options for starting positions since they could also use those that are hot-start only at the moment. So your “concern” is completely inapplicable since the situation that the OP wants to create is the exact opposite to the one you're worried about.

And presumably, adding in hundreds of overlapping binds to cover all eventualities and combinations of switchology would be done by… who? The bind fairy? No, that's not something that makes your idea easier because the exact same thing would have to happen with that one as well.

How so? You're not really explaining your reasoning. In what way would it be easier to have to dig through a much larger number of bind options that only exist to duplicate and combine other functions, for every aircraft, rather than have a single switch that does it for all of them at once? Remember, this is for players who don't feel they have enough input options available to them to bind everything — that lack of inputs will be true regardless of the module, so it's highly likely that if they want it for one aircraft, they'll want it for all aircraft. How is that easier for anyone than Options -> Gameplay -> “Automatically operate covers/latches” [✓] ? Use your words. Explain why it is easier — why it is “better” — to fill up the bind list with literally hundreds of new binds and force third-party developers to add all this overlap rather than have it all condensed into a single thing. And just a hint: there are arguments for your idea, but you're nowhere near being able to articulate them at the moment… (also, they're still not arguments against the OP's wish).

Why would that be better than a universal option?

Read again to understand why they wouldn't. Then respond to that reasoning rather than just repeat the same thing over and over again. …and again, it is not something that applies to what the OP wants to do. Read again to understand why. If you don't understand, ask for clarification rather than repeat the same thing over and over again. If you're going to try to use examples of an alternate solution to what the OP is proposing, at least try to come up with ones that actually match what is being discussed. …and again, that is only part of the problem — it doesn't solve the really crucial issue (nor it is really a sensible burden to put on the player). This, too, has been explained. If the issue is too complex because it involves multiple parts — all of which are blockers — ask about the part that confuses you rather than repeat the same thing over and over again. So, to conclude: no, simple macro solutions will not do the trick, especially not something as bare-bones and simplistic as Logitech's G keys, since they have no game integration whatsoever and since they're a massive faff to get to work even with a single module. What is needed, for the reasons explained, is an in-game, context-aware (or just context-ignoring) option

…and, as mentioned, that wouldn't actually solve the problem described. RShift+Home isn't a macro (keys in sequence) — it's a combo (keys being pressed at the same time, hence the little ‘+’ sign), so that example is pretty useless and is not what the OP is asking for. Now, the G-keys can be programmed with macros as well, but what it can't do, and which the OP's idea pretty much requires, is to know the game state. It also can't know what plane you're flying. It also can't know when to repeat button presses, when to reverse the order, and when not to do them at all. And that is the crux of the matter: you can't just macro together [operate latch] + [operate switch] because you don't know the state of either, and if you don't know the state, you don't know in which order those two actions need to happen. If you don't know the plane, you don't know when it matters and when it doesn't, and that's on top of needing to create two dozen different profiles to cover all planes. There is no convention in the game as to whether closing a latch automatically switches the switch off as well, or if the latch is blocked; there is no convention in the game as to whether there are separate up/down states that can be mapped; and there's even less of that in the cases when there are multi-stage switches being hidden behind the covers. All of that means that the simple idea of macroing together open + operate isn't even available in many modules, and in the ones that are, you end up not actually saving any keys because you end up picking between “let's macro together an open+close and an on+off function” (two different buttons), and “let's macro together an open/on and an off/close function” (and note the difference in order here) — either way, you have spent two keys on it and the whole effort was pretty much wasted. And in the first case, it's doubly wasted because those functions are commonly already in place, and the separation between on/off-states is just an extra convenience added for cockpit builders. Alternatively, you end up with a macro that does things in the wrong order because, again, you don't know the game state. You can't use the same macro for open+on as for off+close because of the order of operation, so you once again have to make two different macros and you've once again done a lot of work for nothing — you still need two separate buttons to fire off the two separate macros, which is no improvement over having two separate buttons to simply operate the cover and the switch. The only way around this is to hook into a script that knows the game state (DCS BIOS-style) and to put some pretty extensive branching logic into your macros, and then hope that you can even hook those two up properly. In most cases you can't, and without going full bore on third-party macro programs, you won't even have the logic available to support it. Again, that's an insane amount of modding and per-module work just to get functionality that we know for a fact can be built into the game: the option that covers don't actually matter because they follow the underlying switch, and have that option work universally across all modules.

Also, having your knee board on… you know… your knee is quite nice.

You mean as in, pressing a (latched/covered) switch input the first time is automatically interpreted as “open latch” and then the second input actually operates the switch, and possibly, conversely, pressing it when the switch is already in a closed position also closes the latch/cover? That would require a fair bit of logic that isn't really in the game at the moment, in particular since it is really allergic to double-binding things. If the option was just “ignore covers”, so that operating a covered switch via a bind would just flip it, opening the cover if necessary but for all intents and purposes ignoring the cover position, then that would probably be a bit more doable (if nothing else because we've already had switches that operate like that… although those were mostly considered bugs. ). But of course, the covers are usually there fore a reason, so that might be a bit… accident prone. Still, if refined, it doesn't sound like a horrible idea. As always, that wouldn't actually solve the problem described, as would be obvious to you if you thought about how macros work for more than, oh, half a second or so.

I'm not entirely sure there's a trivial way to make it use a specific weapon, but it could be that it gives different warnings depending on which system it decides to employ — if sounds a bit like it gives warning if you're in Osa range, but not if you're within S-300F range. I don't know enough about the system to really tell, but it could actually be reasonably accurate: it's a command-guided system with terminal homing so you wouldn't necessarily get any missile indication until just before it slams into you, if even then. A lot of DCS SAMs give off too much warning too soon for how they are really meant to operate, so it could easily be the case that, for whatever reason, the more advanced naval system's don't do that and really are more close to how they should work.

The bigger issue isn't really what tasks are available to what aircraft, but that for no really useful reason, some waypoint actions are tied to specific tasks. There doesn't seem much of a reason not to make all WP actions available to everything all the time, and if the mission maker assigns an intercept set of actions to a Tupolev, then he gets to live with the fact that the AI will just realise that it is out of suitable weapons and RTB:s without contributing in any useful way.

This is clearly just a lack of imagination. But seriously, yes. Even as a low-hanging fruit, there are so many standard map objects that could conceivably be re-made or repurposed as placeable static objects that would let us decorate our missions to a much higher degree. Just take the various airport objects strewn about the maps: air planes that exist in no other format; radar and radio installations; various support vehicles, revetments around spawn points, etc etc etc. Granted, some of the more interesting ones (the artillery positions on the Syria map, some of the more bespoke and area-specific buildings, civilian decorative aircraft) are available only on for-pay maps, and I would venture to guess that there's an argument to be made that not everyone could/would/should get those since that would represent a pretty significant increase in base game size and also give away assets for free... but still -- they're there already, so it shouldn't be a whole lot of extra work to give mission-makers the opportunity to place the stuff they've bought already.

As a general idea, definitely +1. More out of interest, though, how do you handle the myriad of HOTAS buttons you usually have to contend with on an equally usually much less button-festooned VR controller? Do you do all of that via Voice Attack, or has the tech simply moved along much farther as far as finger detection without my noticing?

That is not a fact. That is just your experience with one particular type of replays — and ones that involve far more complex matters than is needed for this, at that. In particular, it's something that can actually be done without even involving any of the pseudo-random traits that plague SP tracks and thus something that even with the current system can be made to reproduce reliable and repeatable outcomes. The tricky bit isn't any of that, but the detailed log and summary of the performance stats during and at the end of the benchmark. Here, too, the data is readily available — just not recorded and packaged.

It's not a bug. Really. It's just an option related to a part of the game that you have on multiple occasions stated that you have no familiarity with. Stop trolling threads where your assumptions are wrong and your opinions are worthlessly based on wilful ignorance.

That can be generalised further. Why do we need any icons on the main menu? The very tiny functionality they add is already far better and more logically handled by the settings screen and module manager. They were a cute idea back when there were all of four modules; these days, they're wholly pointless except maybe for some of the (community) mod icons that tell you at a glance what version you're on so you can tell when it's time to manually upgrade. For DCS proper and any of the official modules, that as long since ceased being something the user should (or even can) worry about.

It literally can't be. That's the entire reason why the setting exists to begin with: to adjust for the headset and the user, since it can't be done the other way around. And even if that weren't true, it wouldn't be likely anyway since we already know for a fact that they've gotten dimensions wrong, so that's the most obvious and first thing to suspect. Again, just because you do not use VR and are not familiar with how it works doesn't mean that it's automatically the VR user's fault and that the developer has done -- and can do -- nothing about it. Especially not with the history consistently showing it being the other way around. Wilful ignorance is not a good basis for your assumptions about what's going on here.

Exactly. So presumably, you're for this solution that avoids that? Yes there is: if the in-game scale is wrong. That's why games have that setting: because they presume a specific scale for the person wearing the headset, and they presume that the person has their headset set up in a specific way, and most importantly: they allow each user to have user-specific settings for each game. Just relying on the headset only works if exactly everything is always right and always equal, but the fact on the matter is that they're not. What looks like the right size of a person for you will not look like the right size of a person for me, because we're not the same person. What IPD works in one game for one user does not work for a different game and a different users, because [drum-roll] they're different users and different games. This is why even such backwards OSes as Windows allow each user to store their settings separately and why games allow their settings to be stored on a per-user level. ...but it is a very good way to determine whether the size matches you and how you see the world. That's why DCS has an IPD setting to make things match up properly. It has this for the very good reasons listed above. What it doesn't have is module-specific IPDs that can be used to fix any perceived incorrect scales between the modules, which necessitates constantly adjustments of IPD. You know, the thing you started out saying was a ridiculous solution. So even though you have no idea how VR works, having never actually used it, and even though you don't have any point of reference for either in-game or real-world scale, and even though you previously thought the proposed idea was ridiculous, we can only conclude that you now support it for some unfathomable and incoherent reason?!

No, that's not how the VR settings work. The very nature of the IPD setting is that it would be different depending on the game's internal intended scale, even as — and especially if — the headset (mechanical) IPD is consistent across all apps… but that is still not consistent or unique since it depends on the user. Again, please read up before trying to invent this kind of nonsense in your quest to keep the game unrealistic and bad-looking. And you should be asking yourself the same question: how can you be “sure” that the cockpits are the right size when you've never seen them IRL or in VR and thus have zero points of reference compared to the VR users who at least have one?

Based on what? How is it ridiculous to ask that cockpits appear at the right sizes, and if it's too much work for the developers, to offer an option to fix that on a per-module basis? You're not really offering anything in the way of argumentation here, which is pretty ridiculous in and of itself seeing as how you've shown that you have no idea what the issue even is. So your basis for evaluating what is and isn't ridiculous, and your opinion on the topic, are pretty much null and void.