Vertigo72

If that is what people actually did, methodically testing each every line in the change log in controlled conditions and reporting back, then sure, that could be considered a job. But that is not what 99.999% of OB players do. They play the game, pick their favorite plane and when something doesnt work, like you know, the radar in the hornet, or they dont get their AI kills, instead of testing everything else, they throw a tantrum and complain they cant play the game anymore as its broken and it needs a hot fix. But you expect highly skilled full time developers to spend their time for free to provide you with updates and improvements even 10 years after you bought something? I hate to break it to you, it doesnt work like that. If you spend 60 euro on a module, you pay for the work that went in to it. You may reasonably expect bugs to be fixed, but you dont get a perpetual claim on the devs time to keep making improvements. Who is paying for new weather models? Who is paying for VR performance improvements or improved AI or whatever?

Thats a bit of a hyperbole, but it describes exactly the problem I want to help fix. Why do you expect ED to spend resources to fix a module you purchased 10 years ago and hardly anyone still buys today when those resources can be spend on stuff that actually makes them money? Their incentives are heavily skewed towards releasing more and new and unfinished stuff and it causes problems for all of us. If that is a real problem, having access doesnt mean you necessarily need to install every module.

I just proposed a variant here: https://forums.eagle.ru/showthread.php?t=277691 Basically subscription would be optional, provide early access (currently known as open beta) and access to all modules (or all ED modules) in both stable and beta. But yes, the transition would need to be considered. Someone who already purchased all modules, should not be treated the same as a new player who hasnt spent a dime yet. I think solutions can be found for that, for instance, every module you already own would give you, say, 6 months of free unlimited access. After that, you either pay like everyone else. Or you dont as in my proposal, but then you lose early access and access to modules you dont own.

Here is a slight variant on the proposed subscription based model that may solve more than one problem and be more palatable to users who object to periodic subscriptions: https://forums.eagle.ru/showthread.php?t=277691

I bet this will be a hugely unpopular idea, but I think its a good one that could solve several key problems with DCS development. One issue is that almost everyone runs open beta as if its a release version. If something breaks in what is supposed to be a test version, everyone is up in arms and demands hot fixes because they dont run OB to test stuff, but as their main/only game. This becomes a self reinforcing problem when most servers run OB, meaning users have little choice but also run OB and for all practical purposes, it stops being a beta release, but our main game. The second problem is not unrelated; ED have every incentive to make new modules and sell them early (way, way too early), because new modules are basically their only revenue stream and they do need revenue to pay their developers. New modules tend to require OB, reinforcing the above problem and new unfinished modules risk breaking the game for everyone (think super carrier in MP). ED also have little to no financial incentive in fixing old problems or improving the base layer (VR, performance, weather models, whatever) because no one pays for those. Same with old modules. When they recently updated the Ka-50 cockpit, they basically did that for naught. The time spent on that would almost certainly have a been a lot more profitable if it had been devoted to a new helicopter, This revenue model also creates other problems for us. We have paying map modules and even asset modules that fragment the online community.. Some may have Normandy, others will have channel map. This really doesnt help anyone. But I understand the necessity as ED is not a charity. So here is my proposal to help mitigate both issues: change open beta to be a subscription based early access program. If you want all the latest stuff early, even if its not necessarily finished, you pay a modest monthly fee. included in that fee could be access to all DCS modules (or all modules by ED) in both open beta and stable. For those who hate subscription (and trust me, I hate them too), you are not forced to. You can still buy modules and play them perpertually. But you will only be playing on the stable version and only buy modules if and when they are actually ready. It will promote more stable channel servers and prevent people from being forced to adopt the beta just to have access to populated servers. It will provide ED with at least some predictable income and give them more incentive to fix things and have things tested, rather than rush the introduction of new modules and force us in to the beta.

Thats another problem that may compound this one; the lack of a steady income stream (ie, subscription fees) means ED can only feed its developers if they keep releasing new modules (regardless of their state of readiness) and they have every incentive to focus their developers time on new stuff rather than on fixing year old issues or even maintain the stable channel.These new early access module typically rely on users running OB, so EB kinda needs their customers to run OB. That system is broken. But when a poll is published here if people want a subscription based model, >80% voted no. Something has to give.

