Lange_666

This bugs me since they changed the Full Screen behaviour a few patches ago. How on earth does one see the difference between real full screen and borderless (if real full screen even exist since then)?

Yup, straight impossible if you ask me which gives me the creepy feeling the loss in performance will stay. I even wonder who at ED's still runs anything older then 2.7.7 since that's the latest "stable" version already with the performance loss in it (compared to 2.7.6). I'll keep my stable at 2.7.6, won't upgrade to anything higher just to keep a reference.

This script is not for assigning keystrokes to various buttons but for assigning DX outputs to every button/switch/trigger combined with longpress and layer actions. If you want to generate keystrokes, the standard scripting (like in the TARGET manual) is what you are looking for. If you want more then 32 DX outputs available on a combined device (when a script runs it combines throttle and stick into one single device) you need to look for the standard 120DX file which replaces the default target.tmh file and start from there (the tmh files are not for editing in general, you should create/write a script with a tmc extention, not tmh, at least for starters). Also, since you are trying to generate keyboard outputs I might be wrong but I don't think you understand what DX outputs are. targetdx120.tmh

Quick Q: 240 or 360 AIO, what are these numbers referring to?

My data (shots and requested files) is in the original thread, i see no need to repeat it again in another individual thread.

OTT user here. ODT comes with chinese (read not understandable) settings like: - Pixels per display pixel override... - Force Mipmap Generation on all layers... - Offset Mipmap Bias on all layers... - Pose Injection... - etc....

Same problem here. And it's also happening in MSFS. Getting the • (an arrow in MSFS) to move over the overlay to press a button or something can be trial and error. For the comms menu, moving the • off screen to the right at the menu location and then back helps.

Never been an issue here with any of my controllers (currently a TM Warthog). The only device that turns windows back on after putting it to sleep or even turning it back on is my Garmin Edge 810 cycling computer when hooked up on USB.

I delivered the requested files and posted some comparison screenshots so that should be enough from my side. I didn't notice a problem at first since i cap my FPS and on 2.7.7 it didn't go below that capped value so there was nothing negative to see. After uncapping the FPS, the difference is what i posted. I'll keep stable at 2.7.6.13436 as a reference because once updated, there is nothing to compare anymore.

According to Spooky over at the BuddySpike Discord the difference comes from a cold start at an airport and a hot start on a road base. From Spooky: Because they start hot started which includes the procedure of adding 5 degrees of nose up trim. You have to trim it back down after gear and flaps up. So that's sorted.

Report: Flew with various aircraft (F-16C etc....) + the UH-1H (i don't have the Hind): Take-off from Boulder City and overflew the coördinates given, no crash, not in any module. Ran the track provided by Avernus in the first post, DCS installed Mi-24P module before running because that was missing to run the track. Track runs fine, tried a few times, track plays through to the end and asks then to "refly", no crash at all.

Left-CTRL + Pause works fine here.

Same here, no improvement at all.

Pointing out to an introduced problem (which you also encountered) is not really dogpiling. You just changed settings "outside" DCS to get it back to an enjoyable level. I don't call that a solution, just some sort of workaround to get you playing again (which is OK for the time being, just don't let loose of the rope, because you'll loose in the end if you do).

Did you do the same with 2.7.6 to see if you wouldn't gain any extra also there? I already had the feeling Marianas got some optimalisation because i used this map as first test after upgrading to 2.7.7.14727 and it ran smoother then on the previous build. So i then thought... nice upgrade, even more so because i ran it with a capped FPS. I removed the FPS cap after reading this topic only to notice that the other maps took quite a dive, compared to 2.7.6.

If FPS is gained from a fresh install then there must be a way to define the problem of losing that FPS when we upgraded from 2.7.6 to 2.7.7. I'm septical about this solution for now.

You talk about what versions now? What is before and after?

I would like to see the same track played on stable 2.7.6 on your system so we have a comparison (and please prove it's 2.7.6 so it's not the last version which shows the same problem). You ask for comparisons and the lot from our side but your own data lacks the things you ask from us. PS: I for one can't believe that none of the ED systems and none of the internal testers ever showed this problem and then moments after release the first post of degradation shows up. Why do i have the feeling that we have to suck up the loss?

Just watched this, very good effort but it seems your framerates are capped, they jump from 60 to 30 and back. The difference between stable 2.7.6 and OB 2.7.7 is exactly 30 FPS which proves my point. Best is to let the FPS loose (no VSync, no FPS limiter) if you make a comparison and use MSI Afterburner or another overlay where you can easily change color and fontsize instead of the onboard FPS counter (which is enough but is very small and therefore difficult to read). I would make one myself but i don't have the knowledge to make one and lack the time to do so.

12900K = 649€ pre-order in local shop here. With mediocre MB's going at least +400€ (the ASUS ROG MAXIMUS Z690 Extreme Glacial goes for 1999€) it ain't for my wallet. How do they call that... cutting off the branch you sit on?

Did the same test after the above (backup and then remove the saved games folder and let DCS OB create a new one (and without SRS in the script). Did put in the same settings as in the old one. Result is as good as the same, same loss compared to the 2.7.6. stable version which still has SRS in it's script folder. So that is a dead end.

But for a test like this it doesn't matter what mission/map/airplane is used. I'm seeing the same thing with other aircraft/maps/missions only with (obvious) different FPS values.

Result is the same, just more CPU usage on the cores used and less on the not used cores. Feels overall a bit less smooth, maybe because the cores now run close to max usage (on some moments they went op to 98-99%). OB 2.7.7: All cores (Hyperthreading OFF) 2 cores (0 and 2 in the shot below = CPU 1 and 3 but test with cores 1 and 3 (CPU 2 and 4) was the same), Hyperthreading OFF Result with Stable 2.7.6. was also the same, all or only 2 cores same result, but better FPS compared to OB (see post a bit up):

Just ran a CPU core test, it jumps between each of them, stable and open beta. I still run Win 10 (no joy in upgrading to Win 11 with my system, i don't pass the tests). Mission: Instant action: F-16C: Free Flight: Caucasus, exact same settings in both. (VSync + FPS limiter off which i normally have on and set to 60 to let the FPS "fly" un-restrictedly). Waited until the mission text in the upper right corner vanished. Then took 3 shots within the minute, +/- around the same time in the mission, same terrain same clouds. Stable 2.7.6.: Open Beta 2.7.7.