Aarnoman

Correction - it appears that when in game integrated radios operate as intended. I am unsure why they do not show up in the DCS dynamic radio options menu in game options. @BIGNEWY not sure if this is due to a bug in core DCS or of the Mirage module? I can confirm the TRAP-136 + TRAP-137B operate as intended with Radio one PTT operating either radio depending whether green or red radio is selected on the left console.

Version: DCS OpenBeta 2.9.2.49940 Bug: All Mirage F1 variants currently are missing integrated radios for DCS voice chat. Although external radios can be created, these also have to be supported server side. Additionally, external radios are unable to utilize in-cockpit frequencies. Fix required: Native integration of F1 (all variants) red/green radios, as has occurred with most other DCS modules. Although DCS voice chat is still in its infancy and most users currently rely on 3rd party programs (SRS), DCS voice chat is now seeing increasing use following recent improvements with DCS 2.9. I do not consider this a wishlist post as native integration is expected for all official paid modules, as voice chat is a core DCS feature.

Consider me a blind man. Thanks for linking the initial report.

DCS 2.9.1.48335 Open Beta Setup: DCS OpenBeta (MT Version) on NVmE, i7 9700k @ 4.2GHz, 32Gb RAM, RTX 3080Ti Issue overview: All Mirage F1 models currently do not have optimised LOD models, resulting in immense resource use even when viewed at distance as the full model is rendered. This results in 12 Mirage F1s able to reduce framerate by up to 70-80% on high end systems. This is due to no LOD1/2/3 models being created for the Mirage F1 at this time. This in particular results in significant system slow downs in airports where Mirage F1's are located (in example cold war servers such as Engima's cold war) resulting in significant performance loss, particular for VR users. See video for demonstration: Note that this test uses an exaggerated LODmult value (0.02, set manually in options.lua) equating to a 50 fold change in distance for LOD switching compared to default value of 1.0. Note that the Mirage F1 only utilises one Level of LOD, with a switch quite a considerable distance by default with no intermediaries compared to other planes with more optimised LOD intermediary models. Additionally, the model is not rendered much earlier than most other in game models. I note that @Flappie has stated this is already known to Aerges, however I was unable to locate an official thread on the forums here hence the post. Performance loss demonstrated by unoptimised LOD models for Mirage F1: Note the constant performance decrease until at very far distance, where LOD models finally switch resulting in >200% increase in performance with no discernible differene in model quality due to immense distance. This second test was conducted with a LODMult value of 0.5 (more in line with typical use case).

+1

+1, same here Reverb G2. Shimmering is very bad on the upper dashhboard area on each side of the hud as shown by arrow in this photo. DLAA somewhat reduces this (at the cost of ghosting artefacts elsewhere).

Just reposting this here for @=Andre=/@f4l0 , query from Aerges developer (Mirage F1) regarding what variables would be needed to implement compressor stall into SimShaker for Aviators. Would be a very neat to see supported imo, having a blast with simshaker and the F1.

@fausete Are we any closer to this being addressed, still occurring in the current open beta version 2.9.1.48335

Bump, this is still an ongoing issue.

+1 to this request.

I have the same issues utilizing OpenXR + MT DCS OpenBeta on Reverb G2/3080Ti setup. Alt-tabbing for 10-15 seconds does appear to resolve this when it occurs.

DCS Version: DCS Open Beta 2.8.4.38947 Bug: The VR cursor (cyan cursor) rotates with aircraft roll, with rotation determined relative to horizon. This is using a clean install with no mods, Hardware setup: WMR with Reverb G2, current version of WMR + OpenXR + OpenXR Tools for WMR. Steps to reproduce (reproduces 100% of the time): 1. Launch DCS with VR enabled. 2. Load into any mission with any plane. Ensure VR cursor is visible (cyan cross to click buttons while in VR). 3. Apply roll axis input. As the plane rotates, the VR cursor will also rotate. Please see demonstration video below:

This is a very bizarre working as intended, as it only became an issue with this update. Please consider reverting to how it worked pre 2.8.2.35632, as it goes against all standards you have set for keybindings by specifically not having functions hardcoded.

@Flappie, can you confirm the bug (and the solution around it) is now tracked? The issue has arisen due to [numpad5] becoming the default VR recenter key if the "recenter VR headset" command under UI layer does not have any keybind assigned. This has been newly introduced in the recent OpenBeta. Thanks, Yoyo

If it helps I am able to use motion reprojection when using OpenXR Toolkit Companion App to force reprojection. I suspect perhaps those reporting motion reprojection is working are using the OpenXR Toolkit Companion App rather than OpenXR Tools for WMR to enable reprojection. Thanks!

Good, just made this post as a number of people on the discord have mentioned this is fixed when it is still an active bug. Thanks!

