Rosly

The modes are not synchronized as well. FCR can go into bananas mode when switching between PLT and CPC back and forth. We are able to scan ground targets behind the bird while in AA mode.

Set EPU to off. This is deviation from standard ED startup which everyone are used to.

@BIGNEWY any plans?

Bump

Seems plane placement logic was changed in latest update DCS 2.9.9.2280 and now planes are placed literally over the hangars.

All missions broken. Campaigning is unplayable at this point.

Can we get mouse center keybind in UI or Common? It is really important for VR as we constantly trying to find this lost cursor to click in cockpit. Also as mouse cursor is following the view, with this function we can simply bind it to one of the joy to recenter pointer on view port, than simply look at given button and use right/left mouse binding to click on cockpit stuff without need to touch a mouse! Extended version would be "save mouse cursor position" and "restore mouse cursor position" in order to place it in position convinient for your VR headset instead of center default. Ideal would be to also add two axis commands (or direction keybinds as well) to move the mouse cursor with HOTAS mini joystick.

This is debug string for exception handler added by compiler on building. This is coming from ED, not my environment. I can attach longer logs but I made this report for ED devs. The stack trace is what they are looking for. The crash is 100% reproducible on entry to any mission with MSAA enabled on VR with Quad View rendering.

Yup seems we are talking the same thing, but this part I didn't known! Thanks!

Can you point out where to do it? If you are talking about "Image quality" presets in Varjo Base than this is not allowing you to change peripheral and focus separately. Those presents are not as good as what mbucchia is adjusting. Btw: This will disable request for XR_VARJO_foveated_rendering altogether. Unless tou have mbucchia installed it will make your setup Fixed Foveed Rendering. Mbucchia layer forces this setting if installed.

If you do 6) than ForceFoveatedRendering = 1 by 4) is not needed. Actually 6) is enabling XR_VARJO_foveated_rendering by DCS which was previously forced by mbucchia + to all above mbucchia mod uses smaller "high res view port" and lower resolution for "peripheral res view port" so installing it will still improve performance (less pixels to draw with no impact on visuals). It not needed due 6) but also gives me ~15 fps extra (as @motoadve mentioned in his post).

