Tippis

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.

It doesn't. It's just that there are two different track recording systems and the one most commonly used and most easily available does not actually record events as they happen. It's also not the AI that makes it different — it's the non-deterministic nature of a number of (world and unit) simulation steps.

That's not how the VR settings actually work. That's the whole point. The “explanation” you're inventing in lieu of any actual experience or understanding of the topic is what the solution the OP is proposing would allow — not something the game currently can provide.

That is not a fact. That is just your fatal allergy to research that is acting up again. So really, it's just a wildly guessed assumption based on nothing but yourself and your own preferences rather than anything that has any basis in actual reality. You could at least have tried to make it look like you did a simple google search before presenting your hallucinations ans reality again. The “information” on which you base your statement is, once again, as always, non-existent, contrary to actual reality, and nothing but projection of how you have chosen to set up your game as if that was in any way universally applicable.

From the EULA: …and… So it sure doesn't sound like it. The license agreement is between you and ED, and cannot be transferred to any third party.

I'm pretty sure you can do this already. I run with three standard TM MFDs and out of the box, they're called MFD 1, MFD 2 and MFD 2 (again) because they have an internal left/right split, and thus number themselves as either 1 or 2. This makes it seemingly tricky to figure out which of the two "2" is the middle one. However, by simply double-clicking the name at the top, I can do this... Or, rather, I guess I'm wondering if this is what you're looking for but haven't found, or are you looking for some more advanced functionality?

It's worth just having a quick look at how binds are actually defined in DCS, and why this option isn't really a big ask, comparatively. The simplest and most immediate example I could find was in the universally available TF-51 module, straight out of DCS World\Mods\aircraft\TF-51D\Input\TF-51D\joystick\default.lua where the plane's base controls are set up: {down = iCommandPlaneUpStart, up = iCommandPlaneUpStop, name = _('Aircraft Pitch Down'), category = _('Flight Control')}, It's pretty self-explanatory, really. If the bound control is detected in a “down” state, send the internal iCommandPlaneUpStart message to make the aircraft pitch down. If the bound control is detected as released — “up” — send iCommandPlaneUpStop and stop pitching down. This control is set up this way because you want a continuous pitch change as long as the button is held, rather than pulsed inputs depending on some arbitrary polling rate. This is not how all controls are set up and the choice of how you want the controls to behave will obviously depend on what kind of control it is. For some, you might want that pulsed input, for others, the underlying controls are set up in such a way that it won't really matter and you don't need separate start and stop states. Further down in the same TF-51 input definition file, for instance, we find this for trim controls: {pressed = device_commands.Button_11, cockpit_device_id = devices.CONTROL_SYSTEM, value_pressed = -0.1, name = _('Trim Aileron Left'), category = _('Flight Control')}, Here, every polled event where a button press is detected yields a change in a numerical value — start and stop events run the risk of making that value spin too quickly or too slowly or just not precisely enough. Basically, the functionality is there and is ubiquitous in all modules. What this kind of option would do is allow the player to separate the “down” and “up” commands in the bind above and assign different device inputs to them. But to offer full customisation, it also needs to sort of work the other way around: things that right now are set to trigger on a button down event need to be assignable to a button up; some momentary actions might need to be split apart; and some up/down combos might need to be possible to chain together so that a singe button push activates both the commands, regardless of whether a button-up event is detected or not. The tricky part in making this player-controllable rather than something that is hard-coded into the module itself is that 1) you have to expose a lot more of the guts of the underlying input messaging, 2) defaulting will require a huge re-think since you'll still want both that press and release action on the same button by… well… default, and give the option to separate the two if the player's input device works with that kind of setup, and 3) there's a huge number of input definitions that will need to be looked over and separated in this way in modules that have barely been touched for almost a decade. It's a pretty significant amount of work for what is technically a fairly simple change, to the point barely being a change at all. But, again, it means that the player will have to work closer to the subsurface command messaging rather than the more immediately obvious descriptions of what any given input is doing on a higher level. This is a level of geekery and faff that not everyone will enjoy or want to bother with. To re-use that first example, it's much easier for the player to grasp “press this button to pitch down” compared to having to juggle “press this button to start pitching down” vs. “release this button to stop pitching down”. The three-way balance between good defaults, clear descriptions of actions, and customisability will be tricky more from a user interface perspective than anything else.

They're called caps. Get it right or you might be… rectified.

Because, as anyone who have flown with AI wingmen will tell you: they absolutely shiver in anticipation at the opportunity to call “bingo” and immediately punch out — and no overbearing silly human will stand between them and their slow descent to the ground, dammit! (But more seriously: just posting to have this show up in my sub list because any info on how to make this more reliable will be immensely helpful.)

