darkman222

I tried it. Half a year ago. I play a lot of dogfighting in DCS. And with quad views the labels seem to be rendered only in the high res image. As soon as the label goes into the low resolution area it disappears and I see that. Also due to heavy head turning, the headset slips and eye tracking is lost. Also I can see the high resolution rectangle follow my eye movement, which is distracting. But it might serve well outside of the special dogfighting needs It seems like the quad views have more performance impact without DFR than the regular performance you'd get with openVR through steamVR. But as my other test seem to show, in general openXR has higher performance than openVR. So I just need to get rid of the Quad Views to compare both. I did not think of it earlier, because I did not realize, due to Varjo Base update, or DCS updates I just did not get the Quad views displayed on the monitor any more, so it seemed that OpenXR performs worse than OpenVR, which seems not to be the case and I want to investigate it now.

Well, okay. The test with the Pimax helped me to find what might cause my Varjo Aero to show the opposite behavior. Right now I realized that with the Aero using steamVR it uses Stereo (2 views) to render: But when I switch to openXR it uses Quad views. I guess thats the reason the Aero performs worse with OpenXR Is there a way to make in render only in stereo (2 images) with OpenXR as I dont want to use Dynamic Foveated Render due to various reasons?

As title says. It seems like the Varjo Base software comes with an openXR hook for DCS. I havent looked into that for quite a while. I was using SteamVR instead all the time as VarjoXR solution had lower performance. I have a Pimax Crystal too. And I just did a quick test on my other PC with it. Seems like using PimaxXR has 30 percent performance boost compared to the use with SteamVR.

Was that an AI or a human opponent? As if it would not be enough that AIM120 can be fooled with barrel rolling, I hope 9X dont start to fall for the same trick now

I held that back because I thought it was fixed in the changelog "Fixed: Scan volume twitching around when bugged target near or beyond gimbal limit." being a related issue. But apparently not. I have not tried it with smaller jets, as you would not fly like that behing unless you want to do a buddy AAR Will try it with a small jet next. Reproduction: Lock up an aircraft flying in front of you. Go to Nav or Missile mode. Get closer to it about at 400 ft distance the FCR azimuth and elevation symbols on the MFD and the aspect line in the HUD get twitchy and dont seem to know any more what to display. Short video, and full track attached. As I said, further testing with small jet as target in progress. FCR twitching close targets.trk

Reproduction: Use air spawn (as Maverick is already boresighted) Expected behavior: -move TGP over target, Maverick seeker will follow as expected. -switch station to other Maverick -> Maverick from other station will also look in the same spot. Now the not to expect behavior: -now lock the ground target with the TGP (Maverick MFD screen becomes SOI) -switch station to other Maverick -> Maverick "line of sight" symbol in HUD will move up to the center of the HUD ( Maverick boresight cross position, not ground stabilized) ->TMS down and "line of sight" symbol and Maverick seeker will move down to the target again - switch station back to previous Maverick and the same will happen again. Unless you press TMS down again. See a short video of the unexpected behavior and to watch the full reproduction in the track attached. with tgp locked station changed mav looks straight ahead until TMS down.trk

Wishlist items for me: Get the current F16 in a good shape again considering the buggy already existing systems, before adding any new systems to it. Sorry for the hijack, just to put such wishes in the right perspective.

... as long as the request does not affect game performance...

You can export it to a second monitor and record it. Do you need to record it while flying? Or can you also run a track replay? So you could use the settings layout of MFD + Camera and use a recording software like OBS and record only a cropped area of the sceen with the MFD. Its not the exact thing you want, but at least it works right now.

What youre saying is that the first units are already shipping? I placed my reservation in Febuary ... But if they started shipping its a good sign.

The thing with the F18 is that in a guns only dogfight that thing just points at you all the time. You expect it to have it bled its energy at some point. You take the fight up hill in the F16 but the F18 still follows. WIth the M2K before the flight model update you could do that exact thing. Let it point at you and let it bleed its energy. After the FM update one year ago it also got a nuclear powerplant installed. So what is to question is not the performance of the F16 but the drag modelling of the F18 and especially the M2K with its delta wings, which should be just like an air brake at slow speeds. For comparison you can do it with F15s. It only has the energy to point your nose at you while youre at rate speed twice. After the second time, hopefully defended the gun two gun shot opportunites of the F15 its nose will drop and its payback time for the F16. This is at least my observation on the dogfight servers. Talking about guns only scenarios.

Thanks. Although its related, this does not cause the main issues using the radar in that case. The issue is that while pressing TMS UP and NO RAD is showing the radar is slewing whlile being active to the desired target and auto locks everything that is in its way. Making it impossible to pick specific targets with the JHMCS ellipse. I am not even sure for how long this bug has been around now, but this orignal thread date is from December last year. I also made a report about a contributing issue with the radar always starting an azimuth sweep from left to right when the radar is turned on in another thread. That thread is tagged as "reported" in March 2023. Thats one year and one month now with the JHMCS being unusable. Can these two related bugs be please adressed now? Nobody requests a new feature here. Just requesting to fix what once was working.

As far as I know the bug only exists in the F16 and the F18 as they seem to share some common code with each other. I dont know of other jets from ED that have that issue. It is very annoying that I once purchased an F16 with working STT lock funcionality. Then it was broken, after that it was fixed only to break again after a few updates to stay broken until now. I cant even remember how long that bug is around now and annoying people. Especially in the F16 where the level 5 pipper has a delay until it shows up. I cant count any more how often I could not take a shot with a working pipper while I was just fighting the radar to lock the bandit instead of fighting the bandit. Together with the jumpy pipper that has not been adressed either gun fights in the F16 are like playing poker against the STT radar.

+1 please fix ED

To bump this thread and to raise awareness to that it might be related to the LOD switching which might have been changed from 2.8 to 2.9 Have a look at the thread I created right after 2.9 was released. My latest test was to revert to 2.8 where performance was good. Correct me if I am wrong but if a simple revert to 2.8 gets rid of the stutters, then it's not a faulty driver or Hardware or anything else that suddenly caused the stutters. It's DCS 2.9 only which causes the stutters. I am really sick of comments making me look for the cause on my end. Also comments like it's running fine on a 2d monitor. I am pretty sure it's there too. But people don't notice as 2D stutters are not as obvious.

+1 Until then give https://openkneeboard.com/ a try. You can use it in VR bind it to your HOTAS. Have different folders, a radio log etc. I spend too much time in my life not using it

Which ones are you referring to? I thought ED models only things that data can be publicly accessed.

If you lock a bandit with STT through the JHMCS helmet, in a ratio of about every 3rd lock will be lost showing this behavior. The bandit is not jamming. I was trying to find similarities in the situations where it happens. Thats why I played it back with the radar MFD showing. Also I thought maybe it only happens when the bandit or another aircraft was locked before through STT. But that was not the case either. It can happen with the first lock attempt too. It happens with the clear sky behind so its no ground clutter involved. Also even if it should not be possible to notch a radar against the clear sky, that can not be the case here. There is always a good closure rate when watching the numbers on radar MFD. Note that the radar is not on its gimbal limits either. If you want, try it by yourself. Take one of the track files and take control. It should not take more than 3 or 4 attempts. To summarize: No notch, not jamming, no radar gimbal limits involved. What else can it be? Maybe someone with a fresh eye can watch the video and look for hints what may cause it, by taking a closer look at the radar screen. Hope that its helpful with the radar MFD showing although the cockpit view and the JHMCS is not very sharp that way. I included all the track files shown in the video lock air behind the bandit4.trk lock air behind the bandit0.trk lock air behind the bandit1.trk lock air behind the bandit2.trk

Yes. I am not doubting how the DCS F16 is modelled with the currently available data. I was saying unless, if not out of a sudden contrary evidence pops up, which is unlikely, we need to work with what we have. Thats the whole point of what I try to contribute here is how to get the 21 deg/sec out of the current F16 FM. Trying to point people struggling in the DCS F16 to look into other factors they need to consider other than flying 450 kts circles and wondering why they cant win a dogfight that way.

Yes and here comes all the misconception from. Staying at the "low" 18 degrees per second is only if you are one of the dudes who think if you fly the perfect speed on a horizontal plane of motion, then you'll win with your "not" rate king F16. If youre already on the deck, sure, youre out of options. Or at least you have less. If you want, you can replay my track file against the mig 29 and watch in Tacview for how long and when I hit 21 degrees per second. Spoiler: Its when I dump the nose below the horizon and pull 9G. And luckily my pilot does not black out because g effects is off. So I have the 21 degrees for as long and when I needed them. I would wish someone came up with a unclassified document that the FM of the DCS F16 is wrong and a sustainable 18 deg/sec is too little ( drag?). But until then we have to work with what we have. So forget about winning a fight by sticking to 450 kts and wait until you win a medal.

Sorry for bumping it up again @BIGNEWY and @Lord Vader. But I did some more testing. I was suspecting the LOD switch factor to have effect on it as many signs point to the sutters coming from geometry and textures loading in and out of the CPU threads. Different LOD switch factor settings produce different CPU frame time spikes and thus different stutters. Interestingly a factor of 1 which is default, produces the worst results. This was all done with the same the track replay. In my previous test using the ST branch of DCS DCS 2.9.3.51704 did not produce stutters as expected. We know that already. But for this test I reverted to DCS 2.8.7.42718 OB where I remembered not to experience these stutters. And whatever was added to DCS from 2.8 MT to 2.9 MT contributed to this bad CPU frame time behavior a lot. I used the same mission as it was simple enough that I could run it in 2.8 too. So the results are pretty well comparable. I am knowing that DCS is progessing. But from 2.8 MT to 2.9 MT something was introduced that made the LOD handling in MT worse. And the root cause seems not having been adressed since then. Edit: My test reverting back to 2.8 at the present day is not irrelevant, as it clearly shows it's not a change in hardware or driver software that caused my well running system to perform worse with 2.9. because I get my performance back the very moment I revert to 2.8

Good to hear the g modelling is being adressed and already in testing phase. What I wanted to illustrate above was not for questioning the sustained or the instantaneous turn rate of the DCS F16. This track file should bring to the attention to people starting to fly the F16, wondering about why outrating an opponent by using sustained turn rate only, does not work, that there are other options too. Because mostly they dont do anything wrong, besides not noticing that they simply wont be able to out rate their opponent considering their jet configuration / weight.

You can measure it in Tacview or try the "SustainedTurnRateMissionF16.miz". I uploaded it. Unfortunately the refresh rate is not too good, but it gives you a clue in the cockpit. As @MTM was very thankful in a PM about my track file dogfighting the Mig29 with 3000 lbs of fuel by not stubbornly trying to outrate it, using bursts of the full 9G and 21 degrees per second capability instead, I feel that it is necessary to answer these questions about out rating an opponent also with the advice that out rating is not the solution for all of the engagements you'll end up in the F16. In fact it mostly is not. That encouraged me to try the initial setup with 7000 lbs of fuel @MTM requested. Although it is not possible to outrate the Mig 29 you can defeat it with by bringing a lot of speed into the merge. Again, whats needed is the capability of the DCS pilot to sustain 9G for around 15 seconds. I was using 8+ G for 13 seconds and for 17 seconds in that engagement. And ended up in his control zone. Even with 7000 lbs of fuel. (track attached) So please ED @BIGNEWY. As even your demo for the sustained turn rate was with g effects off : Do us and yourself a favor and consider to adjust the G tolerance of the DCS pilot for the F16 soon. It makes it much easier in these arguments about the DCS F16 "performance in dogfights" if not only the F16 performance is correct as is, but also the performance of the DCS pilot meets real world requirements. SustainedTurnRateMissionF16.miz Mig 29 vs F16 7000 lbs fuel no sustained turning with no g modelling.trk

Thanks a lot. Me running an Intel 13900KS with an RTX 4090. Vr Headset is a Varjo Aero. And second VR headset is the Pimax Crystal. The user I talked to had a comparable system. Crystal, RTX 4090, 13900K ( not KS). He even had stutters in the menu which were gone using ST. Another user on the dogfight server has the 7800x3d + 4090 + Reverb G2 without issues. Unfortunately he has a different headset and processor. I really am thinking about the intel processor at least contributing to it...

@BIGNEWY Can we please get a tag if it is being worked on or not? As soon as the ST exe will be taken away from us, we wont have any reference to test it with. It is definitely a MT issue here. Testing again with ST and no lags or spikes occurr on the CPU frame time graph. If there was MT optimisation done in the latest update it does not show up in improved texture and geometry streaming performance of displayed aircraft in MT. I had a talk with another VR user who got hefty stutters in the DCS menu already. Switching to ST got rid of the stutters. But this is no permanent solution as ED is planning to take away the ST exe and the lower performance ST has compared to MT.