Chapa

Following the same process seems to have fix the issue for me too. I looked at the _backup folder corresponding to the cleanup and repare processes and it contains only lua files used by VAICOM PRO and its extensions. It's not a proof that was the cause but it would not be surprising

I also have crash systematically when flying the JF17 but have any when flying other like the P51. I will try again today because the sample size of tests are not enough to really conclude but I am now convince there is an issue somewhere given the number of people complaining about crashes: core DCS or JF17 don't know. I had in both the caucasus free flight and easy landing mission. Without using special systems, just turning on the cockpit light and playing with the stick and throttle. It is the first time, I have crash like that with DCS and no issues before the open beta maj, no mods. I also fly in VR with a Rift S. Could be a VR specific issue... P.S I can't attach my crash log here because already attached in this post: https://forums.eagle.ru/showthread.php?t=256837 Thanks you in advance, Best regards

Since the last open beta update and with the JF17, I also encounter CTD. In attachment, you'll find the full crash logs. I have increase the pagefile to 16GB (I have 64GB so not an issue). I have droped my saved games folder to be sure to have a clean one. I use no mods. PC clean, freshly reinstalled, windows update done and with very few softwares installed on it, mainly dedicated to DCS. I am playing in VR with a Rift S the crash log provided has occured during the JF17 caucasus easy landing mission. Suddenly, the hourglass appeared and I had the blue popup displayed on the monitor. Note that previous this crash, I encountered other crash with a windows popup indicating C++ Runtime error but no specific message about dll, except to contact the revendor. I encountered no issue when flying the P51D before the JF17. Crashes have always been encountered when flying the JF17. Thanks in advance for your help, hope the crash log will give answers :) Let me known if I should post in the JF17 dedicated forum instead dcs.log-20191204-232454.zip

First of all, very good job. The are very nice little details like the names of the HOTAS bindings that prove your dedication and the great experience you want to offer in this early access. Question, bug or problem, I don't know but is the default position in VR as it should be ? My first thought when I jumped in the cockpit was: Nice, a plane in which we have the noise in the HUD at it seems to be from pictures I saw. (with the advantage to have all MFD very clear and lisible in VR). But after visiting the pit and looking behind me, I noticed that the back seat is far behind... it is inclined but even the base seems far and the stick near. If people or pilot could share how we really feel in front of the HUD (noise in the hud ?, about arm extended distance?, other simple metric?) it could be great, and if using a Rift S, his custom snapview settings very nice :) Thanks you in advance and very good job again

Mig-15 is probably my favorite

You have probably saved a snapview, overriding the default position by pressing on RALT+NumPad 0 during a session. If you don’t use custom snapviews in any of your modules, deleting the snapviews.lua file in saved_games/dcs/config/view folder should fix the issue. If there is no such path/file, I don’t know what is your issue and reparing DCS could help

I have a WarBRD base and initialy used it with the WarBRD stick on the desk and it was ok. When I bought the F18 TM stick, it started to be less confortable because the stick I taller. So I decided to invest for monstertech table mounts. It is better now and I am happy with them even if I should have bought the long version mounts for the stick. I am not a tall guy with only 170cm and my small hands, so it could be anticipated. Take this feedback for what it is and not a truth. Concerning stability on the desk, not bolted, I had no issue with either stick. But law of physics will apply: high force applied at the extremity of a tall stick will create a high moment, so it is not impossible to lift the base. It occurs few times with the FA18 stick, heavy stick with forward center of gravity and mostly noob manoeuver and piloting skill :)

I think niche market is always driven by passion. Passion from the service provider and passion from the consumers. Expectations are crazy high, time limited and opportunity to win money must be exploited and provoqued with care. Overall, Eagle Dynamics manage this very hard equilibrium quiet well. I feel not stolen, and of course sometimes I would see some improvement sooner than later but I understand the reasons of the wait. I am as you, I also bought some modules to support ED and the third parties. Their work are always worth the investement and I have always huge pleasure to discover the cockpit, the start sequence, read enough the manual to understand its story and philosophy. In a previous life, I was a developer and with me, wishes with mockups even drawn on a tablecloth and detailed bug reports was often solved sooner than others :) Nice post and initiative, wish also to hear the ED and 3rd partie's voices.

@Bob: My post was not dedicated for you specifically but for people reading this post as simple information about what is PD and to rebound about the famous SSAA settings that as no impact with HMDs. You state my numbers are false but they aren't and the render resolution per eyes are the one displayed by the HUD provided by Oculus themselves and accessible from the Occulus debug tool. For people, not knowing these tools (accessible from Oculus Debug Tool and OTT also): https://developer.oculus.com/documentation/pcsdk/latest/concepts/dg-hud/ As you state, the Rift Sa has two settings: Performance and Quality. Behind the scene, Performance setting is in fact a PD of 0.9 or 0.91. It correspond to a resolution per eye of 1488X1600, meaning a total resolution of 3296x1600 (it is the same number than you say, your number are not totally right but same magnitude doesn't care). The quality settings corresponds to a PD of 1.0, a resolution of 1648x1776 per eye, so a total resolution of 3296x1776 (we have the same numbers again). The columns in the table are simply the number of pixels per eyes, the total number of pixels (so 2 times the pixels per eyes and some ratio). My maths looks rights and we agree on the values. The goal of the table is just to have numbers and real figures about what the GPU have to digest to really display the true native pixels of the Rift and some comparison with a 4K display for the range of usual PD values.