Yes. Every new bespoke solution further delays that functionality. It's a case of ripping the band-aid off vs. piling on more band-aids on top of old rotting layers that are slowly being grown over by the skin. The kinds of bare-bones solution you're describing already exists — that's kind of the whole point. Not only that, it exists in half a dozen different ways, all incompatible with each other.. The “temporary improvement” you're envisioning isn't one: it's not different from what exists and working on it will only make it take longer before a permanent solution can be made, and make it harder to even make it at all, thus increasing the chances that it won't be temporary at all. Of course it will. The more disparate and bespoke solutions there are, the more will have to be rebuilt when a proper solution comes around, to the point where it will eventually not be cost-effective to do it at all: the gain is just no longer there and would just break things. The more cruft you accumulate, the more you'll dread the moment when all that cruft has to be cleared out — it is better not to accumulate it at all since doing so will make the transition easier and quicker, and that holds true even if said cruft happens to include the odd little gem. At some point, you simply have to stop creating new hacky solutions to a systemic problem and stop pushing the major rework further into the future. The difficulty increases by simple definition: if you build a system on top of a bespoke hacky solution, you are all but guaranteed that you either end up with something that cannot be replicated later, or something that requires all kinds of extra work to be compatible with the new common system. Feature freezes exist for a reason.

We also have the Viggen DTC, the auto-generated and -populated settings in the F-16 and F-18 (and MIrage, to a lesser extent), the kneeboard-driven interface of the Harrier, the “prepare mission” feature of the A-10 and Ka-50, and a myriad of inconsistent kneeboard and ME settings that, while not all of them are actually handled by a DTC system, should be consolidated into the same kind of UX/UI setup. Like I said, we already have something. That something is already a heterogeneous mess of bespoke solutions. Adding more to that mess isn't “infinitely better than what we already have” because it is what we already have. And, pretty much by definition, it's a mess — it doesn't become better by becoming more. So the only real actual improvement is to make it a centralised API and UI that everyone hooks into. Asking the individual module makers to implement a solution will not make things better, just more, and will make the eventual move to a working solution far more painful and more unlikely.

The only one thinking anything of the kind is you. As has been pointed out on numerous occasions, you should not and cannot generalise from yourself, especially since you invariably do so from a position of absolute and loudly declared ignorance of the topic at hand. In this case, you are proving yourself ignorant of the existence of, oh, let's say Microsoft. Yes there is. It's called “the labour is already done”. All the required components already exist. Software in particular — far more so than the sandwiches you think it can be compared to — allows for this kind of splitting up, which is how you can so trivially find all kinds of tiered-license deals for complex programs. In fact, you're using one of those restricted licenses this very moment. And guess what? The manufacturer of that software is making money hand over fist from offering you that reduced-capability product at a lower price. The single missing part isn't even with Heatblur but with ED needing to allow individual slots to work with multiple licenses. If you want to argue that this cost would not match the additional sales from people buying the restricted slots, you're going to need to present an actual argument — one better than “nuh-uh!”, which is all you've ever offered so far. Not really, no. And even if you did, so what? That just further reinforces the point that it would be all gravy — that it's all just additional sales that otherwise wouldn't happen.

An immediate thought is that there might be some other axis or button press that is interfering and which constantly pegs the throttle to the off position. Have you checked, not just the throttle itself and its axis assignments, but every other device so they're not contradicting it in some way?

This is more akin to DLSS and similar methods of (re)creating non-existing information from a lower-quality sample as a part of the rendering process. As mentioned in the article above, it's not just making the signal compatible - it's actually creating those two extra bits of (mostly luminosity) data. Of course the results will be better if everything is mastered for HDR from the get-go, but it's a lot more than just showing B&W on a colour TV. It's more like showing (auto-)colourised images based on informed guesswork regarding what should have which colour. It's still not creating HDR support in the strictest sense of the term, and it's definitely not native HDR content. The sales pitch from MS' side is more along the line of brightness upsampling (there's very little talk about an actual wider colour gamut).

As long as…

