Tepnox

I found a workaround that worked for me - this is 100 % reproduceable on my end and I have no idea why. If I start DCS (no matter if Fullscreen is activated or not in the DCS graphics menu) and I try to "Fly again" after a mission (or want to fly another second mission) - it crashes immediately. BUT: If I start DCS and I am in the main menu and use ALT+TAB just to switch into another application and go back to DCS - no more crashes on second mission load or "Fly again". I tested this 5 times and this is totally reproduceable - I am totally confused, why this is working but it does (at least for me). I am currently using the newest NVIDIA driver 466.11 - no idea if this is a driver issue or strictly DCS related...

Not working for me. My DCS launches in Borderless Window mode - it makes no difference using forced fullscreen-mode (ALT+ENTER) or using borderless window mode, it still crashes.

I fixed the re-arm problem by using the cleanup command and afterward using the full slow repair option. When I now use the re-arm option, it takes a few seconds until the loadout screen loads - but it finally works. Before that, there was no delay when using the re-arm option and the loadout-screen loaded instantly. Maybe something didn't hook up right with the menu interface?

Still having the same issue crashing to desktop with second mission load and also when using the button "Fly again" after a mission. OB 2.7.0.5118.

There is your track. Having the rearm problem since 2.7. It does not matter, if I start the mission directly or start from the mission editor. Switching the aircraft (slot) in the mission does not help on my end. BUG_Rearm_not_working.trk

Having same issue - how could that happen? Any chance for a hotfix?

Agreed. The workflow with fiddling around is not perfect yet - but definitely overall very good usability. Tried LGBs, GBU-38 and MAV. Worked flawless so far.

Yea :) They changed the logic on current Open Beta 2.5.6.50321 and undesignate works different there. I am on OpenBeta ;)

True, but only for one targeting plan (T001). The logic in stepping acts very strange when trying to step to another weapon station on another targeting plan (T002, T003 etc.). Sometimes it steps correctly to next station, sometimes it steps backwards to targeting plan (T001) and then automatically overwrites the GPS-data of that station. I suppose, by pressing STEP, the current GPS-data gets automatically injected on the current station. This is a problem, with more than 2 JDAMS. So in the current logic and using more than 2 JDAMS, it is necessary to undesignate after designating the target. Which is the next problem: the FLIR resets to snowplow-mode and you have to acquire the target fully again. Not ideal.

Would be interesting to know if the recent open beta build is correct in terms of usability in real life. I highly doubt it. If I would design the logic as a pilot, it would make sense to: 1: point FLIR over the target then depress to store the coords on the selected jdam 2: switch to next jdam (coords should be empty by default) and just point FLIR over the next target and depress to store the coords into the selected jdam 3: repeat for other jdams Simply as that, would it make sense?

Go to: DCS World (Main Folder) / Mods / aircraft / FA-18C / Cockpit / Scripts / TEWS / device / CMDS_ALE47.lua Edit the file with Notepad++ or other than Windows Notepad. You find the Pograms MAN1 to MAN5. MAN6 is the wall dispense button function. I use the MAN6 for the wall dispense button for 2x flare and MAN1-MAN5 for different chaff-programs (1 to 5 cycles).

Situation: Hornet with 1x MAV E and 1x MAV F loaded for ground strike, starting mid air. Both missiles were fully aligned at the beginning (see track files). When firing the MAV F first, the MAV E gets an additional align-time and after finishing alignment, the missile won't lock the laser any more (the laser marking is still recognized). Code 1688 was set. [Track: MAV_E-not_working.trk] When firing the MAV E first, the MAV F gets an additional 3m align-time but works afterwards. [Track: MAV_E-working.trk) Having 2x MAV E and shooting after each other works as intended with no alignment between. [Track: MAV_E-2x-working.trk] Map: Nevada: Singleplayer - OpenBeta 2.5.6.49798 / no mods Please have a look ED. Also: the re-alignment of MAV F after shooting the last MAV E is working as intended? They both were aligned before... MAV_E-not_working.trk MAV_E-working.trk MAV_E-2x-working.trk