As a workaround, you can map the three keybinds and build a macro with a tool like Voice Attacks. It can be useful for so much things that it is worth to be annoyed one time with it and never again by the NVG feature you don’t like. Not as easy for sure but pragmatic.

I agree with dburne. Rifts S and 2080ti is the right combo. Of course you will have pleasure with the 2080super. It is quiet similar in performance than the 1080ti (little bit better according to the benchmark I just looked). I own a 1080ti paired with an i7 8700 and what I can say is that this GPU lack a little bit of juice to really shine. The 1080ti is from 2017 so don’t really expect a GPU to really handle well futur HMD. The 2080ti is the GPU well designed for the Rift S generation of HMD. HMD with higher resolution will really shine with the next gen of GPU, even if they works already well. The only dilemna I would have in your position with the 500$ difference depends about your current HOTAS, and your satisfaction about it. Because 500$ can cover the cost of a really nice base+stick and in my opinion, it could provide more pleasure for the bucks than the 2080ti. If happy with your HOTAS, so 2080ti because you will never have enough power to handle VR

@VirusAM: In the texture filtering LOD Bias (DX) setting you have probably set a positive value... you must set a NEGATIVE value.

Guys, here are some maths to explain why your PD/Super sampling settings looks amazing. First, PD or should we say Super sampling is be definition an antialiasing technique. As far as I know, it is the pendant of SSAA DCS setting but for VR. It is not totally exact to say that but it's an easy to understand vulgarisation: When you set SSAAx2 on a monitor, your GPU will render an image wit the double the monitor resolution and then downscale it to the monitor resolution with the benefit to have reduce aliasing. So, for example, if you set SSAAx4 with a 1080p monitor, it will render a 4k image and then downscale it to the native resolution of the monitor 1080p. Doubling the resolution imply to multiple by 4 the number of pixels, so the SSAAx4 and not SSAAx2. All that to say that PD is the same idea. ----- The Rift S has a native resolution of 1280x1440 per eyes, so a total resolution of 2560x1400 for a total of 3'686'400 pixels. A 4k monitor has a resolution of 3840x2160, so a total of 8'294'400 pixel Here are now the maths: [TABLE]PD Resolution per eye Number of pixels per eye Total number of pixels Multiplicator native resolution/ Equivalent SSAAx Multiplicator 4k resolution 0,8 1328x1424 1 891 072 3 782 144 1,03 0,46 0,9 1488X1600 2 380 800 4 761 600 1,29 0,57 1,0 1648x1776 2 926 848 5 853 696 1,59 0,71 1,1 1824x1952 3 560 448 7 120 896 1,93 0,86 1,2 1984x2128 4 221 952 8 443 904 2,29 1,02 1,3 2144x2304 4 939 776 9 879 552 2,68 1,19 1,4 2320x2480 5 753 600 11 507 200 3,12 1,39 1,5 2480X2656 6 586 880 13 173 760 3,57 1,59 1,6 2640x2848 7 518 720 15 037 440 4,08 1,81 [/TABLE] The resolutions per eyes have been obtained by using the HUD provided by the Oculus Debug Tool and the PD corresponds to the DCS PD setting. In reality, the true HMD PD is sometimes for example 0.91 instead of 0.9 as indicated by the DCS cursor... As you can see, a PD of 0.8 is about near the native resolution of the Rift S. Interestingly, a PD of 1.2 is the equivalent of SSAAx2 and PD of 1.6 is equivalent of SSAAx4. PD has for effect to improve clarity and reduce aliasing and shimmering. If you play at PD1.3+ and are happy with that, there is really no advantage to run the settings proposed in this post. This post is for people that want good clarity but can't afford so high PD for some reasons: want to play always at 80Hz, GPU not strong enough, HMD with high native resolution, etc... With the proposed settings: Negative LOD Bias, it is possible to have the same clarity at PD 1.0/1.1 than 1.4/1.5 but of course without the nice antialiasing and shimerring provided by the so strong but costly PD settings

I am not aware of steam VR settings that could be profitable for a Rifts S that are not natively included in DCS VR tab settings. Keep it simple would be my advice, choice 1. For the story, when I choice my HMD, native support of Oculus in DCS and to be able to avoid to Steam VR was a strong argument. Lower the number of software layers, lower the numbers of settings, bugs, headaches....

I agree with you Wicked, Sparse Grid is not the way to go... Not worth the 0.1 PD it cost at the end for less... For info, SSAA has not effect (or I am not able to see it). I also think that he set positive LOD Bias. The importance is that he is happy with his stuff and settings. Concerning Confusius, he will be happy to know that I am a patriot and the important thing is to have the settings ready for the release of the JF17.