DCS Version: DCS 2.8.2.35759 Open Beta Bug: When using OpenXR with MotionReprojection enabled (set to "Always on"), DCS will freeze as soon as loaded into the main menu. This is using a clean install with no mods, Hardware setup: WMR with Reverb G2, current version of WMR + OpenXR + OpenXR Tools for WMR. OpenXR Toolkit Companion app is not enabled for this demonstration. Steps to reproduce (reproduces 100% of the time): 1. Open "OpenXR Tools for Windows Mixed Reality", ensure Motion Reprojection is set to "Always on") -> Note: When set to either "disabled" or "automatic", motion reprojection will not be enabled in DCS world. 2. Ensure DCS is launched with OpenXR is enabled ( DCS.exe launched with flags --force_enable_VR --force_OpenXR ) 3. DCS will now freeze either at main menu or while loading into any instant mission menu. This is repeatable for me, with 6 retrials having 2 x hang on menu (both occuring as run 1 and run 2), and subsequently hanging on mission load. No error message is displayed with the freeze. 4. If above steps are completed following "OpenXR Tools for Windows Mixed Reality" Motion reprojection set to "disabled" or "automatic", no freezing occurs at the main menu or during mission loading. Note as it is a spontaneous hang there does not seem to be much in the DCS log. I believe that this is already a known bug, but I believe in the discord there were mentions this was fixed. See above steps to illustrate this is still an ongoing issue in the latest version of DCS OpenBeta. dcs.log

Duplicate bug report with temporary solution - if a keyboard binding is created for UI Layer -> "recenter VR headset", it will no longer default to using [numpad 5].

Same bug reported under controls:https://forum.dcs.world/topic/318315-numpad-5-will-always-recenters-vrcamera-view-despite-not-having-this-function-bound-in-controls-menu/#comment-5142169

Yes, I have. The [numpad 5] key is only bound as UFC 5, and has been unbound from any camera view keys. It has also been unbound from any relevant bindings under UI Layer and General tab. This issue is only present when using VR, and does not lead to any camera changes in 2D. Interestingly, it recenters VR head position even when the controls menu is active (normally all inputs are captured when the control menu is active preventing transmission to in game). Edit: Additional info added to title post + workaround. It seems this is now triggered if "recenter VR" does NOT have any keyboard binding, in which case it defaults to [numpad 5]. This has been newly introduced with this hotfix.

Version: DCS 2.8.2.35759 Open Beta Bug: When [numpad 5] is pressed, VR view is recentered. This occurs despite [numpad 5] being unbound in the controls menu under General/UI layer from all camera control functions. Use case: I use the numberpad as UFC input for each number in the F/A-18C. However, since the introduction of this bug (new with DCS 2.8.2.35759 hotfix) it will recenter VR view every time numpad5 is pressed, which makes it no longer usable for this purpose. Addit to temporary workaround: - This bug is specifically triggered when "recenter VR headset" does not have an associated keyboard binding (joystick bindings are not accepted). - A temporary workaround is creating a random keyboard binding for "recenter VR headset" under UI layers. Edit: Duplicate bug posts here:

(This is a repost of my former berm/defensive emplacement posts, seeing as it is now deeply burried in the forums and was created prior to the existence of this core wishlist). Part I Wishlist: Placeable berms using spline implementation Abstract This wishlist post will be discussing placeable defensive berms ("earthen defensive walls"), using a spline-based implementation similar to that seen in TDK (terrain development kit). Such an implementation will offer numerous benefits to the DCS community - both gameplay and graphic wise, significantly enhancing the possibilities of core DCS in both free and paid missions/campaigns, of particular benefit to players of the new line-up of DCS helicopters. Notably, as a significant amount of groundwork has been laid through TDK, it would be realistically possible to port/integrate this as a native feature of the mission editor with limited amount of work needed from developers. An introduction to defensive emplacements and berms Military engineering and earthworks have been of critical importance, both historically and contemporarily, in ensuring successful military operation. From disorganised insurgent groups to well-funded armies of first world nations, the manipulation of the environment has long been a cornerstone in increasing the odds of successful defence and more effective engagement. Vietnam era base with prominent berms surrounding it, providing both cover and concealment Modern Berms in Syria “Berms” refers to an earthen wall, which creates a barrier in the terrain and acts as a defensive wall. They can act as an effective obstacle against vehicles – including many APC’s and tanks – while being easily scaled by infantry. They can be rapidly constructed, and act as effective protection for personnel, vehicles, and equipment from both direct and indirect enemy fire. Berms are found in most defensive positions in conflict zones and are often rapidly erected to allow for better control of newly gained territory. Perhaps one of the best conflicts to illustrate this is the Syrian civil war, where the following berms were placed by an advancing Syrian army in the span of a few days to hold new ground: Defensive berms constructed rapidly to hold new ground in Syria. See attached .kml google earth file for ground references of these and more. How could it be implemented? Interestingly, the ED TDK (terrain development kit) already allows for creation of berms. These currently only feature on the Syria map, and appear as follows: Berms as map objects on Syria, in the Golan Height region. The same berms, seen in game. The system used in TDK to create these berms appears to be splines. This essentially means vertices (These can be thought of as “points” or “nodes”) are created, with lines connecting each vertex sequentially. This set of vertices with lines connecting them is referred to as a spline. A shape (the final berm) is a repeating 3d object (a simple model of a straight berm defining geometry+texture) that is then repeated along the entire length of the spline, creating the continuous berm. Splines in general principle can be selected to either have straight or curved connections between vertices – in the case of TDK, it is clear splines can be curved as demonstrated by the existing berms on Syria, which have a smooth, curved appearance. For a demonstration of splines as they typically appear in video game level editors, see this video here: (https://youtu.be/hbMikfPf16Q?t=139). The purpose of this explanation is to outline that the technology to create splines is already a native feature of the Edge engine – however, it is currently only available in the TDK and not the mission editor. Therefore there is potential to port this feature to the mission editor, as no changes to the map geometry need to be made for inclusion of spline-based berms: they are additive in nature, as opposed to a trench which would have to remove part of the map geometry. The berms would therefore act in much the same way as normal placeable static object such as buildings or units in terms of game logic. Expected implementation in DCS: My wishlist request is to make such a tool available in the DCS mission editor, where the mission creator can place berms by setting multiple vertices, with berms created in the lines connecting these vertices – “splines”. This would maximise utility, as the overall shape of the berms can then be dictated by the mission creator, instead of being limited to several fixed presets as would be the case with a placeable static model. It would be expected for these placable berms to have a functioning collision model, thereby protecting from weapon impact. The implementation of such a feature using splines would have another advantage. This system would be extendable to placing any other continuous object so long as 3d models were created for them. Practical examples would include walls and HESCO barriers, both which would immensely to extend the ability for mission editors to alter the natural environment to suit gameplay and mission purposes. This is therefore an effective future-proof system, with significant potential for iteration and expansion. Expected workflow would be as follows: · User clicks to create a sequential line of vertices (points), with lines connecting each vertex in a sequential order. This creates the spline. · On the right-hand side, the user would select the shape (3d object) that will be repeated along the length of the spline. This shape would define the geometry and texture of the object, for example dirt/wall/HESCO/etc. Multiple presets may exist, such as “Dirt sandy”, “Dirt brown”, etc to allow for a better fit with the environment/map. · An optional checkbox would define whether the lines connecting the vertices are straight between points, or curved. Note the orange points (user clicks create these), with yellow lines connecting the points to form a spline. On the right, the type of berm (“Dirt Sandy”, “Dirt Caucasus”, etc) can be selected. What would it add to DCS? · Gameplay · Berms to act as identifiable ground markings. This may be used for the purpose of delineating frontlines or general area of operations, act as landmarks, or add to the ambience of mission design. In structured sets of missions such as campaigns, new berms may be created to clearly portray changes to the ground conflict, such as advances made or areas of static fighting (increasingly built-up defensive emplacements on either side over the span of multiple missions). · Berms provide some limited protection from both direct and indirect weapons. For example, it may prevent the use of guided missiles or rockets from low altitude, as they may hit the dirt wall as opposed to the enemy behind it. It also provides some extra incentive to use features such as the JDAM terminal attack heading to increase the likelihood of a successful attack. Note that if berms are created with limited space beside the vehicle (example image), it may even protect from near misses by absorbing most of the blast. This may be used to create an interesting tactical challenge for the player. The request for close vehicle berms as static placeable can be found in part two of this wishlist request, linked at the end. · It will add significantly to helicopter gameplay, including the newly released Mi-24 and future AH-64D Apache and Oh-58 Kiowa, by creating a more interesting ground environment to fight in and against. · Creates a more interesting environment, with many tactical considerations, for combined arms players. · Realism · Berms add to the authenticity of the ground environment, adding variety by allowing mission editors to alter the environment in meaningful ways. · In real life, berms are heavily used in nearly all defensive positions of semi-permanent or permanent nature and may be quickly erected to hold gained ground. This is due to their inherent ease of use, speed of setup, and reasonable degree of protection and concealment offered. · Bases, i.e. FOBs used for helicopter operations, would look much more lifelike by adding berms as a defensive perimeter. Concluding remarks: The ability to place berms using splines in the mission editor would significantly enhance the capabilities of creating a more lifelike ground environment: · Both immense graphical and gameplay benefits, as outlined previously. · Adds to the toolkit of mission and campaign developers, allowing for a clearer communication of the ground war environment and frontline advances/losses. · Furthermore, if such a system was implemented using splines as opposed to static placeable models, it could easily be extended to placing HESCO barriers, walls, fences, etc with minimal work from the ED team, thereby futureproofing the system. Many thanks ED for the previous additions to the mission editor; I hope this wishlist item is too seriously considered and discussed as it would allow immense capability with limited work (as much of the foundation has been laid in the implementation within TDK). I hope the primary developer(s) for the mission editor and terrain development kit both see this post, as they would be most knowledgeable on how such a feature could be ported/implemented. I would consider this a medium to high priority addition, as implementation would likely be minimally to moderately resource intensive, with most of the pre-existing groundwork laid in TDK. This is weighed against the significant expansion of capabilities of mission designers in creating a more immersive ground environment. This is particularly important now given the release of the Hind, and the soon upcoming flagship Apache and Kiowa module – all which would benefit immensely from such an enhancement. Moreover, as DCS core addition all other users engaging in A2G warfare would also reap a significant upgrade in terms of both visual and gameplay fidelity. This implementation is designed in conjunction with a part 2 wishlist for placeable static vehicle defensive emplacements, which are a separate thread for clarity and convenience. Part 2: Placeable static vehicle defensive position models As was discussed prior, berms and defensive entrenchments are crucial in modern ground warfare, allowing for the creation of effective cover and concealment in a short time span. Currently, we lack the ability to place defensive positions in DCS without resorting to mods, as no static models are included in the current version. This wishlist item is for the inclusion of a variety of static models of vehicle defensive emplacements. This is distinct from the berms in Part I of the wishlist post, as these vehicle emplacements would be static models analogous to other static objects currently available in DCS. Note the long berms almost surrounding the defensive positions, while the vehicle defensive emplacements are small - only protecting individual vehicles. These are shown in blue. Defensive vehicle berm surrounding Israeli artillery. A destroyed Iraqi tank sitting in a defensive emplacement. Defensive vehicle emplacements in Syria, protecting an MLRS site. Expected implementation in DCS: I would like to see a set of static objects acting as emplacements. These would have a collision mesh, thereby allowing for units within the emplacement to have some additional protection from incoming rounds. By being static objects, mission editors would be able to freely place these anywhere on the map. We already have several defensive emplacements as static map objects in the Syria map. I would expect to see several variations of these in terms of construction material and size, but as freely placeable static objects. An excellent example of how this should be implemented is seen in the model available in the Frenchpack mod: In mission editor In game demonstration of the frenchpack placable defensive emplacement. Note the effective protection offers to the front and sides from both air and ground level attacks, while still allowing the vehicle to engage targets effectively. A set of vehicle defensive emplacements on Syria. Note the variations in size. I would like to see other such variations as placeable static objects. What would it add to DCS? Gameplay and visual benefits would be similar to placeable berms, providing effective cover and concealment for ground units allowing for a significant tactical challenge. This would benefit all aircraft with A2G capability by creating more interesting and immersive mission considerations, while adding to the visual fidelity of the ground war. This would particularly benefit the new set of flagship ED modules, including the Mi-24 Hind, AH-64D Apache, and PC’s OH-58 Kiowa. For a full breakdown of benefits, please see the section covering gameplay and realism benefits in Part I of this wishlist, discussing berms. Concluding remarks: Like with defensive berms discussed in Part I, defensive vehicle emplacements offer mission editors a significant upgrade in crafting convincing defensive positions. Furthermore, it offers a significant gameplay addition by creating a more challenging environment to fight in, offering ground vehicles some protection from both ground and air engagements. The upcoming set of flagship ED modules, including the Mi-24 Hind, AH-64D Apache, and PC’s OH-58 Kiowa would all immensely benefit from this by allowing mission editors to create significantly more believable and immersive ground environment. I would consider this a high priority feature, as it will add significantly to the detail possible for the ground combat environment, while requiring very little work from ED – the models needed for such defensive positions are simple, as most are quite literally just small mounds of dirt. This negates much of the need of creating exact-to-specification models as would be required for vehicles or other units, as is standard operation procedure for ED per their recent whitepaper on the unit model creation process. As such defensive emplacements can be used in any setting (WW2 to contemporary, any map – Caucasus to Syria) it is a feature with limited work required while significantly adding to the DCS core. Therefore, I hope that this is seriously considered and discussed by ED, with involvement of both primary mission editor developers and model developers.

Since using OpenXR+OpenComposit with Reverb G2 I have noticed all shorelines have very distracting horizontal artefacts (see screenshot). I have tried cleaning metashaders + fxo folders to rebuild the shader caches, but this did not resolve this bug. Has anyone found a solution for it?

Bump

Is this reported yet?