m335

https://github.com/mirage335/extendedInterface/tree/master/app/DCS/vrshader Some batch files to quickly manage shader cache files. Besides simply deleting the cache, these can also disable, backup, and restore, the cached shaders.

Google Earth works so far with com0com - http://com0com.sourceforge.net/ . sPort_Nr = 1 COM1 +use Ports class -emulate baud rate +enable buffer overrun COM1 +use Ports class -emulate baud rate +enable buffer overrun

As a supplier, I also greatly prefer AMD products. If Vulkan moves object processing to multi-core so AMD can comfortably work with the 476th's NTTR map, that would eliminate the last reason I have to consider an Intel build. In the meantime though, with AMD lagging so much in benchmarks potentially relevant to DCS, Intel remains a more solid choice.

Passmark scores for single threaded performance of Ryzen 3 CPUs were reportedly slightly higher than the competing Intel i9-9900k as of a few days ago. From recent benchmarks, this seems to be somewhat misleading. In particular, the anandtech benchmark shows much lower performance. Speaking for myself, I don't feel underwhelmed. AMD still managed to turn out a generally quite useful processor. For DCS World, however, it looks like Intel is the way to go. At least if your missions include very large numbers of objects.

https://www.anandtech.com/show/14605/the-and-ryzen-3700x-3900x-review-raising-the-bar/12 Interesting data here. AMD's latest processors are supposed to have higher single-threaded passmark scores. Benchmarks show Intel still has a large single-threaded lead in some cases.

Yes, at least one other CPU is comparable as per single-thread and multi-thread passmark scores. Mod objects are reasonably compatible, since other users continue to use them. Notably GPU performance does seem to have improved slightly. CPU frame latencies, as measured by "fpsvr", are the problem. In case anyone is wondering, I have ensured multiple times TacView is not recording, Scripts/Export.lua have been disabled, etc. Before the recent update, this worked, with this hardware. That is why I am posting this as a probable regression.

Beta has been found to perform worse with large object counts. NTTR mission which previously rendered acceptable CPU frame times of <32ms, now renders >55ms (ie. <<32Hz required). Further reducing the total number of objects brings the frame times back <32ms. However, Intel users, with comparable single-threaded performance, are not reporting similar problems, all other hardware/headsets being same or worse. https://forums.eagle.ru/showthread.php?t=154593 Pimax 5k+ Pitool v1.0.1.144 NVIDIA Drivers 430.86 AMD Ryzen 2700X NVIDIA RTX 2080Ti

Responded there. Retested again PiTool beta does NOT work. Also, SteamVR overlays can interfere, and need to be run at low resolution.

PiTool "Smart Smoothing" does work, although still with more artifacts than Oculus ASW. There are four big GOTCHAS. 1) Beta version of PiTool is BROKEN. Use stable version “v1.0.0.109”. 2) Be careful about overlays and their resolution. Set super-resolution as an Applicaton Override, NOT SteamVR video resolution. OVRDrop in particular, if sampling application windows instead of a desktop, catastrophically adds >10ms to frametimes. 3) DCS window must have foucs. Maybe Windows must also be configured to prioritize "Programs" instead of "Background Services". 4) DCS is *extremely* CPU single-thread heavy, not so much GPU heavy. Upside - use cheaper GPU or turn super-resolution WAY up. Downside - the best CPUs available can fail to deliver 32Hz in 'heavy' situations. Not much you can do about it. The "fpsvr" tool can go a long way towards diagnosing these kind of problems with DCS. Below 31ms CPU/GPU frametimes, good. Above, bad. Below 32Hz framerate, unusable. Pimax and DCS World is a very high-end simulation deal, far above an arcade game running on a GearVR. Don't expect this to work 'out-of-the-box' or on cheap hardware. Do expect to become a mechanic for your virtual jet. :) Also, not complaining, but please do encourage Eagle Dynamics as DCS developers to please fix the single-threading bug soon. Some of the worst DCS VR issues are clearly CPU bound, that hardware is not really getting better, and we could get 5x better performance.