True true. Kind of a mess with the TGP and other bugs. Unbelievable it went into Stable...

In another thread it was posted by astazou:

Can confirm, shadows (low/med/high) have about 30-40% gpu-load impact on my GPU (RTX2070 Super) on the SC when viewing the island. Needs fixing.

Having same difficulties getting EGIW almost every time. No matter what I do - i also tested not touching the throttle at all before hitting the deck. Very frustrating when trying to improve and not finding the error.

True. The Shadow Option alone from Flat-Only to Low/Med/High difference is about 30-40% load on my GPU (RTX2070Super). So if you have no buffer (maxed out GPU load), your FPS will drop in that margin of 30-40%. Pretty hefty and needs adressing for sue.

Appreciate it, thanks!

+1

Having the same problem with the FA-18 especially since launch of that module - other modules have the same weird behavior but not that heavy (degrading fps). I figured out, if you make a little break (5-10 minutes) and still stay in game, it gets back to normal fps. I gave ED a track of my finding - they couldn't reproduce. I tried this two different pc setups, still the same fps-degration. To extreme, you just need to roll the runway along (around 100 knots) and abort the start at the end of the runway, then do a 180 turn and repeat this. And finally after 4-5 runs over the runway, you are down to 20-30 fps (when for me normal is 80-90fps). The gpu-load gets lesser and lesser with each run. Seems to be an engine-problem. The only workaround for me is, not to land the FA-18 on a runway since there is no fps-degradation when landing on a carrier (tried this with over 20 landings, still good after that amount).

Getting this error on start after updating to OpenBeta 2.5.6.43503 (non-steam version): Repair does not help at all...:(

Looks pretty nice and clearly readable in VR (Rift S). I was having the fear, the MFD's would be hard to read (because of the tiny size) but it's working really well with the color-contrast. Loving the fly-by-wire flight model so far and of course the stunning landscape view with the superior bubble-canopy.

There you go. I recorded this on OpenBeta 2.5.4.30386. The LUA-CPU-Value is at 40% at the end of the track and my FPS drop is about 50 %. The CPU-load is identical, the GPU-load dropped from 99% to 50%. See my system specs in my signature. I tested this track also on a Ryzen 2600X system (3000Mhz DDR4 and the same GTX1070Ti graphics card), the LUA-CPU-Value did not climb on that system - however, the FPS were dropping the same way. FPS-Bug.trk

Try Reshade (search Google) to inject SMAA and a sharpening filter like LumaSharpen. Works great for me, and you do not lose that much of fps compared to the ingame MSAA solution.

Hi there. Because analysing the DCS performance becomes my second hobby (struggling with weird fps behaviours on my system too), I watched your video to check this case. Would be cool if you could include the frametime graph in the msi afterburner overlay next time (it makes it much more clear, when dips are occuring and how strong they are - also you see the general frame delivery much better). In your case, it is weird that the fps are dropping but the GPU-load stays around 95 to 99%. Normally, if you would be cpu or ram bottlenecked the GPU-load would shrink (because the gpu wants to deliver the frames but is waiting for the CPU/RAM - so the fps are sinking and so does the gpu-load). I could only assume, it is potentially a GPU bottleneck depending on the workload of the scenery in correlation with the shadow settings. Did you try your test run without shadows and low visibility? In my experience, the game-engine behaves very strange with enabled shadows and also the visib range can have a huge impact on the system (even you dont see that much of a difference, the effective object rendering in this game is pretty lazy and from the old times). I know it may be not that pretty (without shadows) but as I see it, I prefer smoother consistent delivered frames. The no-go for my system are shadows (all shadows). When enabling shadows, the consistency of frame delivery is gone and goes crazy all over the place...