dutchili

Before the April 17th update, we could change the FCR range by slewing the RDR cursor to the top or bottom of the MFD. The range would immediately change. Now, the cursor stops at the edge. To change the range with the cursor, you need to move the cursor back away from the edge and try again. Then the range changes. Seems related to the change log item: 'Fixed: RDR Cursor movement axis bug.' @BIGNEWYIs the current behavior as intended? I like the feature of not changing the range unintentionally while trying to lock a target at the current set range, but the behavior seems a bit incosistent now. Not posting a track, assuming you have test scenario for this basic FCR operation.

yeah, i do see spikes in those times when looking around or manouvering. It only becomes annoying when flying low over cities. All other situations are classified by me as 'not perfect, but not hindering gameplay'. I do notice that a perfectly smooth gameplay make a big difference in perception: smooth = :), stutters are I think (assumption) that the core of this issue is in how the rendering works / is linked to other computations / I/O. Especially in VR. Reported frame rates in 2D are much higher, yet you see the exact same issues

I have set 1.3 in the meta link app, not ODT. It is a lot indeed, but not so much for the GPU according to the DCS FPS meter. That always states 'CPU bound', unless it greatly reduce PD and other graphic settings. Then it is GPU limited, which then in nonsense. Even in heavy static embellished airports, the FPS is pretty steady at 72/73 Hz if not limited by ASW to 36, When i look around i immediately get some stutters in the scenery. Looking around again is usually better, but not perfect. I don't have that issue when i am all alone on the airfield. I notice similar stutters when taxiing and still looking forward. I appears to me that the 'rate of change' for the 'direction of view' is too high for the CPU to generate 36+ frames. When flying straight at low level and looking sideways, you see the same thing, unless all graphics settings are reduced to 'atari mode'

quest 3 via meta quest link i9-13900, rtx 4090, 32 gb. i have oculus resolution set at max (1.3x) and DCS PD set to 1.3 too. This, combined with oculus sharpening gives nice crisp images. All DCS settings are on high/ultra with only tree visibility set to 60% to prevent stutters. Nividia settings are default except for max performance and low-latency = ultra. The latest (yesterday) nvidia driver and oculus v76 greatly reduced ground stutters, especially with ASW locked at half-headset framerate. There have been DCS version with better performance, it highly depends on the workload on the main threat. Statics are degrading FPS significanlty (airplanes parked at the airport). The result change in the Viper with which threat is running the HUD made a good impact. The Viper instruments are stil a big impact on FPS generation.

i am not ED, but there is no such thing and render cores in the cpu, this is a choice by ED to use threats or cores specifically for rendering.

to my experience this is normal, and unwanted Lowering the resolution significantly greatly reduces the issue. headset is set at 72hz, even with ASW locked at 36 i can notice this (a bit)

Using Quest Link (USB) while flying/taxiing, you'll see the same thing, especially when turning your head past the 35-45 degree position (compared to straight ahead). The world passes by faster when doing that, the CPU cannot produces enough frames to make a fluent picture. (less pronounced in slow aircraft). As a result the GPU FPS also decreased (tightly coupled to CPU frames). The more scenery, the more pronounced.

This occurs even with a high-end PC, especially in VR. Sounds like a classic programming issue where the graphical representation is linked to the actual work (getting server data). If the latter is delayed, so is the UI en 'user input'. The gameplay has the same issue (so it seems) where FPS and 'mission complexity' are tightly coupled.

I was indeed I was pretty successful in limited the stutters with DCS, Windows and Nvidia settings, but i can't fix scenary stutters over populated areas. If you watch the recorded stream you can see that the houses etc on the edges of the screen are not fluidly moving backwards. The FPS indications in DCS are not 100% representing what we actually see. In general, in my case, the ground/scenery stutters are the result of the CPU not being able to produce enough frames. It occurs mostly when turning while taxiing, looking sideways more than 45 degrees or when flying low-level over cities. The more complex the weather, the more stutters. With my reference to settings, i primarily mean that the game is unable produces enough frames in all scenario's regardless the settings.

Check yesterday's livestream by Waggs on the Germany map. 2d and continuous scenery stutters. I advised him to remove all unofficial mods. No seriously, I don't think you can fix it with settings.

Does anybody know how to fix the following: - i can't add ground units contained in the VPC Aifield equipment mod. - but for mission already having units from that mod, they show fine. - in the attached picture i copy/pasted a unit into a new miz, and then it shows. But the other available units from that mod do not show in the dropdown list.null

The latest NVidia drivers seemed to have an impact, but about the time it was released we also had a DCS update. Before that, it was near perfect. Some threats are not tuned to the capacity of the CPU core they run on, resulting in all of us being "CPU limited", which is actually 'limited by insufficient load balancing'.

@BIGNEWYCan you address this topic to the correct team?

non moded units do not land either. The error is known in another map too, until it was fixed.

I rather not. Just make Bodo Blue, put a red unit in front of the airport, have it land (waypoint). It won't. Or place a civi (civilian aircraft mod) on the airfield (you'll get the error)

Civilian airplanes cannot be placed with waypoint 'Takeoff from ramp'. The error pop-up mesage reads "error set to airfield. No free airport." I tried this with A330, A320, while KC-135 and E-3A work perfectly. Additionally, AI traffic does not land on Bodo. Instead they divert to Andoya. This was tested with F-18, F-15 and F-16.

When the contrast on the mfd is changed and then the user selects a different sensor on that same mfd, the entire mfd goes black as a result of maximal contrast. When clicking the contrast button the issue immediately resolves itself.

No units positioned, just scrolling and zooming. All of a sudan de mouse pointer becomes laggy and than the entire system hangs. CTRL-ALT-DEL does not respond. Last entries of dcs.log: 2025-02-22 08:36:44.473 ERROR_ONCE DX11BACKEND (15472): texture 'splineAtlas.Splatmap5.1.roof.tif' not found. Asked from '' 2025-02-22 08:36:44.476 ERROR_ONCE DX11BACKEND (2828): texture 'pointAtlas.Splatmap5.1.roof.tif' not found. Asked from '' 2025-02-22 08:36:44.483 ERROR_ONCE DX11BACKEND (2828): texture 'default.mr' not found. Asked from '' 2025-02-22 08:37:39.770 INFO DXGUI_WIN_ADAPTER (Main): resize main window to [0, 0] 2025-02-22 08:38:11.955 INFO DXGUI_WIN_ADAPTER (Main): resize main window to [2560, 1440] 2025-02-22 08:38:16.441 INFO DXGUI_WIN_ADAPTER (Main): resize main window to [0, 0] 2025-02-22 08:38:29.308 INFO DXGUI_WIN_ADAPTER (Main): resize main window to [2560, 1440] dcs.log DxDiag.txt

Haha, I didn't know that.

Documentation on what all actions, tasks etc do.

Then I suggest you build your own test mission(s) to enable regression testing on actions, triggers and conditions. Perhaps write some documentation too.

Tanker have weird behavior too. After completing the left-hand racetrack, then weave to the right before starting the next lap.

let's not discuss windows or hardware settings. We 'all' noticed this since the last update. The root cause is in the (full and complete) change log. Something for ED to figure out.

I think this graphics card will not deliver better performance until the 'CPU overload' is fixed (by spreading the frame generation and other workload over more CPU cores /make it more efficient). In VR: the final FPS is mostly limited by the rendering process in the CPU, not the GPU.

Indeed. There was a good exchange of public documents behind the scenes on this topic. Yet I agree with the original poster that it ...well...sucks. But DCS is a simulation, not a game, so we have to live with what we know about the real world and hope that the real pilots received more useful software in later blocks/MLUs.