No one likes subscriptions. I dont either. I refuse to pay the 3 euro or whatever for my ring doorbell. I refuse to pay in app subscription fees for my smart thermostat. It doesnt matter how low the amount, I bought the hardware, I dont want a service I could easily do myself if only ring allowed me to store my own videos or tado let me decide if Im home or not instead of charging me a fee to determine that based on my GPS coordinates (yes, really). But I do think the idea has merit for something like DCS as it aligns our and EDs incentives so much better. ED is a company, it has staff to pay, it has shareholders to please. The current model gives them only incentives to be focused more on new paying modules, release those modules (way too) early, and doing things that bring in dough but hurt us overall like fragmenting the community with paying map modules or carriers. It also provides them with much less incentive to improve or fix the base layers. Why focus on VR performance when no is paying for a "VR module", why have people work on unpaid under the hood stuff like new weather models when you can instead assign your expensive salaried developers to work on a new module that will actually provide revenue? How can they afford to keep working on DCS world platform when they dont regularly release new paying modules? They should absolutely keep the free version to onboard new players, but once people are hooked, I think its fine to have a subscription based model. Maybe even just for online play or to get access to all the modules. But the a model where you pay 60 euro once, and then expect the game to continue to evolve and expand and improve for the next 10 years is simply not sustainable.

This is largely a chicken and egg problem. Stable isnt stable at least in part because beta isnt treated as beta. Modules are sold in early access, because everyone has access to and most people run the OB. And servers run OB because most users run OB and users are then forced to run OB because all the good servers run OB. It doesnt really matter who's to blame, but ED must find a way out of it.

^ this we are now seeing the pitchforks come out and demand (untested) hotfixes in OB because some feature doesnt work, which wouldnt prevent further testing, but impacts game play, and everyone is playing rather than testing on OB. I play on open beta because everyone runs open beta and all servers run OB. This really must change. Beta should be "safe" for developers to introduce new, risky, not properly tested changes or things that arent quite finished yes and may impact overall game play. And hotfixes should only be applied to bugs discovered in the stable release. I dont know how to get there, maybe the beta should become closed, or in some other way users should be disincentivised from running OB as their primary/only game. Limit session times to 1 hour? Limit the number of users or server slots for OB ? force pink liveries? watermark over the screen? make an annoying popup that every 30 minutes demands the beta tester acknowledges he knows this is a beta release meant for testing rather than serious gaming.. ? whatever. But already we can all do our part by playing on the stable release and only do actual testing on OB.

you are only counting pixels that end up on your screen. With a flat screen, every pixel that is rendered is eventually shown on your monitor. With VR, because of the lens distortion, you need to warp a rectangular flat projection that our GPUs produce, in to some weird shape, stretching it at the borders and compressing it near the center, which throws away a massive amount of pixels. Im also a little skeptical about the 70FPS claim on triple HD with a 1060. Im not getting that with my 1070. And I could get somewhat acceptable frame rates in SP when I had a rift-s.

Mythbusting time. Setting the thread to high priority is snake oil. We all have 4/6/8 core cpu's that are able to run 8-16 threads in parallel. DCS only has one single performance critical thread and you are extremely unlikely to be running any other similarly CPU intensive threads in the background, let alone 16 of them. Then and only then does process priority take any effect, when windows scheduler has to schedule more CPU demanding threads than the cpu can handle in parallel. This simply doesnt happen. If setting process priority high would boost performance at all, every game developer would set their process priority high. no one does, and nor should you. The time where disabling hyperthreading was a good idea, because windows scheduler couldnt differentiate physical CPU cores from logical ones, is also about a decade in the past. Just leave it on. Some people also still believe its a good idea to lock process to a core, to avoid windows bouncing threads between cores. In reality windows does this for good reason, it allows your CPU to boost higher as thermal load is spread over all your cores. Its also aware of slower or faster cores you may have, and CPU cache structure and wil prevent moving the thread to a slow core when its not appropriate or to a core that has no access to the cache data the thread needs. The threads being bounced between cores for thermal reasons is only a tiny benefit, but it at least it is a benefit of having many more CPU cores than DCS uses. And finally be careful drawing firm conclusions based on GPU load figures. AFAICT, those figures apply to the GPU shader units only. Unlike most modern games, DCS is not all that shader heavy, but it is extremely texture heavy. And so your bottleneck may well by in your GPU texturing units or even ROP rasterizers, and GPU load figures, best I can tell, will not show that.