PASS Working configuration found (not subject to bug #1). Performance - PASS. Double vision stutters only at DCS graphical quality settings sufficient to miss at least two frames. Frame Latency - Summary shows 16ms/13.9 In Flight. Detailed view shows some frame latencies >20ms. CPU, Overclock - Ryzen 2700X, Auto Multiplier, 100.6BCLK GPU, Overclock - NVIDIA RTX 2080 Ti, 1750 MHz RAM, Effective Frequency - DDR4-3100 Motherboard - ASUS ROG Crosshair VII Hero SteamVR Version - 1.3.23 Pitool Version - PiToolSetup_1.0.1.109_R193 NVIDIA Driver Version - 430.39 (PiTool Settings) "Hidden Area Mask" - OFF "Render Quality" - 1.25 "Turn on Smart Smoothing" - ON "Turn on "Fixed Foveated Rendering" - NOT AVAILABLE "Compatible with parallel projections" - ON "Field Of View" - Normal "Refresh Rate" - 72Hz (SteamVR Settings) General > "Use SteamVR Home" - OFF Applications > DCS.exe > Custom Resolution (only visible while running DCS) - 100% Video > Custom Resolution - 80% (NVIDIA Settings) "Ambient Occlusion" - Off "Anistropic filtering" - Off "Antialiasing - FXAA" - Off "Antialiasing - Gamma correction" - Off "Antialiasing - Mode" - Off "Antialiasing - Setting" - None (Greyed Out) "Antialiasing - Transparency" - Off (Greyed Out) "CUDA - GPUs" - All "DSR - Factors" - Off "DSR - Smoothness" - Off "Maximum pre-rendered frames" - 2 (No improvement seen at 3+) "Multi-Frame Sampled AA (MFAA)" - Off "OpenGL rendering GPU" - Auto-select "Power management mode" - Perfer maximum performance "Shader Cache" - On "Texture filtering - Anistropic sample optimization" On "Texture filtering - Negative LOD bias" - Allow "Texture filtering - Quality" - High Performance "Texture filtering - Trilinear optimization" - On "Threaded optimization"- Auto "Triple buffering"- On "Vertical sync" - Use the 3D application setting "Virtual Reality pre-rendered frames" - 2 (No improvement seen at 3+)

Please post details of your setup if you have managed to get this working. Just having a hardware whitelist will narrow down possible causes when deploying the Pimax 5k+ with new hardware/software versions. Particularly if chipset/motherboard/USB issues are in question. Preponderance of evidence continues to point to a regression. Downgrading software and firmware to non-beta versions, possibly downgrading firmware to .91 PiTool version, seems to resolve the problem. https://forum.pimaxvr.com/t/dcs-pimax-5k-judder-fest/18921/20 https://forum.pimaxvr.com/t/double-vision-stutters-only-with-pimax-headset-oculus-vive-ok-dcs-world-beta-2-5/19283/2

TLDR Current reported issues for DCS World 2.5 Beta. * DO NOT INSTALL, PiTool Beta, SteamVR Beta. DOWNGRADE, or DO NOT USE, PiTool Beta Firmware. - If you are using a Pimax 5k+, 8k, or similar, with DCS World 2.5 Beta, please unambiguously state the hardware and software versions used. Some users, including myself, are observing four separate issues with DCS World Beta 2.5 in the Pimax 5k+ or similar headset. 1. At minimal graphics resolution/quality. Frametimes generally below 72Hz (excellent). All nearby objects or overlay, including jet aircraft cockpit, SteamVR dashboard. Two frames rendered as a single frame. 2. At high graphics resolution/quality. Frametimes generally above 72Hz/2 (bad). All objects in frame. Two frames rendered as a single frame. 3. At marginal graphics resolution/quality. Most frametimes below 72Hz/2 (marginal). Only objects outside aircraft (ie. trees but not cockpit). Two frames rendered as a single frame (two trees seen ghosted side by side during sharp aileron roll). Visually, all of these issues would make a single tree, appear to be two trees, when looking out the canopy, at the 2'oclock or 10'oclock position, while sharply aileron rolling a jet aircraft. Issue 1 is a bug and should never occur. Please report if you do or do not have this issue. Issues 2 and 3 are understandable. When any frame takes more than two frames at 72Hz, motion smoothing apparently does not keep up, and synchronization is lost. Sometimes this can be reset by temporarily reducing CPU load - such as pausing DCS in single player by pressing "Esc". For Oculus Rift, this kind of desynchronization was rare, usually reset by toggling ASW. For SteamVR/Vive, this did not happen with NVIDIA hardware or a solid 90FPS framerate (AMD GPU poorly supports motion smoothing). Pimax has proven more tricky. Specific versions of PiTool and SteamVR are apparently known to have regressions from time to time. Listing hardware and software versions either working or displaying severe regressions with DCS World Beta 2.5 may help establish some patterns to assist in future diagnosis. Performance - PASS/FAIL, issues. Frame Latency CPU, Overclock GPU, Overclock RAM, Effective Frequency Motherboard SteamVR Version Pitool Version NVIDIA Driver Version (PiTool Settings) "Hidden Area Mask" "Render Quality" "Turn on Smart Smoothing" "Turn on "Fixed Foveated Rendering" "Compatible with parallel projections" "Field Of View" "Refresh Rate" (SteamVR Settings) General > "Use SteamVR Home" Applications > DCS.exe > Custom Resolution (only visible while running DCS) Video > Custom Resolution (NVIDIA Settings) "Ambient Occlusion" "Anistropic filtering" "Antialiasing - FXAA" "Antialiasing - Gamma correction" "Antialiasing - Mode" "Antialiasing - Setting" "Antialiasing - Transparency" "CUDA - GPUs" "DSR - Factors" "DSR - Smoothness" "Maximum pre-rendered frames" "Multi-Frame Sampled AA (MFAA)" "OpenGL rendering GPU" "Power management mode" "Shader Cache" "Texture filtering - Anistropic sample optimization" "Texture filtering - Negative LOD bias" "Texture filtering - Quality" "Texture filtering - Trilinear optimization" "Threaded optimization" "Triple buffering" "Vertical sync" "Virtual Reality pre-rendered frames" Example. Performance - FAIL. Severe double vision stutters . Frame Latency - 16ms/13.9 In Flight CPU, Overclock - Ryzen 2700X, tested both Stock, 40Mult 103BCLK GPU, Overclock - NVIDIA RTX 2080 Ti, 1750 MHz - RAM, Effective Frequency - DDR4-3100 Motherboard - ASUS ROG Crosshair VII Hero SteamVR Version - 1.3.23 Pitool Version - Have tried PiToolSetup_1.0.1.109_R193, PiToolSetup_121_R211_beta. Cannot use PiToolSetup_1.0.1.91 - apparently due to firmware upgrade. NVIDIA Driver Version - Tested 419.17, 418.91, 430.39, and others. (PiTool Settings) "Hidden Area Mask" - Better off. "Render Quality" - Tested 1.0 and 1.25 . "Turn on Smart Smoothing" - No difference observed. "Turn on "Fixed Foveated Rendering" - No difference observed. "Compatible with parallel projections" - May have affected some tests. "Field Of View" - Tested Normal, Large. "Refresh Rate" - Tested 72Hz, 90Hz. (SteamVR Settings) General > "Use SteamVR Home" - Tested both. Applications > DCS.exe > Custom Resolution (only visible while running DCS) - 100% Video > Custom Resolution - Tested from 60% to 100% . (NVIDIA Settings) "Ambient Occlusion" - Off "Anistropic filtering" - Off "Antialiasing - FXAA" - Off "Antialiasing - Gamma correction" - Tested on and off. "Antialiasing - Mode" - Off "Antialiasing - Setting" - None (Greyed Out) "Antialiasing - Transparency" - Off (Greyed Out) "CUDA - GPUs" - All "DSR - Factors" - Off "DSR - Smoothness" - Off "Maximum pre-rendered frames" - Tested 1 and 3 . "Multi-Frame Sampled AA (MFAA)" - Off "OpenGL rendering GPU" - Auto-select "Power management mode" - Perfer maximum performance "Shader Cache" - On "Texture filtering - Anistropic sample optimization" On "Texture filtering - Negative LOD bias" - Allow "Texture filtering - Quality" - High Performance "Texture filtering - Trilinear optimization" - On "Threaded optimization"- Auto "Triple buffering"- On "Vertical sync" - Use the 3D application setting "Virtual Reality pre-rendered frames" - 3

To align DCS, I push the 'recenter' button until the OVRDrop virtual desktop monitor overlays match certain things in the cockpit. This fails every time the headset is set aside, a mission edited/launched/exited, or DCS itself is restarted. There is no reason DCS needs to 'recenter' anything. SteamVR/OpenVR has exact coordinates for my seated position in the room. OVRDrop and SteamVR Home objects are set to exact coordinates, which do not change. All these coordinates have remained the same for months, relative to my chair and HOTAS, which are mounted to wood/rails. If there is any LUA, configuration setting, or similar, to just stop DCS from doing a 'recenter' on its own, and stick with the 'seated' position given by SteamVR/OpenVR, that would be extremely helpful. Specifically, I want DCS to stick with these absolute coordinates as 0,0,0,0 . From the "chaperone_info.vrchap" file. "standing" : { "translation" : [ 1, 2, 3 ], "yaw" : 4 }, More generally, I am also trying to get SteamVR itself to provide a feature for quickly setting applications back to an absolute center position. https://steamcommunity.com/app/250820/discussions/0/1768134097427787881/ EDIT: Well, this happens. After nearly a day of research, finally stumbled across OpenVR Input Emulator. Seems like I can probably create a virtual controller. Still, it would be nice to have DCS World stop tinkering with headset alignment unnecessarily.

Hope no one objects to my cutting up Chuck's fabulous guides this way. I do attribute the source of Chuck's Guides in the repository. Because DCS does not save/persist kneeboard shortcut marks (as in IRL), it can be difficult to navigate large sets of kneeboard pages groups. This is a UNIX/bash script (technically cygwin also if dependencies are satisfied adequately) to add blank pages, splitting 'chapters' into units of 10 pages. From there, it is easy to issue "kneeboard 10 forward", "kneebard mark", "kneeboard jump 1", and similar voice commands to skip around. Similarly, simple one-page svg/png custom checklist templates are included. Reaching built-in DCS kneeboard pages can be done by going backwards from the first page of a custom kneeboard. https://github.com/mirage335/kneeboardIndexer Kneeboard Builder should be used to assemble these groups into a complete, installed kneeboard, as well as to configure kneeboard viewer size. http://www.dcskneeboardbuilder.com/ Binary image exports are provided. Currently F-5E and FA-18C guides have been spliced, as these aircraft have clickable cockpits and good feature sets. More aircraft may be added as I fly them. https://github.com/mirage335/kneeboardIndexer/tree/master/_export Because these are landscape 1080p images, a kneeboard size of 960x540 is recommended for VR users.

*sigh* Ok, yes, I have learned to fly an F-5E, 'without the manual' now, so I know what I am doing, and not just whining about wanting to follow bad habits. That doesn't change the fact that learning by doing can make it much easier to understand the details of why cockpit systems work the way they do. Or the operational reality that other desktop applications may need to be used.

Correct, but real life aircraft do seem to follow similar conventions, improving over time. A recent aircraft, like the F-35, has a very clean cockpit with lots of HOTAS buttons. Yet, the button placement, and presumably functionality, is vaguely similar to the controls of the much, much older F-5, which itself has similar improvements and vague similarities with even older WWII aircraft, like the P-51 Mustang... and so forth. This evolution of vehicle and tool controls is due to three things. * All tools, vehicles, weapons, etc, basically need to be moved some place, then made to do something, then to repeat. * Some tools, vehicles, weapons, etc, move one tool, then move another tool with greater precision. * Design techniques, ergonomics, CAD software, and the like, have been steadily improving for decades. What I am trying to do here is carefully plan out a system which can consistently work the same way, yet support as many features as possible.

Although I am accustomed to the updater running automatically, it seems, it has not been since upgrading to 2.x. So, the updater is now part of my manual launch sequence. Problem solved.

Putting in a feature request, because these really are more than a minor annoyances. For VR users, these issues significantly impede training, profile development and communication. Actually taking the headset off frequently can cause even more eyestrain, dirty the lenses, making the already barely adequate experience even more difficult. This is how it should work. 1 SteamVR Home / Oculus Home 2 OVRDrop / Oculus Dash 3 Web Browser, PDF Viewer - Chuck's Guides 4 Launch Thrustmaster TARGET, VoiceAttack, Discord, TeamSpeak, etc. 5 DCS - VR 6 Alt+Tab 7 Move DCS Window to bottom corner, mostly off-screen, but clickable to resume focus. 8 Maximize Web Browser, PDF Viewer. Remap Thrustmaster profile bindings. Edit VoiceAttack profiles. See who is speaking on Discord, TeamSpeak, etc. Here are the problems. * DCS desktop mirror is forcibly placed at the center of the screen, always on top when focused. Displaying PDF Guides, or voice comms software on a monitor, is at best less efficient and more complex. * Within VR, projecting an existing monitor onto a virtual 2D surface, using OVRDrop, or Oculus Dash, is the most efficient way to multitask, and this is not really going to change. After all, we still use command-line interfaces today. * OVRDrop would require a second monitor to project, and a combination of VoiceAttack commands to show/hide/switch applicatons/monitors. Such a workaround would be complex and relatively slow. * Oculus Dash overlays cannot be moved, without hiding the DCS VR interface. Placing the overlays away from important cockpit controls, is an iterative process at best. Worse, unlike OVRDrop, Oculus Dash does not use absolute positioning, meaning that every time something is restarted, the displays must be repositioned. There is only one usable workaround I have found. * Ten-page multiple kneeboard chapters. * VoiceAttack "kneeboard 10 forward" command and similar. * Landscape kneeboard. * Communications apps - tear off as a separate Oculus Dash overlay (where it is displayed on a virtual monitor). Keep small, use only if needed. Before settling on this workaround, I had gone through such extremes as running DCS World through ReVive, to force it to use SteamVR with an Oculus, allowing OVRDrop to be used. Whereas, with Elite Dangerous, a functionally similar game, the ideal workflow just works. Especially if installed/launched from Oculus Home, in which case the Oculus Dash interface is always transparent. To be clear here, the VR experience is usable as is, and much appreciated. Likewise, it is understandable that Eagle Dynamics has other priorities (speaking of, FA-18 much appreciated also). For me personally, customizing the kneeboard is now mostly sufficient. But that, and related problems, did incur quite a bit of extra work. Just making the desktop mirror an ordinary window would significantly reduce the barrier to entry for VR. For Oculus uses specifically, 'supporting' the Oculus Dash interface, allowing it to become transparent, would ease cockpit placement.

Emphasizes logical grouping of types of commands, with plenty of carefully reserved space to integrate future functions. As an example, every targeting, caging, or sensors function, is always bound to the same throttle hat, on various layers. Goal is to maximize HOTAS use, while minimizing muscle memory retraining between diverse vehicles. Currently DCS F-5E is supported. Working on the FA-18 next. Elite Dangerous, Descent Freespace, Eve Valkyrie, and others are also supported. While these are obviously not true flight sim applications, the first principle requirements addressed by their user interfaces can be a model for future design. For Elite Dangerous in particular, every control binding has been comfortably mapped, meaning typing system names, CMDR names, and text chat, are the only reasons to take hands off the HOTAS. Profiles are given for a T16000M HOTAS, however, the concept should extend well to other controls. Logical grouping does result in more comfortable operation with controls that differ significantly from the original vehicle. Particularly, this principle is demonstrated for the T16000M stick itself, lacking in hat switches. https://github.com/mirage335/t16fcs/blob/master/_ref/convention.pdf https://github.com/mirage335/t16fcs/blob/master/Profiles/DCS_F5E.pdf https://github.com/mirage335/t16fcs/tree/master/Profiles Still under heavy development.

2.5.2.19273 Also, have tried clicking the three icons at the top.

Seeing only three servers. Running latest 2.x DCS Client. Have FCS, F-5E, and FA-18 modules. Is this normal?

Wow, just now managed to get the systray icon to show up. Seems to work. Nevermind I guess.

Kneeboard Settings are not usually taking effect. On rare occasion, the kneeboard position/size has changed, but now it is not. Have tried moving the "Saved Games/DCS" directory, toggling lite mode, relocating the KneeboardBuilder.exe application, launching in both VR and NoVR modes, system restarts, etc. System tray icon does not show up as depicted in the manual. What could I need to do to apply these settings?