It doesn't, at least not in the sense of having an “HDR capable game”. That's the whole point: it takes a standard dynamic range game and tries to figure out the actual full brightness (and darkness) of objects, and then feeds that value to an HDR-capable display. The game itself does not support HDR; the assets are not mastered for HDR; the draw subsystems figures it out on its own. It has nothing to do with switching HDR or automatically — it has to do with creating an HDR output signal where one wasn't present before. There is still some compatibility, but again, not in the sense that the game must support HDR. Rather, it must have a rendering pipeline that allows for this kind of light sampling to work and to be injected on the fly. Not all games have that, and without going on too deep a search, it looks more like there's an internal database of which games can do this and which can't, as opposed to it being determined Magically™ by the system. So it's more a question of a game being “auto HDR-compatible” (which inherently and by very definition not the same thing as being “HDR capable”), by virtue of having the right kind of pipeline, and the developer can get some “free” bling by just altering that pipeline rather than creating an entirely new one with new assets to match. Rather than being “pretty sure”, you could have trivially googled all of this.

That's ok. They don't really matter in making that happen. Well… not much anyway.

Even more fun fact: it is already happening.

Depends on the effort involved, and exactly what's covered, as always. Equally niche games have been given wrapper releases, and given the limits in how DCS processes thing, it might not even be as hampered by those solutions as is often the case — not sure if that's a good thing or not, though… And as mentioned earlier, that also assumes we're talking about the client. If we want a different segment, the picture becomes… quite different. But of course, that swings the discussion right back to the question of effort vs. usage — MP is itself a niche within a niche, and dedicated servers yet another layer of niche:ness on top of that. Even when you take the stripped-down headless dedicated server and no longer have to worry about the usual translation headaches of video and sound, it can easily end up being just too few users and too little benefit from the increased stability, reliability, and usability to be worth that lower cost.

So all software is worth using, then, since no market has that kind of saturation for a single product. Or were you just pulling random numbers out of your nether regions because you are wholly unfamiliar with the topic at hand, and have to be contrary just because? OSes are not formats, and the fact that there are multiple ones have massively and demonstrably benefited the consumer. Format convergence matters when you need to exchange information, especially in large quantities. That is not what OSes do, nor individual applications. If you can't keep those three apart, you've disqualified yourself from having any worth-while opinion on the matter. There is nothing confusing or inefficient about it, and as we can clearly see, there is no “winner” that has been picked by the consumer — odds are that you are using at least three different OSes, each with its own purpose and benefits, at this very second. Now, I'll grant that this does indeed seem to confuse you a fair amount, but has been explained on multiple occasions, you should not generalise from yourself. Even in the case of games, there is no clear winner — even setting aside console OSes, four are large enough that companies want to consider them on a regular basis, again for various purposes and use-cases. And yes, your irrational hatred towards it notwithstanding, Linux is indeed one of those. Again, chances are that you're already using it on a regular basis. Arguing against known reality will not help your case here. If you want to argue against the common and obvious use-cases already expressed, by all means do so, but don't use your ignorance of what an OS even is and of how markets operate be the only foundation for not wanting to see this kind of improvement to the game ecosystem. May I ask why not? While ED might not have any interest in doing this themselves, it's not like there aren't off-the-shelf solutions that would allow it to be packaged that way by a third party either as a partnership or as an unofficial scripted package solution. As long as there is interest in making the game run on other platforms, it is a worth-while discussion to have. Just because some parties get upset over the mere idea of it running on not-their-favourite-OS doesn't mean that the discussion is not worth having — only that they can't really contribute to that discussion.

“Anything worth using” is just relevant to you and you are irrelevant as a sample. In actual fact, everything you're using at this second relies on multiple OSes and Linux is most likely by far the most common of those. You understand that there are already multiple OSes right? And the market not only has room for them all, but constantly proves that there are room for more, and that everyone — customers and companies alike — benefit infinitely more from this variation than from monoculture. To suggest otherwise is hopelessly ignorant.

Really? This is quite a turn-around for you given your long history of championing the boredom part and loudly complaining about any and all ideas to cut down on those.

[citation needed] What you're aggressively avoiding to understand is that this request boils down to asking Heatblur to sell less than half of the Tomcat at some discount — the OP suggested half price, which seems quite sensible as a start for less-than-half a module. You have totally missed the part where you need to explain why this doesn't make sense, and you're using your ignorance of DCS, the module, and of multiplayer as your only basis for not having anything resembling an intelligent argument. Why not? Do you understand what's being asked for here and what it would “cost” (not just monetarily)? What makes you sure about something you don't even understand?

The chances of that changing anything are close to nil — this is something that is happening in the hardware or in your binds. You can see if it helps to (temporarily) rename your local input directory (%USERPROFILE%\Saved Games\DCS\Config\Input) in case there's something that has gone wrong with them on a more universal level, or you can try the reset as mentioned above. Can you post a picture of what the axis tune screen looks like for the pedals in one of the modules affected?