I have the same since the patch in OB yesterday. Zoom axis is laggy and stuttering and sometimes doesnt respond for several seconds, or even at all until I change it a little more, while the rest of the game, including head tracking remains fluid. Tested in F14. The wheel I use on my hotas to control zoom works perfectly fine, thats not causing it.

hmmm? The whole point of FFB is that you dont have a spring that pushes the stick to an arbitrary center position with an arbitrary centering force. This doesnt exist in real aircraft, in non flyby wire planes the stick is just connected to the control surfaces and air pushes against them which then pushes the stick. There is no centering force when you are stalled or on the ground, there is no fixed center position, it all depends on your trim surfaces and AoA. The stick goes where ever the control surfaces are pushed to by the air. And yes, +100 for a new FFB stick. The flight sim market may be small compared to racing (is it though?), but if its large enough for a dozen hotas manufacturers many selling $400+ sticks and throttles and pedals, surely it can support at least one modern FFB stick? And FFB pedals. Spring centered pedals with notches are stupid, they need to have FFB too.

Yes, we should use stable for playing the game, and run beta solely for the purpose of testing. There are countless bad reasons to run OB (cant wait for new module X) but the worst possible reason is the fact we run OB because everyone else does. That means there effectively no longer is a beta branch for testing stuff and safely introducing new and untested and potentially game play breaking features. It means users bring out their pitchforks if something breaks in the OB and devs need to rush untested hotfixes that everyone will run and again expect to work. The current release cycle is broken. Maybe we can do a little ourselves by running the stable branch. This is at least partially because everyone runs OB, so gameplay breaking bugs in OB have to be considered critical and hotfixed. We may even be at the point where they are more critical than bugs in the stable version that hardly anyone plays.

The problem is that a beta would even require any hotfixes and that users demand it, because everyone uses the beta. A beta release is supposed to be for testing. Raise your hand if you start DCS open beta with the goal of actually finding bugs and reporting them? I bet close to no one does. Instead we use the beta as if it where the regular version. Because we dont want to wait for the super carrier. Or our early access module. Or that feature that we have been waiting 6 months for. Or in some cases because the stable version has some major issue that is fixed in the OB, but that is much rarer and those are the only things that would warrant hot fixes. And then there is the worst possible reason to run OB, which includes me; I run the open beta because everyone else does and all the good servers run open beta. And then it becomes truly problematic. Any half finished feature or update that the breaks the game play, ruins the game for almost everyone. There effectively no longer is a beta branch where developers can safely introduce potentially or actually breaking changes or in progress features (when they have side effects) , and all the issues are discovered not by testers testing the game, but by upset gamers trying to play the game. Now you can blame early access / presales for users expecting to be able to run OB without major issues and you can blame ED for a ton of things, but seriously, they need to change this pattern where the beta has to be treated as critical and is not used for actual testing. They must either start treating the beta as if its a release version and thus do all the major changes and introduce new features in a pre beta, but thats rather silly, whats the point of the stable version then. Or they have to curb the (ab)use of OB by all of us, and somehow get back to a point where the beta is used for testing, and stable is used by most people for playing the game.

Dont know, but if so, that is obviously a problem. And it probably is a least partially because stable is not stable enough that people use beta as their normal game and thus expect everything to work in beta and (understandably) get upset when something doesnt. The problem is not that stuff is broken in the beta, its that we all use (or need to use) beta, rather than just test beta. I may get flack for saying this, but maybe ED should limit open beta access or functionality or in some other way discourage people from using it as their default install. 1 hour limit or whatever. Im fairly sure right now there are many more online players playing open beta than stable. If they can revert that back to normal, then they are free to break stuff in the beta without having to worry about backlash, and beta tests can become actual beta tests while we game on a stable release..

Presumably most of these where not known, and because we tested and reported them, they will or should get get fixed before those changes appear in the stable branch. I think you confuse testing with playing. If you find nothing to test in all of DCS and alll the other changes they made because a radar is broken in one module, or you dont get to enjoy your AI kills , Im not sure what to tell you. Dont apply for a job as software test engineer I guess :)