@Wicked: It appears that we are all converging toward a LOD Bias near -0.5 It the old days of DX 9, there was a rule saying that : LOD -0.5 for Sparse Grid x2 LOD -1.0 for Sparse Grid x4 LOD -1.5 for Sparse Grid x8 this criteria was driven by a mathemical formula with a log, so just to say it was something more complicated than a rule of thumb formula. I am playing from yesterday with the Sparse Grid x2 settings but to be honest, I don’t really know if sparse grid really improve the result instead MODE REPLAY ALL... However, LOD bias of -0.5 with minimum -0.75 seems to be the sweet spots to not induce tons of shimmering

I will try your settings because I always read that DCS SSAA is for monitor only. I have a rig similar to yours and it is clear that a PD of 1.3 tend to activate AWS most of the time. The settings proposed in this thread is more fore people wanting to play at 80Hz but with good clarity at the cost of some aliasing and shimmering. With a Rift S, a 1080ti and AWS on it is possible to have near perfect view. Until you chase a warbird and you see 4 times the plane because the gosthing effect induced by AWS and you have hard time to know if it is an ally or not (not easy for me at least). A PD of 1.2 is about the same number of pixels than a 4k screen, 1.4 is more than 11 million pixels and sometimes I read people playing with PD at 1.7. It can works with AWS but each time I try, seduced by the nice picture, I am hit by the hard reality that my 1080ti is tired or too lazy... but I will try your settings. Thanks you for the alternative and feedback

@lange: for the connector you need a Sata to Molex converter. I know it would be better to have one with the good controller and already the SATA connector as you wish but you have now at least one solution

The F-16 has performance issue in VR. Don't use this plane to tune your settings. And being on ground is not a good idea because there are a lot of lack of optimisation. Try to totally disable all the shadows because on ground shadows kills the FPS... It is really annoying and I post yesterday in the wish list forum the suggestion to add a shadow (cockpit only) setting to improve the situation. I suspect you are experiencing it :)

Not a good idea... Asmedia controller. Not surprising it is USB 3.1gen2 ports... As a hint, cards with USB type-C will have most of the time ASMEDIA controller. Try this one, you are in Belgium so it is probably possible to obtain it: https://www.exsys.ch/de/pcie-karten/usb-3.0/standard/pcie-usb-3.0-karte-2-ports-renesas1.html

@Lange: Sorry to hear all the issues you encountered. Very important !!!! : buy a PCIe card with power provided directly from the PC alimentation. Power provided by the PCIe port can not be enough to cover the needs of the Rift S in all situation. For info, I bought this card : Exsys EX-11092-2 The card has a jumper to decide if you want Power from PCIe or from PC Alimentation. By default it is set for PCIe port, so it has to be moved. My motherboard is an Asus Rog Strix Z370 egaming and I can garantee it is compatible with it. However cards with VIA controllers are not (or at least the model I tried first)

Personnaly, today, having a USB port on my GPU would be a pre-requisite. Why ? Because my 1080ti don't have one and I had some headaches to understand why I needed often to unplug and plug again the Rift to be able to play... And when I learnt that it could be caused by the USB bandwith shared by multiple devices, It was not so easy to find a compatible PCIe USB cards with my motherboard and the need of the Rift S. However, it doesn't mean that it's not possible to have a working Rift S with no USB port on your GPU. To have no issue, your Rift must have its own USB controller with all the bandwith dedicated to him. Good news, your motherboard have many USB controllers. Check the manual but if you are able to isolate one of them for your Rift, it will be probably OK and everything will works fine. If not possible, you will have to buy a PCIe USB 3.1gen1 card. Warning: Don't buy card with USB 3.1gen 2 port because they often use ASMEDIA controller and it is well known that this controller create stutters.... It seems that Renesas µPD720201 controller works well. Oculus suggest one card with this controller. I bought another card with this controller and it works perfectly now. But for sure, if you are able to cancel you order and find another GPU, it could be safer and good idea

Try other planes, if the issue is the same, you have probably some tuning to do but... my opinion is that the F-16 is not VR ready. I have clearly a noticeable drop in FPS with this plane and only this one (Ok MiG-21 also but less). I have most of all the planes and it is clear that if I would fly seriously the 16, I will have to drop some settings to recover the FPS somewhere. All that to say that don't use the F-16 to tune your settings and check after being happy with them, how the F16 feel... and adjust ;)

I don’t know the Index and if it has some similar feature than AWS for the Rift (reprojection maybe ?). The fact you are saying that the watery effect occurs on ground let me think it is an artifact caused by something triggering when the charge on the GPU increases. My advice to track it would be to put all DCS settings to low first. Keep only Texture: High, your PD setting (decrease it a little bit could be good for testing) and the Inspector settings at they are now. If it disappear, it means that it could be: 1) some DCS settings 2) because you have free resources, the AWS like system don’t trig and no more artifact. To be sure, then increase a lot the PD setting. It will force its activation and see the problem occurs again. If it occurs, it means that the watery effect is caused by the AWS/reprojection process

Yes Wicked the transparency Sparse Grid Supersampling antialiasing works. It even cost at least 30 FPS. I am speaking about other AA settings in Inspector: AA Mode that should override the MSAA setting in DCS. In fact we are lucky that the transparency setting works For sure, it is not placebo effect you are seeing