2024-10-16 18:51:47.701 INFO EDTERRAINGRAPHICS41 (10304): surface5 gc() LOD 0 0 squares 2024-10-16 18:51:47.701 INFO EDTERRAINGRAPHICS41 (10304): surface5 gc() LOD 1 0 squares 2024-10-16 18:51:47.701 INFO EDTERRAINGRAPHICS41 (10304): surface5 gc() LOD 2 24 squares 2024-10-16 18:51:47.701 INFO EDTERRAINGRAPHICS41 (10304): surface5 gc() LOD 3 6 squares 2024-10-16 18:51:47.701 INFO EDTERRAINGRAPHICS41 (10304): surface5 gc() 0.339100 ms 2024-10-16 18:51:47.728 ERROR GRAPHICSCORE (10304): Failed assert `source.getDesc().msaa == settings.msaa && dest.getDesc().sizeX == source.getDesc().sizeX && dest.getDesc().sizeY == source.getDesc().sizeY` at Projects\GraphicsCore\Source\GraphicsCore\RenderGraphStuff\ToneMapperModule.cpp:109 2024-10-16 18:51:47.794 WARNING LOG (4792): 1 duplicate message(s) skipped. 2024-10-16 18:51:47.794 ERROR GRAPHICSCORE (10304): Failed assert `depthBuffer.getDims() == dims && depthBuffer.getMSAA() == msaa` at D:\Projects\Buildworker\nevada_testing\build\Projects\render\renderer\Include\rwrappers\inl/FrameBuffer.inl:335 2024-10-16 18:51:47.794 ERROR DX11BACKEND (10304): depth buffer gbufferEdgeMask2 (1020x1020) must be the same size as color targets (1444x1236) 2024-10-16 18:51:47.794 ERROR DX11BACKEND (10304): Failed assert `false && "depth buffer must be the same size as color targets"` at Projects\render\dx11backend_win8\Source\DX11FrameBufferManager.cpp:101 2024-10-16 18:51:47.795 INFO EDCORE (10304): try to write dump information 2024-10-16 18:51:47.842 INFO EDCORE (10304): # -------------- 20241016-185148 -------------- 2024-10-16 18:51:47.842 INFO EDCORE (10304): DCS/2.9.8.1214 (x86_64; MT; Windows NT 10.0.19045) 2024-10-16 18:51:47.843 INFO EDCORE (10304): D:\Steam\steamapps\common\DCSWorld\bin\dx11backend.dll 2024-10-16 18:51:47.843 INFO EDCORE (10304): # C0000005 ACCESS_VIOLATION at 00007ff90e27af67 00:00000000 2024-10-16 18:51:47.844 INFO EDCORE (10304): SymInit: Symbol-SearchPath: 'D:\Steam\steamapps\common\DCSWorld\bin;', symOptions: 532, UserName: 'rad' 2024-10-16 18:51:47.844 INFO EDCORE (10304): OS-Version: 10.0.19045 () 0x100-0x1 2024-10-16 18:51:47.845 INFO EDCORE (10304): 0x000000000001af67 (dx11backend): RenderAPI::DX11Renderer::setNewFrameBuffer + 0x37 2024-10-16 18:51:47.846 INFO EDCORE (10304): 0x0000000000019a68 (dx11backend): RenderAPI::DX11Renderer::pushFrameBuffer + 0x68 2024-10-16 18:51:47.846 INFO EDCORE (10304): 0x000000000000bc04 (GraphicsCore): enlight::AtmosphereWrapper::precompute + 0x3C4 2024-10-16 18:51:47.846 INFO EDCORE (10304): 0x0000000000037773 (GraphicsCore): deferredShading::SSS::~SSS + 0xCA3 2024-10-16 18:51:47.846 INFO EDCORE (10304): 0x0000000000094ad8 (GraphicsCore): render::MotionBlurModule::~MotionBlurModule + 0x4B8 2024-10-16 18:51:47.846 INFO EDCORE (10304): 0x0000000000058877 (GraphicsCore): render::BaseRenderingPass::execute + 0x27 2024-10-16 18:51:47.846 INFO EDCORE (10304): 0x0000000000058fbf (GraphicsCore): render::BaseRenderingPass::execute + 0x76F 2024-10-16 18:51:47.846 INFO EDCORE (10304): 0x000000000005deb7 (GraphicsCore): render::RenderGraph::render + 0x317 2024-10-16 18:51:47.846 INFO EDCORE (10304): 0x0000000000028052 (SceneRenderer): DCSSceneRenderer::renderBakedRenderGraph + 0x42 2024-10-16 18:51:47.846 INFO EDCORE (10304): 0x0000000000169c6b (Visualizer): smSceneManager::regLua + 0x139B 2024-10-16 18:51:47.847 INFO EDCORE (10304): 0x0000000000153a34 (Visualizer): smCamera_Implement::getClipRegion + 0x1BE24 2024-10-16 18:51:47.847 INFO EDCORE (10304): 0x000000000013dc8c (Visualizer): smCamera_Implement::getClipRegion + 0x607C 2024-10-16 18:51:47.847 INFO EDCORE (10304): 0x00000000001581d2 (Visualizer): smSceneManager::DestroySceneManager + 0x1202 2024-10-16 18:51:47.847 INFO EDCORE (10304): 0x0000000000032451 (edCore): ed::thread::_get_current_thread_id + 0x71 2024-10-16 18:51:47.847 INFO EDCORE (10304): 0x0000000000021bb2 (ucrtbase): _configthreadlocale + 0x92 2024-10-16 18:51:47.847 INFO EDCORE (10304): 0x0000000000017374 (KERNEL32): BaseThreadInitThunk + 0x14

If you do not need QV you do not need to enable those options.

Heh. Hope knowledge about this will reach more folks! Somebody in Varjo should get to work.

Woooahh I was thinking this is only my problem! So here you have it. You see the same thing as I. varjo 4.x is the issue! I'm using 3.x line in order to mitigate this crazy tree draw distance issue (I cannot stand it) as well as the performance problem. Basically using 4.x I have 75fps on Viper free flight missions low level when on the same NVidia driver, same everything but Varjo 3.x I have solid 90. Both with VQ of course, set in Varjo base and DCS. Thought eye tracking option on 3.x with mbucchia script cause the center spot to be wrongly rendered. With eye tracking option dossabled while QV option enabled I have best performance and no issue. This os expected as eye tracking part the mbuchia script is actually forcing and probably messing around. Try 3.x Varjo base + mbuchia and + only the QV option in DCS enabled and tell me if you confirm tree draw distance problem and performance problem go away!