Its open beta. If you are upset things get broken in a beta release, then use the stable version. And then feel free to complain when ED breaks stuf in the "stable" version (and we know they do) and thats a valid criticism. Too many people use open beta because they can not wait for new feature X or because there is stuff that is broken in the stable version, some of which may be fixed in the open beta.. I think more people run the open beta than the stable branch and its become the defacto standard. But that is the problem Not that stuff gets broken in the beta.

Anyone else noticed that zoom is very laggy/stuttery since the new patch? Its quite odd, head tracking is fluid, but my scroll wheel zoom stutters really badly very often.

Just make sure to use nvidia nvenc as encoder (assuming you run an nVidia card, AMD probably has its own encoder). That uses a dedicated h264 encoder on the videocard. If you dont do that, you will let your poor CPU encode 4K 60 FPS in real time, and that just isnt gonna work on anything less than a threadripper. And maybe not even that.

Im not that surprised the cpu can handle it. Its got only 2 cores, but DCS only needs one fast and one "spare" core. It can also boost to 2.2 GHz and IPC is quite respectable, as its a skylake core. It will "only" be about 50% slower in DCS than current desktop cpu's The gpu; well you took take of that by running just over VGA resolution with everything turned off :) But what really shocks me is that you can run DCS with 4GB ram. Now join a multiplayer server and let us know what happens :D.

Maybe, but the point of high refresh rates is kinda lost when playing DCS; when most of us struggle to maintain >60 FPS, having a 240 Hz monitor is a complete waste. Your monitor can not show more frames than your PC can render. Resolution is also much much more important when looking for a bandit against a desert background than when looking at explosions in Doom. Linus isnt wrong when it cames to typical games, but flightsims are different. Maybe. But the overall cost will be similar, as running 4x MSAA likely performs worse than 2xMSAA in 4K. Or if you keep the same GPU, the performance/experience may be worse. FWIW, on my 27" desktop monitors I find even 1080p sufficient. My eye sight isnt what it used to be. Im sure 1440p would be ok for 32". But in my simpit I have a 50" TV and 1080 is completely unacceptable there no matter how high you set MSAA .4K is a must (and looks oh so glorious).

No, but questions where asked about g-sync vs v-sync. The latter being just an option you can enable, the former, just like freesync, requiring a monitor that supports it. From my brief testing Im not convinced g-sync actually works with DCS to prevent tearing, at least with my non certified monitor. Cant test freesync because I dont have an AMD card. V-sync however, does work, and should work with every monitor or TV out there, as well as with any videocard..

ahem.. no, thats not how it works :) Thats not really how it works either. But yes, I already told you how you can help determine what is primarily bottle-necking your performance: under clock. If you underclock your ram and performance decreases linearly, then you are heavily dram speed limited. If it makes no or almost no difference, then its not bottlencking you. Same with GPU speed. If lowering the clock speed of your 1060 by say 20% results in (close to) 20% lower frame rates, then you are GPU bottlenecked, regardless of what task manager or afterburner or anything else says. You already determined you are not primarily cpu (frequency) bottlenecked, since lowering your cpu clock speed made no difference. The logical conclusion of that, is increasing the clockspeed isnt going to improve things either. The only things this does not help determine, is if there is a capacity constraint somewhere. Like running out of video ram which could result in the GPU having to send massive amounts of data back and forth over the PCI-E bus and that could tank performance. And that could also result in task manager showing the GPU as being "50% idle" because 50% of the time its waiting for data from main memory. Lowering and increasing texture quality and changing the "cockpit display resolution" should change the amount of vram you need to some extend and might help identify that as a bottleneck, but its not a "direct" test and I have no idea if even the lowest settings might exceed the 6GB of your card in VR mode. Looking at afterburner wont tell you this either, it will use all 6GB. It will use 11GB if you have 11GB and I bet DCS will use 24GB if someone makes a 24GB card. The question is how much is actually needed to prevent massive PCI traffic, and I cant tell you that. But I wouldnt be surprised if its more than 6GB in VR.

I wasnt so much confused about the difference as I am about their control. The maneuvering flap axis for me doesnt work as a progressive axis, where it should if I read the F14 manual right (I use the rudder/flapy padels on my TWCS throttle for this). The position of the paddle doesnt control the position of the flaps, its controls "more" or "less" flaps. That same binding does work as a direct, progressive axis for DLC. But for DLC I use binary buttons instead. Maybe that is the problem, that I have both binary and axis bindings for the DLC/flaps, Ill test some more.