5ephir0th

Apache it´s a mess on VRAM usage, more than the Hind so unless you have a 24gb VRAM GPU you should lower the texture detail to medium. To me OTT just mess something, i prefer to use Oculus Debug Tool and, if i need some especific option for DCS, i made a .bat to change what i want (like FOV, as example)

Aerobrake its the word

Then show ED some evidence of that and, if you suggest to reconsider, then it´s not "but ok" DCS Viper can land on some short runways, you just have to make it right

Nah, real Viper pilots knows nothing about the aircraft, we must trust some chair pilots here and there...

The issues with VRAM on DCS are real but with 10-12gb the problems usually appear with the Hind and Apache, those two cockpits, while looking great, are poorly optimized on triangles and textures, for example the Apache cockpits has three times the polygon count of the Viper even looking much more simple. The more strange thing is that the Tomcat cockpit has a greater polygon count and the textures are the measuring bar on DCS and, with all, it runs way better

This, you can see from my signature almost have all the "big fish" from ED and, by the far, F16 is the best plane DCS World can offer tied with the Tomcat from Heatblur

Thats why i said "almost". I dont see jitter on VR (and believe me, on first months of new clouds it was horrible, the jitter you see on FZG_Immel video its like a 5-10% of what it was on VR at first), the problem in VR is, with the lack of detail which i dont know if its DCS fault or the VR headsets himselt, that even in high detail you can see a very agressive LOD on clouds like, at 1nm distance, it looks ok, at 2nm it looks horrible, like if it hast 1/8 of the resolution of close ones. It gets more annoying on low altitud clouds

Follow installations guides but remember, you have to run DCS on SteamVR mode for it to work, it doesnt work with Oculus API

And why it takes, at least, 15 months for fixing with no explanation? Same happens with the raindrops on canopy

Well, at least in 2D it "almost" looks ok, on VR it looks horrible, the farther they are, the worse they look even at high quality, not to mention how they look when on low altitud ones, they are a mess with the terrain (you just have to start free flight mission on Caucasus with the Viper)

So no pilot body this update?

This. I already said it, changes from high to medium looks random, examples: - A10C II: the changes from to medium are hardly noticiable but then, you set medium and, by example, the fire pull handles texture has a very low resolution - AH-64D: same as A10C II, barely noticiable from high to medium, then the textures of text plates below the MPD or the textures from seats side protection has an horrible resolution - F-16C: here is different, differences from high to medium are insame. Thats some differences in cockpits but it happens the same on the outside textures are a total mess, terrains same, ground textures on low on Syria is horrible and full of extrange patterns that dont happen on PG or Caucasus

Being Heatblur guys and knowing their attention for details, i expect it

And not only WMR headsets, Oculus too, i use that smoother on my Quest 2

It will work with all Mavericks if they are looking at the correct spot, the same for the TGP on tracking mode, as @razo+r has told you, clouds has no effects on sensors, it affects too for IA visual searching, they will see you even if theres between you three layers of clouds, just like if theres nothing

Knowing that they, atleast, are making a revamp of the S3 model (that looks awful) i think a good start point would be the tanker announcing his turn and adding physics to the basket, from that a total rework of the comms (and procedures) and adding some effects like the fuel dropping on disconnections and would be great to add collisions to basket and boom, it´s annoying that you can have the basket and boom inside your cockpit, Most of that, for sure, it´s in the pipeline.

Because TrackIR has an inbuilt smoother and it looks like VR headsets tracking has way higher resolution than TrackIR or similar

Hi. I fly VR and lately im getting random crashes, sometimes two minutes after the start of the mission, sometimes 30, some notes: It only happen on this game, no other VR or 2D game give me this error It happens on any map and module Windows 11 power plan is High Performance XMP profile is disabled nVidia debug mode is activated My screen is Gsync, and Windowed and Fullscreen mode is selected It's driving me mad dcs.log-20220709-234254.zip

Have the same problem, throttle profile mount its just simply bad designed, too unneeded complex and blocking half of the mounting holes. Theres no problem for the right ones, just move the mounting rails to the left if you dont want to cut it down, but for the left ones theres no solution as you said, rails don't line up, it´s a fail design. Even without the Viper side profile you will hard a hard time mounting on the left holes due to those plastic appendix on front and back, i was thinking on designing some pieces for 3D printing to mount the side profile on those appendix (there are nuts inside) leaving the bottom area clear for use the hole, but i dont have time right now. The only thing i hate from my Orion 2 it´s that mounting system if you use the Viper throttle...

I was using the Spanish version of the site, it looks like it´s a bit incomplete, change the language to English and everything went fine

This is absolutely ridiculous, who the hell though it was ok or necessary to have two different models or textures for the M4, doubling the requeriments of VRAM for absolutely nothing. I have never seen a game of this magnitude using this kind of ridiculous "optimizations", ED just work with the models like our GPUs has an infinite VRAM and triangles that it can handle.

Are you sure you looked on pinned threads? https://forum.dcs.world/topic/206282-subject-to-change-desired-f-16c-systems-and-payloads-for-early-access/#comment-4997481 On green are the ones already implemented and, if you go down, will see that the last post was last tuesday

And here i stop reading...

I must be wrong but on those four videos the detection range is the same, 45nm. if you are talking about that with more bars you detect more targets on different altitudes of courses you are scanning a bigger space volume

As you said, the TIME cannot be the same, not the range. If you change from 4 to 2 bars, you will scan half the volume but at the double refresh rate. Think about it, per example, you set 4 bars at 30 azimuth, the time the radar take to complete 1 bar at 30 azimuth is 3 seconds (just an example) Bar 1 (top one): 3 seconds, Bar 2: 3 seconds Bar 3: 3 seconds Bar 4 (bottom): 3 seconds If the targets is at the scan volume that takes the bar 1, once completed that bar you have to wait at least 9 seconds to search again on that zone, so the target has been getting closer at that time. An example, we can detect the target at 56 miles, target is located on scan volume of bar 1, 4 bar and 30 azimuth: Bar 1: target is at 60 miles, we cant detect it yet Bar 2: target is at 58 miles, we cant detect it yet Bar 3: target is at 56 miles, already in detection range but we are looking at another altitude Bar 4: target is at 54 miles, as above is already on detection range but searching on wrong altitud Bar 1 (again): target at 52 miles, now we are looking at the correct altitud, detected! Now same as above but with 1 bar 30 azimuth: Bar 1: target is at 60 miles, out of range Bar 1 (again): target is at 58 miles, out of range Bar 1 (again): target is at 56 miles, in range, detected! So, with 4 Bar we detect it at 52 miles but with 1 Bar we did at 56 miles, this mean that with less bars the detection range increase? No, it just increase the refresh rate, the differences depends on timing and closure rate