Not true. Those settings is part of the procedure where app is checking QV availability and request it's use. Previously it was hard coded into DCS. Now it is conditional. Follow the thread: If you not check these on Varjo, DCS will not use QV. Issues mentioned in topic will not appear because simply QV will not kick in.

Yes because QV has API where system is offering this capability and game confirm that it will use it.

Same here on Varjo 3.10.3.25 + mbucchia QV mod @AhSoul Which HS and SW/FW version you use?

After switching to DCS 2.9.8.1107 with build in QV and Eye tracking and with Varjo 4.3.1.29 I notice that trees draw distance is dependent on where I'm looking. It seems to be function of horizontal angle between my sight and center of the view port. When I shift my eye left or right the draw distance of trees decreases, causing them disappear below the ground. When I look straight into HS view port, the draw distance increase. Video:

Seems the F-16 campaign is designed exactly the same as A-10 campaign in terms of radio coms. It uses radio playback function (which is what we want for realistic stimulation) but again with wrong object's as source (guessing again the same trick with single static object is used). I complained about use of this method in A-10 campaign of Baltic Dragon. I really like the campaign. I actually love it, but here we are again! I cannot understand a thing on some of the radio calls! Example is right on the spot on mission 2 (first one) where we flight in formation, 1 mile trail and all leader calls are bearly understandable (over heavy statics) like he would be 200nm from us. Point is DCS calculate signal/noise ratio for radio coms API and if object is faaaar away from us, we hear exactly how it should sound, mean lots of static. This makes me think all coms are made with single stationary object as coms source placed somewhere in the middle of the theatre, exactly the same as A-10 campaign was designed. A properly designed mission would use actual mission object as radio com API source call, but this is more labour intensive.

Uninstall or disable the TacView and LotATC. Both mods enumerate game objects every frame which os killer on move populated missions. If you have other mods similar in nature (like FF telemetry collected by onframe callbacks) disable those as well or ask authors to fix their stuff (pun intended Winwing).

Same here. DL not working in mission 2.

Some trees on Afghanistan map uses leaves vertexes which rotates while moving head in VR. Tried to record video of this issue though this is not well noticeable in 2D. But in 3D is really weird, like whole branch is rotating. You can see this effect in following video when looking at the branch root which is in in relative motion to leaves (pay attention to where root is crossing leave). Only some tree models are affected by this.

BSOD is not fault of DCS. BSOD is a mark your operating system catched problem with the HW. What DCS might have done is the specific code patterns can trigger problems with your HW stability, but you should fix the HW not blaming the game. The operating system and CPU features has ability to catch problems with the applications so if that would be an issue, the app would simply crash and close (there are threads about this in particular). But never whole operating system. For instance intensive use of floating point unit or SSE can make hot spots on CPU if your cooler is mounted improperly. Specific memory access patterns can trigger errors on overclocked DDRs. Shader code can push the tolerance of stability you played around with GPU clocks. Power supply is in most cases also a part of the problem as stability greatly relying on stable voltages. All of above can simply happen if you have thermal issues due dust and fans clogged.

Not directly related to technical side of the topic, but as electronic engineer I'm glad that Heatblur with their detailed analysis of Radar and RWR systems (maybe unintentionally) opened some eyes of DCS players about how unreliable the abilities of early RWR was. The current implementation of RWR in Mig-21, 19 and even 29 don't even bother about frequency band, PRF range, signal power and ability to track dozen of missile guidance techniques. Those simply take game object position (missile or plane) and give you "missile launch" I hope this will start a healthy discussion and hopefully some rework of existing RWRs as currently they are silly and OP in regards to F-4. Imagine fighting with Mig-21 on MP which is able to give clear launch indication for all missile types, including those which was not even existing in times of design of it's RWR. Those mig-line RWRs are analog and require set of antenas, amplifier, filter and discriminator circuits to detect each and every search, tracking and guidance radar systems. Instead those uber-RWRs see and understand everything in the game, even they are just half of dozen cathode ray tubes with 4 light bulbs wired together xD Ps: Heatblur, you are true hero's in my eyes by rising the simulator quality bar to new level's. Your job is amazing for all those EE folks which beg ED for so long to stop threatening electric warfare in DCS as silly topic.