Dangerzone

It's frustrating to potentially lose access to something you've paid for and used for years. But realistically, for 3 of the 4 modules, they've been available and widely used for a long time. Issuing refunds for long-used products is complicated — especially when there's no clear consensus on who's responsible. Is ED, after passing on payment to Razbam supposed to refund what they've already paid Razbam and pay out of their own pockets? The F-15E is a unique case, and credit to ED for offering store credits. That shows some accountability. But for the rest... I get it - as a consumer, it sucks too. But the situation is that this is bad for all involved. No one is going to win out of this. It's going to hurt everyone. And that's the reality of it. We're all going to lose, consumer, ED, and Razbam. Expectations should be adjusted accordingly. But it's also worth noting that the 'other sim' doesn't support module support between major versions and people may need to buy new modules for the newer versions. 3rd party devs may or may not support updates between - but that's up to the 3rd party dev's, not the 'big name company' that can't be mentioned here. Really, if ED drops support come 3.0 - they're actually only doing what 'the other sim' does anyway. If they carry on the majority of modules through 3.0 - that's actually unusual. If anything - shouldn't that be recognised for the good will that it is? If anything - DCS supporting their modules through major versions deserves recognition that it's more unusual. I'd hate to see ED do a good deed, and it being used as a rod for their back. On the other hand... I would happily pay for a Huey v2 in DCS 3.0 if it was updated.

You are correct - this is close to what CB is. This would basically be a step between closed beta and the official release, to give those that don't have closed beta access opportunity and time to test and prepare for the official release (as I presume the closed beta testers currently have?). The reason I advocate for making it harder to access - is to prevent a repeat of the past, where the open beta effectively became the main release. My suggestion still allows those who genuinely want to test to do so, since anyone setting up a server would need to share the IP directly to fellow testers by DM (e.g., advising of IP address of server). It would discourage server hosts from using the beta to attract players by being "first with the module," as these servers wouldn’t appear publicly—reducing the temptation to treat the beta as a production version and avoiding a repeat of what we saw previously with the Open Beta solution. And even if a few did - it would be the minority - thus being more like a real Beta version. So, those who would run / those intended for would be those who specifically want to do beta testing, and fix breaking changes before it's released to public. At present, there is no opportunity for those outside of closed beta to do this. Often, non-CB server operators and mission designers find out only at release what breaking changes there are. The amount of pressure this can put on people to have to provide fixes immediately can be significant. This would hopefully help to alleviate a lot of this. Of course an additional side benefit too would be that more bugs could potentially be flagged that slip by the CB team before it reaches production servers. (This is no dig at the CB team BTW - I genuinely appreciate and value what they do and the time they donate often to test each release before it gets to the rest of us - no doubt an often thankless task that is often overlooked by the community, and comments are mostly only made when something gets through - not for all the things that they have caught). Maybe I'm out of line, or this is a bad idea for reasons I haven't seen. I understand that an Open Beta solution could bring in challenges. (Such as module release announcements - as ED in the past had basically used the OB release, not public release date of a module as it's official release - maybe in those occasional instances a OB is skipped - and only used for all the other updates?). I know I don't have all the answers here. I'm just advocating for some sort of discussion on potential solutions where we can change to assist those who are finding the current method difficult and discouraging which I'm concerned could lead to further burnout for content creators and server hosts. In the end, this comes out of a passion for wanting to see DCS be the best it can be, and reduce the amount of last minute rush some server operators and content creators need to do.

I've previously suggested what I believe is a better solution: a true Open Beta—(implemented differently to before). Make it accessible only via command line, so only those with the tech knowledge of how to execute command lines, and also know the OB version number can install it. That way, it’s not used on production servers, and Open Beta versions don’t appear in the public server list—IP connect only. This would make it a genuine testing platform, not a general gameplay environment, and give us the time we need to adapt and see the upcoming changes and try them out. Sure - there will be some that push and opt to use it as a stable release, but it would be the minority. The previous OB didn't work because the majority used it as a stable release (and even ED recommended people use it for production in MP). I really feel we need a proper Open Beta for everyone’s sake. Far too many issues are being discovered in these new so called stable releases within hours, forcing hotfixes. That’s bad for both ED developers, who get blindsided and must scramble to patch, and for us, who have to react to breaking changes without warning. Let alone the image that it's putting out there of ED's quality. Let an Open Beta run for a couple of weeks—(1) to give content creators time to adapt, and (2) to apply necessary hotfixes—before pushing a public stable. Just a pity that ED seems to disagree that there's issues for the community by working this way and believe everything is fine as is. Nothing needs changing, with "no plans to consider...". While all along I see what I feared when open beta disappeared. That the new and improved stable release would eventually degenerate to being what Open Beta was all along - with no real practical alternatives for public server content creators (that aren't in the CB team anyway) to be proactive, and just have to be reactive and rush about to deal with bugs, problems, or breaking changes at the last minute.

I've stopped flying the Kiowa as this just creates all sorts of eye strain for me. Unfortunately this doesn't appear to have been recognized officially as an issue - so I'm wondering if it's 'correct as is' and will receive no attention. That's a real pity - I had looked forward for years for this module, and would love to fly it more.

Well, this whole time I've been disappointed that it's not aimed for VR - and after your update I realise that there's no point being disappointed - even the target audience is better off without it. Thanks for giving us those test result info!

A log book that tracks hours in different airframes would be great. It's kinda sounds like something a pilot would have IRL.

You could use DCS's built in FPS counter instead. (Right CTRL+PauseBreak IIRC) This shows both in VR, and on the 2D screen. I have no idea how you would get FPSVR itself onto the monitor sorry.

I remember hearing something about this, but I've forgotten. Are you able to list what those planned features are again? Also - as far as the date of implementation goes - I would hazard a guess we're still talking years. I could imagine both COVID, and then the Ukraine/Russian war would have had a pretty big hit. The DCE (which was 'definitely not 5 years' more than 5 years ago) is probably telling of just how difficult and things have changed with progress over the past 5 years. Many companies didn't survive, and others struggle to survive with the difficult times that have been brought on this decade. I honestly expect this to have an impact on the DCS/Vulkan timeframe. I would love to eat my hat, and see Vulkcan released sooner rather than later - but my expectations are definitely otherwise.

Is this by any chance what you're experiencing?

...and be more chaotic than Fawlty Towers?

All those countless hours of keyboard typing - the invaluable deep thought and wisdom on the situation.... all gone. What ever shall we do now?!?

What makes you think that it would require much time? At present, they have a changing sea state. Just that it’s set directly by the wind. All that’s needed basically speaking is an option to set it separately to the wind setting. While I agree with you with the other stuff, with this we’re not exactly asking for a new feature, but more just an alternative way to set an already existing feature. As such, I don’t see any performance issues with it, or significant development required either. If anything, I suspect it’d be one of those relatively simple things to implement that gives another showpiece to show the evolution of DCS. Decent return on investment really.

While I completely agree with you - the reason that (I at least) gave realistic information on how the ocean works is to justify exactly what you're asking for actually far more matches realism in this instance than what DCS has setup. I agree that the best option is independent swell height and direction - regardless of whether it's realistic or not. I love the way they've done the fog. Auto and manual modes - so hopefully they're interested in enhancing the experience with the sea swell too. I wasn't too interested in that other simulator, but after seeing the 'benchmark' that they did with the ocean sea state - it reminded me of this thread and how DCS is falling behind significantly in this area. But as for thunderstorms - how do you get those? The new cloud presets - I couldn't see any thunderstorms at all? We have rain, but that's it. Are you using the clouds mod to get it, or is there something I'm missing?

It matters for AAR, formation flying and any close flying as well as videography where it occurs. It’s immersive breaking for pilots flying close to others, and looks shoddy in videos too. Plus, it doesn’t matter if it’s sort of long- the effect is still the same at the causation point- where it extends from the plane. Honestly, I would prefer no wing tip vortices while refueling than seeing this.

Hmm... does this mean there's less overhead / CPU working within the Pimax app, because there's a 1:1 relationship with the image resolution it's being sent and what it has to display? Is it possible that part of the issue is double-CPU work. QVFR is using the CPU to change upscale/downscale, but then Pimax is also using the CPU to upscale/downscale, and by reducing Pimax out of the equasion, things run much more efficient on the CPU as a result, even though the resolution setting in Pimax is higher?