exil

Hey, something must be a bit faulty with single engine performance. In helicopters, if troque is the limit, you can take double engine performance and multiply it times two to get your single engine power. So i compared some numbers while taking one engine to idle in flight (tried with engine 1 and engine 2): double engine power = 2 x 30 % TRQ single engine power = 1 x 80 % TRQ (should be 1 x 60 % TRQ) double engine power = 2 x 40 % TRQ single engine power = 1 x 112 % TRQ (should be 1 x 80% TRQ) Find the attached trackfile to see what i mean. SINGLE ENGINE PERFORMANCE BUG.trk

Did you try the stuff with WMR4SVR mentioned a few pages ago? That did the trick for me and besides the apache, reprojection is working flawlessly, even when down to 30FPS without any difference to 45FPS.

Yes, A10c, F18, F16, UH-1 and HIP. But apparently, the apache didn't work well with repro on steamvr either. I was seeing some good frames at the beginning but the the whole stuff decreased. I had to alt-tab out of the game to get it fixed only for a couple of minutes before it started again.

The apache does not work well (or at all) with reprojection as I found out. All other modules are going really well. Also with 45 FPS.

I can now confirm that it's the apache itself causing problems. I ran a test mission with a lot of different aircrafts. Here is what I've found out so far: With reprojection off (no matter if steamVR or OpenXR) everything is fine. Apache is a bit more demanding then other modules but generally okay. So I hopped into the A10, F16, F18, Huey, MI-8 and the apache with around 50 - 60 FPS without any major stutters besides of the once that are generally there. Then I turned on motion reprojection and did the same thing again. While I could easily maintain 45 FPS in all other aircraft, I got immediate stutters when in the apache. FPS dropped to something like 15 - 27 and my GPU load decreased (interestingly) to around 35%. To me, it seems like there is a significant negative impact between the apache and motion reprojection (or motion smoothing in steamvr). I am running a G1 with an 5600X,32GB RAM @ 3200mhz and a RTX3080

I had this problem too under SteamVR. I don't know, people are telling that it's a memory leak, but I don't think so. It like at some point the game engine is not using your whole Gpu power. And then, after alt-tabbing it's like a wake up call for the Gpu. I also only have this problem with the AH-64 over Syria (at least I think... Have to try again on other maps). Also switching from one Apache to another resulted in massive framedrops and a lowering in Gpu usage of around 35% where it was around 90% when frames are stable. I recently switched to OpenXR and the problems kinda vanished when not using reprojection.

Copied! Thanks!

I'm not getting better FPS but - and that's the main thing - the spikes and peaks are gone. Consider it this way: with steamVR I was getting frametimes around 13ms and a spike every second now and then over 22ms. Therefore it would stutter. With OXR I didn't get those spikes, so i was able to run a higher resolution close to 22ms without the spikes. No, I think I miscommunicated here. I mean the desktop overlay of OXR toolkit where you can set your keybindings for the overlay in game. I think I left it open when it worked the first time.

Did you leave it running? Because that could be the point. I was able to get the same result as you when I installed openXR toolkit. After some hours later, I fired up my PC again and it didn't work anymore. Maybe there is some process running in the background with OXR toolkit opened that is needed for smooth reprojection.

Roger, got it! But where then do you set motion reprojection to on? In the OXR Toolkit with Ctrl+F2? Sorry for the dumb question but this is somehow confusing

I don't get it? So you are still using SteamVR? But with an OXR runtime?

Just so we are talking about the same thing here. What I mean is the following: Major changes: hold FTR, move the stick, then release FTR. Minor changes: just move the stick without pressing FTR. Nevertheless, there is no 'it must be done this way'. If one feels happy with simply short-pressing FTR when your in the right attitude, why not. I know a lot of guys using different methods in real life. I, personally like the 'hold, move, release' more IRL because I have the feeling it gives me more precision. Whereas in DCS I am more of the 'just press' guy because without FFB you won't feel any resistance when moving the stick around. So that wouldn't hamper my precision. I say whatever suits you best. I really don't get the arguing around here sometimes (not meaning you personally).

Its not necessary to trim out every movement. Once trimmed out straight and level you can just push the stick without trimming, turn, roll out and you'll have the same attitude again (not taking wind into account of course). Only if you intend to make major changes in attitude (E.G. speedchanges) you may want to trim again.

Thanks for the reply. I think so too. There are more desync issues like laser and stuff. Today, I armed the laser and fired it. My pilot was not able to see it. I switched it off and on again and then it worked for us both. As you've said, we just have to be patient. Nevertheless ans despite all the current issues, this is one of the best, if not the best EA release I've ever seen from ED.

Just as a heads up. We tried it again today and route manipulation was seen by the pilot. The only thing that was buggy was the WP information in the IHADSS of the pilot. While I set an direct to to WP 4 he saw it on his TSD. But on his IHADSS was WP1.

Same here, same error code. No sollution yet.

Enlighten us then...

Yes. In DCS. I believe not in the real aircraft.

Not actually a trim switch. They are called micro switches. The pedals are actuated by the AFCS depending on your demand on the collective to keep you in trim. So if you push the micro switches it set a new reference Datum for heading hold. If you let go (feet off) the AFCS maintains that heading depending on your collective setting. Over a certain IAS you would have to press the switches in order to maintain a coordinated turn. I believe the apache works that way too, but it's just not possible to implement Sim wise.

Good to know! Thanks a lot. So it really seems like a desync bug in MP. We were also both in NAV and tried both to toggle through all modes just to be sure. I'll try that again tommorow and see what happens.

No worries. Even that is helpful. Just want to make sure it not a fault on my side before reporting it as a bug.

Yes, he did. But I would also expect that he would see the changes in the TSD?

Maybe a dumb question, but today I tried the first MP session with a friend. I manipulated the route and set a direct-to to a waypoint. While I was able to see the altered information as a CPG on the HMD (distance and ttg) as well as on the TSD, my pilot didn't see any of my route adjustments. Neither on his TSD nor on his HMD. Is this an MP bug, am I just dumb and missing something, or do really both crewmembers have to do the direct-to on their own? Any help appreciated! Thank you!

This did the trick! Thanks so much!

Noticed that behavior too. Have never seen these torque jumps in any FADEC controlled helicopters. Nevertheless, as @comcat stated, the torque in- and decreasing behavior seems about right when inputting pedals for example. It's just the 'jumps' that seem a